코드가 충분하다면 괜찮습니다

원문 : 코드가 충분하다면 괜찮습니다 - ShiftMag

It's OK if your code is just good enough

 

알고 있지만 실현하지 못하는 현실과의 괴리

 

충분히 좋은 코드는 기능을 빠르게 구현하는 것과 코드 품질을 유지하는 것 사이의 좋은 중간 지점입니다.

시험에 합격하기 위해 에세이를 써야 했던 학생에 대한 이야기를 들은 적이 있습니다. 그에게는 3개월의 기한이 있었다. 그 몇 달 동안 그는 페이지를 몇 번이고 다시 쓰느라 많은 어려움을 겪었습니다. 때때로 교수는 그를 확인했고 그는 항상 "아직 끝나지 않았습니다, 단순히 충분하지 않습니다"라고 대답했습니다.

마지막으로 교수는 "에세이가 충분히 좋은 채점인 것처럼 쓰라"고 제안했습니다. 이 접근 방식이 그에게는 낯설었지만 그는 조언을 받아들였습니다. 놀랍게도 그는 예상보다 높은 점수를 받으며 에세이를 채찍으로 마무리했습니다.

내가 태어난 곳에서는 "3", 단순히 1에서 5까지의 평균 등급이면 충분할 것입니다. 견고하고, 수용 가능하고, 좋습니다.

 

코드 품질의 5가지 음영

소프트웨어 개발자로서 우리는 에세이뿐만 아니라 논문을 써서 0과 1의 더미에 생명을 불어넣습니다. 우리 대부분은 코드가 5점 만점에 5점이 되기를 원할 것입니다. 그러나 이것이 추구할 가치가 있는 것입니까? 코드 품질의 다섯 가지 음영을 살펴보겠습니다.

1 – 똥

2 – 개념 증명

3 – 충분히 좋음

4 – 매우 좋음

5 – 완벽

 

1등급: 똥

이것은 당신을 땀을 흘리게 만드는 코드 유형입니다. 새로운 요구 사항에 대해 들으면 가슴이 철렁 내려앉습니다. 당신은 그것을 구현하는 데 오랜 시간이 걸릴 것이라는 것을 알고 있습니다. 당신이 할 수 있는 가장 좋은 일은 모든 것을 버리고 다시 쓰는 것입니다. 그런 코드는 용납되어서는 안되며, 우리는 똥을 보내서는 안됩니다.

 

2 학년 : PoC

일반적인 PoC 코드입니다. 이 코드가 좋지 않다는 것을 알고 있지만 잠시 동안 사용할 수 있습니다.

일반적인 문제 :

• 명확한 아키텍처, 명확한 경계가 없습니다.
• 많은 것들이 밀접하게 결합되어 있습니다
• 많은 엣지 케이스가 다루어지지 않습니다.
• 누락된 유효성 검사
• 부적절한 도메인 개체 모델링
• 너무 복잡하거나 너무 작은 테스트 스위트
• 코드가 깨끗하지 않습니다.

이상적으로 들리지 않을 수 있지만 가고자 하는 방향을 빠르게 결정하는 데 도움이 될 수 있습니다. 정말 빠르게 움직이고 진행하면서 반복할 수 있습니다. 이 코드 품질은 PoC 이니셔티브에 특히 적합합니다.

 

3등급: 충분히 좋음

충분히 좋은 코드는 기능을 빠르게 구현하는 것과 코드 품질을 유지하는 것 사이의 좋은 중간 지점입니다.

몇 가지 예외를 제외하고 일반적으로 2등급 코드에서 발견되는 많은 문제를 해결합니다.

• 일부 불필요한 추상화 수준
• 불분명한 이름
• 더 큰 함수나 클래스가 거의 없음(너무 큰 것은 없음)
• 여기저기서 예외의 오용
• 일부 코드 중복
• 중복 주석 달기
• 테스트의 가독성 문제

이 코드는 대부분의 응용 프로그램에 적합합니다. CRUD 작업을 처리하는 사람들에게 가장 적합할 것입니다. 또한 트래픽 흐름과 관련된 구성 요소에서 이 접근 방식을 사용하여 좋은 결과를 얻을 수 있습니다.

 

4등급: 매우 좋음

4등급은 유지 관리가 용이한 클린 코드 천국입니다. 충분히 좋은 문제가 없습니다.

infobip-spring-data-querydsl 라이브러리를 살펴보십시오. 완벽해 보이지만 그렇지 않습니다. 모든 것이 책에 의해 이루어지지만, 당신은 그것을 좋아하지 않을 수도 있고, 책의 일부를 싫어할 수도 있습니다. 예를 들어, 인터페이스가 너무 일반적이거나 객체 또는 다른 것 대신 프리미티브를 사용하는 데 신경이 쓰일 수 있습니다. 항상 싫어하는 것이 있을 것이고 그것은 괜찮습니다. :D.

이 등급의 문제점은 달성하기 어렵다는 것입니다. 우리는 정말 좋은 코드가 어떻게 생겼는지에 대해 서로 다른 배경과 견해를 가지고 있습니다.

저는 이 수준의 코드를 가진 프리랜서 회사와 함께 일한 적이 있습니다. 이를 달성하기 위해 그들은 매우 엄격한 정적 코드 분석과 정말 어려운 코드 검토를 시행했습니다. 정적 코드 분석은 대부분의 일반적인 문제가 코드베이스에 충분히 들어가지 않도록 하는 초석이었습니다. 원칙에 따라 여기에서 볼 수 있습니다. 코드 리뷰는 개발자와 아키텍트 1명, 그리고 리뷰의 품질을 확인하는 QA 담당자 2명으로 구성되었습니다.

4등급으로 도전하고 싶다면 이를 위한 인프라를 구축하고 모든 사람이 참여하도록 해야 합니다. 이 등급을 목표로 하면 속도가 느려지므로 PD로 추정할 때 고려해야 합니다. 장기적으로 분명한 이점을 볼 수 있습니다.

이 등급은 여러 프로젝트/팀에서 사용할 라이브러리를 구축하거나 시스템의 중요한 부분을 구축할 때 적합할 수 있습니다.

 

5 학년 : 완벽

존재하지 않습니다.

충분히 좋은 길을 갈 수 있습니다

매일 우리는 다양한 요구 사항, 다른 마감일, 범위 등에 직면합니다. 물론 항상 빠르고 간단하게 해결할 수 있는 것은 아니지만 대부분의 경우 충분히 좋은 접근 방식이 좋습니다.

필자는 명확한 아키텍처, 이해하기 쉬운 서비스 이름, 좋은 테스트를 갖춘 코드가 모든 상자를 체크한다고 생각합니다. 그리고 나는 그것을 좋아한다! 클린 코드 캔디일 필요는 없습니다. 사탕을 선호한다면 이 여분의 설탕이 프로젝트에 도움이 될 것이라고 PD와 팀을 설득해야 합니다.

선호하는 코딩 접근 방식은 무엇이라고 생각하십니까?