根據(jù)自己幾年的血淚教訓(xùn)，總結(jié)了6條寫代碼過程中最忌諱的問題，相信絕大多數(shù)剛接觸編程的同學(xué)都會(huì)犯同樣的問題！

1. 添加太多特性

有多少次你通過考慮所有的”可能性“而使一個(gè)故事需求過度復(fù)雜化？

如果你正在開發(fā)的API可以被設(shè)計(jì)成與其他平臺(tái)無縫集成呢？如果你的儀表板可以發(fā)送自動(dòng)報(bào)告呢？

抵制這種行為，不要過度設(shè)計(jì)它。

你不應(yīng)該在未來太過超前的功能上花費(fèi)大量的時(shí)間。而且，更多的代碼意味著更多的bug和不必要的腳本會(huì)增加應(yīng)用程序的臃腫。

理解你的代碼和添加新的特性也會(huì)更加復(fù)雜。

為了避免這種情況，要不斷問自己，你的代碼是否解決了具體的需求。

確保你想清楚用例和邊緣案例，但不要在一個(gè)你可以更快上線的功能上花費(fèi)數(shù)周時(shí)間。

如果你對(duì)添加一個(gè)有可能解決極端用例的功能感到困惑，在下一次版本迭代上提出來。

你將會(huì)節(jié)省大量的時(shí)間，并且你將會(huì)建立起你自己作為一個(gè)團(tuán)隊(duì)成員的形象。

2. 重復(fù)寫同樣的腳本

作為一名軟件工程師，你應(yīng)該遵循DRY（Don’t Repeat Yourself）原則來提高工作效率。

這可以通過兩種方式實(shí)現(xiàn)：消除代碼中的冗余，或簡化開發(fā)流程。

讓我們看看如何解決這兩種情況。

代碼中的冗余

設(shè)置一個(gè)服務(wù)器，甚至一個(gè)虛擬環(huán)境，需要多次編寫相同的腳本和動(dòng)作。

你要用幾乎相同的步驟和代碼建立你的3層開發(fā)架構(gòu)，包括開發(fā)、測試、生產(chǎn)。

除此之外，管理基礎(chǔ)設(shè)施的依賴性也變得越來越復(fù)雜。

這不僅是重復(fù)和枯燥的，而且手動(dòng)操作也讓你容易出現(xiàn)人為錯(cuò)誤。

低代碼平臺(tái)通過可重用的基于抽象的組件和可視化的拖放界面，開箱即有這種功能。

當(dāng)然，你不會(huì)為每個(gè)場景找到一鍵式解決方案，但你會(huì)有最基本、可重復(fù)的解決方案。自動(dòng)管道將幫助你為你需要的許多環(huán)境構(gòu)建、復(fù)制和擴(kuò)展代碼。

流程中的冗余

清楚地勾勒出你在開發(fā)過程中的步驟數(shù)量，并思考如何減少這些步驟。

在這里，自動(dòng)化能夠提供有效幫助。

另外，留意那些你最終執(zhí)行了兩次以上的過程。制定一個(gè)自動(dòng)化序列，每次你想做這個(gè)任務(wù)的時(shí)候都可以觸發(fā)，你會(huì)從中受益。

不過，在你進(jìn)行自動(dòng)化之前，一定要注意時(shí)間上的權(quán)衡。

在實(shí)現(xiàn)自動(dòng)化之前要問自己一些問題”如果我把它自動(dòng)化，會(huì)比我做這個(gè)任務(wù)節(jié)省更多時(shí)間嗎？在接下來的幾周內(nèi)，我是否會(huì)定期做這件事？“

如果答案是肯定的，就把它自動(dòng)化。

3. 從零開始建立系統(tǒng)

如果一個(gè)開發(fā)者每次建立網(wǎng)絡(luò)應(yīng)用時(shí)都要對(duì)JDBC數(shù)據(jù)庫連接進(jìn)行自定義編碼，那么完成一個(gè)項(xiàng)目就需要很長時(shí)間。

開發(fā)可維護(hù)和安全的軟件應(yīng)該是你的首要任務(wù)。

然而，這并不意味著從頭開始構(gòu)建系統(tǒng)。

你不需要重新從零開始造輪子、重建已經(jīng)存在的功能。

公司想要高效的工作，而你花在從頭開始構(gòu)建系統(tǒng)上的時(shí)間，在大多數(shù)情況下是多余的。

因此，取而代之的是，通過使用成熟的框架，根據(jù)客戶的需求進(jìn)行定制。

另外，檢查公司代碼庫。如果該工具現(xiàn)有的功能與分配給你的功能重疊，最好檢查一下函數(shù)調(diào)用是否可以提供你所需要的數(shù)據(jù)，或者是否可以整合。

然而，當(dāng)處理機(jī)密數(shù)據(jù)如財(cái)務(wù)，或健康記錄時(shí)，從頭開始建立功能以加強(qiáng)安全是有意義的。但在大多數(shù)情況下，框架、知名的開源庫可以完美地完成工作。

4. 糟糕的測試策略

在選擇自動(dòng)化和人工測試時(shí)，你必須注意一個(gè)微妙的平衡。

因此，讓我們了解一下，作為一個(gè)軟件工程師，你如何利用這一點(diǎn)來制定一個(gè)有效的測試策略。

寫一個(gè)小的手動(dòng)測試來確保你添加的新功能工作正常是很容易的。

但是，當(dāng)你擴(kuò)大規(guī)模時(shí)，運(yùn)行這些手動(dòng)測試需要更多的時(shí)間，特別是當(dāng)你試圖找到那個(gè)討厭的bug，不斷破壞你的代碼。

你需要花更多的時(shí)間來設(shè)置你的自動(dòng)化測試。不過，一旦它們被寫好，它們就可以被重復(fù)使用。因此，你不必因?yàn)樵黾恿艘粋€(gè)新的功能就手動(dòng)重新測試以前的功能。

反過來說，選擇正確的任務(wù)來實(shí)現(xiàn)自動(dòng)化也同樣重要。不幸的是，這是QA自動(dòng)化測試中最常見的錯(cuò)誤之一。

但是，不要陷入過度自動(dòng)化的陷阱，最終把測試任務(wù)做的本需求本身還要復(fù)雜。

5. 不正確的代碼優(yōu)化

這是一種相當(dāng)常見浪費(fèi)時(shí)間點(diǎn)，通常很難從一開始就發(fā)現(xiàn)。

你花了很多時(shí)間來優(yōu)化那些不是優(yōu)先級(jí)的場景，甚至可能不需要的代碼。

你首要的關(guān)注點(diǎn)應(yīng)該是讓功能發(fā)揮作用，然后再考慮優(yōu)化問題。

而且，優(yōu)化的決定通常是基于具體情況的。

如果這個(gè)性能優(yōu)化只需要幾分鐘，那就做吧。如果你要花幾個(gè)小時(shí)來獲得1%的性能增量，最好先慎重討論一下。

例如，讓我們假設(shè)你正在為一個(gè)內(nèi)部團(tuán)隊(duì)開發(fā)一個(gè)網(wǎng)頁。如果網(wǎng)站在一秒內(nèi)成功加載，使用者并非迫切需要在0.5秒內(nèi)加載，而且，這并不能顯著改善業(yè)務(wù)運(yùn)營。那就沒有必要花費(fèi)太多精力進(jìn)行優(yōu)化。如果它是一個(gè)電子商務(wù)商店，一秒鐘或者兩秒鐘加載對(duì)用戶體驗(yàn)影響較為突出，那么，它就成了一個(gè)功能需求點(diǎn)，需要著重優(yōu)化。

6. 低效的溝通

低效的溝通是造成軟件開發(fā)中許多時(shí)間浪費(fèi)的直接原因。

溝通是至關(guān)重要的，尤其是在開發(fā)和過渡階段。

假設(shè)出現(xiàn)這樣的情況：開發(fā)人員對(duì)業(yè)務(wù)需求有誤。

這種溝通上的差距會(huì)使解決方案過于復(fù)雜，導(dǎo)致技術(shù)上的錯(cuò)誤，并增強(qiáng)出現(xiàn)錯(cuò)誤或返工的機(jī)會(huì)。

由于溝通是軟件開發(fā)中最人性化的方面，這種時(shí)間上的浪費(fèi)是無法完全消除的。

然而，有了適當(dāng)?shù)捻?xiàng)目管理工具和協(xié)作環(huán)境，它肯定可以被減少。

就個(gè)人而言，在開會(huì)或開發(fā)一個(gè)功能時(shí)，總是考慮到大局。學(xué)會(huì)傾聽和有效協(xié)作。養(yǎng)成寫下或發(fā)送會(huì)議討論內(nèi)容紀(jì)要的習(xí)慣，以明確雙方的期望。

另外，要盡早溝通，而不是拖延。

hello，大家好，我是 Jackpop，碩士畢業(yè)于哈爾濱工業(yè)大學(xué)，曾在華為、阿里等大廠工作，如果你對(duì)升學(xué)、就業(yè)、技術(shù)提升等有疑惑，不妨交個(gè)朋友：

我是Jackpop，我們交個(gè)朋友吧！