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