개발자 99% 커뮤니티에서 수다 떨어요!
오늘의 TIL 3줄 요약
코드는 ‘바꾸기 쉽게’, 그리고 그 선택의 이유에 대한 정리까지 마쳐둬야 비로소 바꿀 시점이 왔을 때, 과거의 자신에게 피드백을 줄 수 있다.
개발환경이나 아키텍쳐 또한 비교적 적은 코스트로 바꿀 수 있도록 설계하자.
역시 프로토타이핑보다는 예광탄 코드다.
TIL (Today I Learned) 날짜
2022-05-16
오늘 읽은 범위
2장. 실용주의 접근법 (p.37 ~ p.102)
책갈피
스스로 자꾸 물어보라. ‘내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?’ (p.40)
모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다. (p.43)
모든 코드의 중복이 지식의 중복은 아니다. (p.47)
자신의 힘으로 제어할 수 없는 속성에 의존하지 말라. (p.60)
버그 수정은 시스템의 직교성을 총체적으로 점검해 볼 수 있는 값진 시간이다. 문제가 발생했다면 버그 수정을 얼마나 국소화할 수 있는지 평가해 보라. (p.63)
이렇게 아키텍처가 변덕스러운 환경에서 어떻게 계획을 세울 수 있겠는가? 못한다. (p.69)
여러분의 코드가 로큰롤을 할 수 있게 하라. 락을 할 수도 있고 필요한 경우 롤을 할 수 도 있게 하는 것이다. (p.70)
이전에 해 본 적이 없는 것, 최종 시스템에 매우 중요한 것이 프로토타이핑 대상이다. (p.81)
모델을 만들어 추정을 하면 그 결과는 부정확해질 수밖에 없다. 하지만 이는 피할 수 없는 일이며, 또한 유익한 일이기도 하다. 우리는 간결함과 정확성을 맞교환하고 있다. (p.97)
커피 머신 앞에서 허투루 말한 추정치는 커피와 마찬가지로 여러분에게 해를 끼칠 것이다. (p.102)
오늘 읽은 소감
주니어 시절부터 지금까지도 개발팀 내의 같은 포지션(백엔드 + 웹 프론트엔드)에는 협업하는 인원이 없다. (사수/부사수 X) 그렇다면 주니어 시절에는 코드 리뷰도 없었겠다, 가르쳐주는 이 하나 없으니 미래에 대한 아무런 걱정 없이 코딩하게 되는 건 당연한 일이었다. 간단히 말해 무지성 코딩이었다.
시간이 흐르고 과거에 무지성으로 개발해 두었던 기능들의 업데이트 요청이 들어올 때마다, 생각 없이 짜둔 지저분한 코드에 많은 고통을 받으며 ‘다음부터 이렇게 설계하진 말아야지.’ 결심하는 나날이 지금 오늘날까지도 계속 이어지고 있다.
그렇게 쌓여온 설계에 관한 지식은 이론 하나 없이, 역량과 실력과 경험의 부족으로 인해 쌓아 올려진 것들이기에, 누군가가 ‘좋은 설계란 어떤 건가요?’ 라고 물어본다면 말문이 막혔을 텐데, [Topic 8. 좋은 설계의 핵심]에서 아주 적절한 가이드를 제시해 주어 여러모로 큰 참고가 되었다.
[Topic 9. DRY: 중복의 해악]과 [Topic 10. 직교성]에서 다루는 내용에는 위에서 언급한, 고통받았던 경험을 통해 스스로 체득한 것들도 많아서 감회가 새로웠다. 한창 DRY 원칙에만 매몰됐었다가, DRY 원칙이 적용돼서는 안 되는 부분까지 적용해버려 큰코다치고, 직교성을 고려하지 않고 설계했다가 나중에 연관된 기능 전체를 갈아엎어야 하는 일이 생기고, 그 과정에 큰 버그가 발생하는 등 많은 시련이 있었다... 그래서 유독 ‘완벽함’에 과몰입하는 성향이 된 걸지도 모르겠다.
이렇게 다시 ‘완벽함’을 떠올리기 시작한 나에게 하는 말인 양 [Topic 11. 가역성]에서는 [Topic 5. 적당히 괜찮은 소프트웨어]에서 다뤘던 것처럼 프로그래밍에 있어 ‘완벽함’과 ‘반드시’란 없다는 걸 다시금 강하게 깨닫게 해주었다. 특히 리뉴얼 프로젝트를 진행하는 입장에서 보자면 아키텍처의 유연함은 가장 중요한 대목이라고 생각한다.
개인적으로는 [Topic 13. 프로토타입과 포스트잇]에서 다루는 프로토타입 개발 방법은 좋아하지 않는다.
기획 단계에서 제시하는 기능들에 대한 프로토타입들을 각각 먼저 구현해보고, 나중에 프로젝트가 시작되어 구현했던 기능들을 한데 통합해보니 라이브러리 간 버전 충돌이 나버린 다던지, 막상 같이 배치해두고 보니 별로라고 기획이 변경되고 그 과정에서 기능이 폐기 된다든지... 그런 상황들을 몇 차례 마주하다 보니 시간과 노동력의 절약을 위해 [Topic 12. 예광탄]의 접근 방식을 선호하게 되었다. 프로토타입도 실전성을 갖춰 그대로 가져다 쓸 수 있도록 예광탄처럼 작성해두는 게 베스트라고 생각한다.
[Topic 14. 도메인 언어]에서 다루는 내용은 Rails를 활용하면서 접해본 RSpec이나, 배포환경을 구성하면서 접해본 Ansible 이외에는 전부 처음 접하는 기술과 개념이라 어려웠다. 여러 번 검색해가며 읽었는데 참고한 자료 중 좋다고 느껴진 자료의 링크는 나중에 다시 보려고 아래 정리해두었다.
일을 진행하면서 어려운 부분 중 하나는 업무 시간의 예측이라고 생각한다. [Topic 15. 추정]의 코끼리 먹기에서 다루는 점증적 개발은 크런치 모드 없이도 개발 일정을 비교적 정확하게 예측할 수 있는 방법이라고 생각한다. 회사에서도 이와 비슷한 개념인 애자일 개발 방법론의 스크럼 개발 방식을 활용 중인데, 도입 전과 후의 업무 피로도와 만족도, 진행 속도가 눈에 띄게 개선되었다.
궁금한 내용이 있거나, 잘 이해되지 않는 내용
과제 1. 도메인 특화 언어(DSL)
과제 2. 연습문제들
오늘 읽은 다른사람의 TIL
게시 후 2일차 TIL 전부 읽어볼 예정