소프트웨어 엔트로피 Software Entropy
-
시스템 내 불확실성 정도를 표현하는 용어
-
생겨나는 이유
- 개발자가 다른 사람이 쓴 코드를 이해하지 못할 때
- 서로 코딩 스타일이 다를 때
- 기술 스택과 제품 요구사항을 개선하다가
- 버그 수정
- 성능 최적화 -
관리할 수 있는 방식
- 코딩 스타일 통일
- 버그 탐자 도구
- 코드 리뷰를 하여 지식을 전파하고 코드의 일관성이 떨어지는 것을 방지
- 지속적인 리팩토링
기술 부채 technical debt
- 소프트웨어 엔트로피를 가중시키는 주요 요인
기존 코드의 단점을 수정하면서 나중으로 미뤄둔 작업을 뜻함
코드는 처음보다 더 깔끔하게 유지하자
인터넷에서 코딩 지식을 찾다 보면 간혹 "캠핑장을 떠날 때는 도착했을 때보다 깨끗하게 정리하라"라는 보이스카우트 원칙이 인용된다. 캠핑장처럼 코드베이스도 공유 공간이므로 가능하면 깔끔한 상태로 유지하는 편이 좋다.
버그를 수정하거나 새로운 기능을 추가할 때는 주변 코드를 정리하자. 그렇다고 지저분한 코드를 일부러 찾을 필요는 없다. 그저 기회가 생길 때 정리하면 된다. 코드를 정리하는 커밋은 동작을 변경하는 커밋과 구분하자. 커밋을 구분해두면, 코드를 정리하는 커밋을 유지하면서도 변경된 코드를 되돌릴 수 있다. 커밋의 크기가 작을수록 변경사항을 리뷰하기도 편하다.
깃 커밋 메시지를 작성하는 7가지 요령
How to Write a Git Commit Message
- 본문에는 코드가 '어떻게' 바뀌었는지보다는 '무슨' 코드가 '왜' 바뀌었는지를 설명한다.
되도록 검증된 기술을 사용하자
소프트웨어는 빠르게 변하는 분야다. 계속해서 새로운 도구나 언어, 프레임워크 등이 등장한다. 그렇기 때문에 온라인에서 찾을 수 있는 코드와 비교해보면 기존 코드는 마치 오래된 것처럼 보인다. 하지만 성공적인 기업이 오래된 라이브러리와 오래된 패턴으로 견고한 코드를 유지할 수 있는 데는 이유가 있다. 성공을 거두는 데는 시간이 걸리며, 기술을 갈아타는 것은 집중을 방해하는 요소가 되기 때문이다.
새로운 기술의 문제는 성숙하지 못하다는 점이다. 댄 맥킨리는 '평범한 기술을 선택하자'라는 제목의 발표에서 "평범한 기술은 어디서 문제가 발생하는지가 잘 알려져 있다는 장점이 있다"고 언급한 바 있다. 모든 기술은 문제가 발생할 여지가 있지만, 오래된 기술에서 야기되는 문제는 예측이 가능하다. 새로운 기술은 의외의 방법으로 문제를 유발한다. 또한 기술의 성숙도가 낮다는 것은 커뮤니티 규모가 작으며, 안정성도 낮고, 문서화도 미흡하며, 호환성도 낮다는 사실을 의미한다.
코드 재작성에 대한 욕구를 견디자
리팩토링을 하다 보면 기존 코드를 완전히 버리고 새로 작성하게 되는 경우가 있다. 기존 코드 리팩토링이 벅찬 나머지 기존 시스템을 통째로 날려버리고 모두 새로 작성하면 어떨까라는 생각까지 하게 된다. 코드를 새로 작성하는 것은 최후의 수단이라고 생각해야 한다. 수년에 걸친 우리의 경험에 비춰볼 때 의도대로 새 코드를 작성하기란 여간해선 쉽지 않다.
코드 재작성이 더 나은 경우도 있지만 대부분은 그렇지 않다. 코드를 새로 작성하고 싶은 욕구에 대해 솔직해져야 한다. 여러분이 좋아하지 않는 언어로 작성된 코드나 프레임워크라는 핑곗거리는 합당한 이유가 될 수 없다. 코드 재작성은 그에 들어가는 비용보다 장점이 클 때만 시도해야 한다. 코드 재작성은 위험할 뿐더러 소요 비용도 높기 때문이다. 엔지니어는 항상 코드 재작성이 얼마 안 걸릴 거라 예상한다. 특히 마이그레이션은 끔찍하다. 데이터를 옮겨야 하며, 업스트림과 다운스트림 시스템도 업데이트해야 한다. 이런 작업은 수년, 심지어 수십 년이 걸릴 수도 있다.
