오늘 읽은 범위

1장 깨끗한 코드

책에서 기억하고 싶은 내용

• 바쁜 일정 때문에 제대로 짜지 않고 작동만 되는 코드를 만들고 나중에 정리하겠다고 하는 경우, 르블랑의 법칙에 따라 그 나중은 절대 오지 않는다.
• 다른 파트의 요구사항은 그들의 책임이지만, 프로그래머는 좋은 코드를 지키는 것이 프로그래머의 책임이다.
• 깨끗한 코드의 특징 "가독성이 좋고" "작게 추상화되었다." "DRY" "한기능만 수행"

오늘 읽은 소감

• 내 성격상, 기획이나 운영에서 요청하는 아이디어가 좋다, 혹은 운영의 편의를 크게 개선할 수 있다면 가능한 제품에 '모두' 받아드리고 싶어하는 경향이있다. 그런 내 태도를 조금 반성했다. 개발자에게 큰 책임은 '좋은 코드'를 지키는 것이고, 그 제품을 이 후에 어떤 사람이 봐도 이해할 수 있어야한다는 것을 늘 마음에 새기고 있어야한다라는 것을 읽고 깨달았다. 선배 개발자가 가능한 코드를 사수하라는 말이 이런 말이었구나. 하는 생각이 들어, 좀 더 일찍 깨닳았다면 선배 개발자의 고됨을 깨알 만큼이라도 덜어드릴 수 있었지 않았나. 하는 반성을 하게 되었다.

궁금한 내용, 잘 이해되지 않는 내용 리서치

• OCP 개방- 폐쇠의 원칙 : 기능을 변화, 확장하는 것은 가능하지만, 해당 기능의코드를 수정하면 안된다.
• SRP 단일 책임 원칙: 모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화 해야한다.
• DIP 의존성 역전 원칙 : 객체는 저수준모듈(구현된 객체)보다 고수준 모듈(인터페이스와 같은 객체의 형태나 추상적 개념)에 의존해야한다.
• 추상화: 공통 속성이나 기능을 묶어 이름을 붙이는 것

참고: https://blog.itcode.dev/posts/2021/08/17/dependency-inversion-principle

참고: https://blog.itcode.dev/posts/2021/08/14/open-closed-principle

참고: https://blog.itcode.dev/posts/2021/08/13/single-responsibility-principle