나는 나의 일상 업무로 끝날 수있는 몇 가지 개인 프로젝트를 시작 / 작업 할 계획입니다. 어떻게 생각해야합니까?

• 프로토 타입만으로 쉽게 확장 할 수 있도록 최적화하고 리팩토링하는 데 많은 시간이 소요되는 기본 코드 만 작성하십시오.

• 처음부터 깨끗하고 최적화 된 문서화 된 코드를 작성하십시오. 시간이 지나도 비용 효율적이지 않으면 삭제 될 것이라는 점을 명심하십시오.

업데이트 : YAGNI와 sunpech 및 M.Sameer 답변을 결합하면 나에게 완벽합니다. :) 도움을 주신 모든 분들께 감사드립니다.

YAGNI 이후 오늘날 요구되는 요구 사항을 구현하기 위해 테스트 중심 개발을 통해 깨끗한 코드를 작성하는 세 번째 옵션이 있습니다.

에서 순간 필요는 없지만 쓰기 코드에 유혹 ... 몇 가지 단점에서 미래 겪고있다에있을 수 있습니다 당신이 그것을 필요 않을거야 :

• 소요 시간은 필요한 기능을 추가, 테스트 또는 개선하는 데 소요됩니다.
• 새로운 기능은 디버깅, 문서화 및 지원되어야합니다.
• 새로운 기능은 향후 수행 할 수있는 작업에 제약을가하므로 불필요한 기능으로 인해 나중에 필요한 기능을 구현하지 못할 수 있습니다.
• 기능이 실제로 필요할 때까지 기능을 완전히 정의하고 테스트하기가 어렵습니다. 새 기능이 올바르게 정의 및 테스트되지 않은 경우 결국 필요하더라도 올바르게 작동하지 않을 수 있습니다.
• 코드 팽창으로 이어집니다. 소프트웨어가 커지고 복잡해집니다. 사양과 어떤 종류의 개정 관리가 없으면 기능을 사용할 수있는 프로그래머에게는이 기능이 알려지지 않을 수 있습니다.
• 새로운 기능을 추가하면 다른 새로운 기능이 제안 될 수 있습니다. 이 새로운 기능들도 구현된다면, 크리핑 기능에 눈덩이 효과가 생길 수 있습니다.

결과적으로 프로토 타입뿐만 아니라 처음부터 깨끗하고 최적화 된 문서화 된 코드를 작성해서는 안됩니다.

현재와 ​​미래의 요구를 가장 잘 충족 할 수 있다는 것을 알고 지금 필요한 코드를 작성하십시오.

평소와 같이 ...

그것은 달려있다

위험을 완화하거나 알 수없는 노출을 프로토 타이핑하는 경우 코드를 작성하고 완료되면 버릴 것으로 예상하십시오.

반복적 인 세분화를 위해 프로토 타입을 제작하는 경우이를 코딩하고 자주 수정하고 리팩토링해야합니다.

당신은 실제 제품을 쓰기 시작하는 경우 그러나 당신은 게으른 될 수 있도록 프로토 타입을 호출 하고 게으른하지 말고, 잘 처음으로 쓰기

프로토 타이핑을하는 경우 왜 깨끗한 코드에 대해 생각하고 있습니까? 프로토 타입 제작의 개념은 개념이나 아이디어를 입증하고 나중에 버려야한다는 것입니다.

깨끗한 코드를 작성하거나 프로토 타이핑을 위해 신속하게 작업을 수행하는 것 중에서 선택하는 것에 대해 이미 생각하고 있다면 후자를 선택한다고 말함으로써 대부분의 사람들과 동의하지 않을 것입니다. 특히 초기 개발에 대해 이야기 할 때. 나는 깨끗한 코드를 작성하지 말라고 말하는 것이 아니라 아이디어를 내고, 그것이 방향으로 가고 있는지 확인한 다음 다시 정리하십시오.

소프트웨어 개발자로서 우리는 일을 올바르게하고 깨끗하게하는 일 에 매료되어 우리가 제공하는 코드가 아니라 문제에 대한 해결책이라는 것을 깨닫지 못합니다 .

논문을 작성할 때 코딩을 생각합니다.

논문을 작성할 때 우리는 어딘가에서 시작하고 아이디어, 개요 등을 스케치합니다. 모든 세부 사항을 포함하지 않거나 완성 된 모양을 갖지 않습니다. 기본적으로 첫 번째 초안, 두 번째 초 등입니다. 더 세련되고 완성 된 용지로 이동하는 과정에서 많은 부분이 재 작성, 교체 및 / 또는 제거 될 것입니다. (분명히이 비유는 코드가 실제로 종이처럼 완성되거나 완성되었다고 말할 수는 없습니다.)

프로토 타입에는 두 가지 유형이 있습니다.

• 개선 및 수정을 통해 발전하여 최종 제품이되도록하는 혁신적인 프로토 타입 .
• 처분 할 수있는 프로토 타입 다음 요구 사항을 수집하고 초기 프로젝트 단계에서 고객의 피드백 효과를 높일와 만 존재 완전히 분리되었습니다 및 최종 제품의 개발은 처음부터 시작됩니다.

Capers Jones에 따르면 혁신적인 프로토 타입은 품질이 낮은 최종 제품을 생산하므로 안정성에 도달하는 데 훨씬 더 많은 노력과 시간이 필요합니다.

따라서 프로토 타이핑에 대해 생각할 때 고객이 요구 사항에 대한 더 나은 아이디어와 세부 정보를 얻을 수 있도록 최대한 빨리 무언가를 볼 수 있다면 일회용 프로토 타입이되어 나중에 깨끗한 코드로 개발하는 것이 좋습니다. 그것을 감당할 수 없다면 처음부터 깨끗한 코드를 작성하고 신중하게 유지하되 다른 사람들이 제안한 것처럼 지나치게 최적화하지 말고 필요할 때까지 추가하지 마십시오.

어떤 이유로 든 더러운 코딩을 변명하는 것을 꺼려합니다. 내 경험상, 프로토 타이핑에 대한 변명으로 빠르고 더티 주장하는 사람들은 프로덕션을 포함한 모든 코드에 대한 태도를 가지고 있습니다. 누군가가 지저분한 프로토 타입을 만들면 모든 코드에서 엉망이됩니다. 프로토 타이핑은 더티 코딩을 의미하지 않으며, 가장 중요한 사용 사례를 테스트하기위한 단순화 된 가정을 의미합니다. 코드는 공식적으로 테스트되지 않았거나 모든 세부 사항을 처리 할 수는 없지만 여전히 잘 설계되고 구현되어야합니다. 깨끗함은 역량의 표시이며 유능한 프로그래머는 목적에 관계없이 지저분한 코드로 자연스럽게 혐오감을 느낍니다.

깨끗하고 최적화 된 문서화 된 코드를 처음부터 작성하십시오. 나는 그것을 스스로 할 수 없으며 실제 문제입니다. 저는 코더는 아니지만 관리 역할을 맡고있는 고객의 소프트웨어 개발 회사에서 상당한 금액을 지불했으며 많은 아이디어를 얻었 기 때문에 때로는 프로토 타입을 제작하기도했습니다. 거의 항상 그 프로토 타입이 "정리 된"개발자에게 전달되어 배송 제품으로 바꿨습니다. 소스를 체크 아웃하면 여전히 엉터리 코드가 80-90 %가됩니다.

내 동료는 반복적으로 프로토 타입 제작을지지하며, 각 프로토 타입을 버리고 처음부터 다시 쓸 수있는 충분한 훈련이 있어야 한다는 경고와 함께 마지막 라운드에서 결정된 구현 세부 사항에 영향을받지 않아야합니다. , 결국에는 동일한 프로토 타입을 사소한 다른 스타일로 여러 번 작성하는 것입니다. 그는 당신이 버릴 수 없었던 화려한 코드 조각에 실제로 붙어 있다면, 그것을 인쇄하고, 소스 제어 저장소를 삭제하고, 인쇄물을 자신에게 게시해야한다고 세미 세리에 제안했습니다. 다음 반복에 침투 할 수 없을 정도로 길다.

항상 작동하게하여 시작한 다음 깨끗하게 만들기 위해 수정 한 다음 경제적이고 합리적 일 경우 빠르고 작게 만들 수 있습니다. 나는 당신이 버린 몇 가지 실험으로 시작한 다음 작동하는 것을 다룰 때 TDD를 다시 존재로 만듭니다.

둘 다 좋다. 둘 다 좋아합니다. 그들은 서로 모순되지 않습니다.

나는 프로토 타입을 좋아합니다. 프로토 타이핑은 창의력을 키우고 있습니다. 가능한 많은 솔루션을 테스트하고 있습니다. 빨리하면 문제를 해결할 수있는 많은 방법을 테스트 할 수 있습니다.

깨끗하고 테스트를 거친 코드를 작성하고 싶습니다. 그것은 나의 핵심 기술을 개발합니다. 나는 일반적으로 프로토 타입 중 하나를 선택하여 개선하거나 처음부터 다시 작성합니다.

그러나 프로덕션 코드에서 프로토 타입을 착각해서는 안됩니다. 프로토 타입은 생산에 들어 가지 않아야합니다. 항상 프로토 타입으로 표시해야합니다. 기껏해야 자체 지점에서 모든 프로토 타이핑을 수행하십시오.

나는 극단이 거의 항상 나쁘다고 말하는 경향이 있습니다.

깨끗하고 잘 문서화되고 프로토 타이핑 사이의 균형을 유지하는 것이 좋습니다. 라이브러리 나 플랫폼을 개발할 때 경험이없는 경우 프로토 타입 제작 방향으로 넘어갑니다. 이는 특히 코르셋에 넣는 플랫폼 (예 : Android 또는 컨테이너)의 경우에 해당합니다. 그것은 당신이 그들의 인터페이스를 구현하고 그들이 당신을 호출한다는 것을 의미합니다.

내 경험에 따르면 대부분의 코드는 오래 가지 않습니다. 즉, 기능을 구현하여 빠르게 진행하십시오. 조만간 (대부분은 조만간) 특히 다음 작업으로 인해 복잡한 코드로 복잡한 부분을 정리하여 기존 코드를 재 작업 / 리팩토링해야합니다. 번거롭지 않은 리팩토링이 가능하도록 적절한 자동 테스트를 수행하도록주의하십시오. 위에서 언급 한 Android와 같은 플랫폼과 관련하여 : 종종 밀접한 결합으로 인해 테스트를위한 디자인이 없기 때문에 자동화 된 테스트를 수행하기가 쉽지 않습니다. 그런 다음 통합 테스트와 같이 테스트 기반을 더 높은 수준으로 올릴 수 있습니다.

나는 시작에 대한 힌트를 줄 수있는 기사를 썼습니다 : https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d