軟件開發(fā)的22條黃金法則
編程本質(zhì)上是一門手藝活，既然是手藝，里面就會(huì)有很多個(gè)人技巧和經(jīng)驗(yàn)。
“破窗理論”，DRY（Don't repeat yourself），曳光彈，正交性，這些詞的意思是什么你還記得么？
《程序員修煉之道》這本書在我看來(lái)就是一本師傅寫給徒弟的開發(fā)哲學(xué)指南。
里面既講了一些軟件開發(fā)的哲學(xué)，比如破窗理論，它解釋了你的代碼為什么很快就會(huì)變成“屎山”。也講了一些有用的技巧和工具，比如如何利用好shell，提升你的編程效率。
這本書沒有復(fù)雜的代碼，沒有晦澀難懂的原理，你完全可以當(dāng)作一本閑書來(lái)看。
這本書里提到的看似人人都懂的道理，恰恰是很多碼農(nóng)們平常工作中最不重視，卻應(yīng)該去遵守的理念。
我提煉了一些書中我覺得至今仍然沒有過(guò)時(shí)的觀點(diǎn)（畢竟本書有一定的年頭了，讀起來(lái)很有年代感），和大家分享下，這中間也夾雜著一些我的看法和思考。
一、開發(fā)的哲學(xué)
作為開發(fā)，你需要對(duì)自己說(shuō)的話負(fù)責(zé)。對(duì)于不可能做到，風(fēng)險(xiǎn)太大的事情，你有權(quán)不去為之負(fù)責(zé)。 不要給做不到找借口，在你說(shuō)做不到的時(shí)候，要提供你的想法，告訴大家，做不到的原因是需要重構(gòu)，還是需要時(shí)間做原型，還是需要額外的資源支持。 破窗理論：一扇破窗戶，只要有那么一段時(shí)間不修理，就會(huì)漸漸給建筑的居民帶來(lái)廢棄感。于是窗戶就會(huì)一個(gè)個(gè)破碎，人們開始亂丟垃圾，亂涂亂畫。所以不要容忍你的代碼有“破窗戶”。 這一點(diǎn)大家肯定也深有感觸，在你寫代碼的項(xiàng)目里一旦看到了一些亂七八糟的結(jié)構(gòu)和設(shè)計(jì)，你也會(huì)不自覺地開始往上面寫湊活的代碼，慢慢就變成屎山了。 溫水煮青蛙，代碼是會(huì)慢慢腐爛而不被察覺的。要持續(xù)不斷的觀察你項(xiàng)目的變化，而不要只是專注于自己的那一塊代碼。 重視你的”知識(shí)“，這是你的資產(chǎn)。既然是資產(chǎn)，就要定期投資（不斷學(xué)習(xí)），多元化地學(xué)習(xí)。并且要定期的評(píng)估你的技術(shù)方向，畢竟開發(fā)是個(gè)動(dòng)蕩的行業(yè)，現(xiàn)在吃香的技術(shù)過(guò)幾年就會(huì)過(guò)時(shí)。要不斷地調(diào)整你的方向。 在做需求時(shí)，要像用戶一樣去思考需求的合理性，而不是一味完成產(chǎn)品下發(fā)的需求。 做的軟件，要溫和的超出用戶的期望。給他們的東西要比他們的期望多一點(diǎn)，給系統(tǒng)增加特性時(shí)，多做一些額外的努力，可以給你帶來(lái)很大的美譽(yù)。 當(dāng)你在的開發(fā)團(tuán)隊(duì)人員龐大時(shí)，可以指定每個(gè)人負(fù)責(zé)工作的各個(gè)方面。圍繞功能，而不是工作職務(wù)進(jìn)行工作的分配。比如有人要討論日期處理，就去找Mary，有人要討論數(shù)據(jù)存儲(chǔ)，就去找Fred。
二、開發(fā)的準(zhǔn)則
不要重復(fù)你自己：DRY（Don't repeat yourself）系統(tǒng)中的每一個(gè)組件都要單一，沒有歧義，并且權(quán)威的表示出來(lái)。 保持項(xiàng)目的系統(tǒng)正交性：不要讓系統(tǒng)間互相耦合，非正交的系統(tǒng)意味著你修改這邊的系統(tǒng)，會(huì)影響到其他的系統(tǒng)。
非正交的一個(gè)典型體現(xiàn)是前端的CSS，網(wǎng)上有很多調(diào)侃CSS的段子，CSS的一個(gè)修改經(jīng)常會(huì)影響到別的地方，這也是CSS很讓人痛苦的一個(gè)地方。在后端開發(fā)里，我們要盡量讓系統(tǒng)間不要相互影響，這對(duì)系統(tǒng)的傷害是很大的，并且在排查問(wèn)題時(shí)非常痛苦。
保證代碼設(shè)計(jì)的可撤銷性：如果你的想法是這個(gè)問(wèn)題的唯一解，那么這會(huì)是一個(gè)很危險(xiǎn)的事情。用戶的需求變化的很快，你的決策很可能只在當(dāng)下是正確的，不存在最終的決策，或者說(shuō)，時(shí)刻要注意和反思，如果現(xiàn)在這個(gè)方法行不通，是不是就沒法挽回了。 做好資源的估算：這里的資源指的是很多代碼相關(guān)的資源，比如數(shù)據(jù)庫(kù)，存儲(chǔ)，性能等。在開發(fā)前，一定要做好估算，在設(shè)計(jì)良好的代碼結(jié)構(gòu)，保證再未來(lái)能夠應(yīng)付變化。 把文檔盡量多的做在代碼里，而不是游離于代碼之外。否則，過(guò)了一段時(shí)間后，你這些文檔就沒有什么作用了。 你不可能寫出完美的軟件：作為一個(gè)開發(fā)，你要有這種自覺，自己也不要相信。所以要對(duì)自己可能犯的錯(cuò)誤，做防御性的編程。 異常處理：如果我刪掉所有的異常處理代碼，這些代碼是不是還能運(yùn)行？如果你的回答是”不能“，那么說(shuō)明你的異常代碼正在被用在非異常的情形中。這樣不好。 利用好元數(shù)據(jù)：這里的元數(shù)據(jù)可以理解為配置文件。將抽象放進(jìn)代碼，將細(xì)節(jié)放進(jìn)元數(shù)據(jù)。
我們?nèi)粘ｉ_發(fā)中經(jīng)常使用配置文件和分布式配置中心，把能夠放入配置文件的數(shù)據(jù)盡量放入，這樣不僅方便維護(hù)和修改，也能夠?qū)崿F(xiàn)不重啟應(yīng)用修改應(yīng)用行為的功能。代碼中應(yīng)該只有我們對(duì)業(yè)務(wù)的抽象。
考慮好系統(tǒng)并發(fā)：要為并發(fā)做好周全的考慮。
這個(gè)要求是不是看起來(lái)很稀松平常，大家都會(huì)？其實(shí)很多大型系統(tǒng)，尤其是老的系統(tǒng)，都沒有考慮并發(fā)問(wèn)題（去問(wèn)問(wèn)傳統(tǒng)軟件企業(yè)做的軟件，你就知道了）。并發(fā)其實(shí)可以算作是互聯(lián)網(wǎng)公司最常遇到的問(wèn)題，也是各種技術(shù)面試會(huì)問(wèn)的很深的問(wèn)題，要好好掌握。
不要靠巧合編程，要弄清楚程序?yàn)楹文軌蜻\(yùn)行。
我們接觸變成初期，經(jīng)常會(huì)有些代碼調(diào)著調(diào)著就跑通了，但是連自己也不知道為什么。這種代碼真正用于線上風(fēng)險(xiǎn)很大。畢竟，他也許不是真的能工作，他也許只是看起來(lái)能工作！
什么時(shí)候該重構(gòu)：當(dāng)你發(fā)現(xiàn)這四個(gè)事情出現(xiàn)的時(shí)候，就是你該重構(gòu)的時(shí)候。
代碼違反了DRY法則 有非正交的設(shè)計(jì) 需求變化后代碼過(guò)時(shí)了 性能有很大問(wèn)題
重構(gòu)時(shí)的準(zhǔn)則：
不要試圖在重構(gòu)的時(shí)候同時(shí)增加功能。 在開始重構(gòu)前，確保你擁有良好的測(cè)試，這樣你才敢放開手腳改動(dòng)。 采取短小，深思熟慮的步驟。
在測(cè)試的時(shí)候，要去做狀態(tài)覆蓋，而不是追求代碼覆蓋率。 好好學(xué)習(xí)shell：通常我們喜歡用各種帶界面的軟件，他們的特點(diǎn)是所見即所得。但是也帶來(lái)了缺點(diǎn)，所見即全部所得（what you see is all you see）。這對(duì)于效率的提升是一個(gè)瓶頸，有很多GUI上面需要很多操作的事情，在shell上只需要一行代碼。所以盡管它有點(diǎn)難入門，但是學(xué)好了，會(huì)大幅度提高效率。
有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)
歡迎大家關(guān)注Java之道公眾號(hào)
好文章，我在看??
評(píng)論
圖片
表情