幾年的工作中,經(jīng)歷了2個幾十號人以上的大項目.深深體會了,一個好的框架對項目的成成敗是多么重要的. 尤其是我上一個項目.做的是一個國內(nèi)***的醫(yī)療公司的一個門戶項目.當(dāng)時由于項目的時間比較緊,沒有過多時間去考慮和研究框架.于是就簡單引進(jìn)公司的另外一個框架,到***的2年多使用時間,就逐漸感覺到了那框架的弊端.到后面項目中的很多同事都反映,該框架不但沒有提高效率,而且嚴(yán)重阻礙項目的進(jìn)度.結(jié)果也恰恰證明了這一點.使得我們中的很多開發(fā)進(jìn)度,都是嚴(yán)重推遲了.

當(dāng)然,一個項目的成敗有很多因素.因為我是搞技術(shù)的,我想我還是分析一下技術(shù)方面的原因吧:

1,一開始時定項目時,由于時間的因素.沒有過多的考慮和研究框架.這也是我感覺到的普遍一個項目類型公司的悲哀.一開始為了拿項目, 過多答應(yīng)客戶要求.其實自己并沒有那么大的實力去做那事情.當(dāng)問題出現(xiàn)了,想的解決方法往往都是一些短期的解決方案.以致導(dǎo)致很多該做的事情沒做,俗稱”欠債”.我們當(dāng)時引框架也是,由于前面做的工作有點延誤了,所以為了給客戶交付一個漂亮的項目進(jìn)度報表.于是把這么重要的框架選型時間也壓縮了.而且我們當(dāng)時公司的框架也比較亂.基本一個項目一個框架.沒有成熟的框架。

所以當(dāng)我們引了別的項目的框架,也沒有過多去驗證該框架.結(jié)果到***才發(fā)現(xiàn)那框架根本適合我們的需求.然而發(fā)現(xiàn)了問題,本該要及時糾正. 但由于自己公司,不可能去承擔(dān)這更改框架的成本,而且客戶也不可能去承擔(dān).所以到后面就將錯就錯,不斷去用錯的框架去做.這樣也導(dǎo)致后面的問題越來越多,到***只能讓一些技術(shù)好的同事,就當(dāng)救火隊員,采取頭疼醫(yī)頭,腳疼醫(yī)腳的方式去解決當(dāng)前問題. 可是紙終究是包不住火的,當(dāng)問題不斷出現(xiàn)后,項目經(jīng)理頂不住了,就只好換項目經(jīng)理的方式去解決了. 還好,到***客戶也實在無法忍受了,終于愿意自己掏錢成立一個架構(gòu)優(yōu)化組,專門去處理相關(guān)的架構(gòu)問題了.

2.我們當(dāng)時的項目的主要技術(shù)問題有,

一,框架沒有很好的支持多表查詢.

二.框架的底層報錯機(jī)制不好,動不動就報未將對象引用的錯誤.或者一些看不懂的錯誤提示,導(dǎo)致開發(fā)人員要通過調(diào)試才能找到問題的原因.

三.底層架構(gòu),存在很多性能低下,不穩(wěn)定的代碼.

3.我們沒有很好的執(zhí)行當(dāng)前定下的開發(fā)規(guī)范.一開始有做coder review工作.可是做了幾次后,就再也沒去做了.這樣導(dǎo)致后面的開發(fā)很亂.很多人為了貪求方便,寫代碼都copy 粘貼的方式.而且的代碼的耦合度非常高,經(jīng)常改一個問題,又會帶來了其他問題.而且同樣一個問題,有的地方改好了,有的地方又沒改好.

4.技術(shù)好的人,往往是用來做救護(hù)隊的隊員.沒有充分發(fā)揮好他們的作用.其實我們做的工作更多是要有前瞻性.我們要把問題,扼殺在搖籃里.

俗話說經(jīng)驗是寶貴的財務(wù).作為一個架構(gòu)師,我必須好好總結(jié)我這2年多的項目經(jīng)驗.同時我也希望我把這項目經(jīng)驗跟大家好好分享.共同探討如何做好一個大項目. 接下來,我分別會向大家介紹我自己總結(jié)出來的東西.

一、,如何選框架

二、單點登錄

三、緩存組件開發(fā)

四、夸域選用戶和部門.

五、權(quán)限設(shè)計

六、流程平臺的設(shè)計

七、移動應(yīng)用框架.

很歡迎各位網(wǎng)友,共同關(guān)注我的博客.大家一起探討如何做好一個項目吧.

原文鏈接：http://www.cnblogs.com/incubator/archive/2013/04/22/3035694.html

【編輯推薦】

1. IT行業(yè)弱肉強(qiáng)食 開發(fā)人員接外包項目必須掌握四點技巧
2. 項目經(jīng)理從老客戶那拿到新項目的4種方法
3. 一個糟糕透頂?shù)淖杂陕殬I(yè)者項目
4. 自由職業(yè)者：項目報價過低的17種跡象
5. 12個項目管理成功的關(guān)鍵原則