寫代碼過程中最忌諱的是什麼？切記莫要太過於急於求成
根據自己幾年的血淚教訓，總結了6條寫代碼過程中最忌諱的問題，相信絕大多數剛接觸編程的同學都會犯同樣的問題！
1.添加太多特性
有多少次你通過考慮所有的」可能性「而使一個故事需求過度複雜化？
如果你正在開發的API可以被設計成與其他平台無縫集成呢？如果你的儀錶板可以發送自動報告呢？
抵制這種行為，不要過度設計它。
你不應該在未來太過超前的功能上花費大量的時間。而且，更多的代碼意味著更多的bug和不必要的腳本會增加應用程式的臃腫。
理解你的代碼和添加新的特性也會更加複雜。
為了避免這種情況，要不斷問自己，你的代碼是否解決了具體的需求。
確保你想清楚用例和邊緣案例，但不要在一個你可以更快上線的功能上花費數周時間。
如果你對添加一個有可能解決極端用例的功能感到困惑，在下一次版本疊代上提出來。
你將會節省大量的時間，並且你將會建立起你自己作為一個團隊成員的形象。
2.重複寫同樣的腳本
作為一名軟體工程師，你應該遵循DRY（Don't Repeat Yourself）原則來提高工作效率。
這可以通過兩種方式實現：消除代碼中的冗餘，或簡化開發流程。
讓我們看看如何解決這兩種情況。
代碼中的冗餘
設置一個伺服器，甚至一個虛擬環境，需要多次編寫相同的腳本和動作。
你要用幾乎相同的步驟和代碼建立你的3層開發架構，包括開發、測試、生產。
除此之外，管理基礎設施的依賴性也變得越來越複雜。
這不僅是重複和枯燥的，而且手動操作也讓你容易出現人為錯誤。
低代碼平台通過可重用的基於抽象的組件和可視化的拖放介面，開箱即有這種功能。
當然，你不會為每個場景找到一鍵式解決方案，但你會有最基本、可重複的解決方案。自動管道將幫助你為你需要的許多環境構建、複製和擴展代碼。
流程中的冗餘
清楚地勾勒出你在開發過程中的步驟數量，並思考如何減少這些步驟。
在這裡，自動化能夠提供有效幫助。
另外，留意那些你最終執行了兩次以上的過程。制定一個自動化序列，每次你想做這個任務的時候都可以觸發，你會從中受益。
不過，在你進行自動化之前，一定要注意時間上的權衡。
在實現自動化之前要問自己一些問題」如果我把它自動化，會比我做這個任務節省更多時間嗎？在接下來的幾周內，我是否會定期做這件事？「
如果答案是肯定的，就把它自動化。
3.從零開始建立系統
如果一個開發者每次建立網絡應用時都要對JDBC資料庫連接進行自定義編碼，那麼完成一個項目就需要很長時間。
開發可維護和安全的軟體應該是你的首要任務。
然而，這並不意味著從頭開始構建系統。
你不需要重新從零開始造輪子、重建已經存在的功能。
公司想要高效的工作，而你花在從頭開始構建系統上的時間，在大多數情況下是多餘的。
因此，取而代之的是，通過使用成熟的框架，根據客戶的需求進行定製。
另外，檢查公司代碼庫。如果該工具現有的功能與分配給你的功能重疊，最好檢查一下函數調用是否可以提供你所需要的數據，或者是否可以整合。
然而，當處理機密數據如財務，或健康記錄時，從頭開始建立功能以加強安全是有意義的。但在大多數情況下，框架、知名的開源庫可以完美地完成工作。
4.糟糕的測試策略
在選擇自動化和人工測試時，你必須注意一個微妙的平衡。
因此，讓我們了解一下，作為一個軟體工程師，你如何利用這一點來制定一個有效的測試策略。
寫一個小的手動測試來確保你添加的新功能工作正常是很容易的。
但是，當你擴大規模時，運行這些手動測試需要更多的時間，特別是當你試圖找到那個討厭的bug，不斷破壞你的代碼。
你需要花更多的時間來設置你的自動化測試。不過，一旦它們被寫好，它們就可以被重複使用。因此，你不必因為增加了一個新的功能就手動重新測試以前的功能。
反過來說，選擇正確的任務來實現自動化也同樣重要。不幸的是，這是QA自動化測試中最常見的錯誤之一。
但是，不要陷入過度自動化的陷阱，最終把測試任務做的本需求本身還要複雜。
5.不正確的代碼優化
這是一種相當常見浪費時間點，通常很難從一開始就發現。
你花了很多時間來優化那些不是優先級的場景，甚至可能不需要的代碼。
你首要的關注點應該是讓功能發揮作用，然後再考慮優化問題。
而且，優化的決定通常是基於具體情況的。
如果這個性能優化只需要幾分鐘，那就做吧。如果你要花幾個小時來獲得1%的性能增量，最好先慎重討論一下。
例如，讓我們假設你正在為一個內部團隊開發一個網頁。如果網站在一秒內成功加載，使用者並非迫切需要在0.5秒內加載，而且，這並不能顯著改善業務運營。那就沒有必要花費太多精力進行優化。如果它是一個電子商務商店，一秒鐘或者兩秒鐘加載對用戶體驗影響較為突出，那麼，它就成了一個功能需求點，需要著重優化。
6.低效的溝通
低效的溝通是造成軟體開發中許多時間浪費的直接原因。
溝通是至關重要的，尤其是在開發和過渡階段。
假設出現這樣的情況：開發人員對業務需求有誤。
這種溝通上的差距會使解決方案過於複雜，導致技術上的錯誤，並增強出現錯誤或返工的機會。
由於溝通是軟體開發中最人性化的方面，這種時間上的浪費是無法完全消除的。
然而，有了適當的項目管理工具和協作環境，它肯定可以被減少。
就個人而言，在開會或開發一個功能時，總是考慮到大局。學會傾聽和有效協作。養成寫下或發送會議討論內容紀要的習慣，以明確雙方的期望。
另外，要儘早溝通，而不是拖延。