今天中午把其中一個功能給完成了,那個功能當初用IBM的公式計算需要24人時的時間,差不多就是三天多到四天(人一天工作是不可能滿8小時的),不過我自己的time log顯示,2天搞定了,主要是因為這功能在我比較不熟的前台只有查詢,沒有任何編輯的動作,相對簡單很多,而本來就比較熟悉的後台在前開發一個功能時,留了很多可以重複使用的東西,所以省下一些時間可以拿來準備課程的投影片。下午開始忙下一個功能,老實說這個功能是我估算最麻煩的一個,因為它橫跨了好幾個畫面和動作,更有趣的是,幾乎所有的功能都有規格書,唯獨這個功能沒有,因為PM也不知道要怎麼做?

  為此,不久前曾開了一個需求會議,我跟架構師、PM和大PM一起討論過,但其實還是留了一些未知數,所以下午又去找架構師討論,該怎麼處理這種跨好幾個模組、畫面的東西,最後還是決定用Spring framework去攔截action後再來處理(AOP),定案後開始一邊看Spring framework的書一邊寫code (別懷疑,我本身不是那麼喜歡AOP的programming style,所以過去都不太碰它),本來程式放在A專案,因為dependency和visibility的問題,後來又把程式改放到B專案,花了大概2小時把攔截action需要的程式搞定(ㄟ...這只是這個功能的其中一個步驟而已),告一段落後找架構師code review,很好,沒什麼大問題,明天可以繼續往下做了。

  回到自己的座位,隔壁的同事跟我說有個會議在C室,哈~我忘記今天有Team leader會議了,趕緊匆匆忙忙趕過去,一進去就看到投影片打著XX銀行的YY系統規格書,似乎是某位剛當team leader的同事在和主管討論規格書及開發手冊的撰寫吧!嗯~我自己是不寫那種東西的,等等,剛剛我不是才說某個功能沒有規格書嗎?那自己如果要負責一個新project卻不寫規格?其實平常我也不太看規格,現在寫程式都是根據prototype一邊操作一邊把功能實作出來,規格書只是在我測試時參考用的,就如同主管說的,當規格書越寫越多,之後程式跟規格書的差異維護就越痛苦,如果程式寫的易讀好懂,看程式有時候會比看規格書快(ok,真的只是有時候,畢竟我看到現在,讓我驚嘆的好程式不多),我自己也是靠看程式摸索目前系統的架構,不過這方法不見得適合資淺的工程師,所以開發手冊還是要有,規格書...我倒不那麼在意,只要能溝通清楚就好。但是...凡事都有一個但是,那些規格舒是XX銀行要求的,難怪有一堆奇奇怪怪看不懂的縮寫,他們真的很愛縮寫耶!因為這樣...就只好寫給他們啦~

dbi1463 發表在 痞客邦 PIXNET 留言(0) 人氣()