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