새로운 응용 프로그램을 빠르게 배우는 도구, 팁, 기술 (코드 관점에서)

Question

저는 고객 사이트에서 새 프로젝트를 시작할 때 새로운 응용 프로그램을 빨리 이해할 수있는 도구를 찾는 소프트웨어 개발 컨설턴트입니다 . 응용 프로그램이나 시스템에 대한 높은 수준의 개요를 얻는 것이 유용 할 것 같은 일은 DB 스키마 다이어그램, 도메인 개체 모델 다이어그램, UML 다이어그램, API 등입니다. 기본적으로 제품 및 개발자 입장에서 응용 프로그램을 사용하는 방법에 대해 설명합니다. 지금 저는 Visual Studio에서 객체 브라우저를 사용하고 있지만 이런 종류의 작업을 위해 더 나은 옵션이 있어야한다고 생각합니다. Doc-O-Matic이라는 도구를 사용했는데 C# 솔루션의 클래스 파일 관계에 대한 아이디어를 얻었습니다.

내 현재 프로젝트는 C#, Spring.net, NHibernate, MVC로 작성된 큰 & 복잡한 응용 프로그램이며 디자인을 고민하려고합니다. 매우 정교하고 OO 디자인 패턴을 많이 사용하는 것처럼 보입니다. 매우 추상적이어서 애플리케이션이 수행하는 작업을 수행하기가 더 어려워집니다 (물론 OO 관점에서 잘 설계되었지만).

고객이 문서를 거의 또는 전혀 제공하지 않는 상황에서 이러한 종류의 정보를 얻을 수있는 도구, 기술에는 어떤 종류가 있습니까? 새로운 시스템을 빨리 배우기 위해 어떤 도구, 트릭을 사용합니까?

감사합니다.

Answer 1

당신 (적어도 나는)은 전체 시스템 디자인과 그것이 작동하는 방법을 배울 수 없습니다. 너무 많은 시간을 소비합니다. 한때 직장 생활을 시작할 때도 똑같은 문제에 직면 했었습니다. 큰 프로젝트가 있었지만 멋지게 설계되지 않았습니다.행동에 신속하게 얻을 수있는 몇 가지 단계는 다음과 같습니다 응용 프로그램이 사용자의 관점에서 작업하는 방법을보기, 그건 당신이

때를 작업해야하는 영역에서 응용 프로그램을 사용하는 것을 의미

• 학습 문제 도메인에 익숙하고 애플리케이션에서 처리 된 비즈니스 사례를 알고 있다면 에서 작업해야하는 모듈/코드 부분으로 이동하십시오.
• 가장 좋은 것은 입니다. 개발자는입니다. 이 작업을 수행 할 사람이 없다면디버그 프로세스/코드를 변경하여 관련 구성 요소를 볼 수 있습니다.
• 가능한 가장 작은 유스 케이스부터 시작하십시오.. 응용 프로그램이 잘 설계된 경우 동일한 패턴이 코드 전체에 적용될 확률이 매우 높습니다. 그래서, 만약 당신이 하나의 코드 조각을 "해독"한다면, 모든 것을 얻을 수 있습니다 (최소한 디자인 로직 부분).
• 일단 이해하면 등의 것들을 적어 둡니다. 그렇지 않으면 짧은 시간에 많은 양의 정보를 수집하게되므로 잊어 버리게됩니다.
• 설명이 부족한 코드 코드를 주석으로 작성하는 것이 좋지만 응용 프로그램으로 처음으로 작업하는 경우 위험합니다. 당신은 당신이 무슨 일이 벌어지고 있는지 이해했다고 생각하는 상황에 처하게 될 것입니다.

그건 내가 만든 경험 일뿐입니다.

Answer 2

먼저, 따라하기 힘든 프로그램이 "OO 관점에서 잘 구성되었다"고 가정하지 마십시오. OOA & D의 목적은 "스파게티 코드"(점프가 많이 포함 된 커다란 무질서한 파일이있는 코드를 사용하여 코드를 이해하고, 확장하고, 리팩터링하는 것을 더 쉽게 만들어주는 것보다 더 많거나 적습니다. 오래된 언어). 그러나 디자인 패턴을 과도하게 사용하면 다른 프로그래밍 파스타를 설계 할 수 있습니다. "라자냐 코드"(검사 할 실제 코드까지 파고 드는 추상 레이어가 너무 많음) 또는 "라비올리 코드"(코드가 깨졌습니다. 당신이 하나의 간단한 알고리즘의 실행을 추적하기 위해 파일에서 파일로 끊임없이 움직이는 많은 물린 크기의 덩어리로).

어쨌든 .NET 프로젝트의 경우 VS에는 클래스 다이어그램을 생성하는 몇 가지 도구가 있습니다. Office Visio Professional은 또한 Visual Studio와 통합 할 수 있으며이 기능을 확장하여 다이어그램 변경과 실제 코드 변경간에 "앞뒤로"사용할 수 있습니다. 마찬가지로 MSS에 연결하여 스키마 다이어그램을 제공 할 수 있습니다. 그러나 실전 경험보다 도구가 없습니다. 가장 잘 설계된 코드조차도 문제가있는 오브젝트 (또는 오브젝트 간의 관계 등)를 얻기 위해 코드베이스를 알아야하는 특이한 점이 있습니다. 아직 고용주를 만난 적이 없지만 새로운 고용으로 현재의 아키텍처를 충분히 숙지하여 생산성을 향상시킬 수있는 최소 한 달이 걸릴 것으로 예상하지는 않습니다. 계약 관점에서 볼 때 그 기대는 덜 관대 할 수 있지만 외부 문서가 거의 없거나 전혀없는 대규모 코드베이스에 뛰어 들어 올림픽 선수처럼 수영을 시작하는 것은 무리가 있습니다.