【51CTO.com快譯】在發(fā)現(xiàn)自己能夠?qū)⑴f的Python代碼庫移植至Node中時，我感到興奮莫名。相較于普通代碼維護工作，這類移植任務(wù)往往擁有更多創(chuàng)作自由與發(fā)揮空間，且在樂趣層面遠遠超過修改他人留下的代碼爛攤子。

然而在開始實際工作之后，這種興奮感迅速消失。雖然我已經(jīng)擁有15年的編程從業(yè)經(jīng)歷，但其中的遺留代碼仍然相當(dāng)恐怖，甚至可以說是我所見過的最糟糕的代碼庫之一。原作者構(gòu)建起自己的框架，且其模式與***一詞基本背道而馳：關(guān)注點未進行拆分、縮進時亂用空格/tab、同一概念擁有多個名稱、來自內(nèi)容幾乎相同的不同方法的同一數(shù)據(jù)多次覆蓋變量以及魔幻般不可解讀的字符串……這一切都證明，這套代碼庫絕對是之前某位碼農(nóng)通過復(fù)制谷歌查詢結(jié)果拼湊出來的成果。

[[181385]]

然而，這種徹底違背編程規(guī)范的狀態(tài)反而引發(fā)了我的興趣，并促使我寫下這篇文章。經(jīng)過幾個月的工作之后，我發(fā)現(xiàn)原作者實際是一位經(jīng)驗豐富的高級開發(fā)人員，且擁有出色的技能水平。那么到底是什么原因?qū)е逻@位主管人員編寫出如此垃圾的代碼？立足于此案例，我整理出一份原因清單。 其中條目為即使是經(jīng)驗豐富的團隊中也普遍存在的種種壞習(xí)慣，其會直接體現(xiàn)在最終產(chǎn)品當(dāng)中，且任何靜態(tài)代碼檢查工具或者開發(fā)方法都無法對其加以糾正。

1.對重要性太過高估

此項目中的一大缺陷在于過度關(guān)注截止期限，甚至以損害代碼質(zhì)量為代價。如果開發(fā)者過度關(guān)注項目本身的重要性與交付時間，而非編寫良好代碼，那么其最終結(jié)果絕對會令企業(yè)管理者更加頭痛。造成這種問題的根源有二，其一為過度估量、其二為過度承諾，而二者皆會增加開發(fā)者負(fù)擔(dān)。

[[181386]]

一般來講，過度估量的可能性相對較低，因為項目成本往往能夠說明一切。因此，開發(fā)者可能選擇過度承諾，而后因此思路思考架構(gòu)選擇或者任務(wù)自動化等重要議題，旨在滿足不切實際的項目周期要求。這些任務(wù)通常被視為附加價值，因此往往會被不假思索地砍掉。產(chǎn)品質(zhì)量則將隨著技術(shù)債務(wù)的積累而下降，因為項目后期代碼重組的成本將成倍提升。

舉例來說，我在此項目中發(fā)現(xiàn)一部分代碼明顯被到處復(fù)制，但看起來開發(fā)者同時又急于交付且根本沒時間理會此前是否已經(jīng)有人編寫過同樣的方法或者SQL查詢。

有時候評估本身還存在誤導(dǎo)性。就如，敏捷性原則中有“速度”這樣一項術(shù)語，其思路是計算團隊的交付速度，并作出必要調(diào)整以提升速度。問題在于，我們根本不可能立足中、短期給出準(zhǔn)確的速度評估結(jié)果。平均法則告訴我們，我們無法根據(jù)以往的表現(xiàn)來衡量自己未來能夠推進得多快，因為這樣的已知指標(biāo)并不足以指導(dǎo)未知。

平均法則：小樣本成員間的分布統(tǒng)計結(jié)果必須反映在總體成員的分布結(jié)果當(dāng)中。

事實上，一位開發(fā)者可能在一天之內(nèi)編寫大量代碼，也可能在與同事配合的情況下一天只寫出三、五行代碼——其余時間則用于編寫說明文檔及相互溝通。

平均值并不能代表中、短期內(nèi)的有價值信息凈值。其對于項目而言不具備參考價值。

2.不重視項目相關(guān)知識

隨著項目的推進，團隊對于業(yè)務(wù)、其深層概念以及各元素間的聯(lián)系方式亦更為了解。與此同時，各成員亦更為明確如何編寫代碼，這種循序漸進式的認(rèn)知與問題解決途徑是種必然。某些業(yè)務(wù)領(lǐng)域甚至存在著固有復(fù)雜性，要求開發(fā)團隊拿出大量時間進行消化。

這一點在對舊的代碼進行完整重寫方面體現(xiàn)得尤為突出，也反映出您的團隊是否了解項目相關(guān)知識。 如果您身處某個大型項目內(nèi)且其中包含無人了解且無人可以解答的功能模塊，那么結(jié)果無疑相當(dāng)危險。重寫代碼的價值完全取決于您業(yè)已掌握的專業(yè)知識，因此知識就是力量所言非虛。

[[181387]]

如果大家指派另一支隊伍進行重寫，正如我所遇到的情況，則意味著您忽略了原有學(xué)習(xí)及積累成果，而單純依靠新團隊的自有技能水平。 如果由同一位程序員對自己編寫的原有代碼進行重寫，那么即使其水平平庸亦可帶來更出色的效果及完成速度。在這一點上，利用全新團隊接手絕非良策。

甚至人員招聘工作也與項目知識密切相關(guān)。項目負(fù)責(zé)人掌握的信息越多，其加快項目推進速度的經(jīng)驗就越豐富，因此除了知識本身的價值之外，這還有助于其招納更為出色的參與人才。如果大家的人員選擇決策不力，那么糟糕的團隊很可能耗時數(shù)個月卻一無所獲。

3.關(guān)注錯誤的指標(biāo)取向，例如“已解決問題”或“每天提交數(shù)量”

古德哈特法則：當(dāng)衡量變成目標(biāo)，其就不再是良好的衡量方式。

在嘗試進行項目提速時，有人問我既然快速交付非常重要，為什么其他開發(fā)者能夠比我更快進行代碼提交。然而可以想象，我馬上就從他的一行代碼中找到了四處bug。 專注于代碼提交數(shù)量這種不可靠的指標(biāo)會徹底毀掉整個項目，并使得成員面臨更為巨大的開發(fā)周期壓力。

[[181388]]

人們普遍忽略了問題回歸率這個問題。像空指針異常這類錯誤往往會在缺少回歸率追蹤的情況下反復(fù)出現(xiàn)，并導(dǎo)致整個項目“四處漏風(fēng)”。在這種情況下，由于著眼點有誤，大家將永遠找不到問題的根源。

***，真正重要的是我們將怎樣的成果交付給客戶、對方對產(chǎn)品的滿意程度以及成果為其帶來的業(yè)務(wù)價值，但這要求我們投入大量精力以確保成果質(zhì)量，而非提交速度或者已解決問題量這類無用的指標(biāo)。

理想的指標(biāo)差別方式之一在于了解成員個人的價值觀。注重細(xì)節(jié)、具備良好的溝通技巧與端正的處理態(tài)度非常重要，特別是考慮到如今有很多開發(fā)者不惜以欺詐的方式求得所謂效率提升。

4.假設(shè)良好的流程能夠彌補個人錯誤

良好的流程雖然***價值，但其實際效果卻往往受到高估。根據(jù)我的個人經(jīng)驗，相當(dāng)一部分企業(yè)在人才招聘方面處理不當(dāng)，這迫使其不得不采用越來越嚴(yán)苛的執(zhí)行流程以降低個人錯誤的可能性，而這反過來又限制了團隊的自由創(chuàng)造能力。不僅如此，即使擁有良好的流程，個人因素仍然在其中扮演著重要角色。

這方面追求應(yīng)當(dāng)始終得到保持，而良好的招聘機制則能夠在很大程度解決問題。卓越的人才能夠彌補團隊中其它形式的效率低下問題。總體而言，聰明地工作比勤奮地工作更加重要。

開發(fā)者往往缺乏良好的溝通能力。在這類復(fù)雜的代碼庫中，我需要不斷向他人尋求幫助，但同事們往往沒時間及時伸出援手。他們有時候態(tài)度惡劣，而且在提出的問題較為復(fù)雜時，幾乎沒有同事具備將其解決的知識與耐心。

[[181389]]

我們需要擁有出色知識儲備及良好心態(tài)的人員，他們會在進程緩慢時及時發(fā)出提醒。 每一款構(gòu)建工具、每一種靜態(tài)檢查工具乃至每一類通訊工具都存在優(yōu)勢與弊端，大家需要結(jié)合各方面意見，而非盲目引入看起來不錯的選項。

5.忽略代碼審查與單元測試等***實踐

在現(xiàn)代軟件開發(fā)流程當(dāng)中，保持時間進度已經(jīng)不足以確保項目處于推進正軌之中，但這至少能夠讓我們的團隊保持競爭力。著眼于***實踐指導(dǎo)，測試驅(qū)動型開發(fā)方法能夠?qū)⑷毕萋式档?0%至90%，而開發(fā)時間則僅增加15%到35%代碼審查亦可有效降低缺陷率，有時甚至能夠較手動測試提升80%的錯誤發(fā)現(xiàn)比例。

想象一下，在與同事協(xié)作時，我只能被迫使用遺留項目加記事本這種上個世紀(jì)的處理辦法。因此，使用現(xiàn)代IDE、版本控制以及代碼檢查等功能將有效提升工作效率。 這些并不是什么高新科技，而且必須被應(yīng)用于各類規(guī)模的項目當(dāng)中。

6.雇用那些完全沒有“人際”技能的開發(fā)者

這并不是說開發(fā)者就無法與他人交流。我自己也曾經(jīng)相當(dāng)害羞內(nèi)向，但通過強迫性訓(xùn)練，如今我已經(jīng)能夠較為順暢地完成溝通甚至演講。

問題在于，當(dāng)人們壓根不想嘗試溝通或者為此而煩躁時，結(jié)果必然極為糟糕。身為開發(fā)者，我們必須刻意培養(yǎng)自己的交流能力，甚至將其視為位于開發(fā)技能的重要事務(wù)。只有這樣，大家才能在工作環(huán)境中獲得更為熱情且清晰的意見交換結(jié)果。 交流對象身在何處并不重要。一通Skype語音即可將復(fù)雜的編碼難題轉(zhuǎn)變?yōu)楹唵蔚奈宸昼娦栴}。

總結(jié)

在配合***工具、成熟的技能以及卓越的溝通能力之后，軟件開發(fā)工作將變得順暢而輕松。 我們不能僅僅因為引入了敏捷性或者其它工具而指望問題瞬間消失，畢竟其僅僅是輔助手段而非包治百病的大力丸。 只要設(shè)置得當(dāng)，它們將建立起協(xié)同作用并使團隊的執(zhí)行效率成倍提升; 然而，如果決策草率及粗暴忽略各種細(xì)節(jié)，那么項目仍將陷入恐怖的泥潭。

原文鏈接：https://www.linkedin.com/pulse/how-terrible-code-gets-written-perfectly-sane-people-christian

原文標(biāo)題：How terrible code gets written by perfectly sane people

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】