• Feeds

  • Archive for January, 2012


    程序员的工作环境与效率

    很赞同《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电脑椅
    • 陈旧的办公环境会让面试者或者来访客户印象不佳,办公环境最好有定期维护保养并适当淘汰旧的设备。发暗的地毯、电脑椅上擦不掉的污渍,偏小的电脑屏幕、油光发亮的键盘都会让求职者印象不佳。
    • 有合适的参考图书库,可以找到常用资料
    • 有合适的咖啡、碳酸饮料、零食

    有故障,毋宁死

    —谈系统故障及软件质量

    如果你是一个7×24小时在线服务的整体(或模块)的技术或系统负责人,你的大部分生活会如游走钢丝。

    程序会出bug、资源会出故障、发布会操作错误、测试会有疏漏、安全会出漏洞、网络会有波动、服务器会突然坏掉。当产品的需求日益增多,判随工程师团队会日益增大,一个软件项目或功能从开发到上线的完成,都不可能由一人或者几个核心工程师去做,需要由不同背景、不同能力及做事风格的的开发、测试、工程师配合完成。当任一环节问题(包括有不少并非你直接可控范围之内的问题)未及时发现并带到线上之后,最终的责任会落在你的肩上。每当问题一出,你会感受到各方面的压力,有技术的缺陷、工作的失职、流程及规范执行方面的欠缺的问题;同时也会来自组织内外对你能力及人品等方面的质疑的声音。当发生问题后,你可能会独处一隅,沉浸在未能把事情做好的懊悔中。

    尽管平时付出了很多辛勤与努力,在业界普遍处于KPI焦虑的环境中,技术作为底层支撑部门,出现的各种问题通常是显而易见的,不足的问题通常会被放大。

    因此,你经常面临的艰难的选择是,quality, or death.

    传统工作生产中,有标准化的流程及规范来提高质量、降低故障。比如六西格玛(Six Sigma)可以降低产品瑕疵率。他们有成熟的规范与制度,有熟悉制度执行的专业人员,有提供咨询服务且具有丰富经验执行的咨询公司,企业员工及业务负责人只需要按步就班,就可以把问题做得相对到位。但在互联网在线服务这种不规范的软件系统中,有没有类似的标准化流程来指导生产呢?大部分团队需要从头到尾摸索一遍,在交足学费后才能得到一套并不完善的流程及制度?

    发布前流程

    设计及架构,是否在开发的特性进行设计上的tradeoff?
    风险及依赖,开发计划中充分考虑风险及项目依赖因素?
    代码是否经过足够的review?
    上线计划及风险因素是否考虑详尽?比如是否需要灰度发布?上线后检查及测试措施是否到位?是否有回滚方案,回滚是否会产生脏数据?

    当故障发生时

    是否有充足渠道及时发现问题?以免小问题变成大问题?
    收到问题后是否有合适方式(如日志及工具)快速定位并确认问题?有时候一些用户反馈的些问题并不好测试及重现。

    处理问题

    是否有现成的问题处理预案?
    对于新功能是否有回滚处理方法,回滚后是否存在脏数据需要修复?

    总结问题

    问题的根源是什么?在技术上、流程上、风险防范上各有什么可以马上执行的行动计划?

    非技术因素

    在很多企业中,容易把软件质量上发生的各种问题归结到单一的技术因素。但是,如果没有非技术体系的支持,一个团队不可能做到完善的高质量。

    研发流程及质量改进在你企业规划中的权重是怎样?年度规划中除了业务目标、竞争环境、市场份额、产品策略之外,研发体系改进是否有一席之地?

    在功能需求及产品设计阶段,是否充分考虑了技术风险及人力资源因素?是否会突然启动当前团队并不能支撑的项目?

    在开发阶段,开发计划是否符合软件开发规律?开发计划是根据项目压力制定,还是从定好的交付日期来倒推开发时间表?

    安全及优化,是否有专门的人力及团队?开发工程师需要面临日常的开发任务,突然被用户发现之前开发的模块存在安全问题,修复完之后发现又带出了另外一个bug?

    国内大部分产品面临市场及竞争对手的压力非常大,在相对恶劣的环境下,研发技术建设大多只考虑短期收益。如果期望研发体系做到零故障或者可控的故障(比如six sigma中的99.99966%),需要长时间的体系建设与积累,包括整个企业的工作流程,同时也需要在技术基础研发上投入更多的精力。