多解决些问题,少谈些框架和流程
大概我剛剛畢業那會,是常常喜歡在群里和網友談論框架的,尤其是游戲服務器的框架設計,比如網關啦,邏輯服務器啦,地圖服務器啦,登陸服務器啦等等,巴拉巴拉一大堆;我那會大概是剛剛接觸游戲開發,剛剛明白了一條消息是如何從客戶端,經歷不同的進程傳遞到服務器的,亦或是剛剛聽一個或者兩個人分享了關于游戲開發框架的介紹;所以便開始在群里夸夸其談了。
也是趁著熱乎勁,在博客園上分享了兩三篇關于游戲服務器的文章(現在再看真是漏洞百出,避重就輕),得到很多人的點贊和評論,開始以為自己是游戲服務器開發屆的大拿了!
這大概是年輕的我,在那個時候,一些不成熟的想法和做法了。
在工作幾年之后,犯了很多錯誤,補了很多坑之后,漸漸發現研究解決問題是極困難的;高談框架流程是極容易的事。談論框架是阿貓阿狗都能做的,比如剛畢業時候的我也可以談論游戲服務器框架,然而那個時候的我卻解決不了比如斷線重連的問題,比如多負載的問題等等。
因為一些原因,我短暫離開過公司一段時間;期間公司老板招聘了一個技術經理接替我的位置,當然沒有過多久便離開了,帶著一頓抱怨(私下里和同事抱怨公司的各種問題)和謙虛自責(和離職申請上說自己無法勝任工作)離開了。
我后來重回公司,本來對這位和我并沒有交集的技術經理沒有什么意見。但是當我重新接手他的工作的時候,發現他并沒有解決哪怕一個問題,卻留下了一堆對公司流程和代碼框架的吐槽和無用的文檔。我想,這是不是有點避重就輕,是不是懶,是不是靠著吐槽或者對框架和公司的不屑一顧,來掩飾自己解決不了問題的能力。
框架和流程,一般是那個時候的項目經理技術經理,根據那個時候的技術人員的配備,公司積攢的項目,和當時的業務需求,所做的解決問題的思路體現。當然隨著公司的發展,業務需求的變化,人員的升級,框架和流程也會跟著做微調,但是很少做大的變動,一時人力和工期的緊張,而是做大的調整需要投入太多的資源,這個恐怕是普通公司所無法承擔的。
忽然來一個新的技術經理,接手了這些業務,不去試著解決現在的問題,也不去深入代碼和數據庫設計;便先來吐槽框架設計的不夠時髦,文檔更新的不及時,公司的開發流程不完善等等。這不是懶,不是能力差,又是什么呢?
當然框架也是他們庇護傘。你比如,
某個bug解決不了,那一定是框架設計問題,導致這個問題沒有辦法解決;想要徹底解決這個bug,框架推翻,代碼重寫,項目從來!
總之所有的問題都是框架引起的,和他們絕無想干的,想要他來解決問題,得按照他們的意思,把項目或者產品推翻從新來過才行。
當然也絕不是說不談論框架和流程,良好的框架設計和流程對于項目或者產品的發展絕對是有好處的。框架設計和流程也不是一成不變的,也會隨著業務變化,但是一般不會是巨變,比如推翻重來的那種變化;而是在兼容之前的業務基礎上,漸漸變化,讓產品項目有個適應過程,也讓圍繞這個框架的開發人員有個適應過程。
轉載于:https://www.cnblogs.com/archy_yu/p/7275733.html
總結
以上是生活随笔為你收集整理的多解决些问题,少谈些框架和流程的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 访谈:摩尔定律后时代,看13位行业专家如
- 下一篇: uva140 Bandwidth