一个纯正程序员的啰嗦
最近有一个项目做了一半不做了，准确地说是由于某些原因，项目需要别的团队来接手了，于是我想随便聊聊这个话题。我猜想，“项目做一半撒手”，这应该是一个很常见的现象，因为这样的事情无论大厂小厂，在软件的世界里不断上演。具体来说，有这样几种典型的情况：
无论哪一种，有一点 [……]阅读全文
几年前我曾经写过一点对于 “在家办公” 的思考，后来又写了一点，但是从来都没有想到过，长期的在家办公如今已经不是一个可选项，而是一个必选项了。
应该说，我从来都不是一个频繁在家办公的支持者，我是说，在家办公这样的互联网公司特有的 “福利” 当然是好的，但是 “频繁” 在家办公对于团队、项目，甚至个人职业成长等等各方面来说，都不是一件好事。我记得在刚加入亚马逊的时候，我听说亚马逊给了一位工程师这样一个 offer——允许一个月之内四分之三的时间远程办公。当时我觉得这件事情还是挺不可思议的，因为像曾经的 37signals 这样的小公司当然容易做到，但是长期和频繁地在家办公却不是大型互联网公司能玩得转的。
[……]阅读全文
曾经写过一点关于代码评审（code review）的文章，比如这篇和这篇，现在觉得关于它的认识又有了不少更新。软件工程的技术和实践分成两部分，一部分是和书本知识一致的，大约占一半，这部分基本上在大学里就可以学，自学只要方法得当、刻苦努力也可是途径；但是第二部分来自于实际团队、经验，内容通常无法从书本当中获得，而且难说对错，不同的人和不同的经历造就了不同的认识。代码评审就是第二部分颇具槽点，可以大加讨论的典型。
代码评审是展现个性和性格的途径
我本人特别反对一种颇为常见的观点，就是 “一个良好运作的项目，不同的人，应该写出一样的代码”。我非常理解这种观点的初衷，一个良好规范约束的团队中 [……]阅读全文
我在几年前写过一点对于在家办公的理解，经过最近几年的感受，时不时地需要在家办公，零零散散陆陆续续有了一些新的感受。
首先要明确的是，团队的支持是最重要的。需要一个宽松的团队氛围，能够获得足够的信任，这些都是软基础。如果同事和上司不信任，这件事情是不可能办成的。对于那些把员工视为不可靠、不安全因素的公司，在家办公也是难以实现的。
开发环境。以往我一个不愿意在家办公的重要原因是，我的开发环境都部署在 desktop 上面，从家里无论是通过 Microsoft Remote Desk 还是 NoMachine 之类的连接（我还试过一些别的持有图形界面连接的方式），都不够理想，一顿一顿的，写代码很难受 [……]阅读全文
还记得在 2008 年我做毕业设计的时候，自己心里有一个朦朦胧胧的概念，大概是说，要规范，制度上有标准，流程上有遵循。于是噼里啪啦整了软件工程十项文档，再加上一些辅助性文档就有了下面这个清单。我以为那样的全面会带来更好的评价，但是老师说，“太多了”，我很困惑，难道文档全面、综合，而且完备，这不好么？
在 Amazon 有一个大家都知道和反复自黑的事情。所有 team 都用 wiki 来记录和维护项目、产品有关的事情，但是绝大多数 wiki 的内容都是过时的和不准确的。有几次和其他互联网公司的朋友讨论过这个话题，大家都付诸呵呵一笑，原来大家都差不多。这让我思考，是不是文档这样的东西，和代码不同，它更容易过时，它
[……]阅读全文
以下都来自我的经历，带有主观评价，但是尽量保持平直的论述。
在我工作的第一家公司的时候，一个典型的研发团队是这样组成的。我的经验也只是到 4 年前，现在也许早就不一样了呢。
项目经理，这个角色是不断在换的。项目经理当然是只跟着项目走，这和团队经理（Team Leader）是不一样的。当然，Team Leader 也往往在不同的项目里面兼任项目经理。基层的项目经理也可能会编码，但是不管参与不参与编码，工作压力都不小。
SE（System Engineer，相当于现在大多数公司的产品经理）负责从市场部门等地方承接需求，然后做 “系统性设计”，这个系统多数指的是业务系统，也指有时候 [……]阅读全文
小 S 是一名新员工，他和很多踌躇满志的大学毕业生一样，实习+工作，他来到了一家非常对口自己爱好的公司，来到了一支温暖的团队 A，这支 30 人的大团队由老员工和新员工混合组成，年龄结构复合，有男有女，有从二十几岁到四十几岁的程序员，做的视频编解码项目。整个项目组的成员都是视频编解码领域的能手或专家，最多的有 10 年的相关经验，也有几项专利，小 S 觉得这样的人应该很耐得住寂寞，有很深的造诣。
有一位导师手把手地带着他学习和进入项目，陪他一起吃饭，和他聊天，给了他公司内部通用的学习材料。于是他很快上手，最开始有一些疑惑，但是小 S 积极地去询问问题，导师和同事都很乐于帮助他，于是他进步很快。公司有一个专门帮
[……]阅读全文
不要被我的标题骗了。我可不是来宣扬什么模型驱动开发，或者什么测试驱动开发的，那些都弱爆了。今天我要说的，是几种看起来激动人心、华丽无比，但是可以让程序员们痛苦不堪的开发方式，特别适合那些热衷于折磨虐待程序员的项目经理和产品经理们。当然，掌握以后，偷偷用就好了，请不要来感谢我。
进度驱动开发（SDD，Schedule Driven Development）
这是在国内最为流行的开发方式，大家心照不宣，口口相交，代代相传，我只是把它写下来而已。它最华丽的地方在于，可以百分之百，甚至百分之二百地压榨程序员的劳动力。
需要实现哪些需求？用什么技术？用什么平台？项目采用什么流程管理？这些
[……]阅读全文
过度工程，最初我知道这个词是在 Rod Johnson 的《J2EE Development without EJB》，随着阅历地增长，渐渐发现书中熟悉的场景也在身边再现了。
敏捷、还有设计模式，给一个团队带来了什么？
我之所以把这两个词放在一起讲，是因为我要说一件显而易见的事情，可是这样一件事情很多人又不愿承认。
团队，是有风格个性的；团队，也是有能力强弱的。不管你承认不承认，整体来说，我见过的绝大多数团队都还远不是精英团队，因此相对于某些公司成功的案例来说，我们有很多事是不适合做的。
敏捷强调了主动性，强调了沟通，事实上并不是身边所有的团队都能做好敏捷管理的，譬如一支
[……]阅读全文
Corporate culture is not only a concept that a company uses to attract talents, but also a spirit and method running through the management. Here, I'll talk about the process, which reflects the characteristics and culture of a company as well.
As we all know, a small company cannot handle com
[……]阅读全文
在这篇文章里，我们可以见到许多有意思的编程风格，又没有精神为之一振的感觉，仿佛里面的例子就在自己身上，或者离自己很近。其实，对于文档、代码的评审，也是有诸多风格可言的，我这里列举一些有意思的典型：
一坨屎型评审
阅读文档、代码的时候，这些东西在自己眼里就是一坨屎：“我这么高智商的人都看不懂，明显是你有问题！”。
这样的人有一个他自己相当认可的世界观，凡是和这个世界观相冲突的无论对错的事务，必须强力排斥。这样的人眼中容不下复杂的东西，复杂对他的智商而言是一种侮辱，他会选择下结论的方式来拒绝自己对文档或代码的进一步阅读；对于和自己预期不一致的设计和实现，必须升级为人身攻击，挥舞狼牙
[……]阅读全文
代码评审究竟有什么好处？
在前期发现问题，提高软件质量，降低软件成本。
事实上，代码评审的好处远不止这些。有些项目经理或者开发人员不愿意多提评审，Coding 的过程包含的内容非常丰富，如果只把一个字符一个字符地敲代码叫做 Coding，未免悲哀了一点。优秀的项目，编码阶段实际敲代码的时间不会很长；优秀的程序员，大部分时间都用来思考了。
我来说说代码评审其它鲜为人知的好处，兴许能改变某些同学的看法呢。
增加阅历，学习别人代码的可贵之处
和英语学习是一个道理，如果只听一种纯正口音的英语，英文反而不容易学好，我们需要阅读各种营养的代码，广泛阅读能帮助开阔眼界，积累一些好的
[……]阅读全文
