距離華為無線第七屆編碼大賽結束已經快一個月了，盡管心中一直想着要好好總結一下，但之前由於其他一些原因一直沒有總結，今天趁着要開這個總結會議的原因，理一理，只為下一次做的更好。
在華為無線第七屆編碼大賽之前一個月左右的樣子，我同時也參加了華為成研所的編碼比賽，結果就不提了。面對高手如雲的華為，當初也只是抱着試試水的態度去體驗了一把而已，得到那樣的成績也不意外，今天就不在這里多廢話了……
在本次比賽中，深深的意識了以下幾個方面的問題，現總結如下：
團隊方面：
做為團隊的領頭，我是從以下幾個方面去做的工作：
一、要對整個開發需求了如指掌，了解比賽的每一個細節。作為團隊的領隊，如果沒有了解盡可能詳細的需求，那么比賽的進度怎么安排，比賽的任務怎么分配，你將無從下手。
比賽時間為三天我的概要計划如下：
- 第一天詳讀任務書，明白開發需求，完成程序的消息解析發送，人物的簡單控制。這一點我們當初在做的時候忽略了賽制中的規則，自己在那里想當然。在每次比賽中有兩個子場比賽，每回合都有積分，官方的規則是兩場分數之和誰最高，誰就贏了。結果我們的想當然理解是，只要我能夠把對手全干掉我就贏了，結果不然。雖然這一點規則對我們整體的開發沒多大影響，但從側面就反應出一個問題：我們沒有真正的熟悉需求。第一天的開發工作，協調工作我個人覺得都做的很好，大家輕松加愉快的都完成了，當然這一天晚上我們都沒有熬夜了。
- 第二天完成基本策略的開發，發布基礎版。第二天就是完成基本策略的開發，怎么去搶箱子，怎么去圍殺對手。在第二天晚上經過幾番優化我們的基礎班發布出來了。心中十分歡喜。
- 第三天完成加強版的開發，發布加強版。由於在線對戰平台的幫助，我們也在不斷的用我們的程序去挑戰其他參賽隊，不斷的完善我們的代碼。在完善的過程中，代碼的維護就顯得比較費力，主要就體現在前期框架的設計上不夠完美。
二、要熟悉每一個隊員的能力。了解每一個隊員的能力，最擅長的技能，這樣才能夠把每一個成員的能力發揮到最大，做到勁往一處使，將團隊的能力發揮到極限。
鑒於我對我們團隊的另外兩個隊友的了解，以及他們自己的選擇，前期的任務分工主要就分為了三大部分：師兄負責整體的程序框架設計；發哥負責消息的解析，封裝，發送；我就負責程序入口的控制處理。后期在策略方面都是大家一起討論，一起協同分工完成。
三、規划整體的進度。在第一次的比賽中，這一點就沒有做好，如果做不好這一點，就會導致整體的比賽進度漫無目的，沒有一個開發周期的指定，大家就只能做到哪就在哪，想到哪就在哪，沒有一個目標，容易在開發周期中喪失目標的明確性。指定好了開發周期和項目進度，尤其在像比賽這樣周期短的開發任務中，做好這一點就顯的更加尤為重要了。
四、對開發周期中發現的問題風險進行評估，把握開發進度。
本次比賽中，問題風險評估主要中有兩個地方有問題：
- 風險的評估，由於隊友個人私事的原因，加之個人承載的開發過多，導致后期承載的風險過大，一個人承載了過多的責任，在后期就會承載更大的風險。
- 問題評估就是在復賽的時候，針對初賽的版本，我們修改了代碼，但是部分初賽的問題是修復了，但是又暴露出了很多以前初賽版本沒有的問題，最后只有通過自己挑戰自己的程序，選出最穩定的版本來作為復賽的參賽程序。可悲的是我們最后提交的還是初賽的版本來參加復賽，這也是我們最后失敗的最大原因。
五、參賽的程序應該本着穩中求勝的思想。
從第一次的比賽中中我們總結了，程序不一定要有多好的策略，最基本的要做好程序的健壯性。做火車頭游戲的時候就要保證永遠不掛掉；做炸彈人就要保證逃生策略是無敵的。只有在這樣的基礎上，我們在談其他的優化策略。在這點上也是我們這次成功的秘訣吧。
個人方面：
本次比賽中，我着實動手去寫的代碼不多。我主要負責了程序入口的研究，官方文檔的詳讀和環境的准備。官方提供的資料當中只有C/C++的入口demo，我就只能通過去查看官方提供的一個cpp demo文件來編寫java的入口程序設計。socket的創建於連接，socket消息的解析、幫助隊友解析來自服務端的json消息等。除此之外就是配合着后期遇到的一些問題的解決開發一些小的功能模塊。
1.代碼框架設計，接口定義很重要
作為一個合格的程序員，編碼不應該有什么問題（在我看來編碼就是把我們人類的思維固化成計算機能夠識別的有序代碼而已）。編碼只能從側面體現出你對這個工具的一個熟練程度，而不是開發的重點工作。就好比我們在做游戲的時候，如何移動一個畫面中的對象不是重點，重點應該放在怎么去移動（策略問題）。前期的分析與程序的架構設計，編寫出可靠、高效、靈活、易擴展、可復用的程序才是重中之重。在初級程序員中（也包括我）往往喜歡用計算機能夠理解的邏輯來描述和表達待解決的問題及具體的求解過程，這其實就是在用計算機理解的方式在思考，和面向過程的編程思想如出一轍，這樣的做法本身沒有錯，但這樣的思維卻使的我們的程序只能滿足眼下的需求，程序不容易維護，不容易擴展，更不容易復用，從而不能達到高質量代碼的要求，也不能做好后期開發質量的保證。和我們的面向對象思想更是南轅北轍了。
這里就有人會反駁了，面對如此開發周期短的需求來說，時間不是很寶貴么？我只需要按照比賽規則開發完程序不就完事了么？在實際的比賽過程中大家往往只是注重怎么快速的去縮短開發周期，想留更多的時間去想策略，想通過損失一定的代碼質量來換取策略上的思考時間。然而比賽不像平常的開發工作，開發完成以后，會有自動化的檢測工具，會有同事的代碼檢視。比賽中沒有這些東西，在時間上也不可能自己去設計這么一套東西來看護自己的代碼質量，這也能從側面反映出一個程序員的編程習慣。如果按照上面的開發完成以后，后期想做一些復雜的策略的時候，就顯的難上加難。這一點在后期的策略開發過程中就顯的很突出。
2.團隊協作
在團隊比賽中有一點我覺得很重要，雖然我時刻在告誡自己，但我也不知道自己到底做的好不好，這個只有和我一起並肩作戰的兄弟才知道，那就是：團隊協作的能力。團隊賽不比個人賽。個人賽中一個人只要整好了那就是直接的勝利，而團隊賽不然。在團隊賽中，除了要做好自己，還要服從整體；既要把握模塊的進度，也要注視總體的進展。針對同一個問題，不同的人有不同的想法，不同的思路，唯有做好隊友之間的協調把控，才能將眾想法中優秀的想法運用到我們的程序中。自己做完自己所承擔的模塊以后，不能一意孤行，需要從總體上一起去分析下一步怎么做，該怎么做，怎么做最好？領隊統一協調，這樣才能讓整個比賽進度健康向前推進。
寫在最后：
我們的隊名：我不是路人甲（取這個隊名有兩個原因：第一最近有一部電影叫做《我是路人甲》；第二就是我們真的不想就只是路人甲）
參賽成員：師兄、發哥和我三人組
開發語言：JAVA
初賽時間：三天
比賽游戲原型：泡泡堂
本次比賽是我人生當中參加的第二次比較大型正規的比賽，是一次成功又失敗的比賽。本次比賽總共有252個參賽隊伍，最終我們能夠拿到19名的成績，按道理來說已經十分不錯了，但是期間種種的原因導致我們心里都有一絲絲遺憾，未能將我們最大的能力發揮好。這一絲絲的遺憾都會成為我們下一次走的更遠的鋪路石，在哪里跌倒就在哪里站起來！
最后要感謝公司，感謝我們的客戶方華為提供這樣的平台來挑戰自己，讓我們在挫折中成長。最后也要感謝項目組以及客戶方領導對我們的關心和支持，尤其是我們項目老大，為我們比賽付出了很多。非常感謝！
轉載請注明出處：http://www.cnblogs.com/liushaofeng89/p/4830606.html
2015年09月22日 23:51:12@isoftstone