코드 추가 및 제거
코드 제거의 미학
코드는 꾸준히 이자를 내야 하는 부채와 같다.
코드가 가치 있다고 느끼게 되는 이유는 생산 비용이 비싸기 때문
코드를 작성하려면 많은 시간을 소비하고 많은 카페인을 섭취해야 한다.
시간이나 노력을 드렸기 때문에 어떤 것에 가치를 부여하는 것을 매몰 비용의 오류(sunk-cost fallacy)라고 한다.
가치는 투자 자체에서 나오는 것이 아닌 투자의 결과에서 나온다.
복잡성을 제거하기 위한 코드 제거
어떤 것을 구현할 때 시스템이 어떻게 동작하는지에 대한 멘탈모델(인식모형)을 구축하고, 이에 영향을 미치도록 변경해야 한다.
복잡성은 도메인 복잡성과 부수적 복잡성 두 유형으로 나뉜다.
도메인 복잡성: 도메인이 기본적으로 가지고 있는 것
부수적 복잡성: 도메인에서 요구하지 않았지만 우연히 추가된 모든 복잡성
부수적 복잡성
기술 부채의 동의어
개발이 더디고 더 어려워지는 원인이 된다.
기술적 무지, 기술적 낭비, 기술적 부채, 기술적 방해물로 네 가지 유형의 부수적인 복잡성이 있다.
기술적 무지: 경험 부족으로 무의식적으로 코드에서 잘못된 결정을 내림으로써 좋지 않은 아키텍처를 만든다.
무지해서 불필요한 결합을 추가하지 않고도 문제를 해결할 수 있는 기술이 부족해서 발생
이 문제의 유일하게 지속 가능한 해결책은 "지속적으로 주의를 기울이는것(투자)" - 애자일 소프트웨어 개발을 위한 선언문
기술적 낭비: 시간 압박으로 코드에 잘못된 결정을 내림으로써 아키텍처가 좋지 않은 결과를 초래하는 것
문제나 모델을 충분히 이해하지 못하기 때문에 테스트나 리팩터링을 건너뛰거나, 기한을 맞추기 위해 프로세스를 우회
이런 나쁜 결정은 의도적인 것
외부 압력으로 인해 더 나은 지식을 거스르는 방향을 선택함
기술적 부채: 일시적으로 차선의 해결책을 선택해서 이익을 얻는 것
ex: 적절한 아키텍처 고려 없이 핫픽스를 구현하고 중요 문제를 해결하기 위해 적용한 다음 나중에 적절한 수정을 구현하기 위해 다시 해야할 때
기술적 부채를 발생시키는 것은 전략적인 결정
만료일이 있는한 본질적으로 잘못된 것이 없다
기술적 장애물: 개발을 더디게 만드는 모든 것
문서, 테스트 및 기존 코드 등 모든 범주가 포함됨
무언가를 구축하는데 따르는 부작용
"거기 두어도 아무런 방해가 되지 않는다"라는 말은 모두 거짓말
해결책은 더 이상 삭제할 것이 없을 때까지 가능한 한 많은 것을 삭제하는 것
조금이라도 사용하지 않는 것들은 사라져야 한다.
사용하지 않으면 기능은 퇴화한다.
레거시 코드
수정하기 겁나는 코드 (이 상황은 종종 서커스 팩터의 결과이다.)
서커스 팩터(circus factor) - 버스 또는 로터리 팩터라고도 함
너무 많은 시스템에 대한 지식이 소실되어 개발의 일부가 중단되기 전까지 얼마나 많은 사람이 이탈해서 서커스에 합류해야 하는지를 나타낸다.
"시스템을 배포하는 방법은 존밖에 모른다" 는 해당 시스템에 서커스 팩터가 있다고 말한다.
서커스 팩터를 잃는 순간 우리는 건드리기 꺼려지는 미지의 코드, 즉 레거시 코드를 가지게 된다.
스트랭글러 무화과나무 패턴
이 패턴은 기존 나무 줄기에 씨를 뿌리고 자라면서 숙주를 감싸 궁극적으로 숙주 나무를 교살해 죽이는 스트랭글러 무화과나무의 이름을 따서 명명됨
코드 추가에 대한 두려움 떨쳐내기
완벽한 코드에 대한 부담감
코드가 결함을 갖게 되는 방법이 얼마나 많은지를 생각해보자
완벽한 코드라는 것은 완전히 비현실적 목표이다.
성능, 구조, 추상화 수준, 사용의 용이성, 유지보수 비용, 참신함, 창의성, 정확성, 보안 등 많은 고려사항이 '완벽함'에 영향을 미침
이 모든 것을 염두에 두는 것은 불가능하다.
코드를 추가하는 것이 수정하는 것보다 안전하다는 것을 인식하자.
불확실성 받아들이기: 위험 감수
겁을 먹으면 효과적으로 일할 수 없다.
소프트웨어 개발은 도메인을 학습하고 그 지식을 프로그래밍 언어로 코드화하는 것
팀 생산성의 가장 큰 예측 변수는 심리적 안정이다.
팀원들이 서로를 신뢰하고 위험을 감수하는 것이 안전하다고 느껴지는지의 여부
무언가를 시도하기 전 만드는 방법에 대해 토론하거나 설계해야 한다는 강박관념이 들게한다.
이것은 잘못된 것을 만드는 것에 대한 두려움이 제데로 못 만드는 것에 대한 두려움을 압도할 때 나타남
낭비나 위험에 대한 두려움 극복을 위한 사용 시간 비율 지정
이해관계자의 요청에 의해 발생되지 않는 모든 작업을 의미하는 비티켓 작업들을 금요일에 몰아서 하자.
금요일에 개발자들은 실험과 주요 리팩터링을 수행하거나 개발 작업을 자동화하여 품질을 개선하거나 낭비를 줄이기
일상적인 티켓 작업에 활력을 불어넣을 수 있는 변화이기도 하다.
가면 증후군
스스로를 자격이 없는 사람으로 간주하여 누군가 자신을 사기꾼으로 폭로할까봐 두려워 하는 것
자신을 보호하기 위해 코드를 완벽하게 만들려는 마음에 코드를 공개하지 않거나 -> 생산성에 실질적인 영향
사소한 문제에 대해 완벽한 코드를 작성하는 것은 특히 어렵기 때문에 질질 끌거나 대부분의 시간을 허비
개발자는 종종 다른 사람의 코드를 경솔하게 비판한다.
"누군가 내 코드에 대해 그런 말을 하고 있나요?"
"그 사람이 내 코드를 본다면?", "그가 내 코드를 보고 있는건가?"
이러한 생각은 나를 가면 증후군으로 만들게 한다.
"나는 완벽한 코드가 존재한다고 믿지 않는다."
"코드에서 가장 안전한 것은 아무것도 변경하지 않는 것임을 상기" -> 수정이 아닌 확장
Last updated