답변:
곧 필요할 것으로 예상되는 솔루션에 대해서만 솔루션을 설계하십시오. 2 년 안에 필요할 수도있는 것들을 위해 엔지니어링하지 마십시오. 대부분 다른 것들이 필요할 것이며, 다시 엔지니어링해야 할 것입니다.
"이 디자인으로 우리는 다음 릴리스에서 고객 요구 사항 Z를 수행 할 수 있습니다"대신 "이 시점에서 X 또는 Y를 수행 할 수 있습니다."에 대해 이야기하기 시작한 순간, 건축 천문학으로.
의견에 대한 답변 :
YAGNI오늘까지 들어 본 적이 없다 .
반복적 인 접근 방식을 사용하면이 문제는 대부분 사라집니다. 코드는 첫날과 그 이후 거의 매일 실행되어야합니다. 최소 요구 사항을 먼저 충족하고 시간이 지남에 따라 더 추가하십시오. 오랫동안 코드를 실행할 수없는 큰 변화를 피하십시오.
솔루션을 완성하는 데 걸리는 추가 시간이 더 쉬운 솔루션이 완료 될 때부터 다음에 자연스럽게 업그레이드 / 수정 될 때까지 발생할 수있는 부정적인 영향보다 더 가치가있을 때 과잉 솔루션입니다.
기본적으로 당신은 시간을 나중에 시간과 거래하고 있습니다. 지금 더 많은 시간을 보낸다면 나중에 저축을한다면 잘못하고있는 것입니다. 엔지니어링에 능숙하다면 지금은 시간을 소비하지만 나중에 보내는 시간에 영향을 미치지 않습니다.
경험이 많을수록이 작업을 더 잘 수행 할 수 있습니다. (내 경험에서) 일을하는 가장 좋은 방법은 지금 필요한 것을하는 것이지만 나중에 요구 사항이 필요할 때 가장 쉽게 보강되는 방식입니다. 그렇게하는 방법을 알아내는 것은 까다로운 일입니다.
나는 매우 완벽 주의적이었습니다 (솔루션이 아닌 프레임 워크를 만드는 데 시간을 소비 함).
그러나 실제로 제작 속도를 높이는 데 도움이 된 것은 외부 원칙을 포함하여 BDD / TDD 원칙을 배우고 따르는 것이 었습니다.
이것은 실제로 테스트가 있기 전에 한 줄의 코드를 작성하지 말라고 가르쳐주었습니다. 그러나 단위 테스트는 수용 테스트가 존재하기 전에 존재하지 않습니다. 그리고 수용 테스트는 실제 사용자 요구에서 비롯됩니다.
따라서 모든 코드 줄은 실제 사용자 요구에서 비롯됩니다.
원칙적으로 외부에 익숙하지 않은 경우 테스트 이중을 사용하여 하위 계층의 동작을 시뮬레이션하여 응용 프로그램에서 가장 바깥 쪽 계층 (예 : 거의 모든 경우 GUI)에 대한 테스트를 작성하도록 지시합니다. 그런 다음 테스트를 통과하기에 충분하게 구현하십시오. 그런 다음 최상위 계층을 구현하면 응용 프로그램의 하위 계층에 도달 할 때까지 다음 계층 등에 작성해야하는 테스트가 지시됩니다.
나는 경험에 의해 이것에 더 나아지는 것을 알았습니다.
내가 아주 젊었을 때 나는 항상 가장 완벽한 해결책을 찾았습니다. 이제 예산과 시간을 염두에 두는 것이 좋습니다.
시간 제한은이 선을 매우 명확하게 만듭니다.
내 상사는 실제로 :)
나아지고 있음을 인정해야하지만 여전히 타협 할 여지는 없습니다. 고맙게도 나는 상사가 나를 고삐하게했다.)
오버 엔지니어링은 감지하기 쉬우므로 오버 엔지니어링 이외의 다른 문제를 제기하고 싶습니다.
내 주요 문제는 리팩토링에 있습니다. 문제는 대부분 내가 할 수있는 한 코드를 작성하려고했지만, 지금 내가 알고있는 것 (더 많은 코드, 더 많은 패턴, 새로운 관용구, 새로운 문제, 새로운 것)을 알지 못했다는 것입니다. 솔루션). 그리고 그것이 작동하더라도 이제는 더 나은 방법을 알고 있습니다.
그러나 그것은 그대로 작동하고 있으므로 리팩토링하는 것이 우선 순위가 아니며 진실은 그것이 나에게 잔소리하고 있다는 것입니다. 경제적 인 이유를 이해하고 있으며 고객의 기대를 이해합니다 (코드를 보지 않고 새로운 기능과 버그 수정을 선호 함).
지금은 사장님의 지시를 따르지만, 프로덕션에 제공되는 코드가 지금까지 얻을 수있는 최선이 아니라는 것이 불안하다는 것을 인정해야합니다. 완벽주의라고 생각합니다.
전문적으로나 개인적으로, 내가 적용하려는 표준은 다음과 같습니다.
승리에 만족하십시오.
내 코드로 문제를 해결하면 해결해야하며 새로운 문제를 일으키지 않습니다 *. 바를 설정해야 할만큼 높게 설정하는 것을 배우면 "충분히 양호"가 충분하게됩니다.
완벽 함은 빛의 속도와 같습니다. 절대 도달 할 수는 없지만 시도 할 수있는 에너지에는 제한이 없습니다.
(*- "버기 (Buggy)"와 "유지하기 어려운"는 모두 "새로운 문제"라는 제목에 속합니다. 따라서 코드가 테스트되고 불필요한 비트가 제거되고 의견 / API 설명서가 최신 상태입니다.)
경험을 통해 특정 상황 (언어, 프레임 워크, 플랫폼, 표준)에서 최소한 몇 년을 지낼 때까지 완벽주의가 불가능하다는 것을 깨달았습니다. 초보자로서이 됩니다 당신이 (탈출, 우선 순위, 예약 된 단어, 문법 설탕, 시간 제한, 비동기 호출, 문서화되지 않은 기능 및 버그), 난 그냥 좋은 솔루션을 시도 할 수 있도록, 모든 알 수 없습니다 특질의 모든 종류의 수 최대한 많이 배우면서 중요한 것은 항상 모듈 형 아키텍처, 필요한 경우 주석 및 영리한 트릭이 없는 결과를 간단하게 리팩토링하는 것 입니다.