將我自己的項目傳遞給別人 - 該怎麼辦？

通常情況下，項目在別人身上傳遞。通常這個過程對雙方都是不愉快的 - 新老闆抱怨可怕的文件，錯誤和糟糕的設計。然後原來的主人困擾了幾個月，關於該項目的問題，請求修復舊的錯誤等。將我自己的項目傳遞給別人 - 該怎麼辦？

我可能很快就會處於一種情況，我的一個項目將被給予別人，所以我可以專注於我的其他項目。我想知道我應該怎麼做才能儘可能順利地進行這種轉移。我已經有一個體面的文檔，代碼是相當好的評論，我仍然在改善它。它是一箇中等規模的項目，不是很大，但它仍然不是你可以在一週內編碼的東西。

我正在尋找一些應該做的事情，以幫助未來的老闆接管這個項目，同時也會讓我討厭所有那些惱人的問題，比如「這個功能做什麼，做什麼這個班的目的是......「。我知道文件是必須的 - 還有什麼？

注：雖然我的項目是在C++中，我相信這是一個語言無關的問題。如果您認爲某些語言特定的東西，請提及它們。

來源

2010-07-31 PeterK

我不知道爲什麼近距離投票。請投票人告訴我爲什麼他認爲這個問題應該結束？它不是主觀的，也不是爭辯的，可以回答，我看不到重複。即使標有CW！ – PeterK 2010-07-31 12:11:16

標記CW根本不存在任何影響，無論是否應該關閉問題。無論如何，我認爲這個問題不應該是CW。 – 2010-07-31 13:14:38

文檔，但在所有層面：

API文檔
高層體系結構：哪些組件都在那裏，他們有什麼關係和依賴性
對於每個組件，一個高層次的描述指向教程：如果你想做X，下面是如何使用數據庫模式
成語：如果你在代碼中創建了一些成語，解釋起來

而且，爲了啓動，給這傢伙一個個人介紹給所有的人以上的，希望做一對一些必要的變化編程方式

來源

2010-07-31 11:56:12

如果有好的文檔和註釋的代碼就像你說的，那麼你做你的一部分。只要確保文檔包含高級文檔（體系結構，數據流等）以及較低的模塊或程序級文檔。

如果是這樣，你可以，我會強烈建議你保護自己與某些類型的合同，指定什麼樣的未來支持（如果有的話），你會提供多長時間的情況。

來源

2010-07-31 11:57:23 RWGodfrey

我想大多數的問題都可以用只有兩個簡單的規則來避免。

保持代碼平臺風格指南一致。
命名，命名和命名。

如果項目很大，那麼你只需要與新人一起運行一些代碼陣營。這個沒有捷徑。

也請記住，抱怨發生主要是因爲新來的傢伙是沒有資格不夠，即不明白的東西。這就是爲什麼保持簡單很重要的原因。如果他更合格，那麼我想你應該得到它;）

一些很好的建議，在哪裏開始黑客攻擊/改變的東西總是比文檔更好。在熟悉代碼之後，將文檔視爲備份材料，它不應該是出發點（除非您是具有無限資源和時間的特殊技術撰稿人）

來源

2010-07-31 12:05:20 petteri

文檔是一回事，你的新項目所有者。恕我直言，這是一個典型的情況，「越少越好」 - 你的同事閱讀理解某些東西的文檔越少越好。而且，當然，學習需要時間 - 對於你們兩個來說，接受它。

所以

，而不是寫大量的文件，使你的代碼自commentatory
有一個清潔和命名的文件夾結構中的所有文件/源代碼等
確保您的構建過程幾乎完全自動化
不要忘記文檔如果它不是自動的，那麼也需要你的部署過程
清理，清理清理！

來源

2010-07-31 12:10:57

不能同意更多。必須經歷大量文檔（其中大部分可能甚至不是最新的），這是令人沮喪的，並且通常對理解代碼沒有太大的幫助，如果代碼結構嚴密且不言自明。如果你的繼任者具有相當好的編程技能，那麼良好的代碼和高級概覽文檔可能就足夠了。 +1 – stakx 2010-07-31 12:35:26

+1用於自動構建 – 2010-08-02 05:42:19

當接管一個項目時，文檔當然是可取的，但更好的是一個好的測試套件。試圖修改一個你無法測試正確性的程序是一場噩夢。

來源

2010-07-31 12:28:17

新主人抱怨可怕的文件，錯誤和糟糕的設計。

我懷疑無論你做什麼，新主人總是會抱怨某件事。人們是不同的，所以對你來說看起來很容易理解的東西，對其他人來說看起來很可怕，也很複雜。

原來的主人，然後困擾數月與有關項目的問題，要求修復舊的錯誤等

在這種情況下，你應該明確地拒絕幫助。如果你不會拒絕，你最終可能會免費做別人的工作。如果維持這個項目不再是你的工作，那麼這個新人應該在沒有你幫助的情況下解決他的問題。如果「新人」無法處理這個問題，他就不適合這項工作，應該退出。

它是一箇中等規模的項目，

「中型」相比有哪些？多少行或代碼，多少個文件，多少兆字節的代碼？

我不知道該怎麼做，才能使這種轉移儘可能順利。我已經有一個體面的文檔，代碼是相當好的評論，我仍然在改善它。

我會處理這樣的：

首先，做一個掃在整個代碼：
1.1刪除所有代碼註釋塊。
1.2刪除所有未使用的例程和類（我在說「忘記」例程，而不是實用程序庫的一部分）。
1.3確保所有代碼遵循一致的格式規則。即你不應該在同一個應用程序中混合使用class_a,ClassA和CClassA，你不應該使用不同的樣式來放置括號等。
1.4確保所有名稱（類，變量，函數）都是不言自明的。你的代碼應該儘可能自我解釋 - 這會使你免於編寫太多的文檔。
1.5在有複雜或難以理解的功能的情況下，寫下評論。儘可能縮短他們的時間，並且只在他們絕對要求時才發佈。
1.6儘量確保沒有已知的錯誤。如果有已知的錯誤，請記錄它們及其行爲。
1.7從項目目錄中刪除垃圾（項目中未使用的文件等）
1.8如果可能，請確保代碼仍然編譯並按預期工作。
用doxygen生成html文檔。稍微反覆幾次，稍微修改一下代碼評論，直到你滿意爲止。或者直到你對結果感到滿意。不要跳過此步驟。
如果有一個帶有整個開發歷史的版本控制庫（比如說git庫），把它交給一個新的維護者，或者給他（她？）一個庫的功能副本。這對於（git）平分和查找錯誤來源很有用。

一旦完成並且代碼被轉移給新的維護者，除非您爲其付費（或者除非您獲得其他幫助或除非是訂單）否則不要提供「免費幫助」從你的老闆那裏幫助新維護者成爲你當前任務的一部分）。維護代碼不再是你的工作，如果新的維護人員無法處理它，他就無法勝任這項工作。

來源

2010-07-31 12:29:07 SigTerm

我認爲對於這樣的情況，最重要的是自動編譯，文檔和測試項目的工作，完整的構建。這樣一來，新開發人員就有了一個明確的定義。原則上，他可以從測試和文檔中找出問題。

來源

2010-07-31 13:04:15

將我自己的項目傳遞給別人 - 該怎麼辦？

回答

相關問題