上一节：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这类以打包服务为卖点的平台也更有机会。
