프로젝트를 어떻게 계획하고 시작해야합니까?

프로젝트를 시작할 때마다 핵심 클래스를 완전히 바꾸고 모호한 오류에 빠지기 위해 결정적인 순간을 결정합니다. 나는 사전에 계획을 세우고 보통 발로 시작하지만 다른 날로 가서 다른 방법으로하기로 결정합니다.

클래스를 매핑하고 단위 테스트를 시작하는 등의 프로젝트를 시작할 때 표준이 있습니까? 중간 규모 프로젝트를 계획하고 시작할 때 좋은 규칙은 무엇입니까?

마지막 프로젝트는 발사체 모션 시뮬레이터였습니다.

계획 할 때는 응용 프로그램에 대해 가능한 모든 것을 미리 계획하지 마십시오. 아기 발자국 계획하기. 응용 프로그램 사용을 시작하는 데 필요한 최소 기능 은 무엇입니까 ? 거기서 시작하십시오.

프로젝트를 시작할 때 절대 최소 기능 만 코딩하십시오. 코드를 작성할 때는 스마트 캡슐화를 사용하여 훌륭하고 깨끗한 코드를 작성해야합니다 . 이렇게하면 나중에 변경하여 발생하는 오류가 최소화됩니다.

만족할 때까지 최소 기능을 반복 하십시오. 그런 다음 한 번에 하나씩 새로운 기능과 향상된 기능을 추가하십시오. 스마트 캡슐화로 훌륭하고 깨끗한 코드를 작성하는 데 다시 초점을 맞 춥니 다.

베이비 단계를 계획하고 깨끗한 코드를 작성하면 실제로 변경해야하는 횟수가 최소화됩니다. 첫 번째 기능 작성을 완료 할 때까지 응용 프로그램의 기초가 될 패턴을 채택해야합니다. 해당 기초에 문제가있는 경우 다음 기능으로 문제를 신속하게 밝혀야합니다. 조각이 어떻게 통합되는지 쉽게 알 수 있습니다. 이 시점에서 변경 사항이 발생하면 최소한의 중단이 발생해야합니다.

귀하의 계획이 도움이되지 않는 것 같습니다. 실현 가능한 계획을 세우기에 충분한 경험이 없기 때문에 놀라운 일이 아닙니다. 해결책은 간단합니다. 계획을 그만두십시오. 진행하면서 코드를 작성하고 다시 작성한다는 사실 만 인정하십시오. 시간이 아닌 코드는 무료이기 때문에 괜찮습니다. UI 응용 프로그램을 작성하는 경우 빈 창으로 시작하고 완료 될 때까지 한 번에 조금 추가하십시오. 더 많은 경험이 있으면 프로젝트가 더 빨라집니다. 코드를 변경하기 때문에 걱정하는 것은 실제로 낭비되는 모든 음표에 대해 걱정하는 음악 학생과 같습니다.

어느 정도의 양을 코딩하기 전에는 최고의 디자인이 무엇인지 실제로 아는 사람이 없습니다. 따라서 좋은 디자인의 비결은 첫 번째 초안이 필연적으로 차선 책임을 인식 하고 더 작은 부분을 더 일찍 그리고 더 자주 다시 작성할 계획 입니다. 거의 완전한 프로그램을 폐기하는 대신, 결함을 인식하자마자 줄이나 함수 또는 클래스를 다시 작성하십시오.

숙련 된 프로그래머는 일반적으로 첫 번째 드래프트에서이를 제대로 얻지 못합니다. 경험과 함께 제공되는 것은 나쁜 디자인을 더 빨리 인식하고 더 빨리 다시 작성할 수있는 능력입니다.

내 경험상,이 문제는 더 많은 경험이있을 때 사라집니다. 작동하는 것과 그렇지 않은 것에 대한 느낌을 얻습니다. 또한 캡슐화가 양호하면 설계 변경 비용을 줄일 수 있습니다. 모듈이 더 단단히 캡슐화되면 나중에 변경하는 것이 더 저렴합니다. 수업을 따로 유지하는 훌륭한 동기 부여라고 생각하십시오.

http://nathanmarz.com/blog/suffering-oriented-programming.html

이것은 당신의 문제를 해결합니다. 그는 단순히 소프트웨어가 가능한지 확인하고 프로토 타이핑하고 만드는 것으로 시작했습니다. 그런 다음 코드를 가져 와서 깨뜨리기 시작합니다. 그런 다음 최적화합니다.

응용 프로그램 설계에는 두 가지 측면이 있습니다. 첫 번째는 애플리케이션이 수행 할 수있는 작업을 결정하는 것입니다. 두 번째는 방법을 설계하는 것입니다. 변경 사항은 상당히 중요하며 응용 프로그램의 성숙도 (및 응용 프로그램 방향의 전환)에 따라 재 작업이 아닌 재 작성으로 가장 잘 접근합니다.

두 번째 측면은 방법입니다. 단위 테스트 및 민첩한 개발 관행을 사용하면 리팩토링을 통해 특정 기능이 수행되는 방식 변경으로 인한 영향을 최소화 할 수 있습니다. 이러한 기술을 활용하는 방법을 배우는 데는 연습 연습이 있습니다.

나는 몇 번이고 다시 한 번 조언을 드리겠습니다 애완 동물 프로젝트를 선택하십시오. 당신의 능력을 최대한 발휘하십시오. 새로운 것을 배우고 배운 내용을 적용하여 프로젝트 개발 방법을 개선하십시오.

예를 들어, 할 일 목록으로 시작하십시오. 처음에는 데이터베이스 스토리지에 대해 걱정하지 않아도됩니다. 그냥 작동 시키십시오. 이제 그 기초 위에 구축을 시작하십시오. 아마도 당신은 MVVM과 WPF를 배우고 싶을 것입니다 ... 이미 메모리 할 일 목록을 구현하는 방법을 알고 있으므로 해결할 문제가 하나 더 적습니다. 이제 여러 사용자가 데이터베이스에서 할 일 목록을로드 할 수있는 위치에 만들려고합니다. 메모리와 분리 된 프리젠 테이션으로 해결되었으므로 학습 데이터 액세스에 집중할 수 있습니다. 여기에서 애플리케이션을 확장하여 더 복잡한 도메인 모델 (예 : Todo 목록에서 프로젝트 관리 솔루션으로 변경), 웹 인터페이스를 갖거나 모바일 디바이스에서 실행할 수 있습니다. 이 일을하는 비결은 진척 상황을 표시하고 시간이 지남에 따라 성장할 수있는 성과를 거두는 것입니다.

내 경험상 시스템 설계는 실제 코딩보다 오래 걸리거나 더 오래 걸립니다. "사전 계획"이라고 말할 때 실제로 무엇을 계획합니까? 아마도 구식 학교에 가서 시험되고 검증 된 설계 방법 중 하나를 사용할 수 있습니다. 또는 실제 코드를 작성하기 전에 구식 학교에 가서 의사 코드를 작성하십시오.

나는 원래 계획을 고수하기보다는 왜 중요한 순간에 사물을 바꾸어야하는지 스스로에게 물어봐야한다고 생각합니다. 원래 계획에 결함이 있었습니까? 아니면 일을 더 잘 수행 할 수있는 통찰력있는 순간이 있었습니까? 실제로 더 좋았습니까 아니면 다른가요?

경험치를 얻으면 재 작성 / 스크래치 및 다시 시작해야하는 빈도가 줄어 듭니다. 해결하려는 문제를 기록하십시오. 당신이 필요하다고 생각하는 모호한 수업 설명을 적고, 상호 작용이 필요한 방법을 적으십시오. 모든 것이 어떻게 작동하고 코드화되는지에 대한 아이디어를 얻으십시오. 모든 재산, 수업 방법을 작성하는 데 많은 시간을 소비하지 마십시오. 이 단계에서는 수행해야 할 작업에 대한 50K 피트 뷰를 얻으려고합니다. 더 자세한 내용을 작성해야 할 경우 코딩을 시작하면 진행하십시오. 코딩을 시작하지 않으면

당신이 이것을 너무 어렵게 생각하는 이유는 당신이 아이디어를 가지고 있기 때문입니다. 그러나 당신이 정말로 원하는 것을 완전히 이해하지 못하기 때문입니다. 당신이 당신의 자신의 프로젝트를하고 있고 당신이 그들이 원하는 것을 말해 줄 고객이 없다면, 당신 자신의 고객이 될 것입니다. 고객의 신발에 자신을 넣고 불가능한 희망 목록 작성을 시작하십시오.

다시 말해, 시작할 때 아무 것도 디자인하지 마십시오 !!! .

시스템에서 수행 할 작업 목록이 많으면 모든 작업의 ​​우선 순위를 정하고 기본 시스템을 실행하는 데 필요한 최소 기능을 결정하십시오. 이것은 단일 기본 기능이거나 전체 화면 일 수 있지만 고객이 테스트하기에 충분히 유용하다고 생각하는 것이어야합니다.

따라서 기능 + 기본 우선 순위 = 요구 사항 의 위시리스트입니다 .

이 모든 것을 갖추었다면 매우 높은 수준의 디자인을하십시오. 처음 몇 가지 우선 순위를 설정하고 실행하기 위해 시스템에 필요한 것이 무엇인지 생각해보십시오. 원하는 경우 마음이 바뀌지 만 여기에 가능한 코드에 대한 정보를 얻기 위해 일부 코드 또는 시스템 구성을 스파이크 할 수 있습니다. 디자인에 대한 기본 아이디어를 검증 할 수있을 정도로 멀리 가십시오.

즉 : 이제 디자이너의 충동에 빠지게 됩니다.

완료되면 기능 구현을 시작합니다. 각 기능마다 기본 기능 사양을 작성하십시오. 이것은 기능 선언문처럼 간단 할 수 있습니다. 원하는 경우 스토리 카드. 이를 통해 아이디어를 조금만 개발 하고 구현을 테스트하고 구축 할 사양 이 될 일련의 진술을 만들 수 있습니다.

울부 짖는 소리, 개들을 풀어 주자 ... 코드 !!

여기에서 사양에 맞게 테스트를 구현 한 다음 각 테스트마다 코드를 작성하십시오. 빌드하고 "릴리스"한 다음 프로젝트가 충분히 완료 될 때까지 다음 기능으로 반복하십시오.

그것은 실제로 경험에 달려 있지만, 내가 찾은이 접근법은 너무 많은 일을하려고하여 끝없는 지연의주기에 얽매이지 않고해야 할 일에 정신을 집중시키는 데 도움이되는 간단한 공식입니다. 일단.

프로젝트 목표 설정, 요구 사항 목록 가져 오기 및 외부 시스템에 대한 인터페이스 잠금과 같은 기본 사항을 수행 한 후

그런 다음 모든 사용자 상호 작용에 대해 유스 케이스 또는 "스토리"를 수행해야합니다. "좋은"유스 케이스 또는 스토리를 만드는 내용에 대해 많은 글이 작성되었으며 많은 변형이 있습니다. 유스 케이스는 내가 만난 가장 효과적인 단일 설계 도구입니다. 또한 불필요한 요구 사항을 제거하고 설계를 필수 사항으로 제거하는 동시에 누락 된 기능을 선택하는 데 도움이됩니다. 내가 말했듯이 방법론은 다양하지만 대부분의 개업의는 다음에 동의합니다.

• 간결한 일반 영어 텍스트.
• "목표 주도"가 가장 효과적입니다. 즉 "원숭이는 포도를 얻는다"는 "원숭이는 빨간 버튼을 누르는 것"보다 낫습니다.
• 기술 용어 금지. "풀다운", "텍스트 상자"가 없습니다. 좋은 사용 사례는 인터페이스 기술과 무관해야합니다. HTML 기반 시스템의 유스 케이스를 사용하고 유스 케이스 자체를 변경하지 않고 음성 활성화 시스템에 사용할 수 있어야합니다. (이것은 매우 어렵지만 가치가 있습니다!).
• 첫 번째 초안의 단어 수를 50 % 줄이려고하고 불필요한 단계와 말을 제거하십시오.

주요 수업을 지정할 준비가 된 것보다 :

UML- 범용 모델링 언어. 클래스 디자인을위한 표준 도구입니다. 각 클래스의 공개 멤버와 메소드를 지정하고 간결한 그래픽 모델로 서로 링크합니다.

시퀀스 다이어그램, 데이터 모델과 함께 코딩을 수행하기 전에 설계를 확인하고 개선 할 수 있습니다.

얻고 자하는 결과에 중점을두고 새로운 구현을 학습 / 시도함으로써 얻을 수있는 잠재적 인 이점을 파악하고 도로를 넘어갈 수있는 위험을 감수하십시오.

정사각형으로 돌아가는 경우 경험을 얻었 기 때문에 모든 것이 손실되지 않습니다.

마감일이 있다면 (아마도 재미있게 프로그래밍하는 것처럼 들립니다), 이것은 정말 까다 롭습니다. 지속적으로 한 방향으로 이동하면 시간이 지남에 따라 오래된 방법을 사용할 위험이 있습니다. 계속해서 다른 길을 가면 더 느린 속도 (학습 모험의 결과에 따라 속도가 느려짐)로 결과를 생성 할 위험이 있습니다.

나는 일을하면서 일을 해내 고 해마다 빠르게 일을하던 어느 날, 나는 내 스킬 셋에서 비 현재가되고 있다는 것을 깨달았습니다.