”我熱愛的是做遊戲，相對於玩遊戲，我知道這兩者的差別 …“
這，是我來北京找工作，面試時自我介紹的開頭。
不知不覺，已經工作五年，經歷了三家公司，做過五六個項目，一步步，算是摸爬滾打的過來了。
聊聊過去，聊聊自己。
啓蒙
上大學前，並沒有接觸過編程。
僅有的經驗只是金山打字通的打字練習、做PPT，管管教室電腦（就是開關機）；噢，當然還有打遊戲。
大一初識C++，經典的譚浩強老師的 《C++程序設計(第二版)》，拿着忘了從哪蹭的100道經典C++練習題，一頓猛敲。
大二，就拉了個團隊去做個遊戲，學了點C++的皮毛，就準備擼起袖子大幹一場，正好有個齊魯軟件大賽，正好有個手機遊戲項目，正好就拉了幾個人，一個暑假都在學校奮鬥，還好，沒有半途而廢，算是一個完整的遊戲吧？。。
後來，加入仰慕已久的ACM實驗室，開始擼題。
後來，沒有考研，決定就業。
…
感悟
遊戲開發
從第一份工作到現在一直是在做手機遊戲，一直用的是Cocos2d引擎來開發，有接觸瞭解，也做過一些Creator、Unity的Demo，但真正工業級的項目沒有碰過。
在我所經歷過的各家公司，也各有特色與偏重，沒有同質性的公司。
我目前的理解，做遊戲（僅客戶端而論），可以先大概分爲兩部分：
- 遊戲；每一行代碼都能在遊戲中體現，爲遊戲內容品質服務。
- 基礎組件
- 中間件
- 業務功能
- 產品；項目從立項到上線，所額外負責的工作。
- 版本控制
- 打包、SDK接入
- 跨平臺擴展
- 更新機制
- 遊戲優化
- 統計反饋
- 測試支持
遊戲
遊戲開發中，所做的每個改動，都可以在遊戲中直接表現出來。
我把遊戲分爲三個部分，各部分所重視的角度不同：
- 基礎組件；基礎組成部分，一般涉及到自研底層代碼及引擎底層代碼，相對重視效率與性能。
- 中間件；爲業務功能研發做中間轉接口，將基礎組件拼接組裝或封裝調整，相對重視通用性及便攜性。
- 業務功能；實現各種需求，直面用戶，相對重視靈活性。
在開發的時候，明確並瞭解所開發的模塊屬於哪個部分，從而知曉它的重點偏向。
比如，開發業務功能，更重視靈活性，多與需求方溝通，瞭解他們的本意，不要厭惡、恐懼變化，甚至要擁抱變化，以 “任它需求千萬變，不如我代碼靈活又簡便” 爲目標。
再比如，如果開發基礎組件，理論上，不應該爲了使用方便，而去犧牲它的執行效率。
產品
這部分可能跟遊戲的實際開發無關，但是卻是完整的產品必經之路。
這些部分或許與遊戲的品質等無直接相關，但是會直接影響團隊的研發效率。就如同產品與包裝的關係，包裝不代表產品品質，但是好的包裝亦能影響用戶心中的價值。要不然，月餅、白酒的包裝會越來越華麗呢？
這部分的特點是 簡單繁瑣 、 涉及廣度大 、一次就好。
- 簡單繁瑣；很多簡單且繁瑣的事情，相對於技術可能更考究細心與耐心。
- 涉及廣度大；一般涉及的範圍很大，雖不至於天文地理，但也基本和項目的開發截然不同。
- 一次就好；基本實現一次就好，不需要頻繁迭代維護，甚至不維護。
這些特點，導致這部分的內容，更像一個苦差事。但隨着各種自動化工具、集成工具的發展，完全可以把這些內容腳本化，進而可視化、自動化，慢慢的就會找到這部分的樂趣，能把一堆繁瑣的東西理的井井有條，還是很有成就感的。
有一點要謹記，做好文檔，做好規範。
軟技能
很多行業慢慢由增量時代轉入存量時代，做開發亦是如此。
由於模塊拆分的越來越細，第三方的服務越來越多廣泛且專業，導致開發一個產品的門檻越來越低。
不能再像以前那樣，悶頭只鑽研技術，而忽視軟技能的發展。我不否認依舊有很多硬靠技術喫飯的人，但我知道，我不是。
技術&軟技能，就像一塊木板的長和寬；最終拼的是面積，而不是單純的長或單純的寬。但不要因噎廢食，過於注重軟技能而忽視技術；要做的是以技術爲基礎核心，同時也注重軟技能的發展。
溝通
溝通是一門很大的學問。
小的來說，溝通可以簡單分爲：
- 向上溝通
- 向上級彙報
- 向下溝通
- 向下級安排任務
- 跨界溝通
- 向其他部門諮詢或請求援助
其實，不僅僅是說話，所寫的文檔、代碼等，也都可以算是溝通的一部分。
溝通的目標是讓別人理解你的觀點，或者是理解別人所表達的內容。無論哪一個方面，都需要換位思考，並且有事直問，不要妄加揣測。
主人翁
全心全意去做當前所做的項目。（我可沒說把公司當成自己的家。不一樣嗎？你品，你細品！)
不要只做自己該做的，剩下的高高掛起。
原因如下：
- 早晚都要自己帶團隊做產品，與其到時抓破頭皮，不如早做準備。
- 看的越多越仔細，會發現一些不曾注意到的細節，都是知識，都是財富。
- 有時候，編程也是門經驗學科，有很多坑早晚都要踩過一遍就知道，踩得越晚，坑越深。
- 給上級一個讓你晉升的理由。
在開始，大家都是消費者，但可以慢慢成爲一名生產者，產出對團隊有利，對自己又何嘗不是。
一方的利益獲得不一定伴隨着另一方的利益損失，世界上有很多多贏的事情，只要利益的獲得滿足自己的預期即可。
體會一句話：你可能血賺，但我絕對不虧。
一個咖啡杯的故事
真人真事，在一個早上，我去便利蜂買杯咖啡，它們就是那種自助咖啡機，排在我前面的人，並沒有放置咖啡杯，就開始掃碼結算，這時我可以
- 提醒他，讓他先放杯子。
- 不提醒他，讓他自生自滅。
選擇不提醒，最好的結果是，機器檢測到沒有放咖啡杯，然後提示放咖啡杯；最壞的結果是，機器直接出咖啡，客人手忙腳亂拿咖啡杯去硬放，燙傷自己，然後…。
選擇提醒，就一句話的事情，可以避免很多事情；即使對我自己而言，也節省了我的時間，否則按最壞打算，我的這杯咖啡，什麼時候能拿到呢。
其實，這個現象就跟團隊內的合作溝通一樣，很多東西提前通知，做好預備，往往一句話的事情，可以其他人很多的彎路，對整個項目而言，必然有利而無害的。
方向
工作這些年，早期，基本花了很多的時間花在摸索上，更多的關注在如何做一個完整的項目，也就是俗話中的深度和廣度中的廣度。
現在，對這一行有了大概的認知與理解，更需要的是去進階一些深一層的東西。就像之前的策略 以技術爲主，軟技能爲輔的發展一樣，在技術中也要找到一個專精領域，再以其他領域爲輔去進行進一步的發展。
然後，技術上很多東西是相同的，沒有必要把自己侷限於某個角色，在不同的角度思考問題，會發現不同的內容。
最後，依舊是那句話，屁股決定腦袋。所在的位置，利益訴求，會影響信息、判斷與決定，每個人的閱歷、想法不盡相同，不需要逼迫着所有人 思想的統一、行爲的統一。
準則
專業的事情交給專業的人，簡單繁瑣的事情交給腳本，留出時間做重要且核心的事。
目標
不做總線，做一個被自己替代的人。
總線，是必不可少的組件；它的阻塞會導致系統無法運行。
但有的時候，有些總線就沒必要存在。
一個例子：
之前在生成 Android包及熱更的時候，必須由開發來執行。
大概流程是這樣的：
- A想要包測試內容
- 告知開發出包
- 開發出包完成，交給A
這樣有諸多弊端：
- 出包占用開發電腦資源，影響開發原有功能開發
- 由於出包不便，必然會減少出包測試的請求，整體上講對項目不利
- 期間有多個交接口，無法查進度，隱性所需時間拉長。（比如A告知開發出包，開發是否立馬去出包，或者忘記出包等）
- 在忙碌的時候，手抖導致出包錯誤，重新出包
- 等等
這個流程中，開發就是總線，但是這個總線是必要的嗎？顯然不是。
於是，採用一些方法去把總線替換掉：
- 將出包相關腳本化、自動化
- 使用Jenkins實現接口暴露及工作空間共享
這樣，出包的流程變爲：
- A想要包測試內容，登錄內網jenkins地址，根據需求出包
- jenkins出包
- A從jenkins空間中拿包
這樣，開發從這個流程脫離出來，並且對於A有更多的配置選項可以配置，更爲便捷，同時，出包進度也可視化，更有利於減少隱性時間消耗。
當然，這只是簡單的一步，爲了讓它更加可靠且易用，必然要經歷大量測試並且有一些預警機制，每隔一段時間進行使用者的反饋來擴展功能。
這只是簡單的關於總線的例子，其實很多東西，都是表面上的總線，就如同那句話：
世界正在變得越來越自動化。因此我認爲，並非每個人都需要學習編程，而是每個人都需要學習和理解如何實現自動化。—— 《Don’t Learn to Code — Learn to Automate》
未來
未來，誰都不知道會怎麼樣。
能做的就是總結過去經驗，把握當下。
確定長目標與短目標，以一年或關鍵時間點爲期，進行總結，看是否在既定的路上前進。
重視並珍惜每一個機會，每一個項目，只有在總結的時候纔去考慮收益的事，剩下的期間全心全意的去做事。
多想多討論多實踐多總結，步入一個良性的循環。
然後，多讀書，保持健康。
引用內容：