📂 개발 서적/클린 코드

클린 코드(Clean Code) - 14장, 15장, 16장, 17장

14장. 점진적인 개선 📌 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다. 나쁜 일정은 다시 짜면 된다. 나쁜 요구사항은 다시 정의하면 된다. 나쁜 팀 역학은 복구하면 된다. 하지만 나쁜 코드는 썩어 문드러진다. 점점 무게가 늘어나 팀의 발목을 잡는다. 속도가 점점 느려지다 못해 기어가기도 한다. 너무 서두르다가 이후로 영원히 자신들의 운명을 지배할 악성 코드라는 굴레를 짊어진다. 물론 나쁜 코드도 깨끗한 코드로 개선할 수 있다. 하지만 비용이 엄청나게 많이 든다. 코드가 썩어가며 모듈은 서로서로 얽히고설켜 뒤엉키고 숨겨진 의존성이 수도 없이 생긴다. 오래된 의존성을 찾아내 깨려면 상당한 시간과 인내심이 필요하다. 반면 처음부터 코드를 깨끗하게 유지하기란 상대적으로 ..

클린 코드(Clean Code) - 13장

13장. 동시성 🚦 동시성은 결합(coupling)을 없애는 전략이다. 즉, 무엇과 언제를 분리하는 전략이다. 1. 동시성과 관련된 일반적인 미신과 오해 🚧 동시성은 항상 성능을 높여준다. 동시성은 때로 성능을 높여준다. 대기 시간이 아주 길어 여러 스레드가 프로세서를 공유할 수 있거나, 여러 프로세서가 동시에 처리할 독립적인 계산이 충분히 많은 경우메난 성능이 높아진다. 어느 쪽도 일상적으로 발생하는 상황은 아니다. 동시성은 구현해도 설계는 변하지 않는다. 단일 스레드 시스템과 다중 스레드 시스템은 설계가 판이하게 다르다. 일반적으로 무엇과 언제를 분리하면 시스템 구조가 크게 달리진다. 웹 또는 EJB 컨테이너를 사용하면 동시성을 이해할 필요가 없다. 실제로는 컨테이너가 어떻게 동작하는지, 어떻게 동시..

클린 코드(Clean Code) - 11장, 12장

11장. 시스템 📡 Main 분리 시스템 생성과 시스템 사용을 분리하는 한 가지 방법으로, 생성과 관련한 코드는 모두 main이나 main이 호출하는 모듈로 옮기고, 나머지 시스템은 모든 객체가 생성되었고 모든 의존성이 연결되었다고 가정한다. 제어 흐름을 따라가기 쉽다. main 함수에서 시스템에 필요한 객체를 생성한 후 이를 애플리케이션에 넘긴다. 애플리케이션은 그저 객체를 사용할 뿐이다. main과 애플리케이션 사이에 표시된 의존성 화살표의 방향에 주목한다. 모든 화살표가 main 쪽에서 애플리케이션 쪽을 향한다. 즉, 애플리케이션은 main이나 객체가 생성되는 과정을 전혀 모른다는 뜻이다. 단지 모든 객체가 적절히 생성되었다고 가정한다. 11장 결론 시스템 역시 깨끗해야 한다. 깨끗하지 못한 아키텍..

클린 코드(Clean Code) - 10장

10장. 클래스 🏠 지금까지 코드 행과 코드 블록을 올바로 작성하는 방법에 초점을 맞췄다. 함수를 올바로 구현하는 방법과 함수가 서로 관련을 맺는 방식도 공부했다. 하지만 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차원 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다. 이 장에서는 깨끗한 클래스를 다룬다. 클래스는 작아야 한다! 얼마나 작아야 하는가? 함수는 물리적인 행 수로 크기를 측정했다. 클래스는 맡은 책임으로 측정을 한다. 단일 책임 원칙 (Single Responsibility Priciple) SRP는 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. 이는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. public ..

클린 코드(Clean Code) - 8장, 9장

8장. 경계 💒 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고, 때로는 오픈 소스를 이용한다. 때로는 사내 다른 팀이 제공하는 컴포넌트를 사용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. 이 장에서는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴본다. Map을 (혹은 유사한 경계 인터페이스를) 여기저기 넘기지 말라. Map sensors = new HashMap(); Sensor s = (Sensor)sensors.get(sensorId); 위의 코드는 의도가 명확히 드러나지 않는 깨끗하지 않은 코드이다. 이를 개선하기 위해 제네릭스(Generics)를 사용하면 코드 가독성이 크게 높아지지만 Map가 사용자에게 필요하지 않은..

클린 코드(Clean Code) - 7장

7장. 오류 처리 🏰 무언가 잘못될 가능성은 늘 존재한다. 무언가 잘못되면 바로 잡을 책임은 바로 우리 프로그래머에게 있다. 호출자를 고려해 예외 클래스를 정의하라. // 중복이 심하여 나쁜 코드 ACMEPort port = new ACMEPort(12); try { port.open(); } catch (DeviceResponseException e) { reportPortError(e); logger.log("Device response exception", e); } catch (ATM1212UnlockedException e) { reportPortError(e); logger.log("Unlock exception", e); } catch (GMXError e) { reportPortError(..

클린 코드(Clean Code) - 4장, 5장, 6장

4장. 주석 🌿 나쁜 코드에 주석을 달지 마라. 새로 짜라. 주석은 오래될수록 코드에서 멀어진다. 주석은 오래될수록 완전히 그릇될 가능성도 커진다. 이유는 단순하다. 프로그래머들이 주석을 유지하고 보수하기란 현실적으로 불가능하니까. 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 부정확한 주석은 독자를 현혹하고 오도한다. 부정확한 주석은 결코 이뤄지지 않을 기대를 심어준다. 더 이상 지킬 필요가 없는 규칙이나 지켜서는 안 되는 규칙을 명시한다. 주석은 의미를 명료하게 밝혀야 한다. 그릇된 주석을 달아놓을 위험도 상당히 높다. 그리고 주석이 올바른지 검증하기는 쉽지 않다. 이것이 의미를 명료히 밝히는 주석이 필요한 이유인 동시에 주석이 위험한 이유이기도 하다. 그러므로 주석을 달 때는 더 나은 방법이..

클린 코드(Clean Code) - 1장, 2장, 3장

신은 세세함에 깃들어 있다. 책은 각각의 큰 주제에 대해서 17개의 장으로 구성되어 있다. 해당 글에서는 책의 모든 내용을 다루지는 않는다. 현재 나에게 필요한 내용이거나 다시 한번 상기해야 하는 점들만 다룰 것이므로 이 점에 대해서는 양해를 구한다. 1장. 깨끗한 코드 🌊 워드 커닝햄(Ward Cunningham)은 '깨끗한 코드는 읽으면서 놀랄 일이 없어야 한다'라고 말한다. 읽으면서 짐작한 대로 돌아가는 코드가 깨끗한 코드다. 각 모듈은 다음 무대를 준비하고, 모듈을 읽으면서 다음에 벌어질 상황이 보여야 한다. 2장. 의미 있는 이름 🌼 좋은 이름을 지으려면 많은 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다. 추상적인 개념 하..