寫出爛程式的懷習慣

轉貼自：http://charlesbc.blogspot.com/2010/07/blog-post.html

繼上次的 寫出好程式的好習慣後， 也不得不寫一下我看到常見的壞習慣。

1 複製，貼上

複製，貼上是每位工程師每天至少做100遍上事情，但如果該 習慣拿來寫程式，那就非常不妙。
記得大學時交作業，班上有一堆的同學把我的程式 copy 過去，改一改變數名稱，換一換行號，讓助教看不出來是出自同一個人的手筆後，就魚目混珠地交完作業。如此速成的習慣也發現在許多 programmer 上。
很多人隻是想要儘快地完成功能，可以準時下班，因此當需求一來，就連想到哪裡有類似已實作過的地方，就快速地複製其程式(甚至一模 一樣的程式)。結果，相同的程式就像病毒地以不可思意的速度擴散到任意的地方。這樣違反了 Don』 t repeat yourself (DRY) 準則，類似的程式當然有類似的邏輯，這些邏輯一旦因需求變更而必須修改時，修改者會發現程式改不完，而且擔心是否有沒有改到的地方。
這 樣的困擾會不斷地發生，而且通常會發生在「很有效率」的人。我之前也被稱為「程式快手」，也是這樣來的。後來，才知道是被同事取笑，「程式快手」，複製 bug 也很快。
現在這類的人，我的同事取為「程式貼貼師」。

2 把範例當唯一方法

首先，微 軟的 MSDN 網站上有大量的範例，網路上也有為數不少的 sample。這些範例都是用來說明該類別\方法的使用方式，但未必適合使用在正式商業用途。例如Entity Framework 的連線方式，通常範例，如ObjectContext.SaveChanges 方法，使用

view source

print?

1.var context = new XXXModel();

2.// 使用 context 作一些 entity 的操作

3.context.SaveChanges();

隻使用預設建構子來建立連線？不必使用多個不同權限等級的帳號連線到資料庫，就符合資料庫的安全設計嗎？當然不是。
為了讓資料庫更安全，我們通常會使用不同的帳號，存取不同的資料表/預存程序/View，當然需要不同的連線字串。範例隻是為了示範如何使用該類別 或方式的使用方式，並不會在每個範例上都符合安全設計的原則。
因此，範例請把它當範例吧。不要拿過來隻會照抄，通常不會恰巧地符合您的商業需求的。

3 沒有功勞，也有苦勞

這是心態問題了。這樣的人通常會表現工作的很辛苦，如果工作不如預期，就無法怪到他的身上。這一招通常有效，而且有效得長官也認為責任不在該員身 上。

4 隻(想)會一種技術

存取資料庫的方式，隻會使用 SqlCommand 的方式。新出來的 TableAdapter，Enterprise Library 中的 DAAB，LINQ to SQL，ADO.NET Entity Framework 一律不碰。這樣的人不在少數，原因呢？新技術不斷地推出，誰學得完呢？反正土法煉鋼，總有一天能完成，加上「沒有功能也有苦勞」原則，就能以不變應萬變 了。

5 隻會寫程式

程式除了需要開發之外，其餘有更多的東西需要了解，才能成為一名好的開發/設計人員。諸如 Queue、Cache、IIS、Remote desktop、NLB、Cluster 等數也數不完的東西，都並不與程式直接相關。因此，我也見過太多人並不想了解間接相關的IT知識。
因此，網頁工程師不懂如何部署程式到 IIS，也不了解Application Pool 如何回收/身份識別如何設定等光怪陸離的事情也多見不怪了。
最經典的，我見過一名十多年經驗的係統分析師，其係統分析書以Word 來製作，但其排版方法與 PE2 時代無異。

6 隻想當上班族

發現了嗎？前5個原因，都是「上班族症候群」的結果。上班族來上班，隻為了取得薪水。太傷腦筋的事，無論如何都會推掉。因此，再怎樣簡單的道理， 「上班族」也不願想透。

結論

其實，大部份的人都隻是「上班族」，對於真正想要作出一番事業的人，無法避免地一定會與「上班族」接觸。因此，事業心重的人，也必須善待這些上班 族。
如何與上班族共處呢？我也正在實習中。