我們正在談論很多關於當前程序員的文檔。你如何處理這部分？使用PHP的大型或小型項目的文檔？
什麼是將一個新團隊成員引入「大型」PHP項目的最佳方法。新人需要什麼？
我的想法至今：
有些類型的紙張/維基..與關於基礎設施的信息（數據庫，防火牆..）
你還提供什麼，如果你不得不把你的項目交給別人（可能不如你在php中那麼好）。
你是否創建了類似「添加一個函數來讀出服務器數據，放在模型xYZ？「
對不起，因爲我的窮英文:)
你應該考慮使用他們三個。
儘管如此，不要過分複雜化您的文檔：保持最新版本越困難，就越有可能無法維護。恕我直言，向新程序員介紹代碼庫的最低限度是編碼準則（如何調用變量，如何調用你的類，你使用匈牙利符號？）和phpdoc。如果您的代碼大量使用第三方庫和大型配置文件，請編寫一個小型PDF，其中包含使您的代碼在裸機上工作的步驟。
如果您正在使用單元測試，請記住記錄這些。
即使考慮到這些，在將代碼庫放棄到新的編碼器後，仍然需要頻繁撥打電話。對你來說似乎合乎邏輯和清楚的可能不是新人。
如果項目具有API，那麼除了其他人之外，我可能會提供示例用法，示例等。
文檔很好 - 但將其視爲指導。它不應該寫成教授編程，它不應該是一個容易寫出過時的文檔。
當我加入一個新項目時，我一直需要的一件事就是知道代碼的位置以及如何訪問它。將代碼行匹配到正常運行的開發或登臺環境，可以快速嘗試並發現以前開發人員的「模式」。
如果我可以在界面中進行小小的調整，那麼我已經破解了這個螺母並且可以開始按照我的方式朝着數據方向前進。
但是後來我習慣了幾乎沒有文檔的項目。並非所有人都對此感到滿意。
我編寫了一個幾乎完全是其他程序員工作（我是新人）產品的中等代碼庫。我們有API phpdoc評論和版本控制最佳實踐文本文件的自動美化文檔。我會放棄這兩個：更廣泛的在線評論和某種自動化測試。
我通常會發現api文檔適合構建新功能，但對於查找錯誤並不是特別有用，這隻能通過內聯註釋真正解釋。
因此，在我自己的工作中，我試圖在觸摸代碼行之前，在註釋中展示新代碼的行爲。我也想轉向測試驅動設計，但還沒有真正到達這一點。
是的，我是一個有能力的編碼員，但代碼庫的大小和複雜性以及大多數代碼是由其他人創建的事實意味着我經常不得不去找他解釋潛在的源代碼錯誤。所以，如果你真的投入了在移植之後使代碼庫保持活躍狀態，請考慮如果可能的話，讓自己成爲一個資源。
我認爲最重要的事情是git（或mercurial，或其他一些D.V.C.S.），文件提交歷史記錄和potential web-interface到可以隨它們提供的代碼。