클린코드10 [클린코드] 1장~10장 복기 📌 기간: 2024.03.01 ~ 2024.03.18 📌 범위: 1장 깨끗한 코드 ~ 10장 클래스 (8장 경계 제외) 📌 좋았던 점: 약 3주에 걸쳐서 책의 절반 정도를 읽었다. 그 시간 동안 코드를 짜는 내 모습에 변화가 생겼다. 이전에는 얼른 코드를 짜서 결과물을 실행시키기에 바빴다면, 지금은 어떻게 하면 더 잘 읽히는 코드를 짤 수 있을까 고민하면서 개발을 하고 있다. 이전보다 코드를 좀 더 소중하게 다루는 느낌이다. 개발 서적은 항상 사놓고 책장에 넣어두는게 일상이었는데, 이번 개발자 북클럽을 통해서 하루에 한 챕터씩 읽는 습관을 들였다. 사실 한 번에 책 한 권을 완주하려고 하니까 부담이 되어서 시작도 하지 않았던 것도 있다. 하지만 이번에는 하루에 한 챕터씩만 읽었더니 부담도 없었고, 그 덕.. 2024. 3. 21. [클린코드] 10장 클래스 클래스가 응집력을 잃는다면 쪼개라! ✏️ 기억하고 싶은 내용클래스 설명은 만일("if"), 그리고("and"), -(하)며("or"), 하지만("but")을 사용하지 않고서 25단어 내외로 가능해야 한다.단일 책임 원칙(SRP, Single Responsibility Principle)은 클래스나 모듈을 변경할 이유가 하나, 단 하나뿐이어야 한다는 원칙이다. SRP는 '책임'이라는 개념을 정의하며 적절한 클래스 크기를 제시한다. 클래스는 책임, 즉 변경할 이유가 하나여야 한다는 의미다.새 기능을 수정하거나 기존 기능을 변경할 때 건드릴 코드가 최소인 시스템 구조가 바람직하다. 이상적인 시스템이라면 새 기능을 추가할 때 시스템을 확장할 뿐 기존 코드를 변경하지는 않는다.결합도가 낮다는 소리는 각 시스템 요.. 2024. 3. 18. [클린코드] 9장 단위 테스트 테스트 커버리지가 높을수록 공포는 줄어든다. Fast.Independent.Repeatable.Self-Validating.Timely ✏️ 기억하고 싶은 내용 테스트 코드는 실제 코드 못지 않게 중요하다. 실제 코드 못지 않게 깨끗하게 짜야 한다. 코드에 유연성, 유지보수성, 재사용성을 제공하는 버팀목이 바로 단위테스트다. 이유는 단순하다. 테스트 케이스가 있으면 변경이 두렵지 않으니까! 테스트 케이스가 없다면 모든 변경이 잠정적인 버그다. 아키텍처가 아무리 유연하더라고, 설계를 아무리 잘 나눴더라도, 테스트 케이스가 없으면 개발자는 변경을 주저한다. 버그가 숨어들까 두렵기 때문이다. 가독성, 가독성, 가독성. 💡 떠오르는 생각 테스트 케이스는 내가 구현을 잘 했는지 검증하는 용도라고 1차원적으로 생각.. 2024. 3. 14. [클린코드] 7장 오류 처리 애플리케이션 저 아래서 날린 NullPointer Exception을 도대체 어떻게 처리하란 말인가? ✏️ 기억하고 싶은 내용 Try-Catch-Finally 문부터 작성하라 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다. 정상적인 인수로 null을 기대하는 API가 아니라면 에서드로 null을 전달하는 코드는 최대한 피한다. 💡 떠오르는 생각 null을 반환하지 마라 로그에 줄줄이 찍히던 null을 보고 결국은 코드를 전부 뜯어서 원인을 파악했던 경우가 종종 있었다. 단순히 null을 무시하기 위해서 NullPointer Exception을 쓰는 것이.. 2024. 3. 12. [클린코드] 6장 객체와 자료 구조 객체라면 뭔가를 하라고 말해야지 속을 드러내라고 말하면 안 된다. ✏️ 기억하고 싶은 내용 객체는 동작을 공개하고 자료를 숨긴다. 그래서 기존 동작을 변경하지 않으면서 새 객체 타입을 추가하기는 쉬운 반면, 기존 객체에 새 동작을 추가하기는 어렵다. 자료 구조는 별다른 동작 없이 자료를 노출한다. ( -> 예시로 DTO가 있다.) 그래서 기존 자료 구조에 새 동작을 추가하기는 쉬우나, 기존 함수에 새 자료 구조를 추가하기는 어렵다. 📌 새로운 개념 디미터 법칙(Law of Demeter): 잘 알려진 휴리스틱으로, 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다. 2024. 3. 10. [클린코드] 5장 형식 맞추기 원래 코드는 사라질지라도 개발자의 스타일과 규율은 사라지지 않는다. ✏️ 기억하고 싶은 내용 신문이 사실, 날짜, 이름 등을 무작위로 뒤섞은 긴 기사 하나만 싣는다면 아무도 읽지 않으리라. 프로그래머라면 각자 선호하는 규칙이 있다. 하지만 팀에 속한다면 자신이 선호해야 할 규칙은 바로 팀 규칙이다. 팀은 한 가지 규칙에 합의해야 한다. 그리고 모든 팀원은 그 규칙을 따라야 한다. 그래야 소프트웨어가 일관적인 스타일을 보인다. 한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 줘야 한다. 💡 떠오르는 생각 if else 문 안에 들어가는 내용이 한 줄이라면, 나는 아래처럼 줄바꿈을 하지않았다. 이유는 필요 이상의 공백이 생긴다고 생각했기 때문이다. 하지만 다른 if else 문.. 2024. 3. 9. [클린코드] 샘플코드 JS로 보기 '클린코드'는 Java를 기반으로 샘플 코드와 개념이 작성되었다. '클린코드'를 JavaScript에 적용시킨 내용은 아래 깃허브 리파지토리에서 확인 가능하다: 영어: https://github.com/ryanmcdermott/clean-code-javascript 한국어: https://github.com/qkraudghgh/clean-code-javascript-ko 2024. 3. 8. [클린코드] 4장 주석 진실은 한곳에만 존재한다. 바로 코드다. 코드만이 자기가 하는 일을 진실되게 말한다. 코드만이 정확한 정보를 제공하는 유일한 출처다. ✏️ 기억하고 싶은 내용 나쁜 코드에 주석을 달지 마라. 새로 짜라. 함수나 변수로 표현할 수 있다면 주석을 달지 마라. 주석으로 처리된 코드는 다른 사람들이 지우기를 주저한다. 이유가 있어 남겨놓았으리라고. 중요하니까 지우면 안 된다고 생각한다. 그래서 질 나쁜 와인병 바닥에 앙금이 쌓이듯 쓸모 없는 코드가 점차 쌓여간다. 💡 떠오르는 생각 의무감으로 주석을 달았던 적도 있고, 코드를 보고 바로 이해가 되지 않아서 주석을 남겨 놓은 적도 있다. 이 코드가 언제 다시 쓰일지 몰라서 일단 주석 처리해놓은 적도 있다. 이 모든 것들이 책에서 언급이 되었다. 주석처리가 된 코드.. 2024. 3. 6. [클린코드] 3장 함수 그런데 Sparkle은 모든 함수가 2줄, 3줄, 4줄 정도였다. 각 함수가 너무도 명백했다. ✏️ 기억하고 싶은 내용 80년대에는 함수가 한 화면을 넘어가면 안 된다고 말했다. 당시 VT100 화면은 가로 80자 세로 24줄이었고 우리 편집기는 4줄을 관리용으로 사용했다. 함수는 한 가지를 해야 한다. 그 한가지를 잘 해야 한다. 그 한 가지만을 해야 한다. 함수에서 이상적인 인수 개수는 0개(무항)다. 다음은 1개(단항)고, 다음은 2개(이항)다. 3개(삼항)는 가능한 피하는 편이 좋다. 4개 이상(다항)은 특별한 이유가 필요하다. 특별한 이유가 있어도 사용하면 안 된다. 💡 떠오르는 생각 작게 만들어라! 한 가지만 해라! 함수 안에서 여러 기능을 하던 내 손에서 만들어진 함수들이 스쳐지나간다. 함수.. 2024. 3. 4. [클린코드] 2장 의미 있는 이름 ✏️ 기억하고 싶은 내용 좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다. 읽는 사람이 차이를 알도록 이름을 지어라. (예를 들면 moneyAmount와 money는 구분되게 만들어야 한다.) 검색하기 쉬운 이름을 사용하라. (변수명을 e로 한다면 수 많은 파일들 속 각종 e를 포함하는 변수들이 검색될 것이다. 즉, 검색하기 어려워진다.) 명료함이 최고다. 💡 떠오르는 생각 자신의 기억력을 자랑하지 마라 마치 코드 짤 때는 내가 이 코드를 맘껏 다루며 신나게 짜다가 시간이 지난 뒤 (심지어 적게는 하루) 다시 코드를 볼 때 이게 무슨 코드였지 하는 나를 떠오르게 하는 문장이었다. 모든 코드와 변수는 지금 당장 다른 사람이 봐도 이해할 수 있도록 짜야한다. 내일의 나는 다.. 2024. 3. 3. 이전 1 다음 반응형
