上一節：4. 事 - 項目管理
物 - 技術管理
核心思想: 喜新厭舊
- 喜新（?Upgrade）：升級技術棧
- 厭舊（Migrate）：償還技術債務
喜新（Upgrade）：升級技術棧
從事信息技術的都知道摩爾定律，然而這個定律不止作用在芯片更新換代上，在編程領域也是可適用的，幾乎每年都有一些新編程語言、技術框架、系統架構的出現，其中一些有重大突破性的還能引起熱潮。對于技術團隊，其能掌握的技術棧就是其戰斗力，而今年掌握的很有可能第二年就變為過時，因此一個有活力的技術團隊是需要不斷吸收外界新鮮有活力的技術點，吸納融合入團隊技術棧，轉化為團隊的戰斗力。
然而新技術會不斷提出、舊技術會迅速過時，我們既不能被新技術牽著鼻子走又不能過于落伍。因此在選定技術棧時需要具備有前瞻性，不能被新熱的技術吸引分散精力，也又不能把團隊綁定到一些沒有生命力的技術上，這不是簡單的選擇題，需要經過探索、調研、實踐到最后掌握化為生產力。
厭舊（Migrate）：償還技術債務
在項目開發過程中，有時會根據當時的人、財、物及知識經驗限制等，對技術框架、架構選型做一些當時認為“最適合”的設計或選擇，但隨著時間推移，需求變更、經驗提升、新技術提出等，回過頭來會發現當時的“最佳實踐”已經不適合了，有的嚴重更會成為推進項目的負擔，這種情況我們稱之為“技術債務（technical debt）”。
欠債要還，沒有反思不會進步，因此要給團隊“還債”的時間，團隊才有進步。但這點在外包開發團隊中其實是很難徹底實踐，因為需要跟客戶解釋什么是“重構”，為什么要花時間去做一些沒有明顯輸出的工作；又得在盡量不影響工期的情況下，定下更“正確”的架構，這也很考驗架構能力。
所幸我們團隊是以Ruby/Rails框架為核心技術棧，Rails框架本身就是fullstack且推崇最佳實踐的框架，每年都有大版本升級，每次升級都會引入對提升開發效率、安全、代碼質量的理念和實踐。因此我們選擇了Rails，就相當于在底層框架中有一支專業的團隊不斷的在維護升級，這也是為什么國內外很多創業團隊喜歡選擇Rails作為開發框架的原因，可以讓產品開發者更多去關注業務實現，而不用太過操心底層框架的維護。
更重要的是，Ruby/Rails不止提供給我們快樂編程的體驗，還指導了我們做事情的方式方法、看問題的角度：The Rails Doctrine - Rails 信條
另外遇到一些本身就是做技術開發的客戶時，就會比較好溝通能得到認可，但這種優質客戶是隨機的、可遇不可求，更多情況是我們開發團隊自己要提高自己的迭代能力，在每次階段會議、項目總結時進行技術積累，把經驗知識應用到新的項目上。
上面說了那么多理論，下面說下怎么做。
具體做法
作為公司技術負責人，我進行技術管理主要看以下6個方面：
- 技術調研 - 探索新技術、調研工作上需要用的服務等，以保持技術團隊的先進性
- 技術實踐 - 有實踐過的技術才敢引入團隊中，不要做拍腦袋決策
- 技術培訓 - 得到認可的技術要推廣和普及給其他成員，提升團隊整體戰斗力
- 技術復用 - 提取出可復用的技術點，進一步提高團隊生產力
- 規范化 - 技術團隊應保持一致行事風格，以降低溝通、代碼維護、工具使用的成本
- 自動化 - 解放生產力，讓機器去做重復工作，人力去做突破性工作
具體實踐總結
以下是具體實踐過的一些調研報告（report）、培訓講稿（ppt）、規范文檔（doc）、知識庫（wiki）、內部開源項目（project）以及公開博客文章（blog post），涉及的內容其實很多我這里只列出一些比較有代表性的、在團隊內實踐分享過的內容：
- 技術調研
- report:[angularjs vs reactjs]
- report:[2016 Rails popular app servers]
- report:[chrome extension開發調研]
- report:[Crash Reporting Service]
- report:[React-Native Hot Update Services Research Report]
- report:[流行云主機調研報告]
- report:[國內外流行字體CDN調研]
- report:[QingCloud 調研]
- doc:[Beansmile 技術調研報告規范]
- 技術實踐
- project:[jpush-ionic-demo]
- project:[pushwoosh-example]
- project:[beansmileteam/react-components]
- 技術培訓
- ppt:[how to do model design]
- ppt:[toolbox-for-optimizing-rails-project]
- ppt:[rails項目中性能調優要注意什么]
- ppt:[rails-debug-tips 2016]
- ppt:[如何寫一份壓力測試報告] （如 「圖5-1」）
- ppt:[如何用rails開發一個任務管理的網站和移動app]
- 技術復用
- project:[bean-hub]
- project:[beansmile-quickstart]
- project:[beansmile-rails-composer]
- project:[beansmile-react-boilerplate]
- 規范化
- doc:[Beansmile styleguide(Beansmile代碼規范指南)]（如「圖5-2」）
- wiki:[Beansmile coding standard]
- wiki:[Code Review Tips] （如「圖3-8」，「圖3-9」）
- wiki:[Rules for committing]
- wiki:[trello + git開發流程規范]
- wiki:[how to write a rake task]
- doc:[Tech Stack Example]
- doc:[API design example]
- 自動化
- 自動化測試
- blog post:[RSpec 使用一周小結（上篇）]
- blog post:[RSpec 使用一周小結（下篇）——使用 FactoryGirl 準備測試數據]
- blog post:[rails集成測試學習總結]
- blog post:[rspec集成測試的總結]
- blog post:[簡介如何測試Rails應用]
- blog post:[壓力測試總結]
- 自動化部署
- wiki:[Deploy Project to Staging Using Capistrano on Ubuntu]
- DevOps - 持續集成
- wiki:[Setup GitLab CI]
- wiki:[Setup GitLab CI Runner]
- ChatOps - Slack+Lita
- 自動化測試
? 「圖5-1」如何寫一份壓力測試報告
? 「圖5-2」Beansmile代碼規范指南
重點說說自動化
自動化技術在技術團中對效率提升很重要，在前面的“團隊管理 - 開發自動化” 這節已經提到了：
我提倡善用工具最大程度做到自動化，這種思維是貫穿整個開發流程各個環節的。
如最普通的Terminal（終端shell），推薦使用帶交互的shell（如zsh/Fishshell）來輔助cli的操作，鼓勵善用alias來簡化重復的使用命令；
代碼開發時鼓勵使用支持自動完成的IDE、編輯器（如Sublime Text），鼓勵善用代碼snippet來減少重復編碼的操作；
代碼測試使用自動化測試（可配合guard或者livereload達到保存時自動跑相關測試）；
代碼提交使用自動化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代碼提交并發Merge request；
項目部署使用自動化部署工具（如Chef、Capistrano），做到一鍵部署；
使用CI（GitlabCI）進行自動化測試、自動構建、構建結果通知、自動部署、自動打包上傳app package，達到DevOps的自動化；
服務使用健康監控（如Monit，God），自動監測服務健康并自動重啟服務；
一句話就是盡量把重復的工作丟給機器去做，人力應該專注在機器解決不了的地方。
如「圖5-3」就是我們團隊日常開發中，從本地終端使用一行代碼發起MR（MergeRequest），code rewivew通過合并MR，觸發CI自動進行構建、測試、部署到通知Slack的過程
? 「圖5-3」auto CI/CD
另外我們開發的Chrome Extension項目，也做到了的DevOps貫通、自動化發布，流程如下：
- 開發在本地執行執行構建命令：
gulp release --bumpversion，自動更新 manifest.json中的版本號、自動做git commit、同時自動以版本號創建git tag - 往Gitlab發起MR，合并到develop分支后，CI會自動加上
--env staging為參數，應用上針對staging的配置，進行構建生成zip文件 - 把develop往master合并后，CI會自動加上
--env production為參數，應用上針對production的配置，進行構建生成zip文件 - 在CI上構建生成zip文件時，會自動加上一些stamp（包括extension version，git revision， env，datestamp），如“Trellohub-0.2.2[staging]@2016-12-06^0b89f89”
- zip文件生成完畢后，CI自動把zip文件上傳到Trello board對應環境的card中；發布為staging的，放入packages-for-staging card以便可以給QE進行QA；發布為production的，放入packages-for-production card以便給PM上架發布到Chrome Web Store
整個流程中只有第1、2步是需要人工參與（將來可優化成一步），其他步驟已全部通過CI實現自動化。
對于ios/android app構建發布，我也準備使用Appium做集成測試，使用Fastlane做自動化構建，配合Gitlab CI打通DevOps自動化。
自動化有助減少人工參與，提高效率的同時減少誤操作可能，技術團隊應大力推行。
小結
今年最大的變化莫過于前端圈的火熱和容器架構的盛行，層出不窮的概念、輔助的工具，新技術還沒來得及掌握轉眼已經變為淘汰，但這也意味著對技術的細分越來越專業，同時也意味IT項目的工程化越來越專業。這是挑戰也是機遇，項目越復雜、質量要求越高，對個人的要求也就越高，也意味著團隊作戰的作用越重要，這也正是PaaS/SaaS這類以打包服務為賣點的平臺也更有機會。
