是誰弄髒了個人代碼

前篇文章一發，立馬有程序猿說：解氣呀，我也待在這樣的一個公司，因此我怎麼能作出好的東西呢。

呵呵，那你誤會個人意思了，我可沒說哪一種公司很差，我以爲經歷過的都好。固然咱吐槽仍是要吐的，噴完了領導們，這篇文章來噴本身好了。如今不噴產品不噴測試不噴「領導」，僅僅從程序猿的角度說說，你都有作過哪些「湊合」的事，而後就「湊」出了一鍋粥。

1. 單元測試

首當其一的我以爲就是這個，你可能會想哎如今就這麼兩三條槍，UT那是大團隊的事，我這有啥事吼一嗓子都解決了。但是一旦你公司的開發「戰線」有點長，好比APP/WEB/第三方接口都作的狀況下，測試變得困難起來，API OK了APP沒到位，或是上了線了才發現出了問題。

一旦這個流轉的線路拉長、層級增多，就有人開始「巧合性編程」，自測就基本靠猜了。尤爲是那些隱藏得很深的操做，在APP和WEB上點一次都很麻煩，就更別說反覆的測試了。

更重要的一個缺點是組織結構是渙散的，今天想起來加一個，明天誰喊嗓子再加一個。這種"無組織無紀律」的行爲是壓垮駱駝的那根稻草。

2. 組件模塊

接上面，仍是體如今系統思考上，若是全部的思惟都在功能點上，沒人爬上山頂向下看看這房子是否是要倒了，全部的力量都是在蓋樓、蓋樓，最終的結果可能就是樓歪歪了。

事實上這個「蓋高樓」的觀點並沒錯，對企業發展來講，「時間就是生命」。但忽略了模塊思惟實際上是在浪費更多的時間。組件的價值在於可重複驗證的程序和可定勢識別的操做，不管對開發的工做量化仍是對用戶的使用體驗，都有較高的實施優點。

實際中也有不少優秀的方案能夠直接拿來用，對於啓動者來講，更該作的是找到匹配的方案，作好膠水層把多個體系、模塊、組件更順暢的組織起來。

3. 持續重構

軟件工程相對現實中機械、地產的工程，我以爲一個很大的優點就是能夠拿到實際環境裏檢驗的同時隨時調整結構。若是可能，讓不一樣人擁有不一樣的工具包，在保障整個系統的穩定性和每一個人特長髮揮的同時，持續的將其中優秀的工具、範例集成到公共庫。

4. 基礎樣例

想要新來的人入門快，最好的辦法就是能用最簡單的方式告訴他該怎麼作，拷貝一個隨便改改就能工做起來的範例是個好主意，不至於來了新人不但沒給團隊帶來力量提高還把事情搞得更糟。

---

太晚了（2015/3/7 0:02），眼睛睜不開了，先這樣吧。其實我想說的就是，你的代碼是你本身弄髒的，今天省了事了明天就攤上大事了，老老實實的寫UT，認真的把枝幹拾掇乾淨吧。最後貼上我最愛的《K.I.S.S》與諸君共勉：

KEEP IT SIMPLE, STUPID!

編寫只作一件事情，而且要作好的程序；編寫能夠在一塊兒工做的程序，編寫處理文本流的程序，由於這是通用的接口。這就是UNIX哲學。全部的哲學真正的濃縮爲一個鐵同樣的定律，高明的工程師的神聖的「KISS 原則」無處不在。大部分隱式的UNIX哲學不是這些前輩所說的，而是他們所作的和UNIX自身創建的例子。從總體上看，咱們可以抽象出下面這些觀點：

模塊原則：寫簡單的，經過乾淨的接口能夠被鏈接的部件。
清楚原則：清楚要比小聰明好。
合併原則：設計能被其它程序鏈接的程序。
分離原則：從機制分離從策略，從實現分離出接口。
簡單原則：設計要簡單；僅當你須要的時候才增長複雜性。
節儉原則：只有當被證明是清晰，其它什麼也不作的時候，才寫大的程序。
透明原則：爲使檢查和調試更容易而設計。
健壯原則：健壯性是透明和簡單的追隨者。
表現原則：把知識整理成資料，因而程序邏輯能變得易理解和精力充沛的。
意外原則：在接口設計中，老是作最小意外的事情。
沉默原則：一個程序使人吃驚什麼也不說的時候，他應該就是什麼也不說。
補救原則：當你必須失敗的時候，儘量快的吵鬧地失敗。
經濟原則：程序員的時間是寶貴的；優先機器時間節約它。
產生原則：避免手工堆砌；當你可能的時候，編寫能夠寫程序的程序。
優化原則：在雕琢以前先有原型；在你優化它以前，先讓他能夠運行。
差別原則：懷疑全部聲稱的「惟一真理」。
擴展原則：爲未來作設計，由於它可能比你認爲來的要快。

注：以上文字爲了整潔我有極小的不妨害理解原標準翻譯的改動。

獻醜了，晚安！