一路走來，成長很多。。。

1.第一個月

來的時候，正巧是番茄1.2.5發布，熟悉了曉鴻的代碼，覺得只要負責好自己的那部分就可以了，一直沒有融入到大家的開發中。番茄開始PC端2.0的開發，本以為是從新的開始，作為副組的我，每天給大家分任務，但本身自己對系統不論是功能上，還是實現上，都很生疏，分的任務也不知道大概多久能完成，和詳銘合作主界面，但后來發現BD層基本沒有邏輯，所有的邏輯居然都在U層，后來，詳銘開發新的功能，我也從不主動關注，整個2.0，基本上沒有學到什么技術，更多像是適應項目組的環境，看大家都在忙什么，中間有一段時間，我覺得大家都比我厲害，作為副組的我也就不想擔什么，跟著大家走就好了，反正自己也帶領不好大家，因為技術和經驗上不足以帶領大家，所以一度很失望。

2.第二個月

計劃是新的人熟悉系統，學習資料，而舊的人學習新資料，準備手機端開發，由4月份的時候，再重構
結果開會的時候，李總的一個建議“快速迭代開發”，使得重構任務被提前，放到本月，手機端依舊是這個月在學習ionic,學習搭建框架，因為被分到重構，我沒有參與手機端的學習，想要管理手機端這邊，也覺得什么也管不上，畢竟自己看都沒有看，怎么知道人家看的快慢，好壞！所以在手機端的管理使不上勁。

第二月重構開發的時候，我有點2.0的感覺，感覺自己什么都不會，就帶著大家一起開發。自己不過是知道一些現有系統的整體框架，但關于細節自己都沒有經歷過！萬一我沒有負責過的部分在重構過程中出現問題，自己都不會解決，怎么辦，心里很發虛。
前面的10天，2.0上線，遇到問題我并沒有參與解決，因為出現的這些問題主要是別人負責的模塊，不會解決呀，對于這塊就沒有多管了。
后來真正開始重構，原型主界面用小谷和詳銘做好的，文檔參照之前的寫的，都不知道數據庫里是必須放建表語句得，代碼是復制粘貼2.0的代碼，看懂的基礎上修改。就是這樣完成的重構！

關于番茄加分加不上，和積分組的溝通。積分組幫忙找問題，問題是1.2.5版本和2.0版本record表番茄狀態的標識不同導致加不上分。

在給李總審核數據庫的過程中，和李總溝通數據遷移問題
在C/S系統中涉及版本更新，新的版本增加功能，必然會涉及數據庫會變動。
不論如何更新，要平緩過度，保證兩點
1.舊版本系統要依然可以使用
2.新版本系統是可以查看舊版本的數據
既然涉及數據庫的變動，新舊數據該怎么存放。
情況一：新舊表結構變化非常大，舊表很難適應新的表結構
這種情況下數據遷移的難度比較大，舊表繼續保留，這樣保證舊系統可以查看數據，新系統可以通過鏈接的方式查看到舊的數據，新產生的數據放到新表中，新系統中查看數據只調用新表
情況二：新舊表結構變化不大
這種情況可以考慮將舊的數據遷移到新表中，保證新系統中可以查看歷史數據。在舊系統無人使用時，將舊表撤掉，也可以讓舊系統查詢新表。
在B/S版本中，如果涉及版本更新，增加新功能導致數據庫字段更改，在前端界面上幾乎不存在差異，所以幾乎不存在版本更替問題，也就自然涉及不到數據遷移問題！

番茄2.0開發中

1.偉杰和云召上手非常快，他們在看代碼，理邏輯上上手非常快，在溝通上能一下子就明白任務具體是要干什么。有新的想法時會及時和我溝通，有時候比我想的都全面。上手速度讓我很震驚。遇到問題時，他們會自己先去解決，解決中遇到問題，會及時找寫代碼的人進行溝通，解決自己的問題，并對當時開發的人的邏輯問題指出。分配的任務由于及時的溝通（做到什么樣子，遇到問題的解決，做出來及時給組長看）讓我（組長）很有把控感，在分任務的時候，更加放心。
2.子潁的wcf服務，因為我不會，所以一直是大兵和東興在帶，我心里其實很不踏實，擔心后面會不會出問題，但子潁從看wcf視頻，到問題的解決，不主動尋求和借助他人的幫助，很好的解決問題，讓我明白在項目組中，還存在一種解決問題的辦法，就是集結別人的力量解決自己的問題，在這個過程中學習，收獲！
3.廣晗是要求不高，分好的任務做出來就可以了，不太主動的想去讓自己的功能更加吸人眼球。在代碼上，對于規范，優化上，沒有注入太多自己的想法。
4.思蓮和一開始的我很像，上手困難，看代碼不快，理解代碼不快，在寫代碼和代碼的積累上不夠；在遇到問題時，長時間的自己解決，不善于找人幫助，如果組長不問，不太主動去溝通自己這塊的進度和遇到的問題，在最終問題拖延發生后，比較感性，不能理性面對問題，解決問題；對項目上的事情缺乏興趣，僅僅當做任務完成，所以會覺得有壓力。
5.關于云召此次一個人跨越3個人的功能，修改代碼的螺絲釘精神，組長的我感謝有這樣的組員，不僅能很快很好的完成自己的代碼，“偷偷的去看別人的代碼”，在需要的時候主動承擔，解決問題。不管那塊有問題，只要他去，就很放心一定能解決出來！關于此次的設計界面讓我很滿意，自己能夠將不好的功能按照自己的想法做出來，做出來結果給我選擇！

關于此次重構我的問題

1.發現自己遇到軟件工程中的問題，邊開發，邊在改著需求
2.在整個開發過程中，沒有很好的把控任務的進度，有時候連我自己也會很隨意的玩
3.在開發上，很不專業，從數據庫命名，到文檔的內容，到代碼封裝抽象上，很多地方都不夠專業
4.遇到問題，不要著急去“責任到人”，而是帶領大家一起互相幫助解決問題，更過的是要幫助不會的人解決問題
5.關于此次任務一再的拖延
一開始沒有帶大家和之前的開發人員溝通，借鑒太少
開發過程中，總想著變動，導致反復修改（原型不確定，總覺得不完美）
自己比較貪玩，不夠專業在寫代碼，實現功能上（日報關注，寫日報太少）
對番茄2.1重構的預期很美好，但結果總是“好多沒做”

番茄的代碼走查

中間查了很多關于代碼走查內容
1.開發人員坐在一起，解釋邏輯思路，幫助開發人員主動發現問題，為后續優化提出建議
2.幫助大家規范，專業
3.讓項目組的人都能夠接觸到別人的功能，便于上手修改
4.代碼走查很必要

還存在很多可以做的東西，在PC端！

總結

以上是生活随笔為你收集整理的两个月番茄组长的收获总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。