프로젝트의 첫 반복에 얼마나 많은 세부 사항을 넣을 수 있습니까?

방금 새 개인 프로젝트 (Python)를 시작했으며 프로그램의 "대략 초안"에 해당하는 내용을 작성하려고합니다. 나는 아직 광범위한 오류 / 예외 처리 또는 미적 UI 요소를 사용하지 않고 있으며 (이러한 것들이 궁극적으로 필요하다는 것을 알고있는 경우에도) 문서는 미래에 내가하고있는 일을 볼 수 있도록 충분합니다.

프로젝트 설계 / 관리의 정해진 원칙에 위배 되는가? 나는 프로그래머가 아닌 과학자이기 때문에 이런 일에 빠지지 않습니다. 따라서 가장 중요한 질문은 두 가지 극단 사이에있는 것을 목표로해야 할 합의가 있습니까?

1. 처음부터 철저한 고품질 코드를 작성하십시오. 모든 예외 처리와 궁극적으로 필요할 것입니다.

2. 처음부터 최소한으로 작동하는 초안을 작성하고 나중에 모든 세부 사항을 작성하십시오.

관련 질문 : 프로젝트를 완수하기 위해 디자인의 "청결성"을 희생해도되는 것은 언제입니까?

이것은 전적으로 프로젝트에 달려 있기 때문에 단일 답변은 없습니다. 여기서 두 가지에 대해 생각해야합니다. 최종 목표는 무엇입니까? 당신은 어떻게 거기에 도착할 것으로 예상합니까?

최종 결과

당신은 화성 궤도 제어 소프트웨어를 작성하고 있습니까? 그런 다음 가장 강력한 코드를 작성하고 있는지 확인하십시오. 모든 예외가 제정신 문제로 처리되는지 확인하는 것이 좋습니다.

당신은 당신 만이 실행할 프로그램을 작성하고 있습니까? 그런 다음 예외로 귀찮게하지 마십시오. 무거운 아키텍처를 신경 쓰지 마십시오. 그것이 당신을 위해 일하는 지점으로 작동하도록하십시오.

당신은 어떻게 거기에 도착할 것으로 예상합니까?

필요한 것을 알아내는 데 많은 시간을 할애하는 무거운 폭포 개발을하고 있습니까? 그렇다면 위에서 언급 한 목표 품질을 상당히 일찍 달성하려고합니다. 처음에 모든 오류 점검 인프라를 계획하십시오.

일주일 또는 2 주일 동안 무언가를 모으는 대규모 애자일 개발을하고 있습니까? 이해 당사자들에게 표시 될 것입니다. 당신이 목표를 칠 때까지? 그렇다면 무언가를 얻는 것이 더 나을 수 있지만, 빨리 깨지기 쉬우 며, 제품 요구 사항이 강화 될 때 벨트와 서스펜더 만 추가하면됩니다.

폭포 또는 민첩한 결정 (실제로는 이진 선택이 아닌 연속체)을 제어 할 경우 예상되는 변경에 따라 결정을 내립니다. 최종 결과가 어떤 모습인지 정확히 알고 있다면 폭포가 최선의 선택입니다. 당신이 끝내야 할 것에 대한 모호한 개념 만 가지고 있다면 민첩성이 최선의 선택입니다. (애자일은 기본적으로 더 나은 것이 아니라 두 번째 상황이 훨씬 일반적이기 때문에 요즘 더 인기가 있습니다.)

이제 나만의 답을 찾으십시오

대부분의 경우 답은 중간 어딘가에 있습니다. 프로젝트에 관한 두 가지 질문에 모두 답하십시오. 기본 방향으로 안내해야합니다.

나는 자주 abysmally 설계되고 어떤 것도 검사하는 오류가없는 일회용 스크립트를 작성한다면 스스로 말할 수 있습니다. 또한 오류 처리 및 아키텍처가 많은 관심을받는 프로덕션 코드를 처리합니다. 그것은 모두 당신이하는 일에 달려 있습니다.

마지막주의 사항 : 빠르고 더러운 일을 할 수있는 일회성 스크립트를 수행하기로 결정한 경우 확인하십시오. 불행히도, 흥미로운 일을하는 빠르고 더러운 스크립트가 다른 사람들이 알아 차리면 광범위하게 사용되는 경우가 종종 있습니다. 이 경우 경화 시간이 주어져야합니다.

모든 소프트웨어 설계 및 코딩 개념 및 패턴은 일부 문제에 대응하여 발생합니다. 패턴이나 개념은 그 문제에 대한 해결책입니다. 시간이 지남에 따라 일부 패턴은 일관성, 친숙성, 성능, 유지 관리 성 등에 대한 특정 요구 사항을 충족시키는 방식으로 문제를 해결하기 때문에 바람직한 솔루션으로 "잘 알려져 있습니다".

따라서 소프트웨어 패턴으로 해결하려는 문제가 특정 소프트웨어에 존재하지 않으면 패턴이 필요하지 않습니다. 또한, 어떤 패턴 소프트웨어의 토론에 힘을 또한 제안 된 소프트웨어의 자세한 논의를 포함해야 할 필요 : 그것은 어떻게해야 무엇을? 어떤 문제가 해결됩니까? 몇 명의 사용자가 있습니까? 사용자가 어떤 방식으로 데이터를 공유합니까? 기타 등등.

예외가 해결해야하는 문제는 코드가 할 수없는 일이 발생했을 때입니다. 저장 매체에 존재하지 않는 파일 이름이 지정된 파일 / 열기 조작이 그 예입니다. 예외는 코드가 호출자에게 "계속되는 것을 막는 일이 생겼으며, 그것에 대해 할 수있는 일이 없어서 포기하고 있습니다." 코드에 이와 같은 조건이 존재하는 곳이 없으면 예외가 필요하지 않습니다. 또는 단순히 오류 코드를 반환하고 예외를 완전히 피할 수 있습니다.

경험을 쌓으면 소프트웨어 패턴과 사용시기에 대해 알게됩니다. 또한 얼마나 많은 선행 디자인이 필요한지 알 수 있습니다. 다시 말하지만 이는 전적으로 작성중인 응용 프로그램에 따라 다릅니다. 작은 유틸리티는 큰 엔터프라이즈 응용 프로그램과 근본적으로 다른 방식으로 작성됩니다.

이것에 대한 매우 간단하고 실용적인 접근 방식이 있으며, 이는 중소 규모의 프로젝트에서 광범위하게 작동합니다. 아마 화성 탐험가에게는 잘 작동하지 않을 것입니다.

먼저, 시스템이 원하는 작업을 수행하고 각 개별 기능을 메모하십시오. 이것은 전체 사용자 스토리 보드만큼 정교하거나 몇 개의 글 머리 기호가 앞에있는 종이에 적혀있는 것처럼 간단 할 수 있습니다. 그러나 원하는 것을 아는 것이 중요합니다 .

이를 바탕으로 시스템의 일반적인 구조를 구성합니다. 다시 말하지만, 이것은 종종 다른 클래스 / 모듈의 빠른 그림과 서로 관련이 있지만 전체 문서처럼 복잡 할 수 있습니다. 중요한 것은 시스템을 어떻게 구현할 것인지에 대한 아이디어가 있다는 것입니다 . 그러나이 작업을 수행하면이 기능이 개선 될 수 있으므로 복잡하고 상세하게 진행하지 마십시오.

이 모든 기능 중에서 프로그램이 수행해야하는 핵심 기능인 핵심 기능을 해결합니다.

그런 다음 하나씩 구현하십시오. 이제 여기서 중요한 것은 기능을 구현 한 후에는 이것이 완료되고 완전히 작동하는지 확인하는 것입니다. 이상적으로는 계속 작동하는지 확인하는 단위 테스트가 수반됩니다. 나는 보통 너무 바빠서 기능으로 돌아와서 고칠 시간이 없을 것이라고 가정합니다.

핵심 기능이 구현되면 일반적으로 시스템을 프로덕션 환경에 최대한 가깝게 사용하려고합니다. 이렇게하면 a) 이전에 놓쳤을 수있는 버그와 b) 다음 기능의 우선 순위에 대한 좋은 아이디어를 얻을 수 있습니다.

그런 다음 필요에 따라 나머지 기능을 계속 구현할 수 있습니다.

코드 품질과 기능

위의 사항을 염두에두고 마감일을 정해야하는 경우 코드 품질보다 기능을 희생하는 경향이 있습니다. 최소한 내 작업 라인에서 내가 뭔가를 마치면 경영진이 완료했다고 가정하기 때문입니다. 그리고 그들이 저에게 다음 과제를 줄 수 있습니다. 사실 후에 코드를 더 멋지게 만드는 데 많은 시간이 없습니다.

이제 예외 처리는 어떻습니까?

박쥐에서 구현하지 않으려면 목록에서 다른 기능으로 나열하면됩니다. 그리고 당신이 그것을 얻을 때 당신은 그것을 구현할 수 있습니다. 그러나 아마도 귀하의 경우에는 아마도 가장 중요한 다른 많은 것들이있을 것입니다.

그러나 예외에 대한 최소 요구 사항이 있습니다. 출력이 아무리 추악하더라도 문제가 발생하면 사용자에게 알리십시오. 어딘가에서 예외를 삼키지 마십시오.