본문 바로가기

개발 공부/etc29

클린코드 - 후기 클린 코드 - 후기 부록을 제외하면 드디어 클린코드를 완독했다. 한번 봐서는 아직 제대로 읽었다고 할 수는 없지만 그래도 후기를 적어보려고 한다. 좋았던 점 클린코드는 너무나도 유명해 모르는 사람이 없을 것이다. 항상 읽어야지 읽어야지 하다가 이번 기회를 통해 읽게 되었다. 책을 읽기 전에는 깨끗한 코드 에 대한 막연한 환상이 있었다. 흔히 말하는 깨끗한 코드는 무엇일까? 회사에 있는 코드를 리팩토링하려고 해도 손이 쉽게 움직여지지 않았다. 당연한 일이다. 깨끗한 코드에 대한 기준 없이 무엇을 리팩토링 할 수 있을까? 그런 점에서 클린코드는 깨끗한 코드가 무엇인지 에 대해 설명한다. 흔히들 말하는 유명한 규칙들이 몇가지 있다. 좋은 이름을 지어라. 메서드가 길다면 여러개로 나눠라. 클린 코드에서는 좋은 .. 2021. 12. 21.
클린코드 17장 - 냄새와 휴리스틱 17장 - 냄새와 휴리스틱 Refactoring 에서 마틴 파울러는 다양한 코드 냄새 를 거론한다. 아래 소개하는 목록에서 마틴이 맡은 냄새에 저자가 맡은 냄새를 추가해 정리해봤다. 1. 주석. C1: 부적절한 정보 다른 시스템에(소스 코드 관리 시스템, 버그 추적 시스템 등등) 저장할 정보는 주석으로 적절하지 못하다. 일반적으로 작성자, 최종 수정일, SPR 번호 등과 같은 메타 정보만 주석으로 넣는다. 주석은 코드와 설계에 기술적인 설명을 부연하는 수단이다. C2: 쓸모 없는 주석 오래된 주석, 엉뚱한 주석, 잘못된 주석은 더 이상 쓸모가 없다. 쓸모 없어진 주석은 재빨리 삭제하는 편이 가장 좋다. C3: 중복된 주석 코드만으로 충분한데 구구절절 설명하는 주석이 중복된 주석이다. C4: 성의 없는 주.. 2021. 12. 20.
클린코드 14장 - 점진적인 개선 14장 - 점진적인 개선 이번 장에서는 하나의 프로젝트를 점진적으로 리팩토링하며 코드를 개선해나가는 내용이 주를 이룬다. 자세한 코드는 책에서 확인하고, 결론만 정리하려고 한다. 결론. 그저 돌아가는 코드만으로는 부족하다. 돌아가는 코드가 심하게 망가지는 사례는 흔하다. 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. 나쁜 코드는 오랫동안 심각하게 개발 프로젲ㄱ트에 악영향을 미치는 요인이다 나쁜 코드는 깨끗한 코드로 개선할 수 있지만 비용이 엄청나게 많이 든다. 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다. 반면, 처음부터 코드를 깨끗하게 유지하기란 상대적으로 쉽다. 아침에 엉망으로 만든 코드를 오후에 정리하기는 어렵지 않다. 그러므로 코드는 언제나 최대한 깔끔하고.. 2021. 12. 14.
클린코드 13장 - 동시성 13장 - 동시성 객체는 처리의 추상화다. 스레드는 일정의 추상화다. -제임스 O. 코플리엔 동시성과 깔끔한 코드는 양립하기 어렵다. 스레드를 하나만 실행하는 코드는 짜기가 쉽다. 겉으로 보기에는 멀쩡하지만 깊숙한 곳에 문제가 있는 다중 스레드 코드도 짜기가 쉽다. 이런 코드는 시스템이 부하를 받기 전까지는 멀쩡하게 돌아간다. 이번 장에서는 여러 스레드를 동시에 돌리는 이유, 어려움, 깨끗한 코드를 작성하는 방법, 동시성을 테스트 하는 방법과 문제점을 설명한다. 1. 동시성이 필요한 이유. 동시성은 결합을 없애는 전략이다. 무엇 과 언제 를 분리하는 전략이다. 무엇 과 언제 를 분리하면 애플리케이션 구조와 효율이 극적으로 나아진다. 예를 들어, 매일 수많은 웹 사이트에서 정보를 가져와 요약하는 정보 수집.. 2021. 12. 8.
클린코드 12장 - 창발성 12장 - 창발성 착실하게 따르기만 하면 우수한 설계가 나오는 간단한 규칙 4가지를 소개한다. 모든 테스트를 실행한다. 중복을 없앤다. 프로그래머 의도를 표현한다. 클래스와 메서드 수를 최소로 줄인다. 위의 목록은 중요도 순이다. 1. 단순한 설계 규칙 1 : 모든 테스트를 실행하라. 설계는 의도한 대로 돌아가는 시스템을 내놓아야 한다. 문서로는 시스템을 완벽하게 설계했지만 시스템이 의도한 대로 돌아가는지 검증할 간단한 방법이 없다면 문서 작성을 위해 투자한 노력을 인정받기는 어렵다. 테스트를 철저히 거쳐 모든 테스트 케이스를 항상 통과하는 시스템은 테스트가 가능한 시스템 이다. 테스트가 가능한 시스템을 만들려고 애쓰면 설계 품질이 더불어 높아진다. 테스트 케이스를 많이 작성할수록 개발자는 DIP와 같은.. 2021. 12. 7.
클린코드 11장 - 시스템 11장 - 시스템 복잡성은 죽음이다. 개발자에게서 생기를 앗아가며, 제품을 계획하고 제작하고 테스트하기 어렵게 만든다 -레이 오지, 마이크로소프트 최고 기술 책임자 1. 도시를 세운다면. 도시를 세운다면 온갖 세세한 사항을 혼자서 직접 관리할 수 있을까? 이미 세워진 도시라고 해도 한사람의 힘으로는 무리다. 그럼에도 도시는 잘 돌아간다. 도시에는 큰 그림을 그리는 사람들도 있으며, 작은 사항에 집중하는 사람들도 있다. 소프트웨어 팀도 도시처럼 구성한다. 그런데 막상 팀이 제작하는 시스템은 비슷한 수준으로 관심사를 분리하거나 추상화를 이뤄내지 못한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 2. 시스템 제작과 시스템 사용을 분리하라. 제작 은 사용 과 아주 다르다. 소프트.. 2021. 12. 6.
클린코드 10장 - 클래스 10장 - 클래스 지금까지 코드 행과 코드 블록을 올바로 작성하는 방법에 초점을 맞췄다. 그러나 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경을 쓸지라도 좀 더 높은 단계까지 신경쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 이 장에서는 깨끗한 클래스를 다룬다. 1. 클래스 체계. 클래스를 정의하는 표준 자바 관례에서는 가장 먼저 변수가 나오고 그 다음으로 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 나온다. 추상화 단계가 순차적으로 내려가게 된다. 그래서 프로그램은 신문 기사처럼 읽힌다. 캡슐화 변수와 유틸리티 함수는 가능한 공개하지 않는 편이 낫지만 반드시 숨겨야 한다는 법칙도 없다. 때로는 protected로 선언해 테스트 코드에 접근을 허용하기도 한다. 그러나 캡슐화를 풀.. 2021. 12. 1.
클린코드 9장 - 단위 테스트 9장 - 단위 테스트 애자일과 TDD 덕분에 단위 테스트를 자동화하는 프로그래머들이 이미 많아졌으며 점점 늘어자는 추세이다. 하지만 테스트를 추가하려고 급하게 서두루는 와중에 많은 프로그래머들이 제대로 된 테스트 케이스를 작성해야 한다는 좀 더 미묘한 사실을 놓쳐버렸다. 1. TDD법칙 세 가지. 첫번째 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 두번째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 세번째 법칙 : 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 위의 세 가지 규칙을 따르면 개발과 테스트가 대략 30초 주기로 묶인다. 테스트 코드가 실제 코드보다 불과 몇 초 전에 나온다. 이렇게 일하면 매일 수십 개,.. 2021. 11. 29.
클린코드 8장 - 경계 8장 - 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 어떤 식으로든 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 1. 외부코드 사용하기. 인터페이스 제공자와 인터페이스 사용자 사이에는 특유의 긴장이 존재한다. 사용자는 자신의 요구에 집중하는 인터페이스르 바라지만 인터페이스 제공자는 적용성을 최대한 넓히려 애쓴다. 이러한 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다. 그 예로 Java에서 제공하는 Map이 있다. 프로그램에서 Map을 만들어 여기저기 넘긴다고 가정해보자. 넘기는 쪽에서는 아무도 Map의 내용을 삭제하지 않으리라 믿을지도 모르지만 Map에서는 clear()라는 메서드를 제공한다. 즉, Map을 사용하는 누구나 Map의 내용을 지울 권한이 있다는 말.. 2021. 11. 25.
클린코드 7장 - 오류 처리 7장 - 오류 처리 오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다. 뭔가 잘못될 가능성은 늘 존재한다. 뭔가 잘못되면 바로 잡을 책임은 프로그래머 에게 있다. 깨끗한 코드와 오류 처리는 연관성이 있다. 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다. 1. 오류 코드보다 예외를 사용하라. 예외를 지원하지 ㅇ낳는 언어는 오류를 처리하고 보고하는 방법이 제한적이었다. 오류 플래그를 설정하거나 호출자에게 오류 코드를 반환하는 방법이 전부였다. 이 방법들을 사용하게되면 호출자 코드가 함수를 호출한 즉시 오류를 확인해야하기 때문에 복잡해지게 된다. 때문에 오류가 발생하면 예외를 던지는 편이 낫다. 2. Try - Catch - Finally 문 부터 작성하라.. 2021. 11. 24.
클린코드 6장 - 객체와 자료구조 6장 - 객체와 자료구조 변수를 비공개(private)로 정의하는 이유는 남들이 변수에 의존하지 않게 만들고 싶기 때문이다. 하지만 왜 수많은 프로그래머들이 get 함수와 set 함수를 당연하게 공개(public)해 비공개 변수를 외부에 노출할까? 1. 자료 추상화. 다음 두 클래스는 모두 2차원 점을 표현한 클래스이다. 하나는 구현을 외부로 노출하고 다른 하나는 구현을 완전히 숨긴다. public class Point { public double x; public double y; }public interface Point { double getX(); double getY(); void setCartesian(double x, double y); }첫번째 클래스는개별절으로 좌표값을 읽고 설정하게 강제.. 2021. 11. 22.
클린코드 5장 - 형식 맞추기 5장 - 형식 맞추기 프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야한다. 코드 형식을 맞추기 위한 간단한 규칙을 정하고 그 규칙을 따라야한다. 팀으로 일한다면 팀이 합의해 규칙을 정하고 모두가 그 규칙을 따라야한다. 1. 형식을 맞추는 목적. 코드 형식은 중요하다. 코드 형식은 의사소통의 일환이다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수와 확장성에 계속 영향을 미친다. 2. 적절한 행 길이를 유지하라. 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다. 일반적으로 작은 파일이 이해하기 쉽다. 신문 기사처럼 작성하라. 신문 기사를 떠올려보자. 독자는 위에서 아래로 기사.. 2021. 11. 17.

티스토리툴바