好文翻譯 碼農們 效率與質量,你選擇哪個?

2022-02-26 17:12:01 字數 1374 閱讀 6588

本文作者系程式猿daniel f pupius,這是一篇他發表在medium上的博文,講述自己怎麼在實際寫**的過程中,發現在效率和質量間做出抉擇其實是個偽命題。

程式開發專案進行過程中,通常會冒出這樣的困惑:應該選擇效率,還是選擇質量?很多程式猿都會有偷懶的思維,覺得把一些摸不清頭緒、不知道怎麼寫的**片段去掉,可以節省很多時間,更早完成專案計畫。

其實過去幾年中,我也是這麼想的,但最近我開始意識到,這個問題的糾結之處不在於選擇困難,而在於問題本身是個偽命題。

什麼是「質量」呢?一般程式設計師說到「質量」二字時,他們說的有可能是測試通過率、變數命名、**格式化、元件化、查詢bug、程式測試等等。也有可能是程式的可拓展性、服務延時、產品功能的完整程度。

問題往往就產生於以上兩者被統一看待、不做區分的時候。其實前一種圍繞**的問題可以看成「**質量」問題,第二種情況則可以看成「執行質量」,或者「執行程度」。

從「**質量」上來看,程式猿走捷徑的偷懶思維,其實是種十分短視的做法。含糊繞過某個問題,你可能會一時覺得省事不少,但到頭來,往往發現因此攪亂了系統而要花費更多的時間來一行行檢查**,找出bug,甚至重新調整整體邏輯框架。所以犧牲**質量換取速度通常是得不償失的做法。

相反地,高質量的**其實是可以幫助你節省時間的。統一的**規範和變數命名,不僅可以幫到別的程式猿,還可以幫到未來的你,更好地理解你現在寫下的**;經過嚴密思考而設計出的輕量級**架構,則可以讓你在迭代產品的時候獲得更高的效率,更清晰地了解該從何處入手,而不是到資料庫裡漫天尋找需要替代的地方;而高測試通過率還可以給你充足的自信去調整產品,減少bug數量,最小化qa時間。

至於「執行質量」,這又是另乙個命題。有很多方式可以在不降低產品質量的情況下,使得產品開發過程很緊湊。比如你可以先推遲一些不那麼著急的工作,等到整體執行優化、系統穩健性做好的時候,再來做那些被暫時擱置的事情。

具體的做法就是,先把最終想要的產品效果定好,然後往其中填充內容不斷修改,至於一些無關的細節可以最後再來優化。舉例來說,剛開始開發產品時,可以用rpc來簡化應用開發的流程,繞過複雜的協議傳輸問題,先在產品應用層面上快速迭代,隨後再替換掉rpc,加入重試、錯誤控制、安全檢驗等**,或者乾脆替換掉傳輸協議。

寫medium**的時候,我們就是先實現效果,再調整細化部分的,最後刪掉了很多無法整合進原先設定好的框架中的功能,大約是六萬行**左右。

所以如果我們起初沒有小心處理**質量的問題,最終一定會被查詢各種很細微的問題困擾。如果我們沒有完全聚焦在效果實現上,就一定會拖拖拉拉延後專案進度。但如你所見,很幸運我們前期工作做得充分,所以現在產品可以迭代得很快,並不斷試驗新功能。

其實在網際網路領域中,不僅程式猿會面臨上述問題,很多產品經理也會為專案進度和質量打架的問題煩擾。所以daniel的博文提供了乙個很好的思考角度,或許下一次再有人問你是不是可以犧牲一點**質量來追趕進度的時候,你就可以告訴他們:你問的是個偽命題。

關於翻譯的兩篇好文章

西文自有宗師妙 漢譯難觀對屬能 誰實為之?尤其是繆哲的 誰實為之?道出了眼下譯者的苦衷,抄一段在這裡吧 當然譯書者,沒有為發財的,名也不敢想。指揮家 譯 曲譜,可上唱片的封面 這曲子是卡拉揚的,那曲子是阿巴斯的。作曲家的名字,反成了陪襯。若論 再創造 譯書是甚於譯曲的,但你的 連勒口也上不了。你那名...

多語言機器翻譯 2 編解碼器結構

在 然語 處理的很多應用中,輸 和輸出都可以是不定長序列。以機器翻譯為例,輸 可以是 段不定長的英語文字序列,輸出可以是一段不定長的法語文字序列,例如 英語輸入 they are watching 法語輸出 ils regardent 輸入和輸出都是不定長序列時,我們可以使用編碼器 解碼器 enco...