其他

作為程式員，我們希望的專案經理應該是：1。主動性你不可能指望同層級的同事拋開自己的事情不做跑過來幫你解決問題，這時候專案經理起到的就是協調作用，應該經常向程式員詢問情況，有什麼困難需要什麼協助，盡最大的努力利用自己手上的權利去協助程式員。2。Bug修複及時專案經理要能把握bug的輕重緩急，特別是和業務相關和程式無關的部分，在異常困難的情況下要和程式員一起研究出折中的辦法來儘快解決問題。3。按時完成任務他應該對手下的程式員的水平有一個比較詳盡的瞭解，誰在什麼方向上比較熟練，興趣在哪裡，目前水平如何

人常說："一個中國人是龍，一群中國人是蟲。"由於中西方文化的差異，似乎中國人更擅長單兵作戰。所以，項目團隊的管理在我國顯得特別需要。筆者總結了數年來在IT行業專案管理的經驗和教訓，認為成功的項目團隊應普遍樹立起五種思想意識--目標意識、團隊意識、服務意識、競爭意識和危機意識。下面一一詮釋一下 。一、目標意識1、 目標到人　　專案管理是目標管理，項目有明確的目標，所以團隊中每個人必需有明確的目標。考核時，專案經理只關注各人目標完成的結果，當結果不理想時，再返回去逆向考核過程。2、

1。好奇心 程式員是永遠不會接受現成的東西的，他們必須親自解開內心深處的迷惑和渴望。 2。清晰的思維技巧 編程是一件需要嚴密邏輯和清晰思維的事情，有強大的數學或者科學背景的程式員通常更加成功。 3。快速的閱讀速度和理解能力 相當大一部分程式員的一天都花在閱讀上，閱讀設計文檔，或者其他人的代碼，API，注釋等等，有些程式員讀的快，能很快理解，並且開始行動，另外一些程式員也許要多花三四倍的時間才能閱讀完畢，這些程式員的工作效率肯定不如前者。 4。注意細節

　　在一片泡沫破滅的喧囂中，網路界的一個概念越來越受到各個層面的重視，這就是網路公司的團隊工作。　　人們終於認識到，在網路領域創業，有和風險投資一樣重要的東西，日益頻繁的裁員表明，管理者在認識到管理團隊重要性的同時，也日益清晰地從整個公司的角度意識到團隊工作的重要性。從一定意義上說，一個網路公司能否度過寒冬，迎來春天，關鍵在於這個公司的團隊工作管理和設計是否到位。　　一種基於自我管理的團隊的工作設計是：組織常常會將任務安排給團隊或員工小組，而不是給單個的員工，特別是在高承諾的工作環境和管理方式下

實踐社團CoP的提法就很好，說明了只有通過實踐+社團的方式才能夠更加高效的分享知識，創造知識和升華知識。只有真正的知識實踐者才知道如何更好的進行知識管理，如何讓知識創造價值。只實踐而無社團，容易犯眼光短淺和井底之蛙的毛病，正如學習曲線描述一樣在實踐到一定階段後徘徊不前；無實踐而只社團類似於現在基於互連網的虛擬群組，知識是得到分享了，但知識往往並沒有碰撞出火花，並沒有創造出應該有的價值；無實踐和無社團典型例子就是傳統的學校教育模式，填鴨式的教學模式往往連為什麼而學都搞不清。1.人員:不僅僅是要有共

大部分的技術人員都是純粹的理想主義者，這也難怪，接受了10幾年理想主義的教育，每個人都難免有匡扶某某，恢複某某的決心。就像某個朋友在給我的回複中說的，“為什麼總是張口閉口國情呢?什麼都要符合國內,什麼都不遵循標準,那麼中國永遠也不會出現微軟!

隨著軟、硬體技術的發展，電腦的應用領域越來越廣，而其中軟體的功能也越來越強大，軟體也越來越複雜。這就使保證軟體的品質，保證軟體的高度可靠性，面臨巨大的挑戰。特別是諸如軍事、航空航天、通訊、交通醫學等行業，軟體的微小瑕疵就可能造成對生命安全、天文數位巨額財產、甚至對國家安全嚴重威脅。　　因此，對軟體產品品質的度量、評估和保證，成了使用者和項目承攬公司都十分關注的問題。基於這些原因，國際上的標準化和認證組織已經制定出了一些軟體標準（在ISO-9001以及SEI

在一個系統中，往往有一些服務只需要它們在整個系統中存在一個執行個體，並且在系統的任何角落都可以訪問它。這樣，單件模式出現了。比如在上一篇抽象原廠模式中，在一個系統中往往只有一個工廠，這樣我們可以引入單件模式來解決這個問題。     對於單件模式的定義是：只允許系統中有一個執行個體存在，並且為該執行個體提供一個全域的訪問點 一、單件模式介紹以及其原版         單件模式原版例子如下(將建構函式設為private，防止客戶代碼通過new執行個體化對象)： public class

做軟體測試快兩年了，但是一直有一個問題總是困擾者我，一直在想，什麼樣的問題才叫BUG呢，遇到此類型的缺陷我們該不該提缺陷單呢，作為一個測試人員，提出什麼樣的缺陷，才是一個好的測試人員，做為測試人員，我們是否只要發現了缺陷就提嗎？是否每一個公司的對BUG的定義是一樣的呢？在此公司此類問題判斷為BUG的缺陷難道到另外一個公司也是一樣嗎？   

1.從程式員到PM，是一條脫變的路，事實上程式員走的路最終不應該是專案經理。首先有一點需要明白的就是，一定規模的項目中，專案經理不需要太懂技術，他可以是一知半解。專案經理的任務不是在技術方面，技術相關的應該交給SA去做。專案經理更多地是做管理，溝通等工作，你如果可以的話到書店查看一下關於專案管理的書籍，你就會明白。當然對於小項目來說，有可能是PM，SA是同一個人，而這樣的專案經理更多隻是SA加上一些管理工作。要做專案經理，你就首先告訴自己不再去碰技術細節了。程式員並不是一個培養專案經理的好環境。

定義項目目標時需要遵循SMART原則。SMART包括：1、 詳細而且明確（Specific）2、 可測量的（Measurable）3、 可完成的（Achievable）4、 現實的（Realistic）5、 有時間範圍（Time-bound）下面舉例說明，例如：在兩個月內完成郵件收發系統，該系統實現公司內部的郵件接收發送和轉寄功能，系統效能為郵件平均發送時間不超過2秒鐘，學習使用該系統的平均時間不超過三十分鐘。1、 該項目標描述詳細的的的而且明確2、 系統的目標包括效能以及可用性的是可以測量的，

缺陷標示缺陷嚴重等級描述Ⅰ嚴重缺陷（ A ）不能執行正常工作功能或重要功能。使系統崩潰或資源嚴重不足。•  由於程式所引起的死機 , 非法退出•  死迴圈•  資料庫發生死結•  錯誤操作導致的程式中斷•  嚴重的計算錯誤•  與資料庫連接錯誤•  資料通訊錯誤Ⅱ較嚴重缺陷(B) 嚴重地影響系統要求或準系統的實現，且沒有辦法更正。（重新安裝或重新啟動該軟體不屬於更正辦法）•  功能不符•  程式介面錯誤•  資料流錯誤•  輕微資料計算錯誤Ⅲ一般性缺陷(C)

團隊工作在取得進步的同時也產生了一個問題。在更廣泛的商業和公用服務領域，只要一接觸到“團隊工作”這個詞就會被公眾所認可。“團隊工作”這一用語的含義是協商和合作，它最終要為成功地協商與合作而服務。實現了這個目標可算是個大勝利。因為它標誌著組織文化的重大轉變。但在許多勝利中也包含著災難的種子。一旦團隊工作到達了頂峰，這一用詞就會出現在任何人的口中，用在任何事上。中層管理員和從事人事工作的人為了得到人們的讚揚，最安全的方法就是宣稱自己相信團隊工作。

對CMMI，有許多人能都會有這樣的一些誤解： 　　CMMI重視過程不太重視人員管理； 　　CMMI強調按過程執行，而忽視人員的主動性、創造力； 　　過程是死的，文檔也是死的，但人是活的，事情也是變化的，CMMI的執行缺乏彈性； 　　本文將為大家闡述CMMI對團隊管理方面的要求，還CMMI一個“清白”。

 對於動態檔案,比如 index.asp?id=...  或者 index.aspx?id=... 相信有經驗的程式員都知道怎樣禁止瀏覽器快取資料了.但是對於靜態檔案(css,jpg,gif等等), 在什麼場合下面我們需要禁止瀏覽器緩衝他們,怎麼做?本文討論的主題是如何防緩衝, 尤其是如何防止靜態檔案被緩衝..在  RE:對部落格園URL的一些調整建議, 次層網域不利於用戶端瀏覽器緩衝 一文中,我提到了怎麼最大化的利用瀏覽器緩衝功能,來提高用戶端瀏覽速度,

　　作為Microsoft的最建立立動態Web網站的工具，ASP.NET相對於ASP和JSP在改變原始的Web編程方式方面有了長足的長進。它的代碼與頁面分離技術（CodeBehind）以及完善的Web伺服器控制項為程式員提供了一個更加符合傳統編程的Web伺服器端開發方式。但Web編程還是有著與傳統編程不相同的特點，這些特點決定了ASP.NET編程中必須以一些特殊的技巧來完成程式要求，快顯視窗正是這類編程方式的代表。相當多的編程書籍對快顯視窗採取緘默或者一語帶過，似乎看不過快顯視窗的巨大使用天地。

添加學習課件到MTK平台的項目快接近尾聲了，現在把團隊成員的程式整合在一起，這個過程讓我很受傷。本來按我的規劃，這個整合只需要兩到三小時就能完成了，結果用了我兩天多的時間，還是有問題存在。項目伊始，開工會之後，我安排了一天的時間來建立環境和寫環境架設說明書，本來建立環境沒有很大的難度，可惜一個錯誤改變了一切。由於對平台不是很熟，我不知道在make檔案裡使用的宏定義，不需要再在mmi_feature.h中定義；我一直以為是在mmi_feature.h中定義宏，在make檔案中使用。所以一直出現宏重

本文將介紹以下內容： • 設計模式（Design & Pattern） 本文涉及以下技術：     物件導向、設計模式 引言       設計模式是物件導向思想的集大成，GOF在其經典著作中總結了23種設計模式，又可分為：建立型、結構型和行為型3個大類。對於軟體設計者來說，一般的過程就是在熟練掌握語言背景的基礎上，瞭解類庫的大致架構和常用的函數和介面等，然後多再在百般錘鍊中，提高對軟體設計思想的認識。      

OOA物件導向分析 物件導向分析產生三種分析模型 功能模型(即用例模型à作為輸入) 物件模型:對用例模型進行分析,把系統分解成互相協作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關係,是系統的靜態模型 動態模型:描述系統的動態行為,通過時序圖/共同作業圖表描述對象的互動,以揭示對象間如何協作來完成每個具體的用例,單個對象的狀態變化/動態行為可以通過狀態圖來表達 OOD物件導向的設計 OOD是對OOA的細化 沒有嚴格的界線 OOD的結果直接用於編碼

對於一個程式員來說，什麼語言，什麼技術不是最關鍵，關鍵的還是編程思想，程式架構，商務程序的分析設計，項目進度的控制，上下級之間關係的處理和溝通。1 學好基礎，基礎是關鍵，不要盲目的追崇新技術。2 學技術要刨根問到底，要看清楚本質和原理，這樣你才能根據原理和本質去千變萬化，否則你只有永遠跟在別人後面，做別人做過的功能。3 要在工作和學習中總結，找出自己的不足，然後提高自己。4 要學會溝通，和同事溝通，和上級溝通，和客戶溝通等。5