프로젝트에서 혼자 작업하는 개발자 인 경우 UML이 얼마나 유용합니까?

프로젝트에서 혼자 작업하는 개발자 인 경우 UML이 얼마나 유용합니까?

프로젝트가 너무 커서 머리에 모든 것을 똑바로 유지하는 데 어려움이 있으면 매우 유용 할 수 있습니다. 종이 / 다이어그램에 무언가를 넣는 것은 적어도 나에게있어 디자인과 문제 해결 과정에 도움이 될 수 있습니다.

... 또한 개인 프로젝트의 경우 내 다이어그램이 작업중인 프로젝트와 같이 공식적이지 않으며, 나와 함께 작업하는 것이 좋습니다.

매우 유용하고 가치가 있습니다.

다른 사람들이 의사 소통에 가장 적합하다고 말했듯이 "한 명의 개발자 만 있으면 의사 소통이 필요하지 않습니다"라고 말할 수 있지만 사실은 아닙니다.

그렇다면 UML과 커뮤니케이션은 누구입니까?

1. 당신! - 그래요 당신. 잠시 동안 프로젝트를 마치고 돌아 오면 프로젝트의 작업을 기억하는 데 도움이됩니다.
2. 새로운 개발자 -지금은 유일한 개발자 일지 모르지만 앞으로는 다른 사람이 프로젝트를 수행하지 않거나 개발자가 1 명 이상으로 확장 될 수 있다고 말할 수 없습니다.
3. 비즈니스 어소시에이트 -프로젝트의 상사, 관리자 또는 예비 파트너에게 무엇인가를 제시하려는 경우 프로젝트의 UML이 프리젠 테이션 또는 단순한 대화에 도움이 될 수 있습니다.
4. 문서화 -자신이나 다른 사람이 프로젝트의 UML을 갖는 최종 사용자 문서를 작성하는지 여부는 훌륭한 시작 플랫폼이 될 수 있습니다. 글을 쓰거나 다른 사람에게 리콜 할 수있는 것을 지시 할 때 모든 것을 즉시 기억하려고 시도하는 것보다 훨씬 낫습니다.

또한 그들은 당신이 그들이 의무적 인 상황에 들어갈 때 연습에 유용합니다.

요컨대, 아마도 별로는 아닙니다.

UML의 가장 큰 가치는 의사 소통에있어 1 인 팀에게는 거의 제공 할 것이 없습니다. 거친 디자인 스케치 등에 여전히 사용하지만 시각화는 복잡한 문제를 파악하는 데 크게 도움이 될 수 있습니다.

그러나 중요한 용도 중 하나는 후임자를위한 디자인을 문서화하는 것입니다. 해당 프로젝트 (모든 프로젝트)에서 작업 할 수있는 유일한 사람은 거의 없습니다.

물론 대답은 프로젝트의 규모와 복잡성, 모델링을 얼마나 멀리 할 것인지, 공식적인 디자인 문서를 제공해야하는지 여부에 달려 있습니다.

소규모 개인 프로젝트에 사용하려고 시도했지만 그다지 유용하지 않았습니다. 홀수 클래스 또는 시퀀스 다이어그램은 생각을 정리하는 데 도움이 될 수 있지만 어느 정도 후에는 가치가있는 것보다 더 많은 작업이 필요합니다.

나는 혼자서 많은 일을하고 (나는 프리랜서) UML을 사용하지 않는 경향이있다. 일반적으로 ERD와 조직 도구의 일부 노트 (Onenote를 사용했습니다). 나는 결코 부족함을 느낀 적이 없다. 그러나 많은 사람들이 동일한 프로젝트를 수행하는 더 큰 환경에서 어떻게 유용한 지 봅니다.

UML에서 디자인 및 아키텍처 결정을 문서화하려고 할 때 응용 프로그램에 대해 더 깊이 생각하고 때로는 새로운 것을 발견하고 더 나은 아이디어를 만들기 때문에 유용 할 수 있습니다. 그러나 나는 작은 프로젝트라면 혼자서 일할 때 큰 이익을 얻지 못할 것이라는 다른 사람들의 의견에 동의합니다.

한계라고 생각합니다 ... UML은 디자인의 아이디어를 전달하기위한 것입니다. 실제로 UML을 생각하고 해당 디자인을 매핑하는 다른 방법만큼 빠르게 생성 할 수 있다면 계속 사용하십시오. 그렇지 않으면 프로젝트에 필요할 때 거친 스케치와 약간의 UML "Lite"로 보이는 것을 황삭 처리하는 것이 좋습니다.

특정 영역에서 필요하다고 생각되면 몇 가지 사용 사례를 거친다. 기타

어떤 방법을 사용하든 v2에 대해 생각할 때 12 개월 안에 다시 언급 할 것이 필요합니다.

일부 프로젝트에서 최소한의 구현 (스틱 그림, 연결된 상자 및 일부 레이블)을 사용했습니다. 서면 형식으로 설명하는 것보다 특정 프로세스를 나타내는 것이 더 쉽다고 생각했습니다. 일부 순수 주의자는 실제로 UML이 아니라고 말하지만 클라이언트는 신경 쓰지 않으므로 그렇게하지 않습니다.

아키텍처가 너무 커서 기억하기에 너무 크면 아키텍처를 그래픽으로 표현하면 도움이 될 수 있습니다 (직접 결정해야 할 사항 임).

자신만을 위해서라면 UML과 같은 공식적인 것이 필요하지 않습니다.
목표는 아키텍처를 시각화하여 처리 할 수 ​​있도록하는 것입니다. 가능한 한 방해받지 않고 작동하는 것을 사용하십시오.

프로젝트에 대한 좋은 문서를 유지하는 것이 좋은 습관이지만 한 사람에게는 이것이 쉽지 않고 시간이 많이 걸릴 수 있습니다. 여기서 나의 입장은 UML을 수행해야하며 프로그램이 매우 복잡하거나 코드를 공개해야합니다. 프로젝트가 복잡하고 크면 문서를 충분히 작성하여 생각할 수 있으므로 일정 시간이 지나면 쉽게 다시 가져올 수 있습니다.