개발자 99% 커뮤니티에서 수다 떨어요!
오늘 TIL 3줄 요약
ETC 바꾸기 쉬운 코드를 작성하라.
DRY 모든 지식은 단한번만 표현하라.
예광탄과 프로토타입을 사용하라
TIL (Today I Learned) 날짜
2022.03.21
오늘 읽은 범위
2장. 실용주의 접근 법
책에서 기억하고 싶은 내용을 써보세요.
TOPIC 8 좋은 설계의 핵심
ETC(Easy to change)는 이걸해야하나 저걸해야하나 같은 결정을 돕는다. p39
스스로 자꾸 물어보라 '내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?' 파일을 저장할 때마다 물어보라. 테스트를 쓸 때도, 버그를 수정할 때도 물어보라.p40
엔지니어링 일지에 현재 상황과 여러분의 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라.p40
TOPIC 9 DRY:중복의 해악
소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가 DRY라 부르는 원칙을 따르는 것이라 생각한다. DRY원칙은 다음과 같다
모든 지식은 시스템 내에서 단 한번만, 애매하지 않고, 권위 있게 표현되어야 한다.DRY여부를 판단할수 있는 리트머스 시험지가 있다.
- 코드의 어떤 측면 하나를 바꿔야 할 때 여러 곳을 바꾸고 있나?
- 그것도 여러 가지 다른 형태를?
- 코드를 바꾸고 문서도 바꾸는가?
- 데이터베이스 스키마와 스키마를 담고 있는 구조 등도?
그렇다면 여러분의 코드는 DRY하지 않다.소스 트리의 한가운데 유틸리티 루틴과 스크립트를 모아둘 수 있는 장소를 마련하라. 그리고 일상적으로든 코드 리뷰틀 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라.
TOPIC10 직교성
컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기를 의미한다.
설계가 직교적인지 확인하는 손쉬운 방법이 있다. 컴포넌트들을 나누었을 때 다음과 같이 스스로에게 물어보라
특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇개의 모듈이 영향을 받는가?` 직교적인 시스템에서는 답이 `하나`여야 한다.
TOPIC 11 가연성
이렇게 아키텍처가 변덕스러운 환경에서 어떻게 계획을 세울수 있겠는가? 못한다. 여러분이 할수 있는 것은 바꾸기 쉽게 만드는 것이다. 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라.
TOPIC 12 예광탄
예광탄 개발 방법은
프로젝트는 결코 끝나지 않는다.는 견해와도 일맥상통한다. 변경 요청과 기능 추가 요청은 언제나 계속 들어오기 마련이다. 예광탄 개발 방법은 점진적인 접근 방법이다. p75프로토 타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격중 일부가 된다. 프로토 타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집 같은 것이다. p79
TOPIC 13 프로토타입과 포스트잇
프로토타입을 반드시 코드로 작성해야 한다고 생각하기 쉬운데 꼭 그럴 필요는 없다. 포스트잇은 작업 흐름이나 애플리케이션 로직과 같은 동적인 것을 프로토타이핑 할수 있는 훌륭한 도구다. p80
프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다. 이것이 프로토타이핑의 진정한 핵심이다. p81
사실 아키텍처를 프로토타이핑 할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도된다. 프로토 타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다. p83
TOPIC 14 도메인 언어
TOPIC 15 추정
누군가 추정해 달라고 하면 뭐라고 대답해야할까? "나중에 연락드릴께요."라 말해야한다.
잠시 손을 멈추고 시간을 내어 이번 항목에서 설명한 단게를 밟아 낙나다면 대부분의 경우 더 좋은 추정치를 얻을 수 있을 것이다.
오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요
최근 기존 프로젝트에 새로운 기능을 추가하는 작업을 진행중에 있다. 새로운 기능을 추가하는데 기존의 소스를 건들여야하는 이상한 상황이 벌어졌다. (짜증..) 하지만 기존의 소스를 함부로 건들기가 무서웠다. 지금 잘 돌아가고 있는 소스인데. 이런 배경속에서 오늘 읽을 2장의 첫 TOPIC인 좋은 설계의 핵심인 ETC 바꾸기 더쉽게 만들어야 한다는게 피부로 와닿았다. 앞서 작성한 그 코드처럼 되고싶지 않았다. 동시에 나도 내가 작성한 코드를 누군가가 봤을 때 웃음이 나올까? 아니면 절망이 나올까? 그 비밀은 바로 ETC에 있다는 것을 깨달았다.
코드리뷰 중 같은 기능을 하는 함수를 만든걸 발견했다. 왜 같은 기능이 있는 동일한 함수를 만들었냐고 물어봤는데. 의외로 답변은 간단했다. '못봤어요.' 그렇다 그럴수있지, 못볼수 있지. 그렇다 책에서 말하는 DRY반복하지 마라중에서 개발자들 사이에서 같은 소스가 중복되는 이슈를 경험했다. 개발자들 사이에서도 소통이 중요하다는 것을 느꼈으며, 일상적으로 다른 소스들을 읽는 습관을 들이는게 중요함을 느꼈다.
앞서 말했지만 새로운 기능을 추가하는데 기존 소스코드는 참담했다. 손쓸수가 없었다. 설계부터 잘못됬으며 번들도구 webpack의 버전은 심지어 2.x.x대였다. 잘못된 설계된 소스에 몇년동안 더하고 더하다 보니 이제는 손쓸수 조차 없게 되어버렸다. 아주 절망스러웠다. TOPIC 직교성을 읽고 하나의 희망의 한줄기를 찾을수 있었다. 바로 불필요한 결합을 없에는 것이였다. 그러기 위해서는 계층 구조를 그려야하고, 그리고 각 기능별로 잘개 부셔트려놓는것이 필요함을 느꼈다. 이러한 생각과 논리를 바탕으로 새롭게 리펙토링을 시도해야겠다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.
도메인 언어.
오늘 읽은 다른사람의 TIL
https://jiyoungyim100.notion.site/TIL-2022-03-20-2-bf5439e63e7a4764bf2acdd0d7a95c55