高級(jí)開發(fā)人員，為何會(huì)寫出恐怖至極的代碼！

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

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

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

1.對(duì)重要性太過高估

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

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

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

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

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

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

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

2.不重視項(xiàng)目相關(guān)知識(shí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.忽略代碼審查與單元測(cè)試等實(shí)踐

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

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

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

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

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

總結(jié)

在配合工具、成熟的技能以及卓越的溝通能力之后，軟件開發(fā)工作將變得順暢而輕松。 我們不能僅僅因?yàn)橐肓嗣艚菪曰蛘咂渌ぞ叨竿麊栴}瞬間消失，畢竟其僅僅是輔助手段而非包治百病的大力丸。 只要設(shè)置得當(dāng)，它們將建立起協(xié)同作用并使團(tuán)隊(duì)的執(zhí)行效率成倍提升; 然而，如果決策草率及粗暴忽略各種細(xì)節(jié)，那么項(xiàng)目仍將陷入恐怖的泥潭。

分享標(biāo)題：高級(jí)開發(fā)人員，為何會(huì)寫出恐怖至極的代碼！
網(wǎng)址分享：http://www.bm7419.com/news/183930.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、自適應(yīng)網(wǎng)站、網(wǎng)站收錄、靜態(tài)網(wǎng)站、服務(wù)器托管、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)