今天中午把其中一個功能給完成了，那個功能當初用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銀行要求的，難怪有一堆奇奇怪怪看不懂的縮寫，他們真的很愛縮寫耶！因為這樣...就只好寫給他們啦~
留言列表
