코드 추가 및 제거

코드 제거의 미학

코드는 꾸준히 이자를 내야 하는 부채와 같다.

• 코드가 가치 있다고 느끼게 되는 이유는 생산 비용이 비싸기 때문

• 코드를 작성하려면 많은 시간을 소비하고 많은 카페인을 섭취해야 한다.

• 시간이나 노력을 드렸기 때문에 어떤 것에 가치를 부여하는 것을 매몰 비용의 오류(sunk-cost fallacy)라고 한다.

• 가치는 투자 자체에서 나오는 것이 아닌 투자의 결과에서 나온다.

복잡성을 제거하기 위한 코드 제거

어떤 것을 구현할 때 시스템이 어떻게 동작하는지에 대한 멘탈모델(인식모형)을 구축하고, 이에 영향을 미치도록 변경해야 한다.

• 복잡성은 도메인 복잡성과 부수적 복잡성 두 유형으로 나뉜다.

  • 도메인 복잡성: 도메인이 기본적으로 가지고 있는 것

  • 부수적 복잡성: 도메인에서 요구하지 않았지만 우연히 추가된 모든 복잡성

부수적 복잡성

기술 부채의 동의어

개발이 더디고 더 어려워지는 원인이 된다.

기술적 무지, 기술적 낭비, 기술적 부채, 기술적 방해물로 네 가지 유형의 부수적인 복잡성이 있다.

• 기술적 무지: 경험 부족으로 무의식적으로 코드에서 잘못된 결정을 내림으로써 좋지 않은 아키텍처를 만든다.

  • 무지해서 불필요한 결합을 추가하지 않고도 문제를 해결할 수 있는 기술이 부족해서 발생

  • 이 문제의 유일하게 지속 가능한 해결책은 "지속적으로 주의를 기울이는것(투자)" - 애자일 소프트웨어 개발을 위한 선언문

• 기술적 낭비: 시간 압박으로 코드에 잘못된 결정을 내림으로써 아키텍처가 좋지 않은 결과를 초래하는 것

  • 문제나 모델을 충분히 이해하지 못하기 때문에 테스트나 리팩터링을 건너뛰거나, 기한을 맞추기 위해 프로세스를 우회

  • 이런 나쁜 결정은 의도적인 것

  • 외부 압력으로 인해 더 나은 지식을 거스르는 방향을 선택함

• 기술적 부채: 일시적으로 차선의 해결책을 선택해서 이익을 얻는 것

  • ex: 적절한 아키텍처 고려 없이 핫픽스를 구현하고 중요 문제를 해결하기 위해 적용한 다음 나중에 적절한 수정을 구현하기 위해 다시 해야할 때

  • 기술적 부채를 발생시키는 것은 전략적인 결정

  • 만료일이 있는한 본질적으로 잘못된 것이 없다

• 기술적 장애물: 개발을 더디게 만드는 모든 것

  • 문서, 테스트 및 기존 코드 등 모든 범주가 포함됨

  • 무언가를 구축하는데 따르는 부작용

"거기 두어도 아무런 방해가 되지 않는다"라는 말은 모두 거짓말

• 해결책은 더 이상 삭제할 것이 없을 때까지 가능한 한 많은 것을 삭제하는 것

• 조금이라도 사용하지 않는 것들은 사라져야 한다.

• 사용하지 않으면 기능은 퇴화한다.

레거시 코드

수정하기 겁나는 코드 (이 상황은 종종 서커스 팩터의 결과이다.)

서커스 팩터(circus factor) - 버스 또는 로터리 팩터라고도 함

• 너무 많은 시스템에 대한 지식이 소실되어 개발의 일부가 중단되기 전까지 얼마나 많은 사람이 이탈해서 서커스에 합류해야 하는지를 나타낸다.

• "시스템을 배포하는 방법은 존밖에 모른다" 는 해당 시스템에 서커스 팩터가 있다고 말한다.

• 서커스 팩터를 잃는 순간 우리는 건드리기 꺼려지는 미지의 코드, 즉 레거시 코드를 가지게 된다.

스트랭글러 무화과나무 패턴

이 패턴은 기존 나무 줄기에 씨를 뿌리고 자라면서 숙주를 감싸 궁극적으로 숙주 나무를 교살해 죽이는 스트랭글러 무화과나무의 이름을 따서 명명됨

코드 추가에 대한 두려움 떨쳐내기

완벽한 코드에 대한 부담감

• 코드가 결함을 갖게 되는 방법이 얼마나 많은지를 생각해보자

• 완벽한 코드라는 것은 완전히 비현실적 목표이다.

• 성능, 구조, 추상화 수준, 사용의 용이성, 유지보수 비용, 참신함, 창의성, 정확성, 보안 등 많은 고려사항이 '완벽함'에 영향을 미침

• 이 모든 것을 염두에 두는 것은 불가능하다.

• 코드를 추가하는 것이 수정하는 것보다 안전하다는 것을 인식하자.

불확실성 받아들이기: 위험 감수

겁을 먹으면 효과적으로 일할 수 없다.

• 소프트웨어 개발은 도메인을 학습하고 그 지식을 프로그래밍 언어로 코드화하는 것

• 팀 생산성의 가장 큰 예측 변수는 심리적 안정이다.

  • 팀원들이 서로를 신뢰하고 위험을 감수하는 것이 안전하다고 느껴지는지의 여부

• 무언가를 시도하기 전 만드는 방법에 대해 토론하거나 설계해야 한다는 강박관념이 들게한다.

  • 이것은 잘못된 것을 만드는 것에 대한 두려움이 제데로 못 만드는 것에 대한 두려움을 압도할 때 나타남

낭비나 위험에 대한 두려움 극복을 위한 사용 시간 비율 지정

• 이해관계자의 요청에 의해 발생되지 않는 모든 작업을 의미하는 비티켓 작업들을 금요일에 몰아서 하자.

• 금요일에 개발자들은 실험과 주요 리팩터링을 수행하거나 개발 작업을 자동화하여 품질을 개선하거나 낭비를 줄이기

• 일상적인 티켓 작업에 활력을 불어넣을 수 있는 변화이기도 하다.

가면 증후군

스스로를 자격이 없는 사람으로 간주하여 누군가 자신을 사기꾼으로 폭로할까봐 두려워 하는 것

• 자신을 보호하기 위해 코드를 완벽하게 만들려는 마음에 코드를 공개하지 않거나 -> 생산성에 실질적인 영향

• 사소한 문제에 대해 완벽한 코드를 작성하는 것은 특히 어렵기 때문에 질질 끌거나 대부분의 시간을 허비

• 개발자는 종종 다른 사람의 코드를 경솔하게 비판한다.

  • "누군가 내 코드에 대해 그런 말을 하고 있나요?"

  • "그 사람이 내 코드를 본다면?", "그가 내 코드를 보고 있는건가?"

  • 이러한 생각은 나를 가면 증후군으로 만들게 한다.

• "나는 완벽한 코드가 존재한다고 믿지 않는다."

• "코드에서 가장 안전한 것은 아무것도 변경하지 않는 것임을 상기" -> 수정이 아닌 확장