새 프로젝트를 시작하려고합니다 (게임이지만 중요하지 않습니다). 기본 아이디어는 내 머리 속에 있지만 모든 세부 사항은 아닙니다.
계획없이 프로그래밍을 시작하고 싶지는 않지만, 단지 그것을하려는 충동과 진지하게 싸우고 있습니다. 내가 생각할 수있는 새로운 기능이 필요하기 때문에 전체 앱을 리팩토링하지 않도록 계획을 세우고 싶습니다. 다른 한편으로, 나는 여러 달 (예비 시간)을 계획하고 싶지 않습니다.이 시간에 내 동기를 잃을 것이라는 두려움이 있기 때문에 시작합니다.
내가 찾고있는 것은 둘을 지배하지 않고 둘을 결합하는 방법입니다. 스크럼 방식으로 프로젝트를 실현해야합니까? 사용자 스토리를 만든 다음 깨달아야합니까? 기능 중심의 작업을해야합니까? (스크럼과 고전적인 "코드 지정"방식에 대한 경험이 있습니다.)
업데이트 : "클릭 더미"로 시작하여 나중에 기능을 구현하는 것은 어떻습니까?
답변:
당신은 올바른 길을 가고 있습니다. 계획을 세우는 데 몇 개월을 소비 할 필요는 없지만 계획은 분명히 있어야합니다.
계획은 생각을 정리하고, 필요한 기술을 식별하고, 문제를 해결하고, 측정 가능한 목표로 세분화 할 수있는 로드맵을 제공하는 데 도움이됩니다.
또한이 작업이 시간 낭비라는 사실을 발견하기 위해 며칠간의 계획을 세울 수도 있습니다. 계획을 세우는 동안, 당신은 당신이 리그에서 나왔거나 당신이하려는 것을 시장에 내놓을 수 없다는 것을 알고 있습니다. 이 길을 내려가 숲에서 길을 잃기보다는 현명한 코드 덩굴과 뇌를 뒤틀는 오해의 논리로 둘러싸인 것이 아니라 다른 아이디어에 시간을 다시 투자 할 수 있다는 것을 지금 확인하는 것이 좋습니다. 매듭으로.
가능한 최소 제품을 계획 하고 구현하십시오. 그런 다음 사용자의 의견을 듣고 다음 논리적 향상을 계획하고 구현하십시오. 반복.
프로그램을 계획하고 디자인하는 데 시간이 얼마나 걸리더라도 항상 프로그램의 일부를 다시 작성하게됩니다. 그것은 중력과 같으며 존재를 현명하게 거부하지 않습니다.
하나는 깨달아야한다 리팩토링 개발의 정상적인 부분입니다 그것은 결정의 문제입니다 때 당신이 그것을 할. 오래 기다리면 엄청난 양의 스파게티가 생겨 완전히 다시 쓰기를 요구합니다. 재미 없다.
내 제안은 조금 계획하지만 코드의 모양을 유지하기 위해 최대한 빨리 리팩터링, 리팩터링, 리팩터링 코딩을 시작하는 것입니다. DRY 원칙 (반복하지 말 것)은 이에 대한 훌륭한 지표입니다.
이 위치에있을 때 때때로 TDD (테스트 중심 개발)를 사용하고 개발중인 시스템의 가장 복잡한 부분에 대한 일부 테스트 계획을 시작합니다. 또는 가장 복잡한 영역에 대해 다시 높은 수준의 의사 코드를 구성 할 수도 있습니다. 이 프로세스를 통해 느슨한 작업 계획을 세우고 가장 시간이 많이 걸리는 영역을 식별 할 수 있습니다.
나 에게이 접근법은 코딩과 계획 사이 어딘가에 있기 때문에 효과적입니다. 테스트 아이디어 및 / 또는 의사 코드가 있으면 각 논리 섹션을 통해 작업하고 코드를 구현할 수 있습니다. 일반적으로 가장 어려운 부분은 응용 프로그램의 핵심 기능이므로 언제든지 종과 휘파람을 지연시킬 수 있기 때문에 제안 된 솔루션의 가장 어려운 부분을 먼저 다루는 경우가 많습니다.
대부분의 코드가 머릿속에 있으며 다이빙을 준비하고 프로그래밍 할 준비가되었으므로이 접근 방식을 사용하면 시스템 전체에 정신이 흐려지지 않고 각 섹션에 집중할 수 있습니다.
간결하게 요약하자면, "가장 어려운 부분을 먼저 다루고, 의사 코드 및 / 또는 TDD 계획으로 나누고 정복하십시오"라고 말할 수 있습니다!