面的問題：
A、 元對象是一個弱類型結(jié)構(gòu)，其轉(zhuǎn)換及處理性能不佳；
B、 以字符串形式表示各種數(shù)據(jù)，在處理時再轉(zhuǎn)化為具體類型數(shù)據(jù)進行運算，性能不佳；
C、 XX插件內(nèi)部異質(zhì)樹處理仍使用元對象，內(nèi)存消耗大，速度慢；
對于系統(tǒng)性能的優(yōu)化有許多種解決方案，在決策時應(yīng)該考慮以下幾個方面的綜合加權(quán)因素：
A、 框架的清晰
B、 穩(wěn)定
C、 性能
D、 系統(tǒng)的復(fù)雜性
在系統(tǒng)實施的前期，強調(diào)了框架及穩(wěn)定，但在系統(tǒng)性能方面則考慮不夠，希望首先推出一個能夠運行的穩(wěn)定的框架，再不斷地增加功能，最后才考慮性能的瓶頸及性能優(yōu)化。
XX項目是一個新開發(fā)的系統(tǒng)，也是一個極端復(fù)雜的系統(tǒng)（從數(shù)據(jù)點容量方面看），因此，在初次設(shè)計時不能充分論證系統(tǒng)的可行性，或者論證不徹底等，都是可以接受的，正因為其是一個復(fù)雜的大系統(tǒng)，必須采用螺旋式開發(fā)模式。但本次開發(fā)過程中，對螺旋式開發(fā)的階段性劃分不夠明確，其具體表現(xiàn)在如下幾個方面：
A、 在最初計劃時，對系統(tǒng)開發(fā)周期及階段劃分有一定的計劃，但計劃未能反映各階段的里程碑及新周期的起始條件；
B、 對每階段的起始和結(jié)束時間及每階段需要完成的任務(wù)目標(biāo)未能明確定義；
C、 對階段性目標(biāo)的完成及具體實施控制未能有意識地進行；
D、 以XX的檢查作為階段工作的目標(biāo)，且每次檢查的目標(biāo)都不夠明確，經(jīng)常為了迎接檢查而重新調(diào)整計劃，導(dǎo)致階段目標(biāo)模糊；
3、 一廂情愿，盲目樂觀，違背程序編制的客觀規(guī)律，強調(diào)程序員的個人能力及士氣；
公司第一次采用團隊方式進行項目開發(fā)。對于該項目具體需要多少人員、時間；到底需要什么層次技能的程序組組長和具體開發(fā)人員；以及其它需要考慮的問題等，因為沒有經(jīng)驗，只能在實施過程中逐步修正，但在實施過程中，卻由于功能不明確，或者任務(wù)不明確等，許多程序員在相當(dāng)一部分時間內(nèi)具有盲目樂觀的表現(xiàn)，其具體表現(xiàn)在以下幾個方面：
A、 過多地強調(diào)某人某時編制了多少行的代碼量，甚至以一種自豪的心情描述我們的程序多少萬行。對其編碼質(zhì)量、編程的客觀規(guī)律等有一種輕視的態(tài)度傾向；
B、 忽視模塊測試、接口測試、白盒測試等，將所有的測試以系統(tǒng)整體形式由測試員統(tǒng)一測試；
C、 在某段時間內(nèi)，特別是在XX減免了五一之前的部分功能之后，有相當(dāng)多的人員對工作的艱巨性缺乏認知，特別在系統(tǒng)未統(tǒng)一聯(lián)調(diào)之前，相當(dāng)多的程序員對工作已完成的階段缺少認識，普遍存在一種盲目樂觀的心情。
4、 對各功能點的實施控制過粗，未能使用有效辦法控制總體進度；
具體表現(xiàn)在如下幾個方面：
A、 接口的變動是可以理解的，但接口變動之后，未能形成一個有效的方法來記錄接口變動說明，每個接口變動都是在相關(guān)程序員（而不是程序組之間）商量后進行定義，而定義后的接口未能以清晰、明確的方式在各程序組之間加以確定；
B、 系統(tǒng)設(shè)計的初期采用了一些規(guī)范的方法，擬對系統(tǒng)的開發(fā)過程進行控制，包括開發(fā)流程、系統(tǒng)分析、概要設(shè)計、詳細設(shè)計、測試過程等，但在實際實施的過程中，將前期的許多工作束之高閣，在開發(fā)過程中重新回到一種自發(fā)的下意識的控制過程，未能真正地有效地控制住開發(fā)過程；
C、 各程序組每周都有一些具體的開發(fā)目標(biāo)，對于目標(biāo)是否真正達到，或由于某些原因?qū)е碌娜蝿?wù)延遲，沒有具體的方法來判斷其情況真實、準(zhǔn)確性。所有的工作檢測只能通過系統(tǒng)的整體測試，進度的實施則依賴程序員的責(zé)任心和自覺性。
D、 ClearQuest對系統(tǒng)測試有比較大的幫助，但有一段時間，所有人員依賴ClearQuest來推動進度，導(dǎo)致某些程序員以改正在ClearQuest提出的與自己相關(guān)的問題為主要目標(biāo)；
5、 前期完全以框架推動進度，后期完全以需求推動進度，分
別走向兩個極端；
在系統(tǒng)設(shè)計的前期，主推框架，功能需求的工作只作為一種從屬的作用。許多工作都是在功能不太明確或是未能詳細推導(dǎo)的情況下開始進行，對系統(tǒng)的復(fù)雜性、實現(xiàn)時的性能因素等只在問題暴露時才想辦法解決。導(dǎo)致了系統(tǒng)框架的多次重構(gòu)。
開發(fā)的后期，則完全以功能來推動整個系統(tǒng)的進度，以完全、完美地實現(xiàn)XX項目的所有功能作為在3、4月份的工作，而實際上，以50天的時間，根本完成不了所有的功能。每個人都明白這個道理，但都不愿意承認這個事實，或一廂情愿地相信程序員的能力和責(zé)任心，只能以一種完成多少算多少的心態(tài)來工作。
實際上，該項目的核心問題是框架的穩(wěn)定性和可擴充性，后來才轉(zhuǎn)向以重點需求推動框架的形式。
6、 缺少重心，三個程序組各自為政又相互妥協(xié)，后期則形成了三個程序組和需求組四方相互妥協(xié)的局面；