后端技术 by Tim Yang

很赞同《Joel on Software》中Bionic Office一文所说，办公环境需要比大部分员工的家中环境更舒适。否则老板只能招聘哪些还住在简陋公寓的员工，他们才有可能下班后情愿留在办公室继续工作。

我认为程序员的办公环境的几个条件

1、足够大的桌面空间

程序员的办公桌最好可以并排坐下2人，以便pair programming或者code review。在不离开座位的情况下，有足够空间用白板或者纸面展开讨论问题。协作的同事不必站在身后费力的越过肩膀来看屏幕上的内容。桌面可以放下2个显示器并可以随手拿到常用的参考资料及书籍，有合适的文件柜或壁柜存放归档的资料，避免桌面上堆满了各种打印的资料。

2、电脑环境

工作的机器有足够的内存，比如8G，这样并行打开复杂的workspace时候不需要关闭邮件或者浏览器软件，也避免在debug模式时硬盘在拼命swap以腾出空余内存。
办公环境有足够的带宽，访问Google的服务没有障碍。内部资源如测试服务器、邮件服务器、SVN访问要非常快。

3、座位距离

多人的team中尽量能让所有工位之间行走距离最短，避免坐在对面的两个员工需要绕一大圈才能到达对方电脑前。

4、其他环境

温度及空气状况，办公室不要过冷或者过热。空气质量清新，不要有明显噪音，比如来自空调、日光灯、服务器等噪音。

其他一些可选条件

• 程序员最好有两个显示器，或建议1台式机+1笔记本，可以极大提高开发效率
• 有合适的、方便更新的公告栏
• 有公共休闲区，比如一些游戏区域，方便互相交流，发散讨论
• Joel推崇的Aeron电脑椅
• 陈旧的办公环境会让面试者或者来访客户印象不佳，办公环境最好有定期维护保养并适当淘汰旧的设备。发暗的地毯、电脑椅上擦不掉的污渍，偏小的电脑屏幕、油光发亮的键盘都会让求职者印象不佳。
• 有合适的参考图书库，可以找到常用资料
• 有合适的咖啡、碳酸饮料、零食

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

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

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

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

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

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

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

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

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

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

内容选取

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

可以取得的成效

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

后续主题

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

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

与code review的区别

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

与主题演讲区别

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

-EOF-

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

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