關于大項目的幾點訴苦
幾年的工作中,經歷了2個幾十號人以上的大項目.深深體會了,一個好的框架對項目的成成敗是多么重要的. 尤其是我上一個項目.做的是一個國內***的醫療公司的一個門戶項目.當時由于項目的時間比較緊,沒有過多時間去考慮和研究框架.于是就簡單引進公司的另外一個框架,到***的2年多使用時間,就逐漸感覺到了那框架的弊端.到后面項目中的很多同事都反映,該框架不但沒有提高效率,而且嚴重阻礙項目的進度.結果也恰恰證明了這一點.使得我們中的很多開發進度,都是嚴重推遲了.
當然,一個項目的成敗有很多因素.因為我是搞技術的,我想我還是分析一下技術方面的原因吧:
1,一開始時定項目時,由于時間的因素.沒有過多的考慮和研究框架.這也是我感覺到的普遍一個項目類型公司的悲哀.一開始為了拿項目, 過多答應客戶要求.其實自己并沒有那么大的實力去做那事情.當問題出現了,想的解決方法往往都是一些短期的解決方案.以致導致很多該做的事情沒做,俗稱”欠債”.我們當時引框架也是,由于前面做的工作有點延誤了,所以為了給客戶交付一個漂亮的項目進度報表.于是把這么重要的框架選型時間也壓縮了.而且我們當時公司的框架也比較亂.基本一個項目一個框架.沒有成熟的框架。
所以當我們引了別的項目的框架,也沒有過多去驗證該框架.結果到***才發現那框架根本適合我們的需求.然而發現了問題,本該要及時糾正. 但由于自己公司,不可能去承擔這更改框架的成本,而且客戶也不可能去承擔.所以到后面就將錯就錯,不斷去用錯的框架去做.這樣也導致后面的問題越來越多,到***只能讓一些技術好的同事,就當救火隊員,采取頭疼醫頭,腳疼醫腳的方式去解決當前問題. 可是紙終究是包不住火的,當問題不斷出現后,項目經理頂不住了,就只好換項目經理的方式去解決了. 還好,到***客戶也實在無法忍受了,終于愿意自己掏錢成立一個架構優化組,專門去處理相關的架構問題了.
2.我們當時的項目的主要技術問題有,
一,框架沒有很好的支持多表查詢.
二.框架的底層報錯機制不好,動不動就報未將對象引用的錯誤.或者一些看不懂的錯誤提示,導致開發人員要通過調試才能找到問題的原因.
三.底層架構,存在很多性能低下,不穩定的代碼.
3.我們沒有很好的執行當前定下的開發規范.一開始有做coder review工作.可是做了幾次后,就再也沒去做了.這樣導致后面的開發很亂.很多人為了貪求方便,寫代碼都copy 粘貼的方式.而且的代碼的耦合度非常高,經常改一個問題,又會帶來了其他問題.而且同樣一個問題,有的地方改好了,有的地方又沒改好.
4.技術好的人,往往是用來做救護隊的隊員.沒有充分發揮好他們的作用.其實我們做的工作更多是要有前瞻性.我們要把問題,扼殺在搖籃里.
俗話說經驗是寶貴的財務.作為一個架構師,我必須好好總結我這2年多的項目經驗.同時我也希望我把這項目經驗跟大家好好分享.共同探討如何做好一個大項目. 接下來,我分別會向大家介紹我自己總結出來的東西.
一、,如何選框架
二、單點登錄
三、緩存組件開發
四、夸域選用戶和部門.
五、權限設計
六、流程平臺的設計
七、移動應用框架.
很歡迎各位網友,共同關注我的博客.大家一起探討如何做好一個項目吧.
原文鏈接：http://www.cnblogs.com/incubator/archive/2013/04/22/3035694.html
【編輯推薦】
