幾年的工作中,經歷了2個幾十號人以上的大專案.深深體會了,乙個好的框架對專案的成成敗是多麼重要的. 尤其是我上乙個專案.做的是乙個國內頂尖的醫療公司的乙個門戶專案.當時由於專案的時間比較緊,沒有過多時間去考慮和研究框架.於是就簡單引進公司的另外乙個框架,到最後的2年多使用時間,就逐漸感覺到了那框架的弊端.到後面專案中的很多同事都反映,該框架不但沒有提高效率,而且嚴重阻礙專案的進度.結果也恰恰證明了這一點.使得我們中的很多開發進度,都是嚴重推遲了.
當然,乙個專案的成敗有很多因素.因為我是搞技術的,我想我還是分析一下技術方面的原因吧:
1,一開始時定專案時,由於時間的因素.沒有過多的考慮和研究框架.這也是我感覺到的普遍乙個專案型別公司的悲哀.一開始為了拿專案, 過多答應客戶要求.其實自己並沒有那麼大的實力去做那事情.當問題出現了,想的解決方法往往都是一些短期的解決方案.以致導致很多該做的事情沒做,俗稱」欠債」.我們當時引框架也是,由於前面做的工作有點延誤了,所以為了給客戶交付乙個漂亮的專案進度報表.於是把這麼重要的框架選型時間也壓縮了.而且我們當時公司的框架也比較亂.基本乙個專案乙個框架.沒有成熟的框架. 所以當我們引了別的專案的框架,也沒有過多去驗證該框架.結果到最後才發現那框架根本適合我們的需求.然而發現了問題,本該要及時糾正. 但由於自己公司,不可能去承擔這更改框架的成本,而且客戶也不可能去承擔.所以到後面就將錯就錯,不斷去用錯的框架去做.這樣也導致後面的問題越來越多,到最後只能讓一些技術好的同事,就當救火隊員,採取頭疼醫頭,腳疼醫腳的方式去解決當前問題. 可是紙終究是包不住火的,當問題不斷出現後,專案經理頂不住了,就只好換專案經理的方式去解決了. 還好,到最後客戶也實在無法忍受了,終於願意自己掏錢成立乙個架構優化組,專門去處理相關的架構問題了.
2.我們當時的專案的主要技術問題有,
一,框架沒有很好的支援多表查詢.
二.框架的底層報錯機制不好,動不動就報未將物件引用的錯誤.或者一些看不懂的錯誤提示,導致開發人員要通過除錯才能找到問題的原因.
三.底層架構,存在很多效能低下,不穩定的**.
3.我們沒有很好的執行當前定下的開發規範.一開始有做coder review工作.可是做了幾次後,就再也沒去做了.這樣導致後面的開發很亂.很多人為了貪求方便,寫**都copy 貼上的方式.而且的**的耦合度非常高,經常改乙個問題,又會帶來了其他問題.而且同樣乙個問題,有的地方改好了,有的地方又沒改好.
4.技術好的人,往往是用來做救護隊的隊員.沒有充分發揮好他們的作用.其實我們做的工作更多是要有前瞻性.我們要把問題,扼殺在搖籃裡.
一、,如何選框架
二、單點登入
三、快取元件開發
四、誇域選使用者和部門.
五、許可權設計
六、流程平台的設計
七、移動應用框架.
一 關於大專案的經驗總結
幾年的工作中,經歷了2個幾十號人以上的大專案.深深體會了,乙個好的框架對專案的成成敗是多麼重要的.尤其是我上乙個專案.做的是乙個國內頂尖的醫療公司的乙個門戶專案.當時由於專案的時間比較緊,沒有過多時間去考慮和研究框架.於是就簡單引進公司的另外乙個框架,到最後的2年多使用時間,就逐漸感覺到了那框架的弊...
農大專案 oracle備份及經驗總結
sql insert into test3 values gg 23 已建立 1 行。sql insert into test3 values dd 23 已建立 1 行。sql select table name from tabs table name test3 test1 test2 bin...
大專案的進展和總結
在做第二次大作業之前，我從同學和老師那裡得知了第一次作業的一些遺漏的問題，由於大作業是基於第一次作業來完成的，我還是決定將其整理進報告。另外也很順利的在mysql資料庫裡找到了對應的資訊 解決資訊源的問題後，就可以開始本次的專案了。安裝必要模組和更新資料庫 這部分內容很少，只需少量操作即可完成。首先...