尋求工具，技巧，快速學習新應用程序的技巧（從編碼的角度）

Question

我是一位軟件開發顧問，尋找一些工具來幫助我在客戶現場開始一個新項目時快速瞭解新的應用程序。 我認爲對於獲得應用程序或系統的高層次概述很有用的事情是DB架構圖，領域對象模型圖，UML圖，API等。基本上，這些東西給我一個高層次的概述產品，以及如何從開發人員的角度與應用程序一起工作。現在我在Visual Studio中使用對象瀏覽器，但覺得應該有更好的選擇。我確實使用了一個名爲Doc-O-Matic的工具，它讓我對C＃解決方案中的類文件的關係有了一些瞭解。

我目前的項目是一個龐大的用&編寫的應用程序，用C＃，Spring.net，NHibernate，MVC編寫，我試圖讓我的腦袋圍繞設計。它看起來非常複雜，並且大量使用面向對象的設計模式，並且事物非常抽象，這使得很難跟蹤應用程序正在做什麼（儘管我確信它是從面向對象的角度設計的）。

什麼樣的工具和技術可以幫助我在客戶提供少量文檔或不提供文檔的情況下獲取這種信息（通常情況下）？你用什麼工具，技巧來快速學習新系統？

謝謝！

Answer 1

你（至少我）無法學習整個系統設計及其工作原理。這太耗時了。當我開始工作時，我曾遇到同樣的問題，儘管我有一個大型項目並沒有很好的設計。一些步驟，迅速得到用戶的動作是：

• 瞭解如何將應用程序從用戶的角度工作來看，這意味着你必須在
• 當你的工作區使用的應用程序熟悉問題域並知道在應用程序中解決哪些業務案例，然後轉到您必須在上工作的模塊/部分代碼。
• 最好是從（前）開發人員獲得啓動。如果您沒有人這樣做，請嘗試調試您必須更改的進程/代碼，以便您可以看到涉及的組件。
• 從最小的使用案例開始。如果應用程序設計得很好，那麼在整個代碼中應用相同的模式的可能性非常高。所以，如果你「破解」了一段代碼，你會得到全部（......至少是設計邏輯部分）。
• 一旦你理解了他們，記下下來的東西，否則由於你在短時間內收集了大量的信息，你會忘記他們。
• 評論代碼缺少文檔，但如果您是第一次使用該應用程序，則這是一件危險的事情。你會遇到你認爲自己明白髮生了什麼的情況，但你沒有。

這只是我所做的一些經驗。

Answer 2

首先，不要馬上假設一個難以遵循的程序是「從面向對象的角度來看架構良好」。 OOA & D的目的不過是讓代碼更容易理解，擴展和重構，避免使用「意大利麪條代碼」（代碼中包含大量無序文件，其中包含大量跳轉;它幾乎是唯一可以完成的方式）舊的語言）。但是，您可以通過過度使用設計模式來構建其他編程意圖：「lasagna代碼」（很多抽象層難以深入到您想要檢查的實際代碼）或「餛飩代碼」（代碼被破壞分成許多小塊，您可以不斷從文件移動到文件以追蹤單個簡單算法的執行情況）。

無論如何，對於.NET項目，VS有一些工具來生成類圖。 Office Visio Professional還可以與Visual Studio集成並擴展此功能，允許在更改圖表和更改實際代碼之間「來回」。同樣，它可以插入MSS併爲您提供架構圖。但是，真正沒有比實際操作更好的工具。即使是最精心設計的代碼也會有一些特質，要求你知道代碼庫以便將具有問題的對象（或者對象之間的關係等）歸結爲零。我還沒有遇到過一位僱主，他並沒有指望它至少需要一個月的時間才能讓新員工熟悉當前足夠的架構，從而開始提高生產力。從契約的角度來看，這種期望可能不太寬鬆，但期望有人潛入一個龐大的代碼庫，只需很少或沒有外部文檔，並開始像奧運短跑運動員那樣游泳，這是不合理的。