剛剛上來寫篇博文，看到了《我心中的商用化開發》徵文公告。看了肖老師老師的幾篇文章，獲益匪淺。
其實如果不是這個商用化開發的公告，我也會寫這篇博文，來鞭笞自己。提醒自己，隨時注意在項目開發中注意，可運行版本這個概念。
昨晚，被我們老大狠狠的教訓了一頓。
我先說下我現在的狀況。我們的java team不大，一直在開發自己的商業信息平臺的。從平臺的開始到現在，陸陸續續來了一些人，也走了一些人。基本上，從框架的搭建到現在二期維護，除了老大做一些架構的調整工作，剩下的細微調整，從架構到業務的需求和代碼編寫都是由我來調整。
前些日子，我做了個struts2 Convertion和spring annotation的可行性報告後，老大決定將平臺原來struts2的xml配置改成convertion。
我嫌一個個功能改太麻煩，要不停的重啓服務器做功能測試，先將所有Action改成convention的形式，然後再改jsp頁面。導致最後，整個平臺的後臺管理的很多鏈接失效。
其實，老大在我改的時候，已經強調了，要一個一個功能的改。任何時候保證有一個可運行版本。。但是我就是沒聽。他狠狠罵了我一頓後，然後讓我想爲什麼。
我知道，can run version的概念自己沒有把握好。商業化開發的概念沒在自己心中牢牢鞏固。
晚上，做老大的車回家，他說，雖然我們現在不是做項目。但如果真的趕項目的話，如果客戶讓你明天給他一個版本，那你死活給不了的。因爲，你一頭扎到了修改Action文件中，你要是跟客戶說，現在在修改Action文件？所以影響了進度？那你準備扣錢吧。。客戶不會管你這個的。
回去想想，也是。任何時候保證可運行版本，真的很重要。特別是在商業化開發中
1.在修改中如果以功能爲單位修改，無論什麼時候都能得到一個可運行版本。
2.按功能修改，有利於其他人進入團隊，能根據已修改功能作爲demo去進行其他模塊的修改。
有點兒離題。。呵呵，現在就自己的理解，說說自己在工作中的所謂的商用化開發。
1.在商業化開發中，永遠保持可運行版本。
2.商業化開發不是新技術的戰場和試驗場所。
有時候，自己很喜歡用新的技術，新的方法注入到現行的項目中。什麼都想試試新。如，之前用的Fckeditor(網絡文本編輯器)，後來知道出了Ckedtor（fckeditor的升級版），就開始蠢蠢欲動了。和老大溝通後，被他攔了下來。原因很簡單，現時的編輯器基本能解決問題沒有必要換。我說，沒事啊，就2，3天的時間。他最後說的一句話，讓我很有感觸，他說，你關注的是時間，那麼我問你，摺合下來的修改成本是多少呢？什麼新技術也好，你可以去做。但是做的時候，首先要你能handle它，然後寫一份教程，一份可行性報告。因爲，你要是提它出了，那別人有什麼問題當然找你了。你必須handle它。二，教程是爲了讓新進的同事能快速的掌握它，三，可行型報告是爲了綜合下現時的情況，其他同類技術，做個對比才能“動手”的。
3.商業化開發需要每一個程序員要有一個share的習慣
一個教程，一個想法，一個新技術的觸角。。。很多人都喜歡把一些“小竅門”藏起來，作爲自己的一個競爭力。這在開發中其實是很不利的。比如，A在開發時，需要學習jquery，他用了3天，那麼他將自己的筆記整理了5頁筆記，全部藏起來了，下次，B在開發中又要用到jquery，那麼難道又要給他3天時間嗎？那整個項目期限就都浪費在了學習上了，那麼 我們就需要讓A也好，自己也好，將自己3天學到的東西寫成筆記share出來。這樣，幫助別人，利於團隊。也減少了項目的學習時間。何樂不爲呢？
4.商業化開發需求不是你訂的
有很多時候，有些顧客會按照自己的一些想法提出一些“實體屬性”，雖然你認爲不合適，但是你千萬不要改。雖然一些你看着不符合實際情況的屬性也好，關係也好。你做就是了。。沒有關係的。我們在開發中，經常會過分的爲顧客考慮，總想着，這個需求怎麼行，根本沒有道理的。什麼什麼的。。其實，很多時候，需求，特別是我們做商業平臺的，都是由業務決定你需求的去向。不要輕易的提問題。即便它有問題。。
好了，就寫這麼多了。。。呵呵，還有很多想法，但是不能寫了因爲
5.商業化開發不是你的聊天，看文章瞭解新技術的過程。 很多人都喜歡不讀書，看“聊效”。。我反對這種行爲。呵呵