即使有些職缺會說物件導向多好
有些追求技術的會說物件導向多好
但是，在台灣軟體工作之中，物件導向真的重要嗎?
如果真的重要，那為什麼碰過很多的系統架構都讓人感覺挺糟糕的
(像是：
隨便一個method因為背負太多責任，所以長度就幾百行
隨處都可看到一大塊程式碼重複，也不曉得是完全一樣還是有小部分不同)
為什麼會這樣呢？我最近有個想法
這並非不懂物件導向，而是人所造成的(你也可當作是人性)
首先想一下，物件導向能帶來甚麼好處，我想到的有：
1.容易維護與擴充(容易了解)
2.品質(因為可以容易進行非使用者測試與偵錯)
那麼管理者在意的是甚麼?
1.能驗收
驗收不了就連收入都沒有
驗收往往看的只是程式能不能跑出使用者能接受的結果
並非品質好就真的能接受，也並非爛東西就無法被接受
2.不要延期造成罰款
有些專案如果延期要罰錢，對老闆來說罰錢是件很痛的事情
所以減少罰款造成的開銷是很重要的(總不能跟客戶說：「軟體開發專案延遲本來就很正常的，你要open mind啊」)
專案進行過程中如果進度延遲，煩惱的不會是程式好不好維護與與新加入的PG好不好接手
煩惱怎麼讓人加更多的班又不會中途跑掉的可能性還比較高
3.不一定(可能專案成功時搶功勞、專案失敗時推責任，也可能其他，但絕對不是程式的品質)
也許有些主管或老闆會說品質很重要、物件導向很重要之類的話
但實際上，物件導向是對程式設計師比較有好處
對管理者而言，只要願意加班又不會要求公司付出更多代價(加班費)
每天拼命加班甚至週末也要加班，只要別告公司或被勞動檢查發現都無所謂(實際上對管理者又沒影響)
也許有的管理者會辯解說：「技術的東西我不懂啦，不要跟我講技術，那是你們的問題」(即使真的懂也可能裝不懂)
當專案範疇一直擴大、專案截止日期不變，只能一直加班趕進度
對程式設計師來說，去做些重構的處理未必對他而言是件好事
如果對專案的運作有好影響，不會被上頭當作做得好
如果出問題，就是程式設計師的錯(影響進度、或產生新的bug)
程式設計師讓程式架構爛其實也是很正常的現象
整件事的根源點在哪呢?
我認為在於人性與利益
當一件事情對一個人而言，並沒有好處，甚至可能會增加些麻煩
那麼這個人就可能不會想去做這件事情了
我沒甚麼明確的解決方法，只有想到一個方向
就是把這件事情跟希望能執行的人的利益給串在一起
例如把你想要的事情跟會導致無法驗收給串在一起
主管或老闆只要無法繞過去或硬凹屬下解決
他就只好做你想要的事情...
至於該怎麼串、能不能串，我就不知道了
(我只是提個方向，有更好想法的可以提出)
反向的範例就是以自己的利益來要求
例如:
希望交派任務的主管或系統分析師，能夠把需求給搞清楚，不要說不清楚或一直變來變去
程式設計師如果去說「你這樣會害我做很多白工，影響我的進度」
只要寫程式是做不完就會免費拼命加班，對方根本不會想甩你
留言列表
