寫出爛程式的懷習慣

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

1 複製，貼上

複製，貼上是每位工程師每天至少做100遍上事情，但如果該習慣拿來寫程式，那就非常不妙。

記得大學時交作業，班上有一堆的同學把我的程式 copy 過去，改一改變數名稱，換一換行號，讓助教看不出來是出自同一個人的手筆後，就魚目混珠地交完作業。如此速成的習慣也發現在許多 programmer 上。

很多人只是想要儘快地完成功能，可以準時下班，因此當需求一來，就連想到哪裡有類似已實作過的地方，就快速地複製其程式(甚至一模一樣的程式)。結果，相同的程式就像病毒地以不可思意的速度擴散到任意的地方。這樣違反了 Don’t repeat yourself (DRY) 準則，類似的程式當然有類似的邏輯，這些邏輯一旦因需求變更而必須修改時，修改者會發現程式改不完，而且擔心是否有沒有改到的地方。

這樣的困擾會不斷地發生，而且通常會發生在「很有效率」的人。我之前也被稱為「程式快手」，也是這樣來的。後來，才知道是被同事取笑，「程式快手」，複製 bug 也很快。

現在這類的人，我的同事取為「程式貼貼師」。

2 把範例當唯一方法

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

var context = new XXXModel();
// 使用 context 作一些 entity 的操作
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個原因，都是「上班族症候群」的結果。上班族來上班，只為了取得薪水。太傷腦筋的事，無論如何都會推掉。因此，再怎樣簡單的道理，「上班族」也不願想透。

結論

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

如何與上班族共處呢？我也正在實習中。