주니어 개발 노트

Test Driven Development: 실제 코드 짜기 전 단위 테스트부터 짜라. 1) 실패하는 단위 테스트 작성할 때 까지 실제 코드 짜지 않는다. 2) 컴파일은 가능하지만 실행이 실패하는 정도로만 단위 테스트 작성. 3) 현재 실패하는 테스트를 통과할 정도로만 실제 코드 작성. 이 규칙을 따르면 개발과 테스트가 대략 3초 주기로 묶인다. 테스트 코드와 실제 코드가 함께 나온다. 깨끗한 테스트 코드 유지: 테스트 코드가 지저분할수록 코드를 변경하기 어려워진다. 테스트는 유연성, 유지보수성, 재사용성을 제공. 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 테스트 코드에서 가장 중요한 것은 가독성. Build-Operate-Check패턴. 첫 번째 부분은 테스트 자료를 만들고, 두 번째 부분은..

예외를 사용하라! 개념을 뒤섞지 말고, 원하는 로직을 처리하는 알고리즘과 오류를 처리하는 알고리즘 분리 try-catch-finally 잘 활용하기. try에서 무슨 일이 생기든 catch블록이 프로그램 상태를 일관성있게 유지. 호출자가 기대하는 상태 정의하기 쉬워진다. 먼저 강제로 예외를 일으키는 테스트 케이스를 작성하고, 테스트를 통과하도록 코드를 작성하라. 확인된 예외는 메서드의 일부기 때문에 메서드 사용할 때 선언된 것과 일치하지 않으면 오류 발생. OCP(Open Closed Principle) 위배. 하위 단계 코드 변경시 상위 단계 선언부도 전부 고쳐야(catch에서 새로운 예외 처리, throw 절 추가 등 연쇄적 수정. 모든 함수가 최하위 함수에서 던지는 예외를 알아야하므로 캡슐화 깨짐)..

😃 책에서 기억하고 싶은 내용을 써보세요. 보통 변수를 비공개로 정의하고, get() 과 set()을 공개 함수로 설정해 비공개 변수를 외부에 노출한다. 구현을 외부로 노출하는 셈. 변수 사이에 함수라는 계층을 넣는다고 구현이 감추어지는 게 아니라 추상화가 필요하다. 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스 객체는 추상화 뒤로 자료를 숨긴 채 자료를 다루는 함수만 공개한다. 자료구조는 자료를 그대로 공개하며 별다른 함수는 제공하지 않는다 절차적 방식 예시: 각 도형 클래스는 간단한 자료구조이고, 도형이 동작하는 방식은 Geometry class에서 구현한다. (class Square, class Rectangle, class Circle, c..

😃 책에서 기억하고 싶은 내용을 써보세요. 코드가 깔끔하고, 일관적이며 꼼꼼해야 함 -> 형식을 깔끔하게 맞추는 것이 중요. 귯칙을 따라야 한다. 규칙을 자동으로 적용하는 도구를 활용하라 코드 형식은 의사소통의 일환으로, 매우 중요하다. 오늘 구현한 코드의 가독성은 앞으로 바뀔 코드의 품질에 지대한 영향을 미친다. 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 세로 적절한 행 길이: 평균 파일 크기는 약 65줄이다. 대략 1/3의 파일이 40-100줄 사이이고 가장 긴 파일은 약 400줄, 가장 짧은 파일은 6줄. 신문 기사처럼 작성하기. 최상단에 몇 마디로 요약하는 표제, 첫 문단이 전체 내용을 요약, 쭉 읽으며 내려가면 세세한 사실 묘사. 즉 소스 파일..

😃 책에서 기억하고 싶은 내용을 써보세요. 잘 달린 주석은 그 어떤 정보보다 유용하다. 경솔하고 근거 없는 주석은 코드를 이해하기 어렵게 만든다. 오래되고 조잡한 주석은 거짓과 잘못된 정보를 퍼뜨려 해악을 미친다. 우리는 코드로 의도를 표현하지 못해, 그러니 실패를 만회하기 위해 주석을 사용한다.(?) 프로그래머들이 주석을 유지, 보수하기란 현실적으로 불가능하다.(?) 주석은 나쁜 코드를 보완하지 못한다. 주석 말고 코드로 의도를 표현하라. 좋은 주석은? copyright 정보를 제공하는 주석(내 생각에는 코드를 읽어서 이해할 수 있다면 이런 주석은 필요 없을 듯 하다.) 의도를 설명하는 주석(역시 내 기준에는 코드를 읽으면 쓴 사람의 의도를 이해할 수 있어야 하고 따라서 이것 역시 불필요한 주석이라 생..

😃 책에서 기억하고 싶은 내용을 써보세요. 함수를 만드는 첫째 규칙은 '작게'. 둘째 규칙은 '더 작게' if/else while 문에 들어가는 블록은 한 줄이어야 한다. 중첩 구조가 생길만큼 함수가 커져서는 안된다. 들여쓰기 수준이 1단 2단을 넘으면 안된다. 한 가지만 해라! 함수는 한 가지를 해야 한다. 그 한 가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 의미있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. 함수당 추상화 수준은 하나로! 함수가 확실히 한 가지 작업만 하려면 함수 내 모든 문장의 추상화 수준이 동일해야 한다. getHtml()은 추상화 수준이 아주 높고, render()은 추상화 수준이 중간이고, append()는 추상화 수준이 아주 낮다. 한..

😃 책에서 기억하고 싶은 내용을 써보세요. 의도를 분명하게 밝히는 이름 유사한 표기법 사용하기. 일관성 중요함 의미 있게 구분하라! customerInfo customer getActiveAccount() getActiveAccountData() 발음하기 쉽고 검색하기 쉬운 이름 쓰기 클래스 이름은 명사형, 메서드 이름은 동사형! 한 개념에 한 단어 사용하기 fetch, retrieve, get controller, manager, driver 그래도 add, insert, append 같은 것은 구분해주는것이 좋다. 의미 있는 맥락 추가하기. street, houseNumber, city, state, zipcode state는 너무 general하므로 addrState 🤔 오늘 읽은 소감은? 떠오르는..

😃 책에서 기억하고 싶은 내용을 써보세요. 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄어야 유지보수가 쉬워진다. 있다면 명확히 정의한다. 성능을 최적으로 유지해야 원칙없는 최적화로 코드를 망치지 않는다. 깨끗한 코드는 한가지를 제대로 한다. 단순하고 직접적이다. 깨끗한 코드는 잘 쓴 문장처럼 설계자의 의도를 숨기지 않고, 명쾌한 추상화와 단순한 제어문으로 이루어짐. 간과하기 쉬운 것: 오류 처리**, 메모리 누수, 경쟁상태, 일관성 없는 명명법 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다. 유닛테스트와 인수 테스트(Acceptance test) 작성. Test driven development 중복을 줄여라! 중복과 표현력 신경 쓰면 굿. 객체가 여러 기능을 수행한다면 여러 객체로 나눈다..