05 Sep, 2024
원문

좋은 소프트웨어 개발 습관

2024년 9월 5일

이 글은 조언이 아니라, 제게 효과가 있는 것들입니다.

나쁜 습관은 쉽게 들이지만 좋은 습관을 만들기는 어렵습니다. 제게 효과가 있는 것들을 적어두면 열심히 개발한 좋은 습관들을 유지하는 데 도움이 됩니다. 다음은 제가 현재 개발 중인 제품의 속도를 높이고 적정 수준의 품질을 유지하는 데 도움이 된 10가지 사항을 무작위로 나열한 것입니다.

1. 커밋을 너무 작게 하는 것은 아닌가 싶을 정도로 작게 유지하세요. 특정 변경사항을 되돌려야 할 때가 언제 올지 모르니까요. 6일 전에 버그를 어디서 도입했는지 알고 그 커밋만 되돌릴 수 있다는 것은 병합 충돌의 야만성을 겪지 않아도 된다는 점에서 축복입니다. 제 경험상, 컴파일 가능한 소프트웨어는 커밋할 수 있어야 합니다.

2. Kent Beck의 성스러운 지혜의 말씀을 실천하세요: "원하는 각 변경에 대해, 그 변경을 쉽게 만들고(경고: 이것이 어려울 수 있습니다), 그 다음 쉬운 변경을 하세요". 모든 커밋의 적어도 절반은 리팩토링이 되도록 노력하세요. 지속적인 리팩토링은 10분 이내에 할 수 있는 개선 사항을 생각하는 것입니다. 이렇게 하면 더 큰 요구사항이 들어왔을 때 그 작은 개선 덕분에 작은 변경만으로도 만족시킬 수 있음을 발견하게 됩니다. 대규모 리팩토링은 좋지 않은 아이디어입니다.

3. 모든 코드는 부채입니다. 배포되지 않은 코드는 부채의 죽음의 신입니다. 코드가 작동하는지, 또는 최소한 아무것도 망가뜨리지 않는지 알아야 합니다. 테스트는 자신감을 주고, 프로덕션은 승인을 줍니다. 많은 배포로 인해 호스팅 비용이 약간 올라갈 수 있지만, 마지막으로 한 일이 진정한 진전의 징표였다는 것을 아는 것에 비하면 작은 대가입니다. 애자일 원칙 중 하나는 작동하는 소프트웨어가 진전의 주요 척도라고 말합니다. 여기서 '작동'과 '진전'이 많은 무게를 지고 있으므로, 저는 이를 자신만의 방식으로 정의했습니다. 작동은 배포될 수 있을 만큼 충분히 작동하는 것이고, 그것이 어떤 기능에 기여하는 코드라면 그것이 진전입니다.

4. 프레임워크의 능력을 테스트하고 있는지 알아야 합니다. 그렇다면 하지 마세요. 프레임워크는 이미 당신보다 훨씬 더 많이 아는 사람들에 의해 테스트되었으며, useState() 훅이 해야 할 일을 한다는 것을 믿어야 합니다. 컴포넌트를 작게 유지하면 많은 테스트의 필요성을 줄일 수 있습니다. 프레임워크가 컴포넌트에서 대부분의 무거운 작업을 할 것이기 때문입니다. 컴포넌트가 크다면 더 많은 복잡성을 도입하게 되고 이제 많은 테스트를 작성해야 합니다.

5. 특정 함수가 어디에도 맞지 않는다면, 그것을 위한 새로운 모듈(또는 클래스나 컴포넌트)을 만들고 나중에 그것의 자리를 찾을 수 있을 것입니다. 깊은 곳에서 맞지 않는다고 알고 있는 기존 모듈에 억지로 끼워 넣는 것보다는 새로운 독립적인 구조를 만드는 것이 낫습니다. 최악의 경우, 그것은 독립적인 모듈로 남게 되는데, 이것도 그리 나쁘지 않습니다.

6. API가 어떤 모습이어야 할지 모르겠다면, 테스트를 먼저 작성하세요. 그렇게 하면 "고객"(이 경우에는 당신 자신)을 생각하도록 강제됩니다. 코드를 먼저 작성하고 테스트를 나중에 했다면 생각하지 못했을 케이스들을 불가피하게 발견하게 될 것입니다. TDD에 대해 종교적일 필요는 없으며, 더 큰 단위로 작업해도 괜찮습니다(예: 통과시키기 전에 몇 줄 이상의 코드를 작성). 빨간색/실패 상태에서 작성해야 하는 코드의 양이 항상 작을 필요는 없습니다. 당신은 무엇을 하고 있는지 알고 있으니, 교조주의가 생산성을 방해하지 않도록 하세요.

7. 복사-붙여넣기는 한 번은 괜찮습니다. 두 번째로 중복을 도입할 때(즉, 세 번째 복사본)는 하지 마세요. 이 시점에서 충분히 좋은 추상화를 만들 수 있는 데이터 포인트가 있어야 합니다. 이 시점에서 같은 것의 구현이 분기될 위험이 너무 높으므로 통합이 필요합니다. 거의 같은 것의 여러 구현을 갖는 것보다는 약간 이상한 매개변수화를 갖는 것이 낫습니다. 이 상황이 다시 발생하면 네 가지 다른 구현을 통합하는 것보다 매개변수를 개선하는 것이 더 쉬울 것입니다.

8. 설계는 낡아집니다. 리팩토링을 통해 낡아지는 속도를 늦출 수 있지만, 결국에는 작동 방식을 변경해야 할 것입니다. 한때 당신에게 소중했고 그 당시에 자랑스러워했던 것에서 벗어나는 것에 대해 너무 나쁘게 생각하지 마세요. 당시에는 옳은 일을 한 것이며, 아무것도 변경할 필요가 없을 만큼 충분히 잘 해내지 못했다고 자책할 필요는 없습니다. 대부분의 경우 소프트웨어를 작성하는 것은 소프트웨어를 변경하는 것입니다. 그냥 받아들이고 계속 나아가세요. 완벽한 설계란 없으며, 변경은 소프트웨어 개발의 핵심입니다. 당신이 얼마나 잘 변경할 수 있느냐가 얼마나 소프트웨어 개발을 잘하느냐를 결정합니다.

9. 기술 부채는 세 가지 주요 유형으로 분류할 수 있습니다: 1) 현재 작업을 방해하는 것들, 2) 나중에 작업을 방해할 것들, 3) 나중에 작업을 방해할 수 있는 것들. 다른 모든 분류는 이 세 가지의 하위 집합입니다. #1에 해당하는 것들을 최소화하고 #2에 집중하세요. #3은 무시하세요.

10. 테스트 가능성은 좋은 설계와 관련이 있습니다. 쉽게 테스트할 수 없다는 것은 설계를 변경해야 한다는 힌트입니다. 때로는 그 설계가 당신의 테스트 설계일 수 있습니다. 예를 들어, em.getRepository(User).findOneOrFail({id})를 모의(mock)하기 어렵다면, 그 호출을 모의할 수 있는 자체 함수로 넣거나, 엔티티 매니저 메서드를 더 쉽게 모의할 수 있는 테스트 유틸리티를 작성해야 할 수 있습니다. 테스트하기 어려울 때 테스트를 작성하지 않는 것이지, 테스트하고 싶지 않아서가 아닙니다.

아마도 더 많은 내용이 있겠지만, 10은 좋은 숫자입니다.