어떤 시점에서 프로그램이 개발 중입니다. 기능이 항상 추가 또는 제거 또는 변경되고 있습니다. 모든 버전은 프로토 타입 일뿐입니다. 그래서 그 시점에서 슈퍼 클린 코드를 작성하는 데 많은 시간을 소비하지 않습니다. 물론 코드 표준을 특정 표준에 맞추려고하지만 시간은 항상 문제입니다.
그런 다음 프로그램이 완료되고 의사 결정자 (들)가 "그게 다"라고 말하는 시점이됩니다. 이 시점에서 작동하는 프로토 타입이 있지만 내부의 코드는 개발 단계에서 앞뒤로 약간 지저분합니다. 나는 테스트 / 최종 디버깅을 시작할 것으로 예상되지만 내 직감은 이제 어떻게 든 유지 보수 등을 쉽게하는 적절한 아키텍처를 제공하기 위해 물건을 정리하고 다시 작성해야한다고 말합니다.
일단 재료가 테스트되고 승인되면 다시 작성하는 것은 의미가 없습니다. 정기적으로 작업중인 '완료된'프로토 타입으로 서 있고 테스트 중에 버그가 발생하며 이것이 전체 개발 프로세스의 결과 인 스마트하지 않은 코딩의 결과임을 알 수 있습니다. 나는 테스트 중이며 버그 수정은 다시 작성 될 것입니다 ... 엉망입니다!
더 나은 / 교과서 방법이 있습니다. 그러나 모든 것이 교과서가 아닌 실제 작업 환경에서 일해야합니다.
그러면 작업 프로토 타입을 안정적인 코드 기반의 릴리스 버전으로 어떻게 전환합니까? 어쩌면 개발이 완료된 것을 고려하지 말아야하고 실제로는 정리 단계로보아야합니다 ... 잘 모르겠습니다. 여기에 도움이 필요합니다.
편집하다
몇 가지를 명확히하고 싶습니다.
코드를 깨끗하고 읽을 수 있기 직전과 직후에 100 %하고 있습니다. 그러나 나는 또한 일을 끝내고 코드의 아름다움을 깨끗하고 반짝이는 꿈을 꾸지 못합니다. 타협을 찾아야합니다.
종종 새로운 기능은 실제로 우리가 시도하고 싶은 것과 같은 것을 구현하는 것이 타당한 지 여부입니다. (예 : 실제 앱에서 실제 모양과 느낌을 얻기 위해 모바일 앱에서) 따라서 첫 번째 "보자"반복에서 너무 많은 작업을 정당화하지 않는 것은 작습니다. 그러나 때때로이 tech.debt를 언제 지불해야합니까? 이것이 바로이 질문에 관한 것입니다.
언젠가 기능의 절반이 삭제 될 것임을 알면 (지금까지 회사에서 충분한 경험을 쌓았음에도 불구하고) 내 문제에 접근하는 가장 좋은 방법은 그럼에도 불구하고 모든 것을 깨끗하게 작성하기 위해 여분의 시간을 투자하는 것임을 믿기가 어렵습니다. 그것의 대부분은 직후에 떨어질 것입니다. 일단 문제가 해결되면 큰 정리를 한 번하면 시간을 절약 할 수 있다고 생각합니다.