開發者最常踩到的低效陷阱

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

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

過度開發

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

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

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

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

一次又一次的編寫同樣腳本

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

代碼冗餘

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

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

重複流程

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

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

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

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

從0搭建系統

如果一個開發者每次搭建一個Web服務都需要寫JDBC數據庫鏈接的定製化代碼,它將永遠沒法完成項目的開發。

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

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

你還可以查看公司的代碼倉庫,如果有些功能和你需要實現的類型,你完全可以調研一下是否通過一個方法調用就可以拿到你想要的數據,

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

糟糕的測試用例

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

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

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

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

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

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

不正確的代碼優化

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

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

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

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

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

6無效溝通

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

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

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

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

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

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


總結

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章