如何幫助團隊更好地寫代碼

我們發現很多開發者似乎認為爛代碼最終并沒有帶來太多傷害。

如果你數一下有記錄在案的因代碼問題而失敗的項目個數，那么，我們認同這個數字并不會很大。但是，你不必創造真正的災難導致軟件項目損失大量金錢。

作為一名架構師，你可以做什么來幫助團隊更好地寫代碼呢？

1．爛代碼真的比好代碼更昂貴

我們不清楚你的情況，但我們肯定認為寫爛代碼真的比寫好代碼更加昂貴。至少，我們認為在生命周期比較長，業務影響比較大的項目里是更加昂貴的。

聽起來可能很簡單，當使用爛代碼（即創建、測試和維護它）的成本超過業務模型可以忍受的代價時，項目才會因它而敗。同樣地，如果公司設法使代碼的成本保持在極低水平，沒有項目會因為代碼問題而失敗。

這就是痛點。

你如何定義最終影響代碼成本的因素？哪些動作組成了“寫代碼”：編碼、構建、調試？你應該把測試當作一個附加的按需的特性嗎？文檔呢？缺陷修復呢？

有時候，管理者只是投機取巧，通過雇傭廉價開發者或砍掉測試和文檔等縮減開發成本的手段來解決問題。

不幸的是，這些管理者沒有意識到他們只是縮減了產生可能（但不一定）工作的代碼的成本。產生剛好可以工作的代碼只是問題的一面。現在，需求經常改變，復雜性不斷增長，更糟糕的是，復雜性通常僅在行進的過程中才能完全了解。在這種情況下，產生代碼只是影響總體成本的一個因素。代碼維護和進化才是最大因素。

好的架構師都很清楚，只有寫得好的代碼，對軟件原則和語言特性有很好的了解，恰當使用模式和實踐，以及注重可測試性才能解決代碼維護的問題。這使得編碼比產生剛好可以工作的代碼更加昂貴，但比維護和進化剛好可以工作的代碼就廉價得多了。

2．使用工具輔助編碼

我們認為成功的項目基于兩個因素：懂得領導藝術的管理層，以及懂得代碼質量的開發團隊。

就編碼而言，不一定有時間讓開發者現在寫代碼，然后在往后的某個時間修復和整理它。每個開發者都會發誓，第二遍處理永遠都不會發生，即使發生，也不會造成很大影響。

如果想在第一次就寫出更好的代碼，最好使用代碼輔助工具。這些工具通常集成在IDE里，可以簡化常見開發任務，使開發者的工作進展得更快，可以寫出更好的代碼。在最壞的情況下，代碼可以寫得更快，留有一些時間做第二遍處理。

自動完成、慣用設計提示（即根據語言或框架建議的慣用方式寫代碼）、代碼檢查、支持鍵盤輸入的預定義代碼片段，以及支持預定義和自定義模板等服務都是加快開發以及確保一致性和更好、更干凈代碼的實踐。

代碼輔助工具使開發得以持續發展，只需兩次點擊就能極大地改善你所寫的代碼的質量。代碼輔助工具可以發現重復和沒用的代碼，使重構體驗變得愉快，簡化導航和檢查，以及強制使用某些模式。

比如說，所有開發者原則上都同意適當的命名規范對于代碼的可讀性和質量來說是很關鍵的。但是，當你意識到你應該重命名一個命名空間或者一個方法時，你就會面臨至少要在你自己的整個代碼庫里這樣做的問題。這么瘋狂的工作原本需要你自己在極短的時間內完成，現在可以由代碼輔助工具代勞了。

ReSharper是最受歡迎的代碼輔助工具。若想了解更多，可以訪問http://www.jetbrains.com/resharper。其他類似工具有來自DevExpress的CodeRush，以及來自Telerik的JustCode。

但是，你要記住，代碼輔助工具不是魔法，它們所做的只是讓你付出更低的代價和更少的努力就可以寫出更好和更干凈的代碼。除此以外，一切仍然取決于你。你在重構過程里以及在代碼編輯階段操作工具。

3．如何告訴別人他們的代碼很爛

假設你發現你團隊里有人在寫爛代碼。你會如何跟他們說？

這里涉及一些心理學方面的東西。你不想表現得尖銳，你也不想傷害任何人；與此同時，你不想其他人的工作在某一時刻傷害到你。溝通是關鍵，不是嗎？所以你需要找到最佳方式在別人的代碼很爛時告訴他們。

總體而言，我們認為讓人注意到某些代碼的最佳方式是不經意地問為什么用這種方式來寫。你可能會找到更多背后的動機，不管是信息有誤，態度不好，技能局限，或者你所不知的約束。

在沒有確鑿證據之前，不要斷定你的編碼方式更好。那么，你只需對問題代碼背后的真正動機表現出好奇和興趣，并且表達出想了解更多的意愿，因為如果換了你會用不同的方式來編碼。

4．使每個人都變成更好的開發者

下面總結一下讓團隊寫出好代碼的金科玉律：

針對代碼，而不是寫代碼的人。但通過寫代碼的人來嘗試改善代碼。

你可以通過某種方式修復任何一塊爛代碼。但是，當這種情況發生時，你不要責怪寫代碼的人；你可以幫助寫代碼的人改進他做事的方式。如果你可以這樣做，你至少可以得到兩方面的好處：你的團隊得到一個更好的開發者，你的團隊可能得到一個更快樂更有動力的開發者。你使這個開發者感覺更像英雄，因為他現在有了完成他的工作的最佳方式。

為了改進某些方面，每個人都需要培訓和實踐。最有效的方式是以敏捷的方式結合培訓和實踐。但是，我們經常看到一些公司購買了培訓服務，讓他們在短短幾天內完成和交付，然后期望人們在接下來的星期一就能投入工作。事情并不是這樣的，至少不會如此有效。

這讓我們想起幾年前非常流行的一個短語：在職培訓。它指的是一邊學習、一邊做實際的工作。這起因于擁有不同技能的人在同一個團隊里協同工作。

5．在簽入代碼之前檢查一下

你的公司可能會有最好的編碼標準，但你怎樣實施它們？信任開發者是好的，但驗證可能更加有效。結對編程和常規設計審核是檢查代碼庫健康程度的具體方式。在一次典型的設計審核里，你可以和大家一起開放地討論某些示例代碼。這些代碼可以是來自項目的真實代碼片段，它是某些參與者寫的，或者為了避免牽涉到情緒問題，也可以是為了闡明你想表達的觀點而專門寫的一段代碼。

為了實施編碼標準，你也可以考慮對你的代碼控制系統采用簽入策略，不管是Microsoft Team Foundation Server（TFS）、TeamCity或者其他系統。這個過程可以自動化嗎？

今天，幾乎任何源代碼管理工具都提供針對簽入文件實施控制的方式。比如說，TFS支持封閉簽入（Gated Check-ins）。封閉簽入本質上就是根據規則簽入。換句話說，文件只有在符合既定規則的時候才會被系統接受。當你選擇創建封閉簽入時，TFS會要求你指定一個現有的構建腳本。只有在構建成功完成的時候，這個文件才會簽入。

在TFS里，一個構建只是有一個MSBuild腳本，它可以使用各種任務來定制。TFS自帶一些可以集成的預定義任務。比如說，你會找到代碼分析（以前的FxCop）任務和一個運行選定測試列表的任務。因為MSBuild任務只是一個實現了約定接口的注冊組件，所以你可以自己創建新的任務，添加自己的驗證規則。

值得注意的是，JetBrains的ReSharper，前面提到的其中一個代碼輔助工具，在它的最新版里提供了一組免費的命令行工具，可以在自定義的MSBuild任務里檢測重復代碼以及執行常見檢查，包括根據你定義的自定義模板執行自定義檢查。有趣的是，你甚至不需要ReSharper許可證就能使用這個命令行工具。若想了解更多關于ReSharper命令行工具，可以訪問http://www.jetbrains.com/resharper/features/command-line.html。

6．值得欣喜的是，這個項目不需要英雄

開發者傾向于超越自我，至少在他們深藏的夢想里，希望他們每周可以工作超過80小時來拯救項目，讓客戶滿意，并且成為管理者和開發者同伴眼里的真英雄。

我們想改編詩人和劇作家Berthold Brecht的一句名言：我們總想活在不需要英雄主義的世界里。對英雄的需要以及由此而來的高壓力通常源自不足的期限。

有時候，期限從項目一開始就不公平了。在其他情況下，期限是在進展的過程中被證明為 錯的。

當這種情況出現時，情感上容易默許，但對指出不公平的期限的害怕產生對英雄的需要。溝通以及把問題挑明是一種坦誠，也是恢復更多控制以及降低壓力的有效途徑。

在軟件里，我們可以說，你感到壓力是因為迫在眉睫的最后期限或者缺少所需技能。如果及時溝通，兩種情況都能很好解決。

我們不想要英雄，雖然我們自己也做過幾次英雄（我們猜你們中的大多數也做過），我們認為英雄主義是一種例外情況。在軟件里，例外通常是要避免的。

7．鼓勵實踐

幾乎任何運動的專業運動員每天都會花上好幾個小時來實踐，到底是為什么呢？開發者和專業選手之間是否存在某種相似之處？看情況而定。

一種看法是開發者每天在工作中實踐，并且沒有與其他開發者競爭。有鑒于此，有人可能會得出沒有相似之處的結論，因此沒有必要實踐。

另一種看法是選手經常練習基本動作，以便他們可以自動地重復這些動作。定期回顧面向對象基礎、設計模式、編碼策略以及某些領域的API可以使這些知識記憶得更牢固，回憶得更 快速。

注意

寫過多本ASP.NET的書，也實踐過驗證和成員系統，時隔多年，Dino最近在使用基于角色的ASP.NET系統時感到問題很大。“老兄”，他最近跟我說，“我上次處理角色是什么時候？”最終，創建基于角色的UI基礎設施以及相關的成員系統耗費比預期更多的功夫。

8．持續改變是工作的一部分

持續改變是描述現代軟件項目動態的有效方式。軟件項目始于一個想法或者一個相對模糊的業務想法。架構師和領域專家需要收集一些正式的需求，使原來的想法或業務需要更加明顯。

根據我們的經驗，大多數軟件項目就像活動目標，而需求就是把目標到處移動的東西。每次添加一個新的需求，這個環境以及系統的動態（在沒有這個特性的情況下可以正常工作的設計）也會改變。需求的改變是因為問題領域有了更好的了解，問題領域變化很快，或者時間壓力的問題。

需求波動（Requirements Churn）這個術語通常用來表示軟件項目里的需求變化率（功能性需求、非功能性需求，或者兩者都有）。高需求波動將會為BBM提供理想的藏身之所。

每當處理新的需求都重新審視整個系統的架構是切實避免BBM的唯一辦法。重新審視整個系統的架構確實需要重構，也確實具有較大成本。這里的重點是找到保持低成本的方法。重構是其中一個很難察覺會為項目帶來價值的東西。未能重構會導致這些價值流失，這很糟糕。

注意

Twitter在2010年上線，當時的Web前端充滿了客戶端功能。大量功能是通過在動態下載的JSON數據之上即時生成HTML來提供的。在2012年，Twitter重構了整個系統，選擇了服務器端渲染。這是一個架構層面的重構，毫無疑問是昂貴的。但他們認為這是必要的，并且持續服務數億用戶，不管是對還是錯，反正它能工作。

作為一名架構師，架構和設計重構都是關鍵工具。架構師無法控制歷史以及業務場景和現實世界的發展。架構師需要一直做出調整，避免重新構建。這正是重構派上用場的地方。

本文節選自《Microsoft.NET企業級應用架構設計（第2版）》

內容簡介

軟件架構是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。本書就是一個關于軟件架構的堅實、可重用且易于訪問的知識庫。

本書分 4 個部分來介紹軟件架構相關的內容。其中，基礎知識部分為軟件架構打下基礎；設計架構部分關注表現層和業務層；支撐架構部分涵蓋 3 個可用于構建各種子領域的支撐架構；基礎設計部分介紹了多樣化持久化、NoSQL數據存儲、SQL、Entity Framework和關系型數據庫等內容。

本書著重介紹軟件架構相關的內容，非常適合軟件架構師和想成為軟件架構師的人閱讀，而且首席開發者和各種.NET應用程序的開發者也能從本書獲益。

本文轉載自異步社區。

原文鏈接：https://www.epubit.com/articleDetails?id=NC7E3EF91EB0000013FF0B0F910731B66

軟件開發 架構設計

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。