台灣的專案環境與MVC

我想台灣的專案環境不適合使用MVC架構吧,因為:

1. 台灣的專案環境時程很趕,沒有多餘的時間做複雜的MVC或OO設計。
2. mvc對於新手太過複雜, 新手要花時間學習, 學完專案都結束了。
3. 對於一些基本檔建置程式, 也在用mvc, 會被一般人認為太過複雜。<雖然我不會這麼認為。任何一支程式可以複雜, 可以單純, 不應該因為功能不同有所區別>

結論:JAVA是很適合使用MVC的程式, 所以JAVA不適合在台灣用。所以只好拿JAVA來寫strutcure的程式。結案最重要，只要妨礙到結案的，一律都不準。用什麼MVC架構，隨便寫寫就好了。

只是心情有點煩

沒來由的,不知道為什麼,就是覺得那麼煩了一些。工作不想作,日子不想過,唯一想做的是....喔..連唯一想做的事也沒有。難道是那個來了嗎?是因為工作煩的關係嗎? 直覺顯示是因為沒有成就感。難道我會因為寫好的那幾支程式而到滿足嗎? 會。只不過沒人想看而已。不被別人欣賞鄂殺了我的創作, 甚至不知道自己的創作是否有價值。我有沒有知己呢?我那另一半算不算是呢?不知道。但他的確是很稱職的另一半-無論何時總陪在我身旁。

JAVA在台灣

曾經在感嘆java在台灣的應用及發展程度, 現在思考起來, 不是沒有原因的。在寫程式的時候, 看著自己使用者繼承架構、java bean、design pattern, 可是開發的速度卻比一旁的工讀生慢得一踏糊塗。於是深深在思考:使用著這些將java物件導向發揮的淋漓盡致的機制,真的值得嗎?雖然可以很自豪的說: 我寫的程式彈性比較大, 改得比較快; 可是再進一步細想, 以後有可能會改嗎?

台灣的軟體界主要以專案制度為主, 巴不得趕快結案, 維護期趕快過去, 能不改就不改。一些小系統, 也是功能可以跑就好了, 在軟體開發流程上, 最好是一個瀑布就這樣流下來(標準的瀑布式開發流程)。這樣的環境下, 像java這種具有彈性的OO似乎就發揮不了它的特色, 自然就沒什麼願意用這種沒什麼特色的語言。

再來看OO的另外一種特性:reuse。我認為reuse可以從2個角度來看。一個是reuse的修改(同樣的功能用同一支程式, 要修改這個功能就可以讓全部使用這支程式的部份一起修改), 我個人覺得這項功能很具特色, 也很吸引人, 不過也是在有需要修改的前提下。第2個是真的reuse, 就是說同樣的功能只要寫一次就好。在台灣,這可能是可以發揮java特色的部份

PM與Programmer的目標-the problem is choice

進入公司幹活, 也1個月了。開發程式的進度, 還是如當初的一樣慢。真不知道我這個月來, 每天加班, 練程式練得要死要活是幹什麼的。因為在coding上的速度是如此的慢, 使得整個專案的速度的down了下來。細究自己寫程式之所以會慢, 大多的時間是浪費在思考太多的東西--我女朋友也是這麼說: 做80分的東西可能要1小時, 但是做99分的東西卻可能要花去5小時。對於專案這種東西, pm們要求的當然是進度。然而身為一個programmer, 我卻會花許多時間思考, 程式註解要寫多少以後維護才看得懂, 類別要如何設計才可以在reuse及修改彈性中取得平衡。然後對於身為一個寫專案的programmer, 矛盾就在這裡了。台灣的專案制度下, 企業以結案拿錢為優先考量, 在「其他條件不變下」, 我很難相信在速度的要求下, 程式品質會有多好。就如同尼歐所說的: the problem is choice.(我真愛死他這句了)。而關鍵問題就在這裡: 「在其他的條件不變下」。很明顯的, 要能夠在短時間內寫出高品質的程式是其中的一個解決之道-如果可以的話。因此重點就在於要如何做到這樣了。

未來的規劃

工作了1年半, 別說在職場上的資歷尚淺, 技術能力也承認不成熟。上一間公司, 技術顧問幫我們打了許多底子, 換來的是技術學得不夠踏實。然而最主要的原因, 可能還是因為程式寫太少的關係。
剛才被我們的PM嫌:寫一支基本的單檔建檔程式要花2天的時間太久 。不過最近幾天...幾個禮拜, 幾乎每天工作10個小時以上, 得不到認可的心情實在是很鬱卒。不知道能夠以一天寫完一支單檔建檔的人的功力, 他們是寫了幾支這種類似的程式。
所以結論是: 未來的努力方向, 要再多加上努力練習寫單檔建檔的程式。

白目

不知道為什麼，從以前就很忌諱被人說是白目。有一段時間，我也在研究白目的定義。我的結論有二：白目是指被罵的人的行為是罵的人所不喜歡的。二：白目是指一個人的行為在大多數人在特定的情況下卻沒有呈現大多數人所會呈現的反應行為。舉個例子：在辦公室裡上司都還沒有下班，一個人下班時間到了就走人，在這種情形下，就可能會被形容是白目。當然不是符合上述情況都會被形容作白目，但就我的觀察：在被形容白目時卻大部分是這種情況。