從重構到重寫

從重構到重寫

1 由來

公司在４月份的時候一個團隊總體離職(我最怕這個)，他們的服務器代碼交接是我組長去作的。因爲新項目要給客戶部署，因此咱們須要熟悉上個團隊的代碼。以前的代碼是用java寫的,用了比較多的框架，而目前接手的組長和我對於java都不是很熟悉。因此擺在咱們面前的有兩條路：
1.熟悉Java代碼、相關的框架以及開發工具，繼續使用java開發。
2.根據業務流程和目前的java代碼以及文檔，採用C++重寫。
領導決定採用方案２，所以重構和完善變成了重寫。

2 開始重寫

2.1 熟悉文檔

咱們最開始的工做是閱讀留下來的文檔，主要的閱讀部分是接口文檔。接口文檔基本描述了各個模塊交互的消息定義、字段含義以及交互流程。我跟組長也把目前的業務流程過了一遍，就開始了代碼編寫的工做。

2.2 代碼編寫

咱們的C++代碼的網絡庫採用的是asio，沒有boost依賴。以前的項目都是採用這個庫，因此這部分基本沒有怎麼花費時間。接下來就是編寫對每一條消息的處理了，接口文檔中沒有對這部分的業務流程進行較爲詳細的描述，也沒有對應的流程圖之類，因此只能一邊寫，一邊閱讀java代碼。

* 咱們是翻譯

由於對java框架不熟悉，剛剛開始的時候，每每須要很久才能找到消息處理的地方。後來就是根據java代碼，編寫對應的c++處理流程。在這個過程當中對於我來講比較難的部分就是不要有處理流程的遺漏，這個部分在組長建議下，採用了一步一步來對比的方式，過程很痛苦，效果還不錯。

　* 誰騙了咱們

究竟是代碼在說謊，仍是文檔在騙人。
　　　　　　　　　　　　　　　－－－昊哥

這個過程當中比較鬱悶的事情就是代碼和文檔的描述不一致，而只有等測試的時候才發現這個問題，原來昊哥有先見之明。記得在知乎上看到＠左耳朵耗子　說的文檔描述了Why，而代碼描述了How，因此咱們作的事情大約就是How(java)---->Why----->How(c++)。

2.3 代碼測試

祝賀咱們，終於編寫完成了其中的一個服務程序，能夠進行測試了。在收發短信的測試過程當中,發現因爲短信的消息定義不一致，致使每次發送的時間戳相同。客戶端在收到短信消息之後，會檢查時間戳，相同的不予以顯示，所以每次只看到了一條。這個也是過了很久才發現，也說明了熟悉業務的重要性。

　3.寫在最後

經歷了一個半月的工做，終於完成了初步知足功能的程序，也是時候進行簡單的總結了。

3.1 編程語言是相通的

學過《編譯原理》以後，以爲本身瞭解了程序編譯的過程，特別是自學了號稱最難學的c++以後，就認爲新的編程語言不在話下。接手這個開發任務半個月以後，才知道真的是too young,to naive。java的代碼看起來雲裏霧裏的，配置文件的對應關係，函數的調用流程...分分鐘幹翻我。因此仍是Good good study,day day up吧。

3.2 技術棧的差異很大

每個框架都在發明屬於本身的語言。

就拿作Web開發舉例吧。

編程語言	Web框架
java	Structs、Spring、Hibernate、SpringMVC
Python	Django、Flask
Php	Laravel、Phalcon、Symfony2
C	CGI,apache模塊
c++	asio,muduo...

編程語言多，對應的框架多，仍是能夠理解的。可是每種框架的邏輯相差很大，致使的問題就是是你在換一種編程語言的同時，幾乎全部的那個編程語言的框架的知識都被替換掉了，因此不能輕易的轉換編程語言。

文章的最後，感謝侯俊傑老師《深刻淺出MFC》帶我走過了學習了MFC的最開始的時光，讓我在使用這個框架的時候有跡可循。