기술독서

학교에서 수업을 들으면서 과제를 하면서 코드를 짜고 하다보면한 달 정도만 지나서 다시 그 코드를 들여다보면 '도대체 내가 무슨 코드를 짰던 거지?', '나 그 때는 어떻게 짰던 거지?' 싶은 것들이 있다. 분명 내가 짠 것들인데 내가 알아보지 못하는 코드들.멘토링에서

2장 의미있는 이름 의도를 분명히 밝혀라 >"의도가 분명하게 이름을 지으라"고 말하기는 쉽다. 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 많다. 변수, 함수, 클래스 이름은 존재 이유, 수행 기능, 사용 방법 등에 모두 답할 수 있는

짧으면서도 '한 가지'만 하는 함수함수를 만드는 첫 번째 규칙은 '작게!'다!. 함수를 만드는 둘째 규칙은 '더 작게!'다. 각 함수가 이야기 하나를 표현할 수 있게 작아야 함중첩 구조가 생길만큼 함수가 커져서는 안 된다는 뜻if문/ else문/ while문 등에 들

Clean Code 4장 주석 >"코드를 깔끔하게 정리하고 표현력을 강화하는 방향으로, 그래서 애초에 주석이 필요 없는 방향으로 에너지를 쏟겠다. 우리는 주석을 가능한 줄이도록 꾸준히 노력해야 한다." 주석은 나쁜 코드를 보완하지 못한다 주석을 추가하는 일반적인 이유

프로그래머라면 형식을 깔끔하게 맞춰 코드를 짜야 한다.코드 형식은 의사소통의 일환의사소통은 전문 개발자의 일차적인 의무코드의 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미치기 때문에 코드 형식을 맞춰 가독성을 높이는 것이 중요!일반적으로 큰 파일보다

구현을 감추려면 추상화가 필요하다. 형식 논리에 치우쳐 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다.추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다.인터페이스나 조회/설정 함수만으로는 추상화가

오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.오류 코드를 사용하면 함수를 호출하는 즉시 오류를 확인해야 하기 때문에 호출자 코드가 복잡해진다. 그렇기 때문에 프로그램 논리와 오류 처리 코드가 구분되도록 예외를 던지는 것이 좋

시스템에 들어가는 모든 소프트웨어를 직접 개발하는 경우는 드물다. ... 어떤 식으로든 이 외부 코드를 우리 코드에 깔끔하게 통합해야만 한다.경계외부 프로그램을 가져와서 나의 프로그램에 통합할 때의 경계아는 코드와 모르는 코드를 분리하는 경계인터페이스 제공자 : 적

테스트 코드가 방치되어 망가지면 실제 코드도 망가진다. 테스트 코드를 깨끗하게 유지하자첫재 법칙 : 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다.둘째 법칙 : 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다셋째 법칙 :

Clean Code 10장 클래스 코드의 표현력과 그 코드로 이루어진 함수에 아무리 신경 쓸지라도 좀 더 차우너 높은 단계까지 신경 쓰지 않으면 깨끗한 코드를 얻기는 어렵다 클래스 체계 자바 표준 클래스 정의에 따른 변수 순서 정적 공개 상수 정적 비공개 변수 비공

창발성하위 체계로부터 생겨나지만, 그 하위 체계로 환원되지 않는 속성켄트 벡은 다음 규칙을 따르면 설계는 '단순하다'고 말한다우선 순위 순모든 테스트를 실행한다.중복을 없앤다.프로그래머 의도를 표현한다.클래스와 메서드 수를 최소로 줄인다.설계는 의도한 대로 돌아가는 시

명령행 인수 구문분석기 사례 연구깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다돌아가는 프로그램을 목표로 잡는 것이 아니다여기서 그치는 것이 아니라 점점 개선해 나가야 한다코드를 확장해 나가면서 코드가 더 나빠질 거라는 생각이 든 순간 저자는 기능을