ROSE 編譯器框架/經驗教訓
我們在這裡收集一些過去經驗教訓需要做的事情。
教訓
- 一位開發人員試圖理解一位員工的原始碼。但是他發現程式碼的縮排對他來說不正確。因此，他重新格式化了原始檔並提交了更改。後來，這位員工發現他的程式碼被更改得太大了，他再也無法閱讀它了。
- 更糟糕的是，人們將難以合併混雜著縮排更改和實際更改的更改。
解決方案
- 請不要重新格式化你不擁有或不維護的程式碼。
教訓
- 我們有一名學生被分配了一個辦公桌，它位於一個大房間的角落裡。這臺辦公桌距離其他實習生也很遠。結果，這位學生與其他人的互動減少了。他不得不解決問題時獲得的幫助也更少。
解決方案
- 位置很重要！坐在你應該經常與之互動的人旁邊。讓你的辦公桌/辦公室對其他人來說容易接近。物理上孤立的辦公室/辦公桌可能會對你的工作效率產生非常負面的影響。
教訓
- 不知何故，新的實習生預設被分配了 Mac OS X 機器。但他們中的一些人可能不熟悉 Apple 機器，甚至不喜歡 Mac OS X 的使用者介面，包括鍵盤、視窗系統等（對 Apple 產品的愛恨情仇）。因此，他們感到被困在一個不舒服的開發平臺上。我們有一些實習生即使在一個月後也無法在 Mac 鍵盤上流暢地打字。這是不必要的。
解決方案
- 提前提供選擇：Linux 或 Mac OS X。提醒人們，他們可以選擇自己喜歡的平臺。
教訓
- 一位開發人員使用同一個 Git 倉庫的不同分支來執行不同的任務：修復錯誤、新增新功能和編寫文件。後來他發現他無法提交和推送一項任務的工作，因為其他任務的更改還沒有準備好。
解決方案
- 為不同的任務使用獨立的 Git 倉庫。這樣一項任務的狀態就不會干擾其他任務的進展。
教訓
- ROSE 最初不依賴於 Boost C++ 庫。但後來，一些開發人員看到了 Boost 的好處，並提倡使用它。最終，Boost 成為使用 ROSE 的必備軟體。
- 但是 Boost 庫也有其缺點：難以安裝（看看我們公開郵件列表中有多少 Boost 問題），缺乏向後相容性（使用舊版本的 Boost 的程式碼在新版本上會出錯），巨大的標頭檔案，包含複雜的 C++ 模板，這會減慢編譯速度，甚至會破壞一些編譯器。
- 我們仍然在內部就如何處理 Boost 進行辯論。這通常是一個痛苦且情緒化的過程。
解決方案
- 非常謹慎地引入大型軟體依賴項。否則你會很容易陷入困境。
- 至少要求那些提倡新的軟體依賴項的人負責維護它 5 年，並同時提供一個關閉它的選項。
教訓
- 一位開發人員建立的測試過於寬泛，主要是因為它們是在開發後期才包含進來的。這會導致本不應該透過的測試透過，也就是說，即使程式碼已經損壞，所有測試也都會透過。
解決方案
- 確保測試仔細檢查結果。透過確保你的函式只有一個目的，這會變得容易得多。例如，如果你需要轉換資料並對轉換後的資料進行操作，請將轉換和操作拆分成兩個函式（至少）。
教訓
- 一位開發人員在最初編寫程式碼時沒有添加註釋，後來又回到了程式碼中，不得不經歷一個艱鉅的任務，去理解
他自己的不可讀程式碼。
解決方案
- 保持變數和函式名有意義。邊寫邊做完整文件，不要留到以後再做。
教訓
- 一位開發人員在編寫程式碼時沒有考慮到結構。這導致了臃腫且難以閱讀的程式碼，需要多次
重構。
解決方案
- 程式設計師必須編碼和設計，而不僅僅是編碼。結構良好的程式碼比結構不良的程式碼更容易閱讀。
教訓：一位開發人員編寫程式碼時，沒有了解使用者真正需要什麼。這導致了嚴重的重構，如果他一直專注於使用者，這些重構本來是可以避免的，或者至少可以變得更簡單。
解決方案：儘可能向用戶徵求意見。從長遠來看，這將為你節省很多麻煩。
教訓：一位開發人員編寫了一個相當難懂的元件，而沒有完全理解使用者可能想要用它來做什麼。
解決方案：至少檢查輸入和輸出是否符合使用者期望，這將節省大量時間和煩惱。