我最近成爲了一個複雜的嵌入式項目團隊的一員，爲此我將開發一個部分。對於我的職責部分，只有舊的代碼和沒有太多的文檔。瞭解軟件系統
我熱衷於一個良好的開端，但害羞和害怕出現愚蠢使得難以提出問題。如何提問？
我想問你們用什麼技術來理解一個項目？我的意思是有很多技術細節，人們必須記住並保持上下文才能進行設計。你閱讀代碼並得到一些事實，但如何前進？ 例如，您閱讀代碼和文檔並獲得一些事實A和事實B。如何得出適當的結論X，您可能需要也可能不需要考慮事實C和D？
閱讀代碼是通過編寫文檔來平衡的。
編寫替換件需要的文檔。想象一個比你更少知道的人。爲那個人解釋。
如果您無法向替換者解釋某些內容，請提問。
當您有完整的描述時，您將「知道」該系統。
而且您將製作完整的文檔。
如果沒有足夠的文檔並且代碼記錄不完整且編寫不當，代碼讀取可能會特別困難。我想現在最好的辦法是找到代碼的入口點，並慢慢理解它的流程以及它使用的數據。我會繼續關注的
結構 - 是否有任何分區的實體/系統？代碼中的哪些地方（以及如何）彼此溝通？
數據 - 使用什麼樣的結構來保存全局數據？數據如何被訪問和保存？
如果你在做C或C++，找出如何處理內存和C++（以及其他相關的非託管內存OOP語言，我猜），對象所有權如何包含也很重要。
由於它是一個嵌入式項目，有沒有使用非標準的代碼或編碼結構？
你沒有提到存在哪種測試。如果有測試用例，修改它們並跟蹤這將如何影響最終結果。
您可能想看看圖表，它可以給出系統邏輯結構的全貌，例如，在OOP系統中查看類圖會有很大的幫助。通過查看大型複雜應用程序的設計圖，您可以清楚地瞭解系統內部模塊的組織方式，並以此方式確定特定代碼段的功能是否更容易完成。在沒有圖表的情況下，最好的辦法是從應用程序的入口點開始，例如main（），並在繪製時從字面上開始（字面上在紙上繪製或寫下）自己關於系統的結論（這樣你可以擁有自己的文檔）並詢問你的同事是否正確。
我的經驗是，最好從某種任務開始 - 一個錯誤修復或其他小改變。這將爲您的學習提供重點。我發現很難通過活頁夾閱讀或者通過源代碼或文檔的頁面篩選，而無法應用它。
如果您有一個沙盒，您可以在不改變代碼基礎的情況下進行更改，那可能會更有幫助。