나는 내 마음 속에 모든 것을 담아서 옮기기가 점점 어려워지는 새로운 프로젝트로이 문제에 뛰어 들고 있습니다. 여전히 대부분의 프로그래밍에서이 작업을 수행하지만 물리적 수단이 크게 도움이 될 수 있음을 알고 있습니다.프로젝트를 개념화하는 가장 좋은 방법은 무엇입니까?
어떤 방법을 사용합니까? 내가 생각할 수있는
3 가지 아이디어가 있습니다 :
화이트 보드/용지.
보통 종이 - 화이트 보드는 동료들에 의해 지워지는 습관을 가지고 있습니다!
디자인/계획 단계에서 도움이되는 일종의 소프트웨어를 여러 번 사용해 보았지만이 작업을 수행하는 소프트웨어를 아직 찾지 못했습니다.
완전 요구 사항 (PRD)을 자세히 읽습니다. 해석서 (ERD)를 적어 두십시오. 그런 다음
동일한 소프트웨어가 있지만 사용하지 않은 소프트웨어가있을 수 있습니다.
나는 종이에 학급 이름을 써서 우리의 이마에 붙이려했던 회사에서 한 번 구금했다. 순수한 어리 석음. 상호 작용을 표현하는 팔은 두 개 뿐이지 만 일반적으로 모든 클래스를 표현할만큼의 개발자는 없습니다. 나는 사람들의 부족으로 인해 우리가 하나님의 물건들 (당신의 반 - 디자인 패턴을 읽었을 때)을 읽지 않았다는 것에 놀랐다!
화이트 보드와 지울 수있는 마커 (Sharpie는 아니며 이전에이 실수를 본 적이 있습니다!)가 나를 위해가는 길입니다. UML 표기법을 이해하면 팀에서 일할 때 크게 도움이됩니다. 왜냐하면 동일한 표기법을 모두 사용하고 이해하고 있기 때문입니다. 귀중한 시간 낭비하는 올바른 표기법에 대한 논쟁에 빠지지 마십시오!
결국 코드의 골격 프레임 워크를 생성/업데이트 할 수있는 프로그램으로이 코드를 옮길 수 있습니다. 때로는 IDE가 충분할 수도 있고 (Visual Studio 클래스 다이어그램), IDE에 플러그되는 전용 소프트웨어 (Eclipse 기반의 Rational Software Architect)가 필요할 수도 있습니다.
이동 방법에 대한 조언으로 ... 귀하와 다른 팀원이 사용 사례를 일반적으로 이해하고 있는지 확인하십시오. 귀하와 귀하의 팀이 귀하의 소프트웨어 사용 방법을 완전히 이해하고있는 한 반드시 문서화 할 필요는 없습니다. 당신이 당신의 일에 대해 진지하게 생각한다면, 당신은 이것들을 문서화 할 것입니다. 또한이 모든 것이 순서대로 이루어져야한다고 생각하지 마십시오. 개발과 같은 소프트웨어 디자인은 반복적입니다 ...그것은 프로세스가 완전히 랜덤하고 구조화되어 있지 않다는 것을 의미하지는 않습니다. 유스 케이스는 생성해야하는 클래스에 대한 힌트를 제공합니다. 예를 들어, '사용자가 계정을 등록합니다'는 유스 케이스 인 경우 이미 계정을 나타내는 클래스가 필요하다는 것을 알고 있습니다. 계정을 만들 때 사용자가 거리 이름, 우편 번호 (캐나다 ftw) 및 전화 번호가 각각있는 청구서 수신 주소 및 배송지 주소를 추가 할 수있는 경우 Address 클래스가 필요하다는 것을 알게됩니다.