作為項目後端工程師，本職的開發工作在6月7日前已經基本結束了。

小組本預計在6月7日發布Alpha版本，但6月7日當天小組一位同學在Git操作中出現了網絡問題，前端代碼有非常大一部分遭到了不可逆轉的覆蓋，因此當天發布的計劃也就此破產。而在重新編寫這部分前端代碼後，前端又出現了各種各樣千奇百怪的BUG。至今我們的項目仍在前端Debug中，且剩余了一些對於用戶使用版來說不應該存在的瑕疵（比如需要控制臺操作），這讓我們深感惶恐。

後端

編寫後端代碼的過程中，我發現技術模型和代碼架構決定了代碼實現的難易程度和可維護程度。一個好的技術模型可能比較難以理解，但理解之後實現起來則會越來越容易。例如本次項目的後端God模塊中用到的synchronize、notifyAll的解決並發問題的方法以及前後端交互的request方法。在編寫之前我花了大量的時間學習這兩個方法的原理，但實際編寫代碼時發現一旦了解之後實現起來並不需要繁復和晦澀的代碼操作。

而代碼架構則保證了代碼的可維護性。在編寫前後端交互模塊中，常常設計到功能和模塊的合並、拓展以及接口的改變，而後端良好的代碼架構則使God能夠靈活地根據前端的需求進行局部的修改而不需要大規模重構。

前端

6月份其實前端工作並不重，而在配合前端進行整體測試的過程中，我深刻體會到了前端工作的艱難。

前端代碼量大，而且網頁編寫不能像後端一樣容易地定位錯誤，所有的Bug都需要通過人工來尋找，大大增加了前端工程師們的工作量。我的前端工程師室友多次出現一下午五六小時花在尋找一個小錯誤上面的情況。

此期間我也適當參加了前端的一部分debug工作。我認為要解決或者說是預防以上的問題，一是需要前端工程師具有非常良好的代碼習慣，包括命名風格，縮進風格和代碼架構的設計，良好的習慣不僅能使代碼查錯的難度降低，本身也可以減少許多錯誤的發生，特別是在使用開源框架和html等註重“格式”的工具時；二是可以采用結對編程的方式，前端工作中的細節問題比後端更加難以發現，結對編程對效率有很大的提升。

在工作中我曾經解決困擾某位前端同學數小時的問題，而這個問題又是由代碼習慣不好帶來的，因此我對以上兩點深有體會。

6月開發心得