코징의 개발탐방

현재 클린코드 11장까지 정리 완료하였습니다. 하지만 최근까지 Flutter 위주의 공부와 실무 적용으로 Spring의 언노테이선의 기능들을 확실히 알지 못한 상태에서 단편적으로 이해하고 넘어가는 느낌을 강하게 받았습니다. 12장 그 이후부터는 Spring의 언노테이션과 각각의 기능들이 자바 기반으로 나와있는데, 이를 좀 더 정확히 알고 전달해 드리고자 Spring 언어를 공부한 후 12장 부터 다시 진행하려고 합니다. 현재 인프런을 통해 인강을 듣고 직접 코딩을 작성하고 있으며, 이것 또한 블로그에 올리고 완료되는 즉시 12장 부터 다시 진행하도록 하겠습니다. 감사합니다.

*확장 '처음부터 올바르게' 시스템을 만들 수 있다는 믿음은 미신이다. 깨끗한 코드는 코드 수준에서 시스템을 조정하고 확장하기 쉽게 만든다. 소프트웨어 시스템은 물리적인 시스템과 다르다. 관심사를 적절히 분리해 관리한다면 소프트웨어 아키텍처는 점진적으로 발전할 수 있다. *횡단의 관심사 원론적으로 모듈화 되고 캡슐화된 방식으로 영속성 방식을 구상할 수 있다. 하지만 현실적으로는 영속성 방식을 구현한 코드가 온갖 객체로 흩어진다. 여기서 횡단의 관심사라는 용어가 나온다. 사실 EJB 아키텍처가 영속성, 보안, 트랜잭션을 처리하는 방식은 관점 지향 프로그래밍 AOP(Aspect-Oriented Programming)을 예견했다고 보인다. AOP에서 관점(Aspect)이라는 모듈 구성 개념은 "특정 관심사를 ..

*도시가 잘 돌아가는 이유 수도권 관리팀, 전력 관리팀, 교통 관리 팀, 치안 관리 팀, 건축물 관리 팀 등 각 분야를 관리하는 팀이 있다. 적절한 추상화와 모듈 때문이다. 그래서 큰 그림을 이해하지 못할지라도 개인과 개인이 관리하는 '구성요소'는 효율적으로 돌아간다. 흔히 소프트웨어 팀도 도시처럼 구성한다. 깨끗한 코드를 구현하면 낮은 추상화 수준에서 관심사를 분리하기 쉬워진다. 높은 추상화 수준, 즉 시스템 수준에서도 깨끗함을 유지하는 방법을 살펴본다. *시스템 제작과 시스템 사용을 분리하라 제작은 사용과 아주 다르다 소프트웨어 시스템은 (애플리케이션 객체를 제작하고 의존성을 서로 '연결' 하는) 준비 과정과 (준비 과정 이후에 이어지는) 런타임 로직을 불리해야 한다. 대다수의 애플리케이션은 시작 단..

책 내용 - 클래스 *클래스 체계 클래스를 정의하는 표준 자바의 관례 변수 목록이 나온다. 정적 static, 공개 public 상수가 있다면 맨 처음 나온다. 정적 static, 비공개 private 변수가 나온다. 비공개 인스턴스 변수가 나온다. 공개 함수가 나온다. 비공개 함수는 자신을 호출하는 공개 함수 직후에 넣는다. 즉, 추상화 단계가 순차적으로 내려간다. 그래서 프로그램은 신문 기사처럼 읽힌다. 여기서 정적 변수와 인스턴스 변수라는 말에서 어떤 부분을 말하는지 잘 와닿지 않았다. 정적 변수 static 클래스 내에 satitc 키워드로 선언된 변수 static영역에 생성되면서, 모든 객체의 공유가 가능해진다. 처음 JVM이 실행되어 클래스가 메모리에 할당될 때부터 프로그램이 종료될 때까지 메..

책 내용 - 경계 시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. 때로는 패키지를 사고, 때로는 오픈 소스를 이용한다. 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다. *외부 코드 사용하기 패키지 제공자나 프레임워크 제공자는 적용성을 최대한 넓히려 애쓴다. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하니까. 반면 사용자는 자신의 요구에 집중하는 인터페이스를 바란다. 이런 긴장으로 인해 시스템 경계에서 문제가 생길 소지가 많다. 아래 java.util.Map을 살펴보자. Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다. Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다. Map을 만들어 여기저기 넘긴다고 가정하자. 넘기는 쪽에서는..

책 내용 - 오류 처리 깨끗한 코드와 오류 처리는 확실히 연관성이 있다. 상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다. 여기저기 흩어진 오류 처리 코드 때문에 실제 코드가 하는 일을 파악하기가 거의 불가능하다는 의미다. 깨끗하고 튼튼한 코드에 한걸음 더 다가가는 단계로 우아하고 고상하게 오류를 처리하는 기법과 고려 사항 몇 가지를 소개한다. *오류 코드보다 예외를 사용하라 public class DeviceController { ... public void sendShutDown() { DeviceHandle handle = getHandle(DEV1); // 디바이스 상태를 점검한다. if (handle != DeviceHandle.INVALID) { // 레코드 필드에 디바이스 상태를 저장..

책 내용 - 객체와 자료구조 변수를 비공개 Private로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 그렇다면 어째수 수많은 프로그래머가 조회 함수 get와 설정 set 함수를 당연하게 공개해 비공개 변수를 외부에 노출할까? *자료 추상화 //목록6-1 구체적인 Point 클래스 public class point { public double x; public double y; } //목록6-2 추상적인 Point 클래스 public interface point { double getX(); double getY(); void setCartesian(double x, doube y); double getR(); double getTheta(); void setPolar(doubl..

코드 형식은 중요하다.! 너무 중요해서 무시하기 어렵다. 너무나도 중요하므로 융통성 없이 맹족적으로 따르면 안 된다. 코드 형식은 의사소통의 일환이다. 오늘 구현한 기능이 다음 버전에서 바뀔 확률은 아주 높다. 그런데 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가동성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 그렇다면 원활한 소통을 장려하는 코드 형식은 무엇일까? *적절한 행 길이를 유지하라.! Junit, FitNesse, Time and Money는 상대적으로 파일 크기가 작다. 500줄 넘어가는 파일이 없으며 대다수가 200줄 미만이다..

책의 내용 - 주석 나쁜 코드에 주석을 달지 마라. 새로 짜라 - 브라이언 w. 커니핸, P.J 플라우거 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 사실상 주석은 기껏해야 필요악이다. 내가 이렇듯 주석을 무시하는 이유가 무엇이냐고? 거짓말을 하니까. 항상도 아니고 고의도 아니지만 너무 자주 거짓 말을 하니까. *주석은 나쁜 코드를 보완하지 못한다. 코드에 주석을 추가하는 일반적인 이유는 코드 품질이 나쁘기 때문이다. 모듈을 짜고 보니 짜임새가 엉망이고 알아먹기 어렵다. 지저분한 모듈이라는 사실을 자각한다. 그래서 자신에게 이렇게 말한다. "이런! 주석을 달아야겠다!" *코드로 의도를 표현하라! 확실히 코드만으로 의도를 설명하기 어려운 경우가 존..

책의 내용 - 함수 *작게 만들어라! 명백한 함수는 2줄 ~ 4줄이 적당하다. 각 함수가 명백하게 하나를 표현한다면 너무나도 멋진 다음 무대를 준비했다. - 블록과 들여쓰기 if문/ else 문 / while 문 등에 들어가는 블록은 한 줄이어야 한다는 의미다. 대개 거기서 함수를 호출한다. *한 가지만 해라 함수는 한 가지를 해야 한다. 그 한가지를 잘해야 한다. 그 한 가지만을 해야 한다. 아래와 같은 코드가 있다고 해보자. public static String renderPageWithWetupsAndTeardonws( PageData pageData, boolean isSuite ) throws Exception { boolean isTestPage = pageData.hasAttribute("T..