建站
咨詢
售后
建站咨詢
新聞中心
本文作者系程序猿Daniel F Pupius，這是一篇他發(fā)表在Medium上的博文，講述自己怎么在實際寫代碼的過程中，發(fā)現在效率和質量間做出抉擇其實是個偽命題。
在高青等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供網站設計、成都網站建設 網站設計制作按需制作網站,公司網站建設,企業(yè)網站建設,品牌網站制作,成都全網營銷,外貿營銷網站建設,高青網站建設費用合理。
程序開發(fā)項目進行過程中，通常會冒出這樣的困惑：應該選擇效率，還是選擇質量？很多程序猿都會有偷懶的思維，覺得把一些摸不清頭緒、不知道怎么寫的代碼片段去掉，可以節(jié)省很多時間，更早完成項目計劃。
其實過去幾年中，我也是這么想的，但最近我開始意識到，這個問題的糾結之處不在于選擇困難，而在于問題本身是個偽命題。
什么是“質量”呢？一般程序員說到“質量”二字時，他們說的有可能是測試通過率、變量命名、代碼格式化、組件化、查找bug、程序測試等等。也有可能是程?序的可拓展性、服務延時、產品功能的完整程度。
問題往往就產生于以上兩者被統(tǒng)一看待、不做區(qū)分的時候。其實前一種圍繞代碼的問題可以看成“代碼質量”問題，第二種情況則可以看成“執(zhí)行質量”，或者“執(zhí)行程度”。
從“代碼質量”上來看，程序猿走捷徑的偷懶思維，其實是種十分短視的做法。含糊繞過某個問題，你可能會一時覺得省事不少，但到頭來，往往發(fā)現因此攪亂了系統(tǒng)而要花費更多的時間來一行行檢查代碼，找出bug，甚至重新調整整體邏輯框架。所以犧牲代碼質量換取速度通常是得不償失的做法。
相反地，高質量的代碼其實是可以幫助你節(jié)省時間的。統(tǒng)一的代碼規(guī)范和變量命名，不僅可以幫到別的程序猿，還可以幫到未來的你，更好地理解你現在寫下的代碼；經過嚴密思考而設計出的輕量級代碼架構，則可以讓你在迭代產品的時候獲得更高的效率，更清晰地了解該從何處入手，而不是到數據庫里漫天尋找需要替代的地方；而高測試通過率還可以給你充足的自信去調整產品，減少bug數量，最小化QA時間。
至于“執(zhí)行質量”，這又是另一個命題。有很多方式可以在不降低產品質量的情況下，使得產品開發(fā)過程很緊湊。比如你可以先推遲一些不那么著急的工作，等到整體執(zhí)行優(yōu)化、系統(tǒng)穩(wěn)健性做好的時候，再來做那些被暫時擱置的事情。
具體的做法就是，先把最終想要的產品效果定好，然后往其中填充內容不斷修改，至于一些無關的細節(jié)可以最后再來優(yōu)化。舉例來說，剛開始開發(fā)產品時，可以用RPC來簡化應用開發(fā)的流程，繞過復雜的協(xié)議傳輸問題，先在產品應用層面上快速迭代，隨后再替換掉RPC，加入重試、錯誤控制、安全檢驗等代碼，或者干脆替換掉傳輸協(xié)議。
寫Medium代碼的時候，我們就是先實現效果，再調整細化部分的，最后刪掉了很多無法整合進原先設定好的框架中的功能，大約是六萬行代碼左右。
所以如果我們起初沒有小心處理代碼質量的問題，最終一定會被查找各種很細微的問題困擾。如果我們沒有完全聚焦在效果實現上，就一定會拖拖拉拉延后項目進度。但如你所見，很幸運我們前期工作做得充分，所以現在產品可以迭代得很快，并不斷試驗新功能。
其實在互聯網領域中，不僅程序猿會面臨上述問題，很多產品經理也會為項目進度和質量打架的問題煩擾。所以Daniel的博文提供了一個很好的思考角度，或許下一次再有人問你是不是可以犧牲一點代碼質量來追趕進度的時候，你就可以告訴他們：你問的是個偽命題。
原文鏈接：http://www.html5cn.org/article-5203-1.html
文章名稱：程序員:選擇效率,還是選擇質量？
當前網址：http://m.jiaoqi3.com/article/dpjsshe.html
