代碼極簡主義

     我是代碼極簡主義者。

1：寫代碼，可以用簡單語句寫的，絕對不用複雜語句。

     簡單語句，無論什麼水平的人都能閱讀，在讀代碼的過程當中，會很順暢。而複雜語句，水平不夠的人，不必定能看懂。試想一個場景，項目時間很緊，我今天要把這段代碼看懂，而後爭取把這個bug解決掉。但是忽然來了這麼一個複雜語句，之前都沒有見過，都不知道是什麼意思?你說討厭不討厭?爲了弄懂它，我得擺渡一下，擺渡若是沒有結果，那谷還得谷歌一下，若是仍是看不太懂。那沒辦法了，問一下大牛吧。擡頭一看，大牛都下班了。因而今天要把這個bug解決的但願完全破滅，你說鬧心不鬧心，多耽誤時間？

     因此，我從不用複雜語句。你能夠說我水平不夠，也能夠說我沒見過世面，無所謂。只要功能實現了就好，只要代碼容易維護就好，其餘的我不care。

     你也可能會說，寫這種複雜的代碼，執行效率高。可是，我以爲，以犧牲代碼的易讀性和易維護性來獲得這一點點的性能，不太值得。並且如今的硬件性能都很高，這點性能提高根本就是杯水車薪。寫這種複雜代碼，我以爲通常都是酸腐程序員的我的技能秀，沒有多大的實用意義。

有人說，一個手機，80%的功能是沒有用的，我以爲，一門語言，也有不少語法是沒用的，咱們不必必定要用它們。

2：我從不肯意保留無用的代碼。

    記得有一次，咱們公司的項目上線運行的時候出了個大bug。同一時間點全部業務進程集體重啓了。業務團隊查了好久，都沒有查出緣由，由於沒有發現任何異常的日誌文件。而後就把我叫過去。說他們發現這些集體重啓的業務進程有一個共同特色，就是都包了我提供的一個庫，因此他們懷疑是否是我這個庫的問題，但願我查一下這個庫。

      由於沒有經歷過，因此我理所固然地認爲，此次集體重啓事情跟個人庫應該沒什麼關係。就算是個人庫有問題，那也只可能影響單個的業務進程，而不可能同時影響其餘的業務進程。由於這個庫以前不是我作的，我也是剛接手過來沒多久，正在整理代碼。因此回來後，雖然我不太相信是個人庫的問題，但仍是把代碼仔細走讀了一遍。這不走讀沒關係，一走讀才發現還真的是我這個庫代碼的問題。

      事情是這樣的，這個庫代碼是從之前老的庫代碼修改過來的。老的庫代碼裏面有一段邏輯，若是這個庫鏈接服務器失敗，那麼就會開啓一個72小時的定時器，若是72小時尚未重連成功，那麼庫就會自殺，使用的自殺手段是kill -9 進程pid。若是72小時內重連成功，那麼就會把定時器停掉。

      新的庫代碼不須要這個邏輯，可是相關的代碼並無徹底刪除。重連成功的時候，中止定時器的代碼被刪除了，可是網絡鏈接失敗的時候，開啓定時器的代碼沒有刪除，定時器回調函數也沒有刪除。因此一旦在業務的運行過程當中，出現過網絡鏈接失敗的狀況，那麼72小時定時器就會被開啓，即便後面重連成功了，定時器也不會被刪除，因此72小時一到，全部業務進程就集體自殺了。因此此次事故的根本緣由就是沒有把老代碼刪除乾淨！

      你們應該都有這樣的經歷，維護老代碼的時候，裏面常常會有不少註釋的代碼。有時候更誇張的是，你會發現有用的代碼尚未註釋掉的代碼多，有用的代碼都被淹沒在註釋代碼裏，看到這樣的代碼，你會以爲爽麼？還有的狀況是，代碼沒有被註釋掉，可是根本沒有什麼用處，由於沒有地方調用他們，或者是已是沒有用的邏輯。這樣的代碼多了，你可能會迷失在這些無用的代碼中，而忽略真正有用的代碼。

      因此，我通常接手一份老代碼後，第一件事情就是把這些廢代碼刪除。首先是把註釋掉的代碼刪除，而後就是把代碼從頭至尾走讀一遍，把沒有註釋掉，可是已經明顯沒用的代碼都刪除。這樣作的好處一方面是減小代碼量，另一方面就是避免了老代碼裏面隱藏的bug。你只有對每一行代碼的用處都有清晰的認知，才能在出bug的時候精準定位。

      以前有個同事跟我說，代碼爲何要刪除，放在那裏，說不定之後還有用呀。這應該就是大多數廢代碼殘留的緣由。我不排除這種可能性，可是常常的狀況是這種可能性出現的機會不多。即便真的出現了，我再從新寫一次，又有什麼關係呢？

3：我不肯意作超前的設計

      不少人在設計一個新系統的時候，會進行過分的設計。

      什麼叫過分設計？打個比方，原本計劃只是要造一個一層樓的小房子，可是設計人員認爲之後這個一層的小房子可能會加到十層，因此地基被設計成能支持十層樓的地基。由於之後可能會加到十層，因此，房子的周圍應該要設計一些停車位，以知足之後住戶的停車需求。那既然之後這裏會住那麼多人，那相關的門衛，便利店，菜場，健身產所，幼兒園，小學，中學等等都要考慮起來。

因而乎，原本只須要幾百行代碼就能搞定的系統，被這麼一過分的設計，變成了幾千上萬行的代碼。各類封裝，各類泛型，各類繞。設計人員本身還沾沾自喜，看我設計了一個多麼牛逼的系統，之後的擴展性多麼地好。而目前真正用到的代碼，只是那幾百行而已。若是這個系統一直是這個設計人員本身維護，那也就罷了，愛咋整咋整。不幸的是，後來這個設計人員離職了，而後系統被移交給了一個並不熟悉這個系統的同事。

      這個同事傻眼了，這個系統原來這麼複雜啊，我都快繞暈了？這裏爲何要用泛型？直接定義一個類不就好了？這裏爲何要封裝，封裝類裏面什麼都沒有作呀？是否是裏面有什麼玄機我尚未參透？是否是我能力有限呀？

      因此，我總不建議在設計的時候考慮太多「之後」這種可能性。如今軟件更新換代那麼快，之後的事情誰知道呢？你的這種可能性可能尚未出現呢，你設計的模塊可能就已經被淘汰了。可是你的那些過分的設計卻花費了後續維護人員太多的時間和精力。

      以個人經驗，一個軟件在初期規劃的時候是什麼樣子，之後基本上就是什麼樣子，可能會有些小功能的添加，通常不會在結構上有大的調整。若是真的須要在結構上進行大的調整，基本上就須要從新規劃一個新的軟件了。因此代碼知足如今的需求就好了，不須要作過多超前的設計。

-----------------------------------------------------

歡迎關注個人微信公衆號 ^_^