TIL (Today I Learned)

2022.02.19

오늘 읽은 범위

1장. 깨끗한 코드

책에서 기억하고 싶은 내용을 써보세요.

• P4 우리 모두는 자신이 짠 나쁜 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다. 

• 나쁜 코드로 치르는 대가 

나쁜 코드는 개발 속도를 크게 떨어뜨린다. 프로젝트 초반에는 번개처럼 나가다 1-2년만에 굼벵이처럼 기어가는 팀도 많다.  코드를 고칠 때마다 엉뚱한 곳에서 문제가 생긴다. 

시간이 지나면서 쓰레기 더미는 점점 높아지고 깊어지고 커진다. 청소할 방법이 없다. 불가항력이다.

나쁜 코드를 쌓을 수록 팀 생산성을 떨어진다. 그러다가 마침내 0에 근접한다. 

• P6 태도

우리는 온갖 이유를 들이댄다. 원래 설계를 뒤집는 방향으로 요구사항이 변했다고 불평한다. 일정이 촉박해 제대로 할 시간이 없었다고 한탄한다.

하지만 잘못은 전적으로 우리 프로그래머에게 있답니다.우리가 전문가답지 못했기 때문입니다. 

• p7 원초적 난제

누구나 나쁜 코드가 업무 속도를 늦춘다는 사실을 익히 안다. 그럼에도 모든 프로그래머가 기한을 맞추려면 나쁜 코드를 양상할 수 밖에 없다고 느낀다. 간단히 말해 그들은 빨리 가려고 시간을 들이지 않는다.

진짜 전문가는 두 번째 부분이 틀렸다는 사실을 잘안다. 

나쁜 코드를 양산하면 기한을 맞추지 못한다. 

그러니까 빨리가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이다. 

• P10

  비야네는 깨끗한 코드란 한 가지를 잘한다고 단언한다.

수많은 소프트웨어 설계 원칙이 이 간단한 교휸 하나로 귀결된다는 사실은 우연이 아니다. 수많은 저술가들이 이 생각을 나름대로 표현하려 애썼다. 나쁜 코드는 너무 많은 일을 하려 애쓰다가 의도가 뒤석이고 목적이 흐려진다. 

깨끗한 코드는 한가지에 ‘집중’한다. 각 함수와 클래스와 모듈은 주변 상황에 현혹되거나 오염되지 않은 채 한길만 걷는다. 

• P18코드를 읽는 시간 대 코드를 짜는 시간 비율이 10대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코를 읽는다. 비율이 이렇게 높으므로 읽기 쉬운 코드가 매우 중요하다. 

기존 코드를 읽어야 새 코드를 짜므로 읽기 쉽게 만들면 사실은 짜기도 쉬워진다. 

• P19

  보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

체크아웃 할 때보다 좀 더 깨끗한 코드를 체크인 한다면 코드를 절대 나빠지지 않는다.

한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다. 변수 이름 하나를 개선하고 조금 긴 함수를 분할하고 약간의 중복을 제가하고 복잡한 if문 하나를 정리하면 충분하다. 

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

1장은 좋은 코드를 위한 구체적 기술 보다 나쁜 코드로 인해 치르는 대가와 그렇기 때문에 좋은 코드와 깨끗한 코드가 지닌 가치와 중요성에 대해 주로 설명했다.

특히 우리 모두는 자신이 짠 나쁜 쓰레기 코드를 쳐다보며 나중에 꼭 고치겠다고 생각한 경험이 있다. 이 부분에서 심히 공감이 되었다. 나쁜 코드라는 사실을 알면서 언젠가 고치겠다는 생각으로 미뤘던 많은 기억들이 떠올랐기 때문이다. 하지만 그때의 나는 르블랑의 법칙을 몰라서 였을까 나중은 결코 오지 않는단 사실을 새삼 깨닫는 순간이었다.

또한 나쁜 코드가 치르는 대가에 대해 진지하게 생각해볼 수 있어 좋았다. 개발자라면 모두가 알듯 나쁜 코드는 업무 속도를 늦춘다는 사실을 알고 있지만 그것이 지니는 파장과 영향력에 대해 큰 고민을하지 않았던 것 같다. 큰 고민없이 싸질렀던 나쁜 코드들은 언젠가 부메랑이 되어 나에게 혹은 우리 팀에게 다시 날아온다는 사실을 명심 해야한다.

태도와 원초적 난제에 대한 부분도 큰 공감과 반성을 느끼게 만들었다. 개발팀의 체계가 제대로 잡혀있어 리팩토링에 대한 중요성을 인지하고 있는 극히 드문 회사를 제외하고서는 대부분의 회사에서는 현실적인 기한의 이유로 좋은 코드를 위한 노력을 들이기 위한 시간을 투자하기 쉽지 않은 현실이다. 하지만 저자는 그 잘못은 전적으로 개발자에게 있다며 개발자가 전문가 답지 못했기 때문 이라며 그 태도를 꼬집는다. 또한 모든 개발자가 기한을 맞추려면 나쁜 코드를 양산할 수 밖에 없다고 말하지만 사실 그들은 빨리 가려고 시간을 들이지 않을 뿐이라고 꼬집는다. 진짜 전문가는 반대로 나쁜 코드를 양산하면 기한을 맞추지 못한다고 말한다. 그렇기 때문에 빨리 가는 유일한 방법은 언제나 코드를 최대한 깨끗하게 유지하는 습관이라 말했다. 나 역시 좋은 코드의 중요성에 대해 인지 하면서 현실적인 기한을 맞추려면 어쩔 수없는 측면이 있다고 한 켠으로 생각했던 것 같다. 하지만 그런식으로 일을 진행하면 그 순간에 빨리 가는 것처럼 보일 지라도 조금만 지나도 그 속도가 더디어질 것이라고 느낄 수 있었다.

마지막으로 보이스카우트 규칙이 인상 깊었다. 저자는 체크아웃 할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다고 말하며 한꺼번에 많은 시간과 노력을 투자할 필요가 없다고 말한다. 깨끗한 코드를 위해 엄청난 시간을 투자하며 거창한 무언가를 하는 게 아니라 변수 이름 하나를 개선하고 중복을 제거하며 조금 긴 함수를 분할하는 등 저번보다 나은 코드를 향한 작은 노력이면 충분하다고 설명했다. 중요한 것은 코드를 향상시키는 엄청난 스킬이 아니고 저번의 코드보다 조금 더 나아지기 위한 고민과 노력이라는 사실을 명심 해야겠다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• // 르블랑의 법칙? (LeBlanc's Law states) - "Later equals never" is used in the context of software development, but may be applied more broadly to other areas. The law is attributed to Dave LeBlanc.