빠르고 더러운 프로그래머는 그들이 올바르게 알고 있다는 것을 어떻게 알 수 있습니까?

프로그래머에게 왜 깨끗한 코드를 작성해야하는지 물어 보면 가장 큰 대답은 유지 보수성입니다. 그것이 나의 목록에있는 동안, 나의 주된 이유는 더 즉각적이고 이타 적이 지 않습니다. 새 코드가 너무 더러운 지 새 코드가 올바른지 알 수 없습니다. 나는 개별 기능과 코드 라인에 너무 집중하여 첫 번째 초안을 끝내고 다시 큰 그림을 보러 돌아갈 때 때로는 매우 깔끔하게 맞지 않습니다. 청결을 위해 1 ~ 2 시간 동안 리팩토링을하면 복사 / 붙여 넣기 오류나 거친 초안에서 감지하기 어려운 경계 조건이 자주 발견됩니다.

그러나 일부 사람들은 소프트웨어 배송을 위해 의도적으로 더티 코드를 의도적으로 체크인하고 "나중에 정리"계획을 세우는 것이 좋다고 생각합니다. 가독성이 이상적이지 않을 때 코드의 정확성을 확신 할 수있는 실용적 기술이 있습니까? 개발할 가치가있는 기술입니까? 아니면 일부 사람들이 쉽게 받아 들일 수있는 코드에 대한 확신이 부족합니까?

코드가 올바르지 않을 수 있습니다.

그러나 중요하지 않을 수 있습니다.

다음과 같은 상황에서는 빠르고 더러운 것이 올바른 방법 일 수 있습니다.

• 코드 수명이 짧습니다 . 예를 들어, 임시 프로그램을 사용하여 많은 데이터를 표준 형식으로 변환하고 있습니다.
• 실패의 부정적인 영향은 낮습니다 .
  • 변환하는 데이터는 중요하지 않으며 오류는 쉽게 수정할 수 있습니다.
  • 최종 사용자는 동정심 많은 프로그래머로, 오류 메시지에 대해 추론하고 입력을 마사지하여 문제를 해결합니다.

때로는 코드가 강력하고 모든 가능한 입력을 처리하는 것이 중요하지 않습니다. 때때로 그것은 당신이 가지고있는 알려진 데이터를 처리해야합니다.

이 상황에서 단위 테스트로 코드를 더 빨리 작성하는 데 도움이되는 경우 (이 경우에 해당) 사용하십시오. 그렇지 않으면 코드가 빠르고 더러워지고 작업이 완료됩니다. 트리거되지 않는 버그는 중요하지 않습니다. 즉석에서 해결하거나 해결하는 버그는 중요하지 않습니다.

절대적으로 중요한 것은 이러한 상황을 잘못 진단하지 않는 것입니다. 코드가 한 번만 사용되기 때문에 더 빠르고 더러운 코드를 작성하는 경우 누군가 더 나은 코드가 필요한 일부 프로젝트에서 코드를 재사용하기로 결정하면 해당 코드에 더주의를 기울여야합니다.

그들은하지 않습니다. 저는 현재 "빠르고 더러운"프로그래머가 만든 코드베이스에서 "나중에 정리"를하고 있습니다. 그들은 오래 전부터 사라졌고 코드는 계속되어 망각으로 나아가고 있습니다. 카우보이 코더 는 일반적으로 소프트웨어가 가질 수있는 모든 잠재적 실패 모드를 이해하지 못하고 회사 (및 고객)에게 노출 될 위험을 이해하지 못합니다.

좋아, 완전한 downvote- 미끼의 위험에, 나는 반대 견해를 "악마 옹호"할 것입니다.

개발자가 적절한 연습 및 코드 청결과 같은 것에 지나치게 관심을 갖는 경향이 있다고 제안합니다. 나는 그 것들이 중요하지만, 당신이 결코 배를 보내지 않는다면 아무 것도 중요 하지 않다고 제안합니다 .

이 사업을 한 적이있는 사람이라면 어느 정도 소프트웨어를 무기한으로 피들 링 할 수 있다는 데 동의 할 것입니다. 듀크 누켐 포에버 그 멋진 기능이나 긴급한 리팩토링 작업을 그냥 치워야 할 때가 왔습니다.

나는 이것에 대해 동료들과 여러 번 싸웠습니다. 항상 하나 더 조정해야합니다. "올바른"것으로하기 위해 "해야 할"다른 작업이 있습니다. 당신은 항상 그것을 찾을 수 있습니다. 언젠가는 현실 세계에서 충분하면 충분해야합니다. 실제, 실제 배송 소프트웨어는 완벽하지 않습니다. 없음 기껏해야 충분합니다.

그러한 프로그래머 들은 자신들이 올바르게 알고 있다는 것을 거의 알지 못하고 믿습니다 . 그리고 그 차이는 인식하기 쉽지 않을 수 있습니다.

단위 테스트에 대해 배우기 전에 프로그래밍에 사용한 방식을 기억합니다. 그리고 나는 첫 번째 괜찮은 단위 테스트를 실행 한 후 완전히 다른 수준의 자신감과 신뢰감을 기억합니다. 내 코드에 대한 그러한 신뢰 수준이 이전에 존재했는지 알지 못했습니다.

이 경험이 부족한 사람에게는 그 차이점을 설명하는 것이 불가능합니다. 그래서 그들은 평생 동안 자비 롭게 (그리고 무지하게) 상황을 고려하여 최선을 다하고 있다고 믿으며 평생 동안 코드와기도 모드로 발전 할 수 있습니다.

즉, 문제의 전체 공간을 완전한 흐름 상태로 유지할 수있는 훌륭한 프로그래머와 예외적 인 사례가 실제로있을 수 있습니다. 나는 무엇을 쓸지 완벽하게 알았을 때, 코드가 나에게서 쉽게 날아 갔고, 모든 특별한 경우와 경계 조건을 예측할 수 있었고 결과 코드가 제대로 작동했습니다 . 나는 그러한 흐름의 상태에 오랫동안 또는 대부분의 시간 동안 머무를 수있는 프로그래밍 천재가 있으며, 그들이 생산하는 것은 노력 없이도 아름다운 코드입니다. 그런 사람들은 이미 알고 있는 것을 확인하기 위해 퓨니 단위 테스트를 작성할 필요가 없다고 생각합니다.. 그리고 당신이 정말로 천재라면 괜찮을 것입니다 (그러나 그럼에도 불구하고, 당신은 그 프로젝트 주위에 영원히 있지 않을 것이며, 당신의 후임자에 대해 생각해야합니다 ...). 그러나 그렇지 않다면 ...

그리고 그것을 직면하자, 당신은 그렇지 않을 가능성이 있습니다. 나는 나 자신이 아니라는 것을 안다. 나는 종종 내 자신의 실수로 인한 드문 흐름의 순간과 수많은 슬픔과 슬픔을 겪었습니다. 정직하고 현실적이어야합니다. 사실, 나는 위대한 프로그래머들이 자신의 실수와 과거의 실수를 완전히 알고 있다고 생각하기 때문에 그들의 가정을 두 번 확인하고 작은 단위 테스트를 작성하는 습관을 의식적으로 발전 시켜서 스스로를 안전하게 지키고 있습니다. ( "저는 훌륭한 프로그래머가 아닙니다. 훌륭한 습관을 가진 훌륭한 프로그래머입니다." -Kent Beck.)

단위 테스트 . 모든 코드에 대한 확신을 가질 수있는 유일한 방법입니다 (더러운 지 여부).

부수적으로;

지름길이 긴 지연 (Pippin)

단위 테스트 및 코드 조정이 얼마나 많이 수행 되더라도 합리적인 복잡도의 소프트웨어 시스템이 완벽하지 않다는 점을 이해하는 것이 좋습니다. 어느 정도 혼란과 예상치 못한 취약점은 항상 코드 내에 숨어 있습니다. 그렇다고 좋은 코드를 만들거나 단위 테스트를 수행해서는 안된다는 의미는 아닙니다. 물론 이것은 중요합니다. 추구해야 할 균형이 있으며 이는 프로젝트마다 다릅니다.

개발 될 기술은 특정 프로젝트에 어떤 수준의 '완벽 성'을 사용해야 하는지를 이해하는 것입니다. 예를 들어, 12 개월 프로젝트 타임 라인으로 전자 의료 기록 애플리케이션을 작성하는 경우 일회성 컨퍼런스 등록 웹 앱보다 테스트 및 코드 유지 보수에 더 많은 시간을 할애해야합니다. 금요일까지 배포해야합니다. 프로그래머가 코드를 너무 바빠서 EMR 앱을 사용하는 사람이 느슨해 지거나 등록 앱이 제 시간에 배포되지 않으면 문제가 발생합니다.

하위 시스템 내에서는 빠르고 더러운 것이 완벽합니다 . 당신의 쓰레기와 나머지 시스템 사이에 잘 ​​정의 된 인터페이스와 당신이 못생긴 빠르고 더러운 코드가 옳은 일을한다는 것을 확인하는 좋은 단위 테스트가 있다면, 그것은 완벽하게 괜찮을 것입니다.

예를 들어, 타사에서 가져온 일부 파일을 구문 분석하기 위해 정규 표현식과 바이트 오프셋에 대한 끔찍한 해킹이있을 수 있습니다. 그리고 예제 파일을 구문 분석 한 결과가 예상 한 것임을 테스트 한 것으로 가정합니다. 당신이 할 수 있도록 이것을 정리할 수 있습니다 ... 모르겠어요, 제 3자가 파일 형식을 변경할 때 더 빨리 반응합니까? 그것은 종종 자주 일어나지 않습니다. 아마도 그들은 완전히 새로운 API로 변경 될 것이고 아마도 오래된 파서를 버리고 같은 API에 맞는 새로운 파서를 꽂을 것입니다.

빠르고 더러운 문제가되는 곳은 아키텍처가 빠르고 더러운 경우입니다. 핵심 도메인 객체와 인터페이스를 잘 고려해야하지만 일반적으로 파이퍼를 지불하지 않아도 시스템의 가장자리가 복잡 할 수 있습니다.

내가 아는 빠르고 더러운 프로그래머에 대한 이야기가 있습니다.

단위 테스트를하는 사람이 시간 낭비라는 것을 알고 있습니다. 많은 논쟁 끝에 마침내 그는 글을 썼습니다. &&와 ||를 뿌린 하나의 긴 메소드로 구성되었습니다. assertTrue에 부울을 반환했습니다. 이 문장은 20 줄에 걸쳐있다. 그런 다음 그는 모든 방법에 한 줄이 있고 주요 방법에는 공백이없는 1000 줄이 넘는 클래스를 작성했습니다. 텍스트의 벽이었다. 그의 코드를 검토하고 새로운 줄을 삽입했을 때, 그는 '왜'를 물었다. 나는 '가독성 때문에'라고 말했다. 그는 한숨을 쉬고 삭제했다. 그는 "만지지 마세요, 작동합니다!"라고 댓글을 달았습니다.

내가 마지막으로 그와 이야기했을 때, 그는 회사의 웹 사이트를 코딩했습니다. 그는 버그를 찾으려고 노력했다. 그는 지난 3 일 동안 하루에 8 시간 동안 그렇게했습니다. 조금 후에 나는 그에게 다시 이야기했고, 그의 팀 동료는 리터럴의 가치를 바꾸었고 다른 곳에서는 그것을 업데이트하지 않았다. 상수가 아니었다. 그래서 그는 다른 리터럴도 변경하여 버그가 수정되었습니다. 그는 팀원의 스파게티 코드에 대해 불평했습니다. 그는“하하, 우리 모두 디버거와 함께 밤새도록 머무르는 것이 무엇인지, 하나의 불쾌한 버그로 잠을 자지 않는 것은 무엇인지 알지 못한다”고 말했다.

또한 그는 프로그래밍 서적과 블로그를 읽는 것이 쓸모 없다고 생각합니다. 그는 '그냥 프로그래밍을 시작하십시오'라고 말합니다. 그는 12 년 동안 그 일을 해냈으며 그는 훌륭한 프로그래머라고 생각합니다. / facepalm

몇 가지 더 있습니다.

또 다른 시간에 우리는 웹앱을위한 DatabaseManager 클래스를 작성했습니다. 그는 모든 데이터베이스 호출을 넣었습니다. 상상할 수있는 모든 것에 대해 50 가지가 넘는 방법을 가진 신 클래스였습니다. 모든 컨트롤러가 모든 데이터베이스 메소드에 대해 알아야 할 필요는 없기 때문에 서브 클래스로 나누는 것이 좋습니다. 그는 전체 데이터베이스에 대해 하나의 클래스를 갖는 것이 '쉽고'필요할 때마다 새로운 메소드를 추가하는 것이 '빠르기'때문에 동의하지 않았습니다. 결국 DatabaseManager는 사용자 인증에서 고고학 사이트 위치 정렬에 이르기까지 100 가지가 넘는 공개 방법을 가지고있었습니다.

빠르고 더러운 것을 피하는 것에 대한 나의 교훈은 6 개월 동안 1 년의 가치가있는 것으로 추정 된 것 (과대 평가되지 않은 것)을 전달할 때였습니다. 작업을 시작하기 전에 방법론을 연구하기로 결정했습니다. 결국 나는 3 개월간의 연구에 투자했고 나머지 3 개월 동안 연구를 수행 할 수있었습니다.

공통 기능을 식별하고 해당 요구 사항을 처리하는 데 필요한 라이브러리를 구축함으로써 큰 ​​이점을 얻었습니다. 사용 가능한 라이브러리 루틴이있을 때 여전히 코더가 자체 코드를 작성하는 것을 봅니다. 이러한 코더는 나중에 동일한 문제를 해결해야 할 때 종종 동일한 코드를 다시 작성하거나 최상의 코드로 잘라 붙여 넣습니다. 버그 수정은 항상 일부 코드 사본 만 포착합니다.

한 개발자가 라이브러리 코드를 사용하도록 요청했을 때 "응답하지 않습니까? 학교에서 내 코드를 모두 작성해야했습니다."라고 대답했습니다.

어떤 경우에는 "모든"버그를 찾아서 동작을 검증하는 대규모 회귀 테스트가있을 수 있으므로 빠르고 더러운 코딩 기술이 가능합니다. 그러나 대부분 나쁜 프로젝트 계획과 문제를 해결하는 것이 중요합니다.

그리고 "나중에 정리"를 잊지 마십시오. 드문 경우이지만, 프로그래머는 처음 작업을 수행했을 때보 다 비용이 많이 드는 코드를 대부분 잊어 버렸습니다.

제품이 배송됩니다.

진공 상태에서는 코드가 존재하지 않습니다. 나는 빠르고 더러운 카우보이 카우보이의 결과로 전례없는 슬픔의 화재를 겪었습니다. 그러나 때로는 최상의 코드를 작성하는 방법을 모른 채 제품을 완성하는 것이 우선 순위입니다. 궁극적으로, 제품이 제대로 배송되고 제대로 작동하면 사용자와 고객은 코드가 얼마나 "나쁜"지 알거나 신경 쓰지 않을 것입니다. 내가 문 밖으로 나가는 한.

그렇습니다. 이것은 조직 문제에서 발생하며 "절대 일어나지 않아야합니다." 그러나 관리가 잘못되고 마감 기한이 긴 조직에서 코드를 작성하는 경우 개별 프로그래머 수준에서 옵션이 제한됩니다.

나는 그들이 쉽게 유지할 수 없다면 정직하게 말할 수 있다고 생각하지 않습니다. 그들이 "나중에 정리해야한다"고 인정하면 충분히 생각하지 못한 것이있을 수 있습니다. 철저히 테스트하면 더티 코드와 관련된 문제 만 발견 할 수 있습니다.

저는 개인적으로 "더러운 코드 작성"기술을 개발하고 정확성을 확신하는 것을 목표로하지 않습니다. 차라리 처음에 적절한 코드를 작성하고 싶습니다.

그들이 올바르게 이해했는지 어떻게 알 수 있습니까? 테스트는 간단한 답변입니다.

좋은 품질 보증팀에서 코드를 철저히 테스트하여 통과 한 경우 코드를 제대로 받았다고 말할 수 있습니다.

빠르고 더러운 코드를 작성하는 것은 습관이되어야하는 것이 아니라 동시에 20 분 동안 코드를 작성하는 데 사용할 수있는 경우가 있습니다. 비즈니스 세계에서는 때로는 20 분만 있으면 업무를 수행 할 수 있으며 마감일이 빠르고 더러워 질 때 유일한 옵션 일 수 있습니다.

나는 나 자신의 양쪽에 있었고, 더러운 코드를 수정해야했고 내가 개발중인 시스템의 한계를 해결하기 위해 내 자신을 작성해야했습니다. 비록 더럽고 약간의 해킹이 있었지만 때로는 철저하게 테스트되고 오류 처리 기능이 내장되어 있기 때문에 문제가 발생하면 시스템의 나머지 부분을 파괴하지 않기 때문에 작성했습니다.

이러한 빠르고 더러운 프로그래머를 살펴보면 한 가지만 기억해야합니다. 고객은 일반적으로 제품이 배송 될 때까지 지불하지 않고 UAT 테스트에 참여하여 빠르고 더러운 코드에서 버그를 찾습니다. 제품이 거의 작동하는 제품을 가지고있을 때 꺼낼 가능성은 훨씬 적지 만, 아무 것도 가지고 있지 않으면 "x를 곧 고정시킬 것입니다"또는 " "완벽하게 일하는 것"은 경쟁 업체를 포기하고 갈 가능성이 높습니다.

물론이 이미지는 아무도 빠르고 더러운 코드의 위험을 과소 평가해서는 안된다는 것을 보여줍니다!

나는 당신이 그 길을 따라 가기 시작해야한다고 생각하지 않습니다. 빠르고 더러워지면 더 빨리 마무리 할 수 ​​있다는 일시적인 이점을 얻을 수 있지만 결국에는 10 배의 비용을 지불해야합니다.

제 생각에는 정확성을 위해 Q & D 코드를 판단하는 법을 배우는 것은 나쁜 습관이기 때문에 개발할 가치가 없습니다. 이유는 다음과 같습니다.

나는 "빠르고 더럽다"와 "모범 사례"가 전혀 어울리지 않는다고 생각합니다. 많은 코더 (자체 포함)는 트리플 제약 조건 의 왜곡으로 인해 빠르고 더러운 코드를 크랭크했습니다 . 내가 그것을해야 할 때, 그것은 일반적으로 접근 마감일과 결합 된 스코프 크리프의 결과였습니다. 내가 체크인 한 코드를 알고 있었지만 입력 세트가 주어지면 적절한 출력을 내 뿜었습니다. 이해 관계자에게 매우 중요한 것은 정시에 배송되었습니다.

원래의 CHAOS 보고서 를 보면 Q & D가 좋은 아이디어가 아니며 나중에 (정비 또는 확장 중) 예산을 삭감 할 것임을 분명히 알 수 있습니다. Q & D 코드가 올바른지 판단하는 방법을 배우는 것은 시간 낭비입니다. Peter Drucker가 말했듯이, "무효해서는 안되는 것을 효율적으로하는 것만 큼 쓸모있는 것은 없습니다."

새 코드가 너무 더러운 경우 새 코드가 올바른지 알 수 없습니다.

"더러운"은 사람들마다 다른 것을 의미합니다. 나에게 이것은 주로 의존하지 말아야 할 일에 의존한다는 것을 의미하지만, 단기적으로 일할 것으로 기대할 수도 있습니다. 예 : 버튼의 높이를 계산하는 대신 높이가 20 픽셀이라고 가정합니다. 이름을 해석하는 대신 IP 주소를 하드 코딩하는 단계; 배열을 제공하는 메소드가 보장하지는 않지만 배열을 알고 있기 때문에 정렬 할 수 있습니다.

더티 코드는 깨지기 쉬우므로 테스트하고 지금 은 작동한다는 것을 알 수 있지만, 앞으로 어느 시점에서 깨질 것입니다 (또는 모든 사람이 알을 잃을 우려가 있기 때문에 난각을 밟도록 강요합니다).

약간 논란의 여지가 있지만, 아무도 그들의 코드가 100 % 정확하고 100 % 오류 가 없다는 것을 진정으로 아는 사람은 아무도 없다고 주장합니다 . 실제로 테스트 범위가 우수하고 BDD / TDD 모범 사례를 엄격하게 적용하더라도 오류가 포함 된 코드를 개발할 수 있으며 부작용도 포함 할 수 있습니다!

코드를 작성하고 작동한다고 가정하면 개발자 자신의 능력에 대한 개발자의 인식에 대한 과도한 자신감을 의미하며, 문제가 발생할 때 (필연 히 그럴 것입니다) 특히 다른 개발자가 필요한 경우 코드를 디버깅하고 유지 관리하는 데 많은 비용이 소요됩니다 나중에 코드를 유지합니다. 실질적인 차이점은 훌륭한 소프트웨어 엔지니어링 사례를 적용하여 코드가 대부분의 시간 동안 작동 할 가능성이 있으며 오류가 발생하면 디버깅하기가 더 쉽다는 확신을 가질 수 있다는 것입니다. 나중에 해당 코드를 작업하는 사람에 관계없이 변경하고 유지 관리하는 데 훨씬 적은 비용이 듭니다.

중요한 점은 잘 짜여지고 잘 테스트 된 코드를 통해 다른 사람들 이 자신의 코드에 대한 신뢰를 가질 수 있다는 것입니다. 대부분의 경우 자신의 신뢰보다 더 중요합니다.

더티 코드가 제대로 테스트되면 신뢰할 수 있습니다. 문제는 더티 코드를 테스트하는 단위는 일반적으로 매우 어렵고 번거 롭다는 것입니다. 이것이 TDD가 좋은 이유입니다. 먼지와 냄새를 드러내고 제거합니다. 또한 단위 테스트는 종종 시간 확보로 인해 가장 먼저 발생합니다. 따라서 가장 깨끗한 사람이 자신이 한 가장 깨끗한 코드를 만든 경우에도 시간 보장으로 인해 단위 테스트를 생략해도 여전히 조금 신뢰하지 않을 것입니다.

좋은 프로그래머 (Quick & Dirty 등)는 올바른 지식을 가지고 있다고 생각하는 사람들이 없습니다. 그들은 모든 대형 시스템에 버그와 결함이 있다고 가정하지만, 어느 시점에서 코드를 배송 할 수있을 정도로 충분히 낮은 위험 또는 충분히 낮은 비용이 발생할 정도로 충분히 테스트되고 검토 될 수 있다고 가정합니다.

그렇다면 왜 프로그래머가 Quick & Dirty라고 불리는가? 나의 가설은 다윈의 선택이다. 실행 가능한 코드를 빨리 배송하거나 때로는 경쟁이 시작되기 전에 배송하거나 예산이 소진되거나 회사가 파산 한 프로그래머. 따라서 그들의 회사는 여전히 정리해야 할 혼란에 대해 불평하기 위해 새로운 프로그래머를 고용하고 있습니다. 클린 코드 (Clean Code)도 제공되지만, 퀵앤 더티 (Quick & Dirty) 코더를 멸종시킬 정도로 차분하지는 않습니다.

아마도 수명이 짧거나 비즈니스에 미치는 영향이 적거나 코드를 작성하는 데 시간이 거의 없기 때문에 코드의 최적 부분이 아닌 것이 차이를 만들 수 없다고 생각할 수도 있습니다. 정답은 당신이 정말로 모른다는 것입니다. "이것은 작은 기능"이라고 말하거나 "우리가 할 수있는 한 빠르고 간단하게 만들어 보자"라는 말을들을 때마다 올바른 디자인에 대해 생각하는 데 불충분 한 시간을 보냅니다. 아르:

1-) 프로젝트가 커지고 팀 동기 부여가 줄어든다. 이 경우 프로젝트는 혼돈을 향한 빠른 차선으로 이어질 수 있습니다.

2-) 프로젝트가 최적이 아닌 솔루션으로 알려지고 새로운 솔루션이나 새로운 솔루션만큼 비싼 리팩토링을 선호하여 사용을 권장하지 않습니다.

항상 최선의 코드를 작성하십시오. 시간이 충분하지 않으면 왜 더 필요한지 설명하십시오. 제대로 제작되지 않은 작업으로 자신을 위험에 빠뜨리지 마십시오. 항상 더 나은 전문가가 되십시오. 당신이 합리적이라면 아무도 당신을 처벌 할 수 없습니다. 그들이 할 경우, 당신이 일해야 할 곳이 아닙니다.

선배와상의하고 실패의 영향이 있다면이를 평가하십시오. 예를 들어, 더러워진 하루를 고칠 수 있고 강력한 코드를 수정할 수있는 상황에서는 설계 변경에 영향을 미치는 모든 워크 플로우를 완전히 검증하기 위해 4-6 개월 + 추가 검증 시간이 소요될 수있는 설계 및 아키텍처 변경이 필요합니다.

또한 목록의 시간 + 용량 + 우선 순위에 따라 결정을 내려야합니다. 선배 또는 경험이 많은 사람들과 팀에서 잘 논의하면 팀과 그 결과에 가장 적합한 결정을 내릴 수 있습니다.

클린 코드는 에스컬레이션을 저장하기위한 더티 코드, 고객의 결정을 내리거나, 결정을 내리고, 스토퍼를 보여주고, 조직의 평판을 더럽 히고, 더티 코드가 더 깨끗한 코드를 만드는 더 많은 곳에서 가장 먼저 접근하는 방법입니다.