개발자 99% 커뮤니티에서 수다 떨어요!
추천사 ~ 1장 깨끗한 코드
나중은 켤코 오지 않는다. (p.4)
그들이 일정과 요구를 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. (p.7)
깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 열쇠는 '코드 감각'이다. (p.8)
나는 우아하고 효율적인 코드를 좋아한다. 논리가 간단해야 버그가 숨어들지 못한다. (비야네 스트롭 스트룹)
테스트 케이스가 없는 코드는 깨끗한 코드가 아니다. (p.12)
중복 줄이기, 표현력 높이기, 초반부터 간단한 추상화 고려하기. (p.14)
나는 협업을 잘 하는 개발자가 되고 싶었고, 여태까진 그 방법이 기획자의 요청을 되도록 받아들이고 존중하는 것이라 생각했다. 때문에 추가 요청이 들어오는 기능들을 거의 수용했고, 정해진 기간안에 프로젝트를 마무리해야했기에 부끄럽지만 더러운 코드가 되었다. '그들이 일정과 요구를 강력하게 밀어붙이는 이유는 그것이 그들의 책임이기 때문이다. 좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다.' 라는 말처럼 좋은 코드를, 좋은 설계를 사수하고 진행시키는 것도 프로그래머의 책임인 것을 다시금 느꼈다. 기획자가 보지 못하는 부분을 채워주는 것이 프로그래머인 것이다. 기획자의 책임을 존중하며 나의 책임도 지키는 개발자가 되자.
나의 코드는 얼마나 깨끗한가 다시금 돌아보는 계기가 되었다. 최근들어 코드 작성 습관을 다시 잡고 있는데, 이 책이 좋은 길잡이가 되어줄것 같아 설레인다. :)
스크럼과 애자일
SRP (The Single Responsibility Priciple)
단일 책임 원칙
클래스에는 한가지, 단 한 가지 변경 이유만 존재해야 한다.
OCP (The Open Closed Priciple)
개방-폐쇄 원칙
클래스는 확장에 열려있어야 하며 변경에 닫혀있어야 한다.
LSP (The Liskov Subsituation Priciple)
리스코브 치환 원칙
상속 받은 클래스는 기초 클래스를 대체할 수 있어야 한다.
DIP (The Dependency Inversion Priciple)
의존 역전 원칙
추상화에 의존해야하며, 구체화에 의존하면 안된다.
ISP (The Interface Sergregation Priciple)
인터페이스 분리 원칙
클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지해야한다.
화이팅! 🔥
→ 블로그 링크 : https://potato-hyun.tistory.com/52?category=1003262