<좋은 코드는 맥락에 따라 달라진다> 1. 많은 프로그래머들이 좋은 코드에 대해 얘기한다. 어떤 코드가 좋은 코드인가? 요즘 유행하는 클린 코드가 좋은 코드인가? 모르겠다. 2. 초기 스타트업의 경우, 분명 가독성이 낮고 중복이 많고 자주 오류를 발생시키는 경우가 많다. 하지만 동시에 이 코드는 소수의 인원에 의해 빠르게 작성되어 중요한 비즈니스 타이밍에 배달되었다. 3. 초기 스타트업에서 타이밍은 (비즈니스적으로) 굉장히 중요하다. 발생하는 프로그램 오류는 분명 나쁜 것이지만 비즈니스를 치명적으로 방해하는 수준은 아니라면, 그게 나쁜 코드인지는 다시 생각해볼 필요가 있다. 4. (비록) 유지보수 비용을 높였지만, (만약에) 비즈니스 타이밍을 놓쳐 회사가 사라지면 유지보수성은 아무 가치 없으니까. 이런 코드는 (오류를 가지고 있지만) 비즈니스를 성장시키고 매출을 만들고 투자를 이끌었다. 그리고 경험 많은 개발자들을 불러들였다. 이런 유형의 코드를 '프로토타이핑 코드'라고 하자. 5. 프로토타이핑 코드의 성과를 나열했지만, (이게) 언제나 바람직한 것은 아니다. 시스템 규모가 특정 수준에 이르면 코드의 낮은 가독성과 많은 중복, 잦은 오류는 전진에 필요한 비용을 증가시키고 심각한 경우 비즈니스를 멈추게 할 수도 있다. 그래서 어느 시점에서는 이런 오류를 줄이고 유지보수 비용을 줄일 수 있는 지속가능 코드가 필요하다. 6. (물론) 프로토타이핑 코드와 지속가능 코드가 좋은지 아닌지는 절대적이지 않다. 조직의 성장 단계나 시스템 규모에 따라 달라진다. 7. 좋은 코드는 맥락에 따라 달라진다. 그러니까 ‘좋은’이란 표현은 코드를 수식하기에 부족하다. 프로토타이핑에 적합한 코드, 유지보수하기 쉬운 코드, 전력효율이 높은 코드, 응답시간이 짧은 코드, 프레임 수를 유지하는 코드, GC를 덜 자극하는 코드 같은 건 있지만 그냥 좋은 코드란 존재하지 않는다. 8. (따라서) 엔지니어는 (다양한 상황과 맥락에 적합한) 다양한 도구를 준비해 적절한 곳에 쓸 줄 알아야 한다. 우린 문제를 해결하는 해커이지 진리를 탐구하는 과학자가 아니다. ++코드를 콘텐츠로 바꿔도 그대로 적용될 듯 ㄷㄷㄷ