多解決些問題，少談些框架和流程

大概我剛剛畢業那會，是經常喜歡在羣裏和網友談論框架的，尤爲是遊戲服務器的框架設計，好比網關啦，邏輯服務器啦，地圖服務器啦，登錄服務器啦等等，巴拉巴拉一大堆；我那會大概是剛剛接觸遊戲開發，剛剛明白了一條消息是如何從客戶端，經歷不一樣的進程傳遞到服務器的，亦或是剛剛聽一個或者兩我的分享了關於遊戲開發框架的介紹；因此便開始在羣裏誇誇其談了。

也是趁着熱乎勁，在博客園上分享了兩三篇關於遊戲服務器的文章(如今再看真是漏洞百出，拈輕怕重)，獲得不少人的點贊和評論，開始覺得本身是遊戲服務器開發屆的大拿了！

這大概是年輕的我，在那個時候，一些不成熟的想法和作法了。

在工做幾年以後，犯了不少錯誤，補了不少坑以後，漸漸發現研究解決問題是極困難的；高談框架流程是極容易的事。談論框架是阿貓阿狗都能作的，好比剛畢業時候的我也能夠談論遊戲服務器框架，然而那個時候的我卻解決不了好比斷線重連的問題，好比多負載的問題等等。

由於一些緣由，我短暫離開過公司一段時間；期間公司老闆招聘了一個技術經理接替個人位置，固然沒有過多久便離開了，帶着一頓抱怨(私下裏和同事抱怨公司的各類問題)和謙虛自責(和離職申請上說本身沒法勝任工做)離開了。

我後來重回公司，原本對這位和我並無交集的技術經理沒有什麼意見。可是當我從新接手他的工做的時候，發現他並無解決哪怕一個問題，卻留下了一堆對公司流程和代碼框架的吐槽和無用的文檔。我想，這是否是有點拈輕怕重，是否是懶，是否是靠着吐槽或者對框架和公司的不屑一顧，來掩飾本身解決不了問題的能力。

框架和流程，通常是那個時候的項目經理技術經理，根據那個時候的技術人員的配備，公司積攢的項目，和當時的業務需求，所作的解決問題的思路體現。固然隨着公司的發展，業務需求的變化，人員的升級，框架和流程也會跟着作微調，可是不多作大的變更，一時人力和工期的緊張，而是作大的調整須要投入太多的資源，這個恐怕是普通公司所沒法承擔的。

突然來一個新的技術經理，接手了這些業務，不去試着解決如今的問題，也不去深刻代碼和數據庫設計；便先來吐槽框架設計的不夠時髦，文檔更新的不及時，公司的開發流程不完善等等。這不是懶，不是能力差，又是什麼呢？

固然框架也是他們庇護傘。你好比，

某個bug解決不了，那必定是框架設計問題，致使這個問題沒有辦法解決；想要完全解決這個bug，框架推翻，代碼重寫，項目歷來！
總之全部的問題都是框架引發的，和他們絕無想幹的，想要他來解決問題，得按照他們的意思，把項目或者產品推翻重新來過才行。

固然也毫不是說不談論框架和流程，良好的框架設計和流程對於項目或者產品的發展絕對是有好處的。框架設計和流程也不是一成不變的，也會隨着業務變化，可是通常不會是鉅變，好比推翻重來的那種變化；而是在兼容以前的業務基礎上，漸漸變化，讓產品項目有個適應過程，也讓圍繞這個框架的開發人員有個適應過程。