Clean Code 3판을 읽고 정리한 글입니다 Ⅷ. 경계모든 프로그램을 직접 개발하지 않음 패키지, 오픈소스, 다른 사내의 컴포넌트등 외부 코드와 우리 코드를 깔끔하게 통합하는 방법? 외부 코드 사용인터페이스 제공자와 인터페이스 사용자의 긴장 제공자 패키지 제공자, 프레임워크 제공자 적용성 최대한 넓히려 → 더 많은 환경에서 돌아가도록 사용자
Clean Code 3판을 읽고 정리한 글입니다 Ⅶ. 오류 처리클린 코드와 오류처리의 상관관계 오류의 가능성은 늘 언제나 존재 오류 정정의 책임은 프로그래머가 가지고 있음 여기저기 흩어진 오류 처리 코드 → 실제 코드 로직 파악 어렵게 만듬 오류 코드 보다 예외 사용이전 프로그래밍 언어 → Exception 제공 x 개발자들이 에러 상태나 flag
Clean Code 3판을 읽고 정리한 글입니다 Ⅵ. 객체와 자료구조Intro 변수를 비공개private로 정의하는 이유가 있다. 남들이 변수에 의존하지 않게 만들고 싶어서다. 충동이든 변덕이든, 변수 타입이나 구현을 맘대로 바꾸고 싶어서다. 그렇다면 어째서 수많은 프로그래머가 조회get 함수와 설정set 함수를 당연하게 공개public해 비공개 변수를
Clean Code 3판을 읽고 정리한 글입니다 Ⅴ.형식 맞추기(Formatting)목적코드 형식은 중요하다 너무 중요하지만 융통성 없이 맹목적으로 따르면 안된다 코드 형식은 의사소통의 일환이며 개발자의 1차적 의무 돌아가는 코드가 1차적인 의무가 아님 오늘 구현한 코드의 가독성은 앞으로의 코드 품질에 큰 영향 원래 코드는 사라져도 스타일과 규율은 사
Clean Code 3판을 읽고 정리한 글입니다 Ⅳ. 주석나쁜 코드에 주석을 달지 말아라. 새로 짜라. 브라이언 W. 커니핸 P.J 플라우거 주석 잘달린 주석 : 그 어떤 정보보다 유용 경솔하고 근거 없는 주석 : 코드 이해 어렵게 만듬 오래되고 조잡한 주석 : 거짓과 잘못된 정보를 퍼뜨려 악영향 주석은 필요악 주석은 순수하게 선하지 않다 프로그래
Clean Code 3판을 읽고 정리한 글입니다 Ⅲ. 함수함수 프로그래밍 초창기 : 시스템을 루틴과 하위 루틴으로 나눔 포트란, PL/1 시절 : 프로그램, 하위 프로그램, 함수로 나눔 현재는 함수만 살아남음 : 가장 기본적 단위 함수 잘만드는 규칙작게 만들어라 첫째도 작게. 둘째도 더 작게! 블록과 들여쓰기 if/while등에 들어가는 블록은 단
Clean Code 3판을 읽고 정리한 글입니다 Ⅱ. 의미 있는 이름이름을 잘 짖는 간단한 몇가지 규칙 의도를 분명히 밝혀라 변수명이나 메서드 명에서 정확하게 의도를 알 수 있는 이름 그릇된 정보를 피하라 그릇된 단서 : 널리 쓰이는 단어를 다른 의미로 사용, 자료구조 이름을 다른 뜻으롷 사용하는 등 역시 이름만 바꾸면 깨끗이 풀리는 문제들
Clean Code 3판을 읽고 정리한 글입니다 Ⅰ. 깨끗한 코드오프닝 사소한 곳에서 발휘하는 정직은 사소하지 않다. 신은 세세함에 깃들어 있다 SW는 80%가 유지보수 코드는 언제나 존재코드는 사라지지 않음 코드 : 요구사항 상세히 표현하는 수단 하위 어느 수준에 다르면 코드 없이 요구사항 표현이 불가능 기계가 실행할 정도의 상세하게 요구사항을
Related POSTintro 원래 잘 사용하고 있는 어플리케이션에 변경 요청 사항이 생김 addAttribute로 끝내는 건줄 알고 까봤더니 마지막 view가 “redirect”접두어로 리다이렉트 Redirect는 이전 요청이 끊어지고 새로운 GET 요청 시작 따라서 Redirect 실행 이전의 모델 데이터는 소멸하므로 모델전달은 의미가 없음 Redi