后端技术 by Tim Yang

在互联网系统中，开发效率与系统稳定性与产品成败非常相关。开发效率在一定程度反映了团队的执行力，快速开发能力带来了产品的竞争优势。系统稳定性（包括安全及性能等）则是产品的后防线，稍有失误则会给产品带来很大伤害。因此开发效率与系统稳定性是衡量互联网系统开发成熟度最重要的两个指标。

在软件开发周期不同阶段，这两者如何控制？

在需求阶段，对开发效率的影响常见的是沟通理解偏差带来的技术风险，之外最常见的还有需求变更的风险。后者大多是来自市场环境的变化作出调整，技术主管更多的是积极心态去应对。但对前者沟通理解偏差导致效率问题也不罕见，更值得警惕。

在技术设计阶段最大的风险是技术方案，找个无需多讲，考验团队的架构能力以及对当前系统的驾驭程度。

开发阶段最大的风险是单元测试不到位或缺失。很多号称“敏捷”型项目依赖在线上测试及修改，当模块增多后，这样代码健壮性就会变得比较脆弱，不少团队也会越走越慢。

Review阶段风险是简洁性及性能。除了压力测试能达标之外，警惕那些不易懂的代码，这些代码将来会成为事故多发地带。

部署阶段最大的风险是上线计划把控，上线过程中操作错误的情况并不罕见，如去年Amazon EC2的故障就是由于操作失误造成。

从宏观看来，技术方案的风险最大，由于模块很多，具有丰富经验的高手不可能参与每一个环节，这就会出现木桶的短板效应，架构师认为不重要的地方总是会出问题。给用户体验造成极大伤害。

另外还有团队文化的风险。大部分团队很难形成书面交流的习惯。口头沟通需求、讨论方案对创业团队非常适合。在团队变大之后，这样的习惯会造成信息流动障碍，可能会给工作效率带来更多负面问题。同时大部分团队也对流程、模板、规范缺乏了解与重视，过多依赖参与人的内部驱动力及能力，无法依靠制度与流程来取胜。

最近在微博上提到了每周五进行一次内部的技术交流，方法也在不断的改进中，目前情况分享如下。希望也能听到一些更好的建议。

内容选取

大部分都是接近工作的，比如应用层如何访问cache及db、当前项目的重构或某个复杂的算法等。比如一个重构的话题让大家找出项目中目前不合理的若干问题，并分析这些问题存在的历史原因。然后大家分别发表自己认为合适的解决方案并进行讨论。

可以取得的成效

• 团队成员取长补短，获得更全面的技术
• 分享经验，避免成员步入已知的雷区
• 提高分析技术问题的能力
• 认识不足，找到自己需要提高的方向
• 达成团队更多共识，比如什么是好的做法什么是不推荐的做法

后续主题

以后可以进一步考虑的讨论主题，最大的原则是考虑跟近期项目有相关性，比如

• 互联网应用合适的压力测试方式
• profiler 系统性能分析，热点调用的主要消耗点并提出解决方案。
• 工具介绍，可以提高效率或者对工作有帮助
• 某个算法，如粉丝排序

与code review的区别

code review关注代码细节, 团队讨论更关注宏观抽象层面的问题，但部分时候团队讨论也进行一些有代表意义的code改进。

与主题演讲区别

倾向于圆桌式的讨论，需要大家参与的开放式问题。以前也尝试过主题式的，但是由于团队内的主题演讲空间有限，演讲者可能要先精通某个领域才适合讲，如果每周一轮不太可行，比如Facebook Engineering tech talks也是精英演讲的方式，结果也不是非常活跃。因此每周一次更合适讨论一些跟工作相关未达成共识的话题，这样更敏捷，也更容易给参与者带来成效。

-EOF-

广告：我们团队招收各层次技术人才，包括Java后端工程师，数据架构师(MySQL)，PHP工程师, 数据挖掘工程师(如精通Hadoop)等，工作地点是北京，有兴趣可以直接给我邮件。

上次提到的Web 2.0技术沙龙已经与CSDN顺利举行了第一期，由于之前报名的已经非常多，就未在博客上宣传了，第一期活动今天已经结束。