對自己哪方面工作滿意，有效的經驗總結有哪些？
1） 客戶端的完整事件 機制和訊息分發機制的構建。
構建了比較穩定有效的事件和訊息分發機制，目前的事件機制建立在as3.0新的事件機制基礎
之上，使用全域性靜態屬性，並且傳遞的引數可以不限長度，不限型別的的進行新增，使伺服器、
訊息和客戶端各模組之間，客戶端內部各模組之間的資訊通訊 簡便而穩定。
經驗：在構建訊息機制前，在網上，和各個技術群理參考了大量例項和** ，和很多as 的技
術人員進行了溝通和了解，最終確認了目前採用的通訊構架。
2） 本地資料 庫資料結構的設計和分析載入 機制的構建。
在分析了客戶端本地資料的需求後，設計了一套適合本地解析維護的文字資料結構，採用這一
資料結構以後，所有的本地資料都可以在文字資料中進行維護，包括通訊協議的解析**和之
後新增的各項客戶端資料，基本上維護資料的工作可以由負責相應功能的策劃人員進行維護，
體現了比較良好的可維護性和更新性。
經驗：在和策劃的比較深入的溝通下，再比較早的時間就制定了規範的客戶端資料結構，在之後
的策劃一直按制定好的資料設計結構，早制定，早執行。
3） 各個功能模組的oop設計和模組化設計
各個基本的功能模組基本都按照oop的思想設計，將資料和顯示分離，將素材和**分離。這
樣的處理。使得後續開發 的模組都有比較好的模板可以參考，加快了開發速度， 素材和**分
離的做法使資料更加安全，介面和各個效果 的改版也更加方便
經驗：主要得益對as3.0語法特性的理解，在專案開始的階段，就確認了as3.0本身物件導向
的開發特性，在開發過程中主動的思考和設計相應的功能和模組，在可復用性，可維護性，和
低耦合性做了比較多的思考。
4） 對於幾個重點的技術問題的處理
1） 客戶端效率 問題：這個難題一直是flash 大型專案開發的瓶頸，我們也無可避免的遇到這一
難題，但我們歷經三次的大規模效率優化，甚至將所有模組拆分一一測試，目前，客戶端
**的效率比較穩定，在同類產品中還占有一定的技術優勢。
經驗：對於必須處理的重大問題，必須下大決心，用必勝的信念去克服，甚至不惜拖後進度
的代價。處理過程中也需要有科學的測試和優化過程設計。
2） 客戶端黑屏bug問題：這個問題在技術測試和內測前期一直存在，多次調整技術方案，多次
改進測試方式，也未能將此問題完成解決，最後，只能從源頭思考解決方案，既然無法移除，
就乾脆不進行載入。此問題得到解決
經驗：對於長期得不到解決和處理的問題，不妨全部推到，重新再來，或者，換乙個角度
去思考5） 與伺服器端相當默契的配合
目前和伺服器端程式設計人員的配合比較默契，從功能的實現和bug的排查，都能比較有效而迅速
的進行處理，極大的保證了工作的進度，也能對客戶端的**進行比較大的節省和優化。
經驗：前期多溝通（甚至是比較激烈的溝通方式），這樣可以知道對方的程式設計習慣和處理事情的 原則，知道對方考慮問題的輕重緩急。後期多理解（遇到問題時自己先多考慮一些），在保證功能
實現不繁雜不臃餘的基礎上，自己可以多處理些功能，需要對方處理的時候，給出合理的理由。
對自己哪方面工作還不太滿意（需要提高的方面），怎樣去改進？
1） **風格和邏輯嚴密性
**風格一直是我自己程式設計習慣帶來的影響，前期的**編寫主要考慮的是**的可讀性和可
維護性，沒有採用過於複雜**邏輯和簡潔的**略寫方式，新增的注釋也比較少，但又由於負責的模組涉及比較多的顯示和操作的邏輯，需要對比較多意外操作和 狀況進行容錯處理，導致**量比較大，部分介面顯示**邏輯比較繁雜。
邏輯嚴密性不好，在編寫**時過於考慮實現過程，少考慮了意外和容錯的處理，尤其是到了
專案的後期，由於**量和功能模組大量增加，對**的乙個改動就可能引起各個功能模組的
錯誤反映，而在提交測試時又沒對相應的影響完全考慮，後期導致多次上線就出bug，出bug
就更新的問題。工作相當的被動和狼狽，對玩家也產生了不好的遊戲 體驗。
改進方式：目前正在整理客戶端相應的介面文件，逐步對**進行結構整理和效率優化，新增
相應注釋，對**中相互影響的訊息，事件和引數 逐步歸類，生成文件。
和策劃及測試部門進一步配合，對新上版本的測試提出更合理和準確的測試需求，爭取將嚴重的
bug消滅在上線之前。
2） 工作計畫和主動性
工作計畫在某些時候會出現忽鬆忽緊的情況，在臨近更新和跟新之後往往需要加班才能處理工
作，在某些時候又無確實的工作安排。
改進方式：進一步和產品經理，策劃的需求進行協調，工作安排一些提前量，對更新帶來的增
加的工作量1是盡量提前在t1測試服進行版本測試，2是提高**質量，和測試工作，減少
因為bug帶來的額外工作。
工作主動性：在專案後期，工作進度比較緊張的時候，對策劃的需求 和bug的反饋，反應都不
夠及時和積極，有時候有辯解的工作表現。
改進方式：堅決克服。
自我肯定及批評。
自我肯定：
1） 學習 ，創新能力
能一直保持比較積極向上的心態，能不斷的要求自己上進，對新技術，新改變保持歡迎並樂於
接受的態度，不斷的通過學習和改進來完善自己的專業能力
善於並敢於創新，對flash大型網遊這一新的專案，通過自己的努力，逐步克服了專案程序中
各種的技術難題，對於各方面也查詢不到資料的難題和策劃的一些特殊需求，都通過自己的思
考來找到解決方式，最終一步步的完成了flash遊戲專案的各項工作
2） 溝通合作能力
和配合的伺服器，策劃，客戶端同事的溝通合作良好，共同處理各種工作中遇到的難題，提出
合理的問題處理方式，工作氛圍關係良好。工作進度完成有序。
3） 必勝信念
對目前從事的工作，專案的實施前景以及公司的整體戰略都抱有絕對的信心，在工作上相信自己
己有能處理好所有技術需求難題的信心，對專案絕對相信flsahmmo專案能為公司帶來真實巨
大的收益，更相信公司堅持的自主研發，多線發展的原創網頁理念一定在在未來的網頁遊戲市場
裡成為領軍人物和行業的豐碑。
批評：1） 工作主動性
在工作壓力比較大，工作比較繁瑣的時候工作主動性，嚴謹性都不太好，程式設計的技術和水平
也需要進一步的提高。這是比較長期的改進，也是自我完善必經的一步，我唯有正視缺點並堅
決克服之。
2） 同事相處和建議
對客戶端同事在工作指導和工作協助上做的工作還不夠，還需要進一步的為同事提供和創造
良好的工作條件，對自身的責任不再推脫和辯解，有則改之。對工作中應該提出的要求和工作
進度要一步的跟進，對某些不好的工作方式要敢於提出意見，自己也要更虛心的接受批評
對公司各方面工作的意見或建議。
1） 穩定伺服器端程式設計人力，促進相互溝通磨合
確保工作時間和進度，並進一步的促進雙方的溝通，比如可能交流下伺服器和客戶端的簡單邏輯，以促進雙方在工作分配上的理解和配合
2） 重視測試工作
後期測試版本比較多主要的原因是程式設計**複雜，邏輯繁複，但有一些比較明顯和突出的bug
還是應該在測試工作期間得到處理的，遊戲的測試應該有一套針對遊戲測試的更科學和量化的
測試方式，不僅是將內部bug測試出來，還應該將玩家反饋的一些問題加以重現，甚至是**
模擬遊戲重大更新會給玩家帶來的各個方面的影響，將從而為策劃和程式 部門的改進提供參考
3） 對已上的功能模組總結
遊戲開發至今，各種功能，模組上線很多，應該對目前上的功能模組進行乙個跟蹤，以確定此
功能模組更新以後，是否已經達到了設計時的效果，是否應該調整和改進。應該有乙個短期和長
期的資料來證明和確認這一模組的效果。
4） 重視玩家體驗調查
遊戲最終的使用者是玩家，所以玩家的體驗和表現才是決定遊戲活力和生命的關鍵，雖然玩家直
接的反饋都可能是虛假和片面的，但更應該從中辨明厲害，聽到真實的資訊反饋，在遊戲性和
商業性的平衡中謀求利益最大化。
為使工作更出色，需要提供的支援或幫助。
1） 團隊合作建設的指導
新的工作要求需要有更多的工作放在協調客戶端各人員工作上，需要的不僅僅是能力還有技巧，
客戶端人員雖少，卻各司其職，不可或缺，希望公司在團隊合作建設上給與更多的指導和支援。
FQ也是開發人員的乙個技能
在 技術這十年 書中看到一段文字談到，前端web開發的過程中最值得參考的一些資料時，提到了yahoo,google,facebook，這些都是引領了技術潮流的公司，其中開源的內容和技術非常的多，如 yui hadoop 等等。而這三個公司其中兩個的 基本是無法訪問的，因此如果需要了解這些知識需要fq...
web開發人員必備的提高開發水平的20個參考手冊
提高web開發的乙個有效方法是總結檢視api，好的程式設計師往往都注重這點，因此開發出來的專案往往能夠節省時間，效率高，經常在開發當中，我們可能遇到某個問題然後卡住了，這時候往往是經驗不足造成的，因此高質量的參考手冊對於開發尤為重要 今天，我們要為web開發人員共享一些手冊。這些手冊，有助於使您的w...
怎樣做乙個讓領導和開發人員認可的測試人員
根據測試經驗，個人理解！自己在測試這個行業多少也呆了近3年了的，在這3年中也接觸了不少的測試專案，所以在測試過程中也遇到了不少的測試插曲，直到今天總算靜下心來做個自我總結，也給測試同行們一起 我們測試人員在測試專案過程中與不同的人員的事情處理能力。在國內的測試人員在it中現在也還是處於不是很主要的地...