首頁 常見問題 要注意避開這七個程式設計迷思啊!

要注意避開這七個程式設計迷思啊!

Aug 09, 2021 pm 05:41 PM

我們很少看到有人公開談論自己的錯誤。

人非聖賢,孰能無過?雖然難言出口,但反思過去所犯的錯誤可以讓人不會在未來——至少是短期的未來,犯下同樣的錯誤。

Mohamed Barouma是位工作5年的專業程式設計師,但和任何人一樣,他也犯過錯。

他這麼說:「通常情況下,我不會馬上意識到自己做錯了什麼;只有在接觸到正確的做事方法後,我才知道犯了哪些錯。」

結合他的原文,本文總結了他所犯下的七大誤解。

1、沒有使用適當的ORM

資料存取層程式碼總是混亂、乏味和無聊的。不幸的是,往往這點到最後才能發現。

Mohamed和ORM有著一段孽緣。 ORM,即Object Relational Mapping,它是物件關係模型的簡稱。它的作用是在關係型資料庫和物件之間作一個映射,使程式能夠透過操縱描述物件方式來操縱資料庫。

當Mohamed第一次做一個簡單的內部會計應用程式時,他發現只是為了完成基本的程序,就必須編寫大量的程式碼。於是他開始埋頭於ADO.NET,並手動編寫了一個自製的、具有非常特殊的、自訂的表格模式的ORM,來滿足目的。

在一段時間裡,這個ORM工作的相當不錯,直到幾個月後,公司的業務需求發生了一些變化,這導致了整個表格模式的變化,然後,就是對ORM的反覆修改。這個流程的痛苦之極,讓Mohamed最終選擇了強類型資料集適配器。

雖然這件事因此解決,但如果能找到一個更合適的ORM(比如NHibernate)來完成工作,Mohamed仍會義不容辭,至少當他的用戶數量增加時,不必擔心更改數據庫的供應商。

2、沒有學會使用泛型

Mohamed Barouma的職業程式設計師生涯始於Net 1.1。而在當時,Net 1.1的主要問題在於它沒有泛型支持,這代表它不能有一個強類型列表,只能滿足於乏味的ArrayList。但是使用Arraylist在Java程式碼中進行型別轉換和裝箱,會導致讀寫起來十分痛苦。

因此,Net 1.1的程式設計師們使用CodeSmith產生一個強型別集合清單。

但隨著程式碼庫的成長,那些客製化產生的清單本身就變成了一個無法收拾的怪物。只要經常為了創建物件或呼叫方法去達到目的,隨後就會因為修改程式碼導致混亂和錯誤。

如果切換到Net 2.0,並在它可用時立即開始使用泛型,而不是創建越來越多的難以維護的自定義集合列表,那麼一切問題都將迎刃而解。

3、沒有放棄「造輪子」

這是個老生常談的話題,「反覆造輪子」(Reinvent The Wheel)。新程式設計師總是喜歡反覆“造輪子”,自認為當前的實現不夠好,所以不得不從頭重寫整個東西。

為什麼叫「造輪子」?就像真正的輪子早在幾千年前就被確定是圓形的一樣,很多數據庫也早就已經成熟易用了,但還是有數不勝數的程序員們鍥而不捨的去“造輪子”,有的人飛蛾撲火、蚍蜉蝣樹,有的人別具一格、推陳出新,這就是「造輪子」魔法一般的吸引力。

這其中也不乏Mohamed,他想重新編寫自己的UI控件,因為Windows Forms UI控制項實在是太簡單了。最後,他造的GUI工具被商業化成體系的.Net UI控制輕鬆打敗,又一輛新生程式設計師造的「輪子」被擊沉到了程式碼海洋裡。

4、沒有精簡過多的文檔

很多剛入行的程式設計師,會在一開始覺得程式碼文檔很好,因為它用簡單的英文註釋了代碼在做什麼。但事實上這些文件通常在修改了幾次程式碼之後變成了一攤廢紙,變得陳舊、過時亦或是完全錯誤。

常常有人花了很多時間寫程式碼文檔-例如XML文檔,結果發現在更改程式碼時需要更新文檔。因為它的功能可能都已經改變了。更新程式碼是必須的,但更新XML文件不是必須的:這是一種負擔,它消耗時間,而且毫無用處。

最終,反覆地更改XML文件使人逐漸失去耐心,轉而做其他事情。

5、沒有使用自動化建置

應用程式的部署和打包比程式設計相對容易,所以它往往被放在了非常低的優先順序上。但很快,粗製濫造的建構就會因為無法運作,受到各式各樣的投訴:

「先決條件缺失,該如何修復?」

「dll沒有更新,你能給我一個補丁嗎?」

「我的圖示怎麼不見了?」

緊接著,電話像雪崩一樣源源不絕地打到桌旁。這是Mohamed的真實經歷,並讓他那天精疲力盡——不是因為編程,而是因為令人麻木的重新部署和重新包裝過程。

而這一切,本來可以透過編寫自動化腳本來節省一些時間,否則在事後debug浪費的時間絕對比可以節省的時間多上數倍。應該讓軟體可以一鍵構建,否則再多都是一種浪費。

6、沒有停止對視覺偵測和debug的依賴

Visual Studio讓人們可以輕鬆地偵錯程式碼並進行動態檢查,這也使得建立表單並顯示輸出非常簡單。但如果太沉迷於調試器,這項好處就要變成壞處了。

為什麼呢?想像一下,如果一個方法只在應用程式啟動並運行45分鐘後才被調用,那難道要打算等45分鐘再開始調試嗎?

所以,動動手將應用程式分解為可以獨立調用的子模組,這樣就可以準備產生錯誤輸出的輸入值,並從那裡開始測試它。

7、沒有做單元測試

不少程式設計師可能這麼想過:「我的這個應用程式微不足道,它可以很容易地被手動測試覆蓋;單元測試是針對大型和複雜的東西,而不是針對我的程式。」

可想而知,這會直接親手創造一個沒有關注點分離,難以重構,完全不可維護的程式碼庫。

 「躡手躡腳」幾乎是許多小白程式設計師的通病,害怕對程式碼進行哪怕是最輕微的修改,因為任何更改都可能導致或不會導致破壞性的更改。結果到最後一發不可收拾,出現的問題無法解決。使用這種遺留代碼不僅僅是無聊和緊張,而且精神上也有壓力。

但是使用單元測試,能讓程式碼的壽命大幅提升。 Mohamed希望自己能學會單元測試的“藝術”,從入學第一天開始練習單元測試,可惜學校並不教這個。

世界上,無數令人為之一振的創新發明都源自無數次的試錯,但即便如此,避免基礎性的錯誤依舊是很有必要的。在你的程式人生中,還遇到過哪些令人啼笑皆非的「常見迷思」?亦或者是創造了一些百思不得其解的「致命迷思」?歡迎下方留言,分享你學習程式設計時的心得體驗。

參考:

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software- engineer-f14ef540be10

以上是要注意避開這七個程式設計迷思啊!的詳細內容。更多資訊請關注PHP中文網其他相關文章!

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)