當在將老的 Python 代碼庫移到 Node 的時候，我內心是有點小激動的。這些項目相對于常規的代碼維護工作總會給你更多的創造性的自由。重新編寫其他人的代碼帶來的挑戰使得這一切變得非常開心。
但這種興奮之情在我看了一眼我們即將要做的事情的時候很快就消失了。舊代碼真的是很惡心，我已經編程 15 年了也就只見過幾次這樣的情況。原作者創建了他們自己的框架結構，而且可以稱得上是一個反模式的劫難：沒有關注點的劃分，混合空格/制表符縮進，同一個概念有多個名字，變量被來自不同的但是幾乎有相同的方法下的同一個數據過多的重寫，字符串。。。這一爛攤子就好像是呀呀學語的猴子從 Google 隨意復制代碼的成果。
但是，刺激我寫下這篇文章還不只是因為代碼本身糟糕的質量，而是在經過幾個月工作下來，我驚奇地發現原作者實際上是一群擁有很高技術水平的資深工程師。是什么導致一群有能力的開發者產出并交付這樣一堆垃圾呢？我能想到的原因有很多。這些是我認為連資深的團隊都可能會沾染的壞習慣，這些壞習慣會嚴重地影響你的終端產品，甚至連源碼檢查或者開發方法論都無法拯救。
過于強調預算
這個項目的一個重要問題就是過多的關注截止期限，這對代碼質量帶來了很大的傷害。如果開發者們被迫關注交付而非編寫一個好的代碼本身，他們最終不得不為讓老板開心而買單。原因有兩種，一是估計過高，二是承諾過多，不管怎樣，最終都會帶來更多的包袱。
通常來說，由于效果很快會在項目的成本上體現，因此您的開發人員可能會選擇過度承諾，然后跳過重要的工作，如考慮架構的問題，或者如何使任務自動化，從而達到一個不現實的截止期限。這些任務通常是被視為附加值，所以它們會在沒有通知的情況下直接削減。積累的技術債務越多，產品的質量也就隨之下降，甚至會比以前設想的更多，因為在一個項目上后期重編代碼的代價會成倍增加。
舉一個例子，在這個項目上，我會發現一些代碼明顯在其他地方已被寫過，但是好像當時急于交付，一些開發者也就懶得檢查是否有其他人在此之前已經寫了相同的方法或者SQL查詢。
有些時候，預算可能是假的。例如，Agile有一個術語叫“速度”，這個概念是為了計算你的團隊交付有多快，然后做一些必要的調整來提速。問題是在短期到中期里是不太可能算出一個精準的速度的。平均法則強度，你不能憑借過去的業績來測量你現在的速度，因為過去的業績并不是一個好的未來結果的指示器。
（注：平均法則是一個外行術語，認為一部分小樣的數據分布的結果肯定會反映整個數據分布的結果）
事實上，一個開發者可以一天可以編寫很多的代碼，也可以在讀完文檔并在考慮和同事們如何合作后，三天只寫五行代碼。平均預算并不會在短期和中期得到有價值的反饋。
不重視項目知識
隨著您的項目的推進，您的團隊會學習業務，業務背后的概念以及它們是如何聯系在一起的。他們還會在編寫代碼時研究實現方式，因為您無法完全了解業務的演變以及將會面臨的挑戰。一些業務領域甚至本身就很復雜，需要很長時間才能消化。
由于這是對舊代碼的全面重寫，在這方面特別有趣，因為它可以顯示您的團隊的管理層是否了解項目知識以及它對開發的影響。如果你在一個大型項目中，沒有專家，沒有人過問項目知識，這是一個很大的危險信號。重寫代碼的價值完全在于利用你第一次學到的項目知識，所以項目知識很珍貴。
如果你把不同的團隊放在一起做重寫，就像我的情況一樣，你忽略了所有的項目知識學習，只依靠你的新隊員的技能，這可能不會彌補缺乏的信息。比起把工作完全交給別人，一個普通的開發人員能更好地重寫他自己寫的內容，他會做的更快。
即使招聘也受到項目知識的影響。項目的信息越多，人們成長需要的時間就越長，所以不僅僅知識很重要，還要注重招聘好的人才。如果招的不好，你會忙于應付一個糟糕的團隊，幾個月內什么事也做不成。
重點關注諸如 “關閉的問題” 或 “每天的提交” 等不好的指標
當一個政策變成目標，它將不再是一個好的政策。 – 古德哈特定律（Goodhart’s law）
一些時候當我開始著手于推進項目的進度，一些人會問我為什么另一些開發者關閉問題的速度遠遠快于我，似乎解決得越快是一件好事。你可以想象到，當我去瞥一眼他寫的代碼，在一行里面發現了 4 個 bug。關注于像這樣不可靠的指標完全是與項目脫軌的，會引起人們類似于項目截止期即將到來般的壓力。
似乎很少人關注的一個指標是問題的重現率。一些 bug，例如空指針異常, 可能會在后期重復的出現，如果你并沒有跟蹤它的復現，那看起來就像 bug 會無處不在地不斷涌現。在這種情況下，你將永遠無法找到問題的源頭，因為你的關注點錯了。
最終真正重要的是交付給客戶的東西，他們拿到產品時的愉悅，以及它如何影響他們的底線，但是它需要大量的自我管理，專注于提高交付的質量和對無意義指標的忽略，如提交率或關閉的問題。
了解一個指標有意義與否的一個好的方法是試著去理解其所體現的個人價值。關注那些可以給出好的建議、體現溝通技能和良好態度，尤其是需要巨大的付出才能作弊的指標。
假想好的流程能彌補人員素質的不足
良好的流程常在商業上被認為是靈丹妙藥。以我在一些公司里的經驗來說，尤其在那些使用了差勁的招聘方法的大公司，最終使得他們的操作流程越來越嚴苛，這反過來限制了團隊參與人自由的發揮創造性。話雖如此，但是仍然需要人們首先按照正常的流程工作。
這永遠不會結束，除非通過改進招聘方法來彌補該問題。人才可以彌補你的團隊在效率上的不足，這是使工作化艱巨為高效的整個關鍵點。
開發人員之間可能特別難以溝通。在使用一個復雜的代碼庫時，我不得不從他人那里尋求幫助，也不見得每一次他人都能愉快的抽出時間給予援手。無法回饋一個良好的態度，而且在艱難的任務面前如果你需要尋求幫助，卻只能指望那有限的幾個有能力且愿意幫你一把的隊友，此時你會倍感壓力。
你需要的隊友應該具備足夠的開發常識且樂于助人，如果你的流程對他們產生了影響，會向你反饋。每個構建工具，每個靜態檢查器和溝通工具有好或壞的用例，你需要人們告訴你這件事，不要盲目地在不同的環境下應用這些僅僅是幾個月前看起來好的東西。
忽略已經被驗證的實踐，比如代碼評審和單元測試
保持最新的現代軟件開發過程可能不足以使脫軌的項目回到其軌道上，但如果你希望團隊保持競爭力，那肯定是必要的。這是經驗證過的實踐的介入點，這里是其中一些。測試驅動的開發已經被證實可將缺陷率降低 40％ 至 90％，開發時間增加約在 15％-35％ 的范圍內。代碼評審也被證明可以降低缺陷率，在某些情況下比手動測試高出 80％。
想象一下，當我不得不與那位遺留下來的項目的同事合作時，我沮喪的樣子。他的屏幕上用記事本顯示了所有代碼。使用 “搜索” 來查找方法可能已經在九十年代被忽略了，但是這些天，避免使用諸如現代 IDE，版本控制和代碼檢查等工具，將使你極大地重視它。它們現在對任何規模的項目都是絕對需要的。
為了深入了解在軟件開發中有哪些工作，請查看 Making Software: What Really Works, and Why We Believe It （軟件制造：真正的工作原理是什么以及我們為什么信任它）。它有一個很好的關于有價值和成熟的實踐列表，并且已經被研究證實多年了。
雇用沒有人際溝通技巧的開發者
這不是說開發人員不能和其他人交談。我曾經是一個害羞的開發者，最終成功地站在觀眾面前，很好地說話。
當有人不愿意嘗試，或者因為提高溝通的要求而感到煩惱時，問題就會出現。 如果有一件事可以比我所提到更多地加快開發時間，那就是正在改善溝通技巧。 特別是在你為了降低距離感以及從事與信息相關工作時，你可以在工作場所實現更加熱切和清晰的連接。 另一個人可能在萬里之外并沒有什么問題。一個Skype通話可以將長的編碼馬拉松變成一個五分鐘的解決方案。
結語
當你通過使用最好的工具、成熟的技術和良好的溝通來實現和鼓勵聰明的工作方式，軟件開發肯定會推動得更加自然。 你不能假定的是：因為你已經篤定了應用敏捷開發工具或其他工具，其他事情都不重要了，事情能夠自動排序。 這里有一個協同效應，如果設置正確，這可以使一個團隊按照指數級得變得更有成效，并且在不關注這些細節的情況下會非常緩慢和混亂。
