소프트웨어 개발은 늘 새로운 도전과 변화를 요구하는 과정입니다. 그 과정에서 좋은 습관을 유지하는 것은 생각보다 어려운 일입니다. 이번 글에서는 제가 실제로 적용하고 있는, 생산성을 높이고 품질을 유지하는 데 도움을 준 10가지 소프트웨어 개발 습관을 공유하고자 합니다. 이 글이 누군가에게는 작은 영감이 되기를 바랍니다.
1. 커밋을 최대한 작게 유지하라
커밋을 작게 유지하는 것은 문제가 발생했을 때 특정 커밋만 되돌려 복잡한 병합 충돌을 피할 수 있는 좋은 방법입니다. 저는 "컴파일 가능한 상태일 때 커밋할 수 있어야 한다"는 규칙을 따릅니다. 작은 커밋은 문제가 생겼을 때 원인을 빠르게 파악하고 수정하는 데 큰 도움이 됩니다.
추가 팁: 너무 작은 커밋으로 느껴질 때도 있을 것입니다. 하지만 문제 해결 시 커밋의 의미를 실감하게 되니, "작은 커밋을 유지하라"는 원칙을 따르는 것이 좋습니다.
2. 지속적인 리팩토링의 중요성
켄트 벡(Kent Beck)의 유명한 조언처럼, "변화를 원할 때, 먼저 변화를 쉽게 만들고, 그런 다음 쉽게 변화를 만들어라"는 말을 기억해야 합니다. 저는 모든 커밋 중 최소 절반이 리팩토링을 포함하도록 노력합니다. 지속적인 작은 리팩토링은 나중에 큰 요구사항이 들어왔을 때 큰 도움이 됩니다.
주의사항: 큰 리팩토링은 피하는 것이 좋습니다. 작은 개선 작업을 지속적으로 수행하여 큰 변화를 준비하는 것이 더 효율적입니다.
3. 배포가 곧 승인이다
코드는 그 자체로는 잠재적 부채입니다. 배포되지 않은 코드는 더욱 큰 부채입니다. 저는 코드가 정상 작동하는지 확인하기 위해 빠르고 자주 배포하려고 합니다. 테스트는 신뢰감을 주지만, 실제 배포는 진정한 승인을 의미합니다.
추가 팁: 호스팅 비용이 다소 증가할 수 있지만, 자주 배포하여 최신 작업이 실제로 작동하는지 확인하는 것이 중요합니다. 이는 품질을 보장하는 가장 확실한 방법입니다.
4. 프레임워크의 기능을 테스트하지 마라
프레임워크의 기본 기능은 이미 충분히 검증되었습니다. 예를 들어, React의 useState() 훅이 올바르게 작동하는지 테스트할 필요는 없습니다. 대신 컴포넌트를 작게 유지함으로써 프레임워크가 대부분의 작업을 처리하게 하고, 테스트의 필요성을 줄이는 것이 좋습니다.
추가 팁: 큰 컴포넌트는 복잡성을 증가시키고, 그만큼 많은 테스트가 필요합니다. 작고 명확한 컴포넌트 설계를 지향하세요.
5. 새로운 모듈을 주저하지 마라
특정 기능이 기존 모듈에 잘 맞지 않는다면, 새 모듈을 생성하는 것을 두려워하지 마세요. 억지로 기존 모듈에 기능을 추가하는 것보다 독립적인 모듈로 남겨두는 것이 나을 때가 많습니다.
추가 팁: 독립적인 모듈은 나중에 구조를 개선하거나 확장할 때 더 유연하게 대처할 수 있습니다.
6. 테스트 주도 개발(TDD)의 유연한 적용
API 설계가 명확하지 않다면 테스트를 먼저 작성하여 "고객"의 입장에서 생각해보세요. 테스트를 먼저 작성하면 예상하지 못했던 다양한 상황을 미리 고려할 수 있습니다. 하지만 TDD에 너무 매몰되어 교조주의적으로 따를 필요는 없습니다. 필요하다면 더 큰 단위로 작업한 후 테스트해도 됩니다.
추가 팁: 중요한 것은 생산성과 품질 사이의 균형입니다. 상황에 맞게 유연하게 적용하세요.
7. 복붙은 한 번만 허용하라
한 번의 복사는 괜찮습니다. 하지만 두 번째 복사부터는 중복을 제거해야 합니다. 세 번 이상 같은 코드를 복사해 사용하면 유지보수 시 큰 문제를 초래할 수 있습니다. 적절한 추상화를 통해 중복을 최소화하는 것이 중요합니다.
추가 팁: 약간의 불완전한 파라미터화도 중복된 코드를 여러 개 유지하는 것보다 낫습니다. 나중에 더 좋은 방식으로 개선할 수 있습니다.
8. 디자인의 변화 수용하기
디자인은 시간이 지남에 따라 낡아지기 마련입니다. 리팩토링을 통해 노화를 늦출 수 있지만, 결국에는 바뀔 수밖에 없습니다. 과거의 디자인에 집착하지 말고, 변화에 열린 마음을 가지세요. 완벽한 디자인은 없으며, 변화에 잘 대처하는 능력이 소프트웨어 개발의 핵심입니다.
추가 팁: 변화에 적응하는 것은 소프트웨어 개발자로서 성장하는 데 매우 중요한 요소입니다.
9. 기술 부채의 세 가지 유형
기술 부채는 크게 세 가지 유형으로 나눌 수 있습니다:
- 현재 작업을 방해하는 것
- 미래 작업을 방해할 가능성이 있는 것
- 방해할 가능성이 있을지도 모르는 것
첫 번째 유형의 부채는 최소화하고, 두 번째 유형에 집중하며, 세 번째 유형은 무시하는 것이 좋습니다. 현재와 미래의 생산성에 직접적으로 영향을 미치는 부채에 우선순위를 두세요.
10. 테스트 가능성과 좋은 설계
테스트하기 어렵다면 설계에 문제가 있을 가능성이 큽니다. 테스트 설계를 개선하거나, 테스트하기 쉽게 코드를 분리하는 것이 좋습니다. 테스트가 작성되지 않는 이유는 대부분 테스트하기 어려운 구조 때문이며, 이는 곧 설계의 문제일 수 있습니다.
추가 팁: 테스트 가능성을 고려한 설계는 유지보수성과 확장성을 높이는 데 큰 기여를 합니다.
이 10가지 습관은 제가 소프트웨어 개발자로서 매일 실천하려고 노력하는 부분들입니다. 좋은 습관은 꾸준한 노력을 통해 만들어집니다. 이 글이 여러분에게도 좋은 개발 습관을 만들어가는 데 도움이 되길 바랍니다. 혹시 여러분만의 좋은 습관이나 팁이 있다면 댓글로 공유해주세요!
참고 링크
'DevOps' 카테고리의 다른 글
OpenSearch Performance Analyzer: 클러스터 성능 최적화를 위한 필수 도구 (0) | 2024.11.22 |
---|---|
Python 코드로 클라우드 아키텍처를 그리다 - Diagrams 소개 (0) | 2024.11.08 |
Git을 더 강력하게 만드는 스크립트 모음, ToolGit을 소개합니다! (0) | 2024.11.06 |
깔끔한 커밋 히스토리를 만드는 방법: Git Squash의 모든 것 (0) | 2024.09.30 |
GitLab Merge Request 충돌 해결하기: 웹에서 vs. 로컬에서 (0) | 2024.09.30 |