처음 1장을 들어가면 익명의 회사의 데이터를 보여준다.
데이터를 살펴보면 시간이 지날수록 Software Engineer수는 늘어나지만 생산성은 점점 떨어진다.
Robert C. Martin(밥아저씨) 는 토끼와 거북이 우화로 예를들며 어리석음을 말했는데, 현대의 개발자도 토끼와 유사한 과신을 드러낸다고 한다.
- 느려도 꾸준하면 이긴다.
- 발 빠른 자가 경주에 이기는 것도 아 니며, 힘센 자가 싸움에서 이기는 것도 아니다.
- 급할수록 돌아가라
밥아저씨는 현대의 개발자들을 우화의 토끼와 다를것없다고 말을한다.
왜 그럴까?
- 코드는 나중에 정리하면돼. 당장은 시장에 출시하는게 먼저라는 흔해 빠진 거짓말에 속는다.
- 나또한 그런적이 있는가? → 맞다 첫 프로젝트 당시. 마감기한이 다가오자,, 당장 배포 먼저 해야한다는 생각으로 코드정리는 나중에 하자 하고 흐린 눈 하고 넘어간적이있다
- 지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.
- 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. → 프로젝트를하는 당시 오류가 터진 적이 있다. 하지만 그때같은반 동기와 협업을 배우자는 이유로 같이 개발을 하였는데, 그결과 두명이 합쳐,, 매우 엉망인 코드가 되었다. 그로인해 오류 해결하는데 생각보다 오랜시간이 걸렸던 기억이 난다.
- 사실 이번 EasterEgg기능 또한 처음엔 지저분한 코드에 속해있다고 생각한다. Eli 와 Bart의 피드백으로 인해 그나마 코드가 간결해지고 Timer 또한 Activity에서 처리하던 것들을 Timer Class 안에서 처리를 해 Activity쪽 코드는 매우 깔끔해졌다.
Jason Gorman(TDD) → 테스트 주도 개발
예전에 입사 초기 Bart 와 Eli 가 TDD 이야기를 하던 것을 들은적이 있어 그때당시 잠깐 찾아봤는데,
- 테스트를 먼저 만들고 테스트를 통과하기 위한 것을 짜는 것 이라고 간단하게 이해하고 넘어갔던 기억이있다.
Clean Architecture를 읽으며 다시 TDD를 마주하게 되엇는데.
표를 보여주며 예를 들었는데, 결과가 흥미로웠다.
TDD를 적용한 개발 방식이 적용하지 않은 방식보다 매우 빠르게 작업이 완료 되었다는 것이다.
밥아저씨는 예제를 보이고 이런말을했는데,
💡 빨리 가는 유일한 방법은 제대로 가는것.
두 가지의 가치
첫 번째 가치는 바로 "행위"
- 프로그래머는 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는다.
두 번째 가치는 "소프트웨어(software)"
- 본연의 목적을 추구하려면 소프트웨어는 반드시 '부드러워'야한다. → 변경하기 쉬워야한다.
- 아키텍처가 특정 형태를 다른 형태보다 선호 할수록 → 새로운 기능을 구조에 맞추는게 더 힘듦
- 아키텍처는 형태에 독립적 이어야 하고, 그럴수록 더 실용적이다.
더 높은 가치?
기능 or 아키텍처?
-
관리자에게 묻는다면 동작하는 것이 중요하다고 할 것이다.
→ 여기서 나는,, 동조하고있었다 하지만, 바로 뒤 잘못된 태도라고, 사례를 들었다.
-
수정이 불가능한 코드는 결국 만들 수 없게 되며 따라서 이 프로그램은 쓸모가 없다.
-
사실 수정이 완전 불가능한 코드는 존재하지 않지만, 수정이 현실적으로 불가능한 프로그램은 존재한다.
→ 수정에 드는 비용이 창출되는 수익을 초과하는 경우.
아키텍처를 위해 투쟁하라
여기서 밥아저씨는 책임을 다하려면 싸움판에 뛰어들어야 한다고 말을했다.
→ 나는 한번이라도 싸움판에 뛰어든 적이 있는가,,? 음,,대답은 아니요.
나 또한 소프트웨어를 안전하게 보호해야 할 책임이 있다 는 것을 명심해야 할 것
아키텍처가 후순위가 되면 개발하는 비용이 더 많이들고,
일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.
