貓頭鷹的深夜翻譯:開發者最常踩到的六個低效陷阱

raledong發表於2021-10-11

高效的時間管理是大部分成功的軟體工程師具備的能力。它能夠幫助你在職業生涯上快速進步,而不是每個敏捷迭代末瘋狂加班。

每個企業都試圖通過自動化流水線,升級版IDE和DevOps來降低成本提高效能。而通過避免以下六種低效陷阱可以讓你的領先一步,收穫高效的一天。

1. 過度開發

你是否曾經將需求複雜化,考慮哪些奇奇怪怪的可能會出現的場景。比如設計的這個API是否可以無縫的接入其它平臺?或者控制皮膚是否能夠自動傳送報告?

控制住這些想法,不要過度設計!你不應該話大量時間在一些過於超前的功能上。而且,程式碼越多意味著更多的bug和不必要的指令碼將會加到本已臃腫的程式中,從而導致程式碼可讀性擴充套件性的降低。

要想避免這一點,要經常反問自己這段程式碼是否在解決當前的需求。你只需要考慮用例和邊界場景,不要花大量的時間在一個短期內不會用到的功能上。

如果你不確定是否要新增一個功能用於解決一個潛在的極端場景,在下一次的敏捷會議上提出來並和大家討論。這能幫助你節省大量時間,並且促進團隊合作精神。

2. 一次又一次的編寫同樣指令碼

作為一個工程師,你應當儘可能的遵循不要重複開發原則(DRY-Don't Repeat Yourself)來提效。 有兩種方法可以貫徹這一原則:減少冗餘程式碼或是流水線開發流程。

程式碼冗餘

搭建一個服務或者是虛擬環境往往意味著需要寫同樣的指令碼並且反覆執行。如果你需要搭建一個包含四層的分層架構服務,並且適配到開發,測試,預發和生產環境上,它們所需要的程式碼和執行的步驟基本是相似的。除此以外,基礎服務的依賴正在變得日益複雜。上述的工作不僅重複而乏味,人工執行還可能會導致誤操作帶來故障。

低程式碼平臺提供了開箱即用的工具,包括可複用的元件和圖形化的介面拖拽生成器。當然,你不能為每個場景找到完美適配的方案,但是它可以完成最基礎的重複的工作。自動化流水線可以幫助你構建,複製和部署程式碼到很多的環境上。

重複流程

詳細的列出開發過程中的所有步驟並且思考你是否可以去掉其中幾步,將它們自動化吧。

除此以外,額外關注執行超過兩次以上的步驟。如果可以在需要做這些任務時通過一鍵觸發自動化流程完成,你將極大提高效率。

在開始自動化之前,你還需要評估一下自動化的價效比。建議問一下自己:自動化真的比手動操作更節省時間嗎?我是否在後面幾周頻繁的做這個操作?

如果答案是肯定的,開始寫自動化指令碼吧。它能極大減少浪費時間(和頭痛)。

從0搭建系統

如果一個開發者每次搭建一個Web服務都需要寫JDBC資料庫連結的定製化程式碼,它將永遠沒法完成專案的開發。

開發可維護的並且安全的軟體是我們的最高優先順序。但是,這並不意味著要從0搭建系統。我們不需要重複造輪子,並且開發一些已經有現成實現的功能。

公司需要的是高效的工作,而從0搭建系統所花費的時間在大多數情況下都是不必要的。所以使用現成的二方包或框架並對其做一些定製化的處理來滿足客戶的需求。

你還可以檢視公司的程式碼倉庫,如果有些功能和你需要實現的型別,你完全可以調研一下是否通過一個方法呼叫就可以拿到你想要的資料,

然而,在處理一些敏感資料如金融或健康類的資料時,從0搭建功能來保證安全性就很有必要了(畢竟你不知道引入的框架是否存在安全問題)。但是,在大多數場景下,執行緒框架、開源庫或是付費外掛完全夠用了。

糟糕的測試用例

在自動化和手動測試之間技術選型時,必須注意一個微妙的平衡。因此,讓我們瞭解如何使用它來制定有效的測試策略。

編寫一個小的手動測試來確保您新增的新功能正常工作很容易。但是當你擴充套件時,執行這些手動測試需要更多的時間,尤其是當你試圖找到那個不斷破壞你的程式碼的討厭的錯誤時。

如果你的應用程式或網站有許多元件,那麼正確地執行特定測試的可能性也會增加。自動化測試甚至更有效地執行測試的系統有助於避免這種情況。

你可能需要花些許時間來設定自動化測試。但是,一旦它們被編寫好,無論進行任何程式碼更改,它們就可以被重用和觸發。因此,你不必因為新增了新功能而手動重新測試以前的功能。

相反,選擇正確的任務進行自動化同樣重要。不幸的是,這是QA自動化測試中最常見的錯誤之一。很容易陷入過度自動化的陷阱並最終逐個指令碼地複製測試。這是一個重大的時間浪費,因為弄清楚為什麼這些複雜的自動化失效了仍然是一項人工操作-——這正是你想要避免的事情。

不要讓它變得比它預期的更復雜。相反,應專注於簡單的測試用例,而忽略具有許多依賴項的低頻的或複雜的任務。在開始編寫任何單元測試用例之前優化和計劃你的測試策略,將幫助節省大量時間。

5. 不正確的程式碼優化

這是一種相當常見的時間浪費,通常很難從一開始就發現。你花費大量時間為低優先順序甚至可能不需要的用例優化程式碼。

你唯一的關注點應該是讓功能正常執行,然後再考慮優化。但是,不要設定不切實際的優化目標。優化決策通常是不同場景定製的。

如果效能優化只需要幾分鐘,那就去做吧。但是,在大多數業務場景中,皮毛級的優化通常對專案來說並不重要。進行優化是好事嗎?是的。但是,如果您需要花費數小時才能獲得1%的效能提升,最好先與使用方進行討論。

舉個例子,假設您正在為內部團隊開發網頁。如果網站在1秒內成功載入,你實際上不需要優化到在0.5秒內載入該網站,因為這不會顯著改善業務運營。然而,如果它是一個電子商務商店,讓它在一秒內而不是兩秒內載入將是一個強烈的訴求。

解決這種時間浪費的最佳方法是定期從使用者那裡獲得反饋。根據他們的具體用例進行優化,而不是構建自己的用例。

6. 無效溝通

無效的溝通是軟體開發中時間浪費的直接原因,有時是間接原因。

軟體開發包含許多步驟——各個團隊成員致力於不同的產品功能,然後交到QA團隊進行測試,最後成為使用者的產品。

溝通至關重要,尤其是在開發和測試階段。假設開發人員誤解了需求的商業用途。產生的誤差會使解決方案過於複雜,從而導致技術方案錯誤並增加異常或返工的機會。

由於溝通是軟體開發中最人為介入的方面,因此無法完全消除這種時間浪費。然而,有了適當的專案管理工具和協作環境,它完全可以降低。

在個人層面上,在開會或開發功能時,始終考慮大局。學會傾聽和有效協作。養成將會議討論的內容寫下來或傳送摘要的習慣,以對齊雙方的期望。

除此以外,儘早溝通。不要猜測需求,並在可能的情況下,在正式投入整個專案之前做一個demo演示。

總結

本文關鍵是養成避免這些浪費時間行為的習慣。短期生產力“提示和技巧”只能帶您到此為止。但是良好的編碼實踐和自我意識將幫助您提高效率。注意你的時間花在什麼地方,試著減少它,你就可以成為一名成功的軟體工程師了!

相關文章