很有趣,先有再說先生,通常也是 程式改不動先生
這聽起來像是對立的兩個人,卻總是在Case期初和期末交換角色,
先有再說先生,總是先急著弄出個成品,不考慮之後程式修正的問題
就gadget(google桌面,網頁程式)說好了;
為了要考慮之後的擴充性,
或不得不為的修改,通常會盡量的切割之各個系統。
使其獨立,
MVC 構架是最常用的。
網頁application結構其實分割還滿容易的,
Server端(Model), Client端(View),
Control部份,個人是覺得盡量寫在Client(拖別人系統,決對比拖自已系統好,科科)
但先有再說先生,可以很棒的將其混在一起。
反正他只想先丟出去再說。
所以一個gadget(google桌面),
他用了<iframe> 將整個原在Server端的查詢網頁,
是的,也不是<iframe>不能用,
不過 gadget就已經是設計來成為你的網路桌面上的小程式的這件事情,
好像完全不管他,我完全看不到他的MVC架構在那裡?
這樣子的東西,也不可能在google桌面上縮放啊?
看了整個禮拜不知道在看啥?
(如果我也可以只整個禮拜只搞這個就好了,雜事有夠多的。)
反正先出去再說,
那今天老闆想要gadget上縮放呢?
這也不算強人所難,因為這本來就是google桌面設計的目的,
那你不就立刻倒了。
喔! 不會的! 因為 程式改不動先生(注意:康攢有夠才開的出這一隻)跳出來救你了。
老闆想要修改程式了,
「但這個程式改不動」程式改不動先生說話了。
(當然要說這句話前請先墊墊自已的份量),
其實程式改不動,也是因為你在Case期初時,
完全沒有考慮程式的擴充和修改性這件事。
就這醬出去了,真是營養雞排。
「反正我改不動,不然你找別人好了」程式改不動先生又說話了
(更高段的話,說這句話之前,請先考慮公司有多少專案在你手上,讓老闆投鼠忌器)
通常到這裡,
第一,找替死鬼收尾。
第二,算了。
是。算了機會還滿大的,通常 先有再說 先生 的程式,別人還真的改不動,
因為全都搞在一起了。重新幫他寫一個可能會比較快一點。
這個系列,不小心也寫到了第三篇,才發現,原來我是愛靠B的人(汗),
這些只是我在工作觀察到的,不見得對或錯,
可能在某些壓力下,你也不得不成為某一種先生。
不過請僅守「對修改關閉,對擴充開放的底限」吧
不然很難成為一個被尊敬的程式設計師。
這可能太難了,
那至少不要成為一位被唾棄的程式工人。
下一篇,我決定來罪已一下,以表自已不是一個只會打嘴砲的人。
留言列表