케이제이 Blog

📌 오늘 TIL 3줄 요약 SRP(단일책임원칙) : 클래스는 작아야 하고 클래스는 책임, 즉 변경할 이유가 하나여야 한다. OCP(개방폐쇄원칙) : 새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다. DIP(의존역전원칙) : 상세한 구현에 의존하는 클라이언트 클래스는 구현이 바뀌면 위험에 빠진다. 그래서 우리는 인터페이스와 추상 클래스를 사용해 구현이 미치는 영향을 격리한다. 📆 TIL (Today I Learned) 날짜 2022.03.09 📚 오늘 읽은 범위 10장. 클래스 📝 책에서 기억하고 싶은 내용 클래스는 작아야 한다! 함수는 물리적인 행 수로 크기를 측정했다..

📌 오늘 TIL 3줄 요약 테스트 코드가 지저분하면 코드를 변경하는 능력이 떨어지며 코드 구조를 개선하는 능력도 떨어진다. 테스트 코드는 최소의 표현으로 많은 것을 나타내야 한다. 테스트 함수 하나는 개념 하나만 테스트하라. 📆 TIL (Today I Learned) 날짜 2022.03.05 📚 오늘 읽은 범위 9장. 단위 테스트 📝 책에서 기억하고 싶은 내용 TDD 법칙 세 가지 실패하는 단위 테스트를 작성할 때까지 실제 코드를 작성하지 않는다. 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 현재 실패하는 테스트를 통과할 정도로만 실제 코드를 작성한다. 테스트 코드가 지저분할수록 변경하기 어려워진다. 테스트 코드가 복잡할수록 실제 코드를 짜는 시간보다 테스트 케이스를 추가..

📆 TIL (Today I Learned) 날짜 2022.03.04 📚 오늘 읽은 범위 7장. 오류 처리 📝 책에서 기억하고 싶은 내용 오류 코드보다 예외를 사용하라 : 오류가 발생하면 예외를 던지는 편이 낫다. 그러면 호출자 코드가 더 깔끔해진다. 논리가 오류 처리 코드와 뒤섞이지 않으니까. (p.131) Try-Catch-Finally 문부터 작성하라 : 어떤 면에서 try 블록은 트랜잭션과 비슷하다. try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다. 그러므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다. 그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다. (p.132) 먼..

📆 TIL (Today I Learned) 날짜 2022.03.01 📚 오늘 읽은 범위 6장. 객체와 자료 구조 📝 책에서 기억하고 싶은 내용 자료 추상화 : 변수 사이에 함수라는 계층을 넣는다고 구현이 저절로 감춰지지는 않는다. 구현을 감추려면 추상화가 필요하다! 그저 (형식 논리에 치우쳐) 조회 함수와 설정 함수로 변수를 다룬다고 클래스가 되지는 않는다. 그보다는 추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있어야 진정한 의미의 클래스다. (p.119) 자료/객체 비대칭 : 복잡한 시스템을 짜다 보면 새로운 함수가 아니라 새로운 자료 타입이 필요한 경우가 생긴다. 이때는 클래스와 객체 지향 기법이 가장 적합하다. 반면, 새로운 자료 타입이 아니라 새로운 함수가 필요한 경..

📆 TIL (Today I Learned) 날짜 2022.02.28 📚 오늘 읽은 범위 5장. 형식 맞추기 📝 책에서 기억하고 싶은 내용 형식을 맞추는 목적 : 오랜 시간이 지나 원래 코드의 흔적을 더 이상 찾아보기 어려울 정도로 코드가 바뀌어도 맨 처음 잡아놓은 구현 스타일과 가독성 수준은 유지보수 용이성과 확장성에 계속 영향을 미친다. 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. (p.96) 적절한 행 길이를 유지하라 : 500줄을 넘지 않고 대부분 200줄 정도인 파일로도 커다란 시스템을 구축할 수 있다는 사실이다. (FitNesses는 50,000줄에 육박하는 시스템이다.) 반드시 지킬 엄격한 규칙은 아니지만 바람직한 규칙으로 삼으면 좋겠다. 일반적으로 큰 파일보다 작은 파..

📆 TIL (Today I Learned) 날짜 2022.02.25 📚 오늘 읽은 범위 3장. 주석 📝 책에서 기억하고 싶은 내용 나쁜 코드에 주석을 달지 마라. 새로 짜라. (p.68) 코드는 변화하고 진화한다. 일부가 여기서 저기로 옮겨지기도 한다. 조각이 나뉘고 갈라지고 합쳐지면서 괴물로 변한다. 불행하게도 주석이 언제나 코드를 따라가지는 않는다. 아니, 따라가지 못한다. 주석이 코드에서 분리되어 점점 더 부정확한 고아로 변하는 사례가 너무도 흔하다. (p.68) 부정확한 주석은 아예 없는 주석보다 훨씬 더 나쁘다. 부정확한 주석은 독자를 현혹하고 오도한다. 부정확한 주석은 결코 이뤄지지 않을 기대를 심어준다. 더 이상 지킬 필요가 없는 규칙이나 지켜서는 안 되는 규칙을 명시한다. (p.69) 코드..

📆 TIL (Today I Learned) 날짜 2022.02.22 📚 오늘 읽은 범위 3장. 함수 📝 책에서 기억하고 싶은 내용 켄트가 코드를 보여줬을 때 나는 함수가 너무도 작아 깜짝 놀랐다. 그때까지 나는 장황하게 긴 스윙 프로그램 함수에 익숙했다. 그런데 Sparkle은 모든 함수가 2줄, 3줄, 4줄 정도였다. 각 함수가 너무도 명백했다. 각 함수가 이야기 하나를 표현했다. 각 함수가 너무도 멋지게 다음 무대를 준비했다. 바로 이것이 답이다! (p.43) 함수가 '한 가지'만 하는지 판단하는 방법이 하나 더 있다. 단순히 다른 표현이 아니라 의미 있는 이름으로 다른 함수를 추출할 수 있다면 그 함수는 여러 작업을 하는 셈이다. (p.45) 코드는 위에서 아래로 이야기처럼 읽혀야 좋다. 한 함수 ..

📆 TIL (Today I Learned) 날짜 2022.02.20 📚 오늘 읽은 범위 2장. 의미 있는 이름 📝 책에서 기억하고 싶은 내용 의도를 분명히 밝혀라. 변수나 함수 그리고 클래스 이름은 다음과 같은 굵직한 질문에 모두 답해야 한다. 변수(혹은 함수나 클래스)의 존재 이유는? 수행 기능은? 사용 방법은? 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다. (p.22) 그릇된 정보를 피하라. 프로그래머는 코드에 그릇된 단서를 남겨서는 안 된다. 그릇된 단서는 코드 의미를 흐린다. 나름대로 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용해도 안 된다. 서로 흡사한 이름을 사용하지 않도록 주의한다. 유사한 개념은 유사한 표기법을 사용한다. 이것도 정보다. 일관성이 떨어지는 표기법은 그..

📆 TIL (Today I Learned) 날짜 2022.02.19 📚 오늘 읽은 범위 추천사 ~ 1장. 깨끗한 코드 📝 책에서 기억하고 싶은 내용 추천사 심지어 자동차 업계도 대다수 활동은 제조가 아니라 유지보수다. (혹은 유지보수 회피다.) 소프트웨어는 80% 이상이 소위 "유지보수"다. 고치는 활동 말이다. 좋은 소프트웨어를 만드는 데 치중하는 전형적인 서양식 사고를 포용하는 대신, 우리는 좀 더 건축 업계의 수리공이나 자동차 업계의 수리공처럼 소프트웨어 개발자를 생각해야 한다. (p.xxiii) 불행히도 우리는 세세함에 집중하는 태도가 프로그래밍 기술에 핵심적인 주춧돌이라 여기지 않곤 한다. 코드에서는 일찌감치 손을 뗀다. 구현을 끝냈기 때문이 아니라 본질(substance)보다 모양새를 중시하는..

📆 TIL (Today I Learned) 날짜 2022.02.18 📷 책 구매 인증 나도 오늘부터 노마드 개발자 북클럽(노개북) 챌린지 시작! 회사 일이 많아 바쁘긴 하지만... 😢 스케쥴 밀리지 않게 부지런히 열심히 해봐야지! 아자아자! 챌린지 참여 및 노마드 코더에 대해 궁금하신분들께선 아래 링크 클릭! Challenges – 노마드 코더 Nomad Coders 멱살 잡고 캐리하는 챌린지? 무료로 시작하세요! nomadcoders.co