좋은 소프트웨어 개발 습관

이 글은 조언이 아니라, 제게 효과가 있었던 내용입니다.

나쁜 습관을 들이는 것은 쉽지만 좋은 습관을 만드는 것은 어렵습니다. 저에게 효과가 있는 것을 적어두면 열심히 개발한 좋은 습관을 유지하는 데 도움이 됩니다. 현재 개발 중인 제품에서 속도를 높이고 적절한 수준의 품질을 유지하는 데 도움이 된 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})모의할 수 있는 자체 함수에 호출을 넣거나 엔티티 관리자 메서드를 더 쉽게 모의할 수 있는 테스트 유틸리티를 작성해야 할 가능성이 있습니다. 테스트하기 어려울 때 테스트를 작성하지 않는 것은 테스트를 원하지 않기 때문이 아니라 테스트하기 어렵습니다.

아마 훨씬 더 많은 것이 있겠지만, 10이라는 숫자가 적당할 것 같아요.

 

출처 https://zarar.dev/good-software-development-habits