軟件開發(fā)的51條建議
最近在讀《軟件開發(fā)的201個原則》，書內(nèi)容不多，但是每一頁都看的很仔細，好像往往這種言簡意賅的書更讓人有靜下心來仔細閱讀的欲望。在我看來，讀書的作用本來就不是解答所有的困惑，而是激發(fā)人更加深入地學習的動力。
如果看這本書的時候，你會主動搜索文獻或者資料，去了解更多的信息，那說明這本書就已經(jīng)幫助了你。話不多說，拋磚引玉，今天和大家分享下我的“讀后感”。
質(zhì)量第一：編程一定要把質(zhì)量放在首位，沒有可商量的余地。當你被要求要為質(zhì)量做妥協(xié)時，要直接說不。質(zhì)量必須可量化。
做好質(zhì)量與開發(fā)效率之間的權衡：對質(zhì)量要求越高，開發(fā)效率就越低。越是強調(diào)提高開發(fā)效率，最終的質(zhì)量就越低，bug的密度就會增加。
如何提高軟件質(zhì)量：讓客戶參與、在全面開發(fā)之前驗證需求、保持設計簡單、code review、雇傭最優(yōu)秀的人。
盡早把產(chǎn)品交給客戶：在需求階段，無論你多努力了解客戶需求，都不如給他們一個產(chǎn)品，讓他們使用后確定自己的真實需求?？梢栽陂_發(fā)過程的早期構建一個快速且粗糙的原型，交給用戶，收集反饋，然后可確定真正的需求。最終產(chǎn)品也就更有可能讓客戶滿意。
與客戶/用戶溝通：永遠不要忽視開發(fā)軟件的原因：滿足真正的需求，解決真正的問題。解決真正需求的唯一方法就是去跟有真正需求的人溝通，讓他們參與進來。
開發(fā)者要與客戶的目標一致：從客戶的角度出發(fā)，按優(yōu)先級對需求排序，確保不要delay。
開發(fā)正確的原型：有兩種原型，一次性原型和演進式原型。一次性原型用快速粗糙的方式構建，交給客戶來獲得反饋，得到反饋后廢棄，然后獲取正規(guī)的需求后再開發(fā)。演進式原型用高質(zhì)量的方式構建，交給客戶獲取反饋，然后進行整改。如果你對大多數(shù)功能都不了解，應該首先構建一個一次性原型，然后從零開始構建一個演進式原型。
注意：開發(fā)一次性原型要快，不用擔心質(zhì)量，可以使用任何工具任何語言，只需要開發(fā)那些沒有充分理解的特性。
注意：開發(fā)演進式模型時，從小的可用系統(tǒng)開始，只實現(xiàn)少數(shù)功能，然后逐步擴展，覆蓋更多的功能子集，這樣可降低風險。
為變化做好準備：開發(fā)過程中的變化是不可避免的，可能體現(xiàn)在新的代碼、新的測試計劃、新的需求或需求變更等，不要抱怨，積極應對，做好準備。
讓軟件只需簡短的用戶手冊：即簡短的文檔，文檔內(nèi)容越少，軟件質(zhì)量越高，這里不是說要少寫文檔，而是要做高質(zhì)量的軟件，讓用戶盡量少看文檔就能使用明白。
“知道何時”比“知道如何”同樣重要：一個工程師要了解更多的技術，要知道什么時候使用什么技術，要知道什么項目使用什么項目。
跟風要小心：當學習新技術時，不要輕易接受與之相關的不可避免的炒作。
不要忽視技術：不要固步自封，緊跟技術潮流，每年努力參加1-2個關鍵會議。與參會者的交流，很可能比會議報告更重要。
使用文檔標準：如果你的項目、組織或客戶要求遵循一套文檔標準，那就要遵循它，理智的執(zhí)行。
要承擔責任：軟件有任何問題時，不要找任何借口，要承擔責任，要么做好，要么就不做。
先確定問題，再寫需求：先明白要解決的是什么問題，再提出相關的需求。
立即修復需求規(guī)格說明中的錯誤：
如果錯誤保持到系統(tǒng)設計階段，定位和修復要多花5倍的代價
如果保持到編碼階段，要多花10倍的代價
如果保持到單元測試階段，要多花20倍的代價
如果保持到交付階段，要多花200倍的代價
記錄需求為什么被引入：記錄每個需求的動機。
給需求排列優(yōu)先級：并非所有需求都是同等重要的，要明確需求的優(yōu)先級，先做哪個需求，后做哪個需求，或者在關鍵階段哪個需求可以暫時舍棄掉。
明確環(huán)境超出預期時的系統(tǒng)行為：當環(huán)境超出為其定義的任何約束時，在軟件需求規(guī)格說明中應明確聲明預期的系統(tǒng)響應。用我們開發(fā)者的話說就是，做好邊界處理。
評估備選方案：設計架構或者某個解決方案時，最好詳細列出多種方法，明確優(yōu)缺點，在這些方法之間權衡分析，最終選擇一種。
做好封裝：面向?qū)ο蟮囊环N思想，對某一需求做好抽象，做好封裝，做好信息隱藏。
不要重復造輪子：程序員經(jīng)常一次又一次的重新發(fā)明組件，卻很少修補已有的組件。
保持簡單：構建軟件設計有兩種辦法，一種辦法是使它簡單到明顯沒有缺陷，另一種辦法是使它復雜到?jīng)]有明顯的缺陷。
保持概念一致：這是高質(zhì)量設計的一個特點，方式一定要統(tǒng)一，包括模塊如何向調(diào)用方通知錯誤，軟件如何向用戶通知錯誤，如何組織數(shù)據(jù)結構，模塊通信機制，文檔標準等等。
使用耦合和內(nèi)聚：盡量做到高內(nèi)聚低耦合。高耦合意味著，當修改一個組件時，很可能需要修改其他組件。低內(nèi)聚意味著，難以分離出錯誤原因或者難以判斷為滿足新需求而要修改的位置。
為變化而設計：需要選擇合適的架構、組件和技術來適應不斷的變化，設計需要做到：
模塊化：產(chǎn)品由獨立部分組成，每一部分都可以單獨升級和替換，對其他部分造成最小的影響。
可移植性：產(chǎn)品應該很容易修改以適應新的硬件和操作系統(tǒng)。
可塑性：產(chǎn)品可以靈活適應預期外的新需求。
軟件最好做到通用，靈活：通用性體現(xiàn)在，在不同的場景下不做任何修改就能執(zhí)行預期功能。靈活性體現(xiàn)在，它很容易被修改，以在不同的場景下執(zhí)行其功能。
使用高效的算法：了解算法復雜度是成為優(yōu)秀軟件工程師的必要前提。高效的算法和低效的算法可能會相差幾個數(shù)量級。
編碼時避免使用特殊技巧：很多程序員喜歡編寫比較trick的代碼，然而這種程序讓別人很難理解，也很難維護，這種特殊技巧被頻繁使用的理由有很多：
程序員都非常聰明，他們想展示這種聰明
維護人員在最終搞清這些特殊技巧如何生效時，不僅會認識到原來的程序員有多聰明，也會意識到自己有多么聰明。
職業(yè)安全感。
避免使用全局變量：全局變量寫代碼很方便，但是如果此全局變量訪問出現(xiàn)問題，很難確定問題具體出現(xiàn)在哪個模塊，所以，可以將重要數(shù)據(jù)封裝在對應模塊中，做好封裝。
編寫可自上而下閱讀的程序：有助于讀者理解。
使用有意義的別名：確保每個變量，每個函數(shù)的命名都有意義，盡量做到代碼即文檔，代碼即注釋。
程序首先是寫給人看的：程序的功能以及效率固然重要，但程序也是寫給人看的，要提升程序的可讀性，以免在這個過程中對相關人員造成負面影響。
先確保正確，再提升性能：不要擔心優(yōu)化問題，每個項目都有很大的進度壓力，在這種情況下，任何時候一個組件要是能夠按時完成并且可靠運行，都值得慶祝，先保證完整功能，然后再去考慮做性能優(yōu)化。
先寫文檔后寫代碼：也可以理解為，不要上來就埋頭寫代碼，要先想清楚代碼應該怎么寫，然后再動手。
代碼審查：即code review，一定要做code review，code review大約會消耗15%的研發(fā)資源，可以將總成本減少25%~30%。
不要嵌套太深：即圈復雜度不要太高，不過過多的if-else，switch-case之類的嵌套，考慮做優(yōu)化。
編程語言不是接口：如果你是一個好的程序員，對任何一種編程語言來說你都應該是一個好程序員。
編程語言的知識沒那么重要：一個真正優(yōu)秀的程序員很好的理解和贊賞高質(zhì)量編程的概念，而不只是了解某些編程語言的語法和語義特性。為一個項目選擇語言的首要驅(qū)動力應該是什么語言更適合，而不是說我們只知道C語言。
格式化代碼：使用標準的format規(guī)則，可大大提高程序的可讀性。選擇遵循哪種規(guī)則不重要，但一旦選擇了，就要保持一致。
不要太早編碼：即在編碼之前，要確認需求和設計都是正確且合適的，即想清楚再編碼。
為你的代碼做單元測試：老生常談了，自己寫的代碼自己都不測試就去提測，那得多坑啊。
好的管理比好的技術更重要：好的管理可以激勵人們做到最好，糟糕的管理會打擊人們的積極性。
人是成功的關鍵：具備合適經(jīng)驗能力的人，是在預算內(nèi)按時完成滿足用戶需求軟件的關鍵。
幾個好手要強過很多生手：對于關鍵任務，最好只安排少數(shù)有足夠經(jīng)驗的工程師，而不是安排許多沒有經(jīng)驗的工程師。
不要設定不切實際的deadline：要設定合理的deadline，然后嚴格踩住。
知曉風險：在開始項目時，要熟悉經(jīng)常導致軟件災難的情況，并制定降低風險的計劃：
人員短缺
不切實際的排期
不理解需求
開發(fā)糟糕的用戶界面
沒有控制需求變化
缺乏可重用或接口化的組件
糟糕的響應時間
試圖超越當前計算機技術的能力
預先了解風險：在項目計劃的早期階段，要梳理與你的項目相關的最大風險列表。
有時重新開始會更好，有時候從頭開始設計和編碼可能是更好的選擇。
每次改動后都要進行回歸測試：這個相信大多數(shù)程序員都會遵循的一個原則，代碼改動后需要驗證它是否能夠正確的運行。
在優(yōu)化前先進行性能分析：先做性能分析，拿到性能數(shù)據(jù)進行性能分析后再考慮做優(yōu)化，80-20原則，80%的CPU周期
版權申明：內(nèi)容來源網(wǎng)絡，版權歸原創(chuàng)者所有。除非無法確認，都會標明作者及出處，如有侵權，煩請告知，我們會立即刪除并致歉!