架构师给程序员的一封信
下面的邮件是某Architect发给他的Engineering团队的(来源),我觉得挺不错的,翻译过来,我相信我们所有的程序员都能从中学到很多东西。下面是这封邮件——
每次当我开始做新的东西是我就会很兴奋。就算在软件圈里做了20年以后,每当开始新的旅程里,我都觉得我心中有一些东西不吐不快。这是我们大家一起的旅程。我强烈地相信我们详细规划的过程是很有乐趣的,富有挑战的和丰富多彩的。我想让这个旅程让你们难忘,并且能增添你们所有人的阅历。
这看起来有些唯心主义,不过,我想制订我的工作日程,我们的技术策略,以及你们密切合作的进度。这样一来,当你们做了什么相当不错的事,我们所有人都可以受益。我相当的尊重第一个工程师和他们的代码。
1. 代码是王。文档仅随其后 。所以,代码一定要和文档一致,并可以正确执行。
2. 测试,测试,测试。
3. 单元测试非常关键 。每一个在单元测试之后发现的bug需要开发人员双倍的开销。记住,我宁可增加你的薪水,也不愿意把这些钱发给另一个QA团队然后你再修正bug。因此,如果你的代码满是bug的话,我不得不把钱付给更多的人,而你也只能分得很小的一块饼。
4. 写下有效率的代码,不但是让人读得有效率,而且也是让CPU执行 地有效率。对于坏代码永远不会善罢甘休。
5. 多了解今天工作需要之外的事情。你不仅仅要知道今天干什么,还要知道明天需要什么。
6. 回家时不时做点菜,是的,真正的做菜。这会教会你菜谱和做饭的不同。菜谱告诉你这道菜需要什么样的食材,而你实际去做需要考虑的是你现在手上有什么……这就是其中的不同。(对于一个刚起步的公司,这是一个最大的教训)
7. 创新和好点子(技术或是产品),请与大家共享。
8. 我知道你不喜欢商人。我也知道为什么。他们销售那些你做不到的,他们承诺那些你完不成的。他们要求的比他们付出的更多。但是,没有他们,我们可能没有办法把商业转换成产品。这是一件很难的技能。把你的想法告诉我,我愿意成为你和他们间的缓冲。要建造一个好的团队,我们需要的所有的东西。
9. 作为一个工程师,热爱你的专业。你能拥有一个可以挣钱、受人尊重、并拥有乐趣的程序员人生。
你觉得怎么样?
(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)
《架构师给程序员的一封信》的相关评论
我觉得还不错 很真诚
特别赞同第7条 共享
呵呵,知识共享+测试测试
非常不错,受益匪浅啊!可以感受到作者的好心情了。
我需要创新的好点子,大家共享
写得很好,12347是一个合格的程序设计员必备的品质.
文档仅随其后 紧随其后?
好吧我来吐槽:
1. 代码是王。文档仅随其后 。所以,代码一定要和文档一致,并可以正确执行。
如果这两句没有错别字,那么前面一句和后面一句是矛盾的:前面说代码是关键,后面却说这个关键要被非关键的东西牵着鼻子走。
3. ……记住,我宁可增加你的薪水,也不愿意把这些钱发给另一个QA团队然后你再修正bug。……
单元测试只能减少QA的工作量,但是不会完全替代QA的作用。毕竟集成测试、压力测试等其他测试还是有其意义和必要性的。
4. 写下有效率的代码,不但是让人读得有效率,而且也是让CPU执行 地有效率。对于坏代码永远不会善罢甘休。
如果他这里说的是“不但让CPU执行 地有效率,而且也是让人读得有效率”,那我可以理解,不过这里反过来说……要知道软件的性能瓶颈不一定就在CPU上,而一个软件项目的短板也并不一定在软件性能方面。
5. 多了解今天工作需要之外的事情。你不仅仅要知道今天干什么,还要知道明天需要什么。
做一件事并做好。很多需求分析人员都在说“需求变更是不可避免的,开发人员应该预留充分的灵活性”,如何让具体的开发人员预知未来?更何况这样的担心会影响人把眼前的一件事情做好,半吊子的东西在长远看来是会引起很多维护性上的麻烦的。
恩我觉得这个东西是架构师的典型表现:一知半解+指手画脚。
ACMer表示
文檔是用來整理思路的。。。。。
严重同意 (8)”商人”在这里翻译得不准确. 他实际上说的是销售人员(sales), 这在国外属于Business development部门, 所以管他们简称为”business folks”. 我在自己的一篇博客“白痴程序员的特征列表”里提到过相同的观点.
URL:
http://c2.teckoo.com/blog/story/idiot-programmer.html
“””
瞧不起销售人员. 极度傻X. 不要以为自己写了一些代码就有多了不起. 销售是把钱赚进来最重要的一个环节(没有之一). 不信的话程序员自己去试一回销售就知道了, 你把产品白给人家用都不一定有人要, 因为会浪费人家的机会成本.
“””
非常同意8. “商人”在这里翻译得不准确, 应该是销售人员(sales). 在国外销售属于”Business development”部门, 所以作者简称他们为”business folks”. 我在”白痴程序员的特征列表”里提出了相近的观点.
http://c2.teckoo.com/blog/story/idiot-programmer.html
瞧不起销售人员. 极度傻X. 不要以为自己写了一些代码就有多了不起. 销售是把钱赚进来最重要的一个环节(没有之一). 不信的话程序员自己去试一回销售就知道了, 你把产品白给人家用都不一定有人要, 因为会浪费人家的机会成本.
ls的c2,如果你的逻辑是“如果没有X就一定没有Y,所以X是最重要的(没有之一)”,那么反过来,没有程序员,软件销售人员去卖什么?那么按照你的逻辑,程序和销售都是“最重要的(没有之一)”,而这样就产生了矛盾。不要用“极度傻X”的逻辑摆出讲理的姿态。
上面是我的博客里的一段节选, 是不是没加引号产生歧义了?
我承认写得有点标题党的味道. 博客不是论文, 娱乐性要大于正确性, 呵呵. 我的论点是指出瞧不起销售人员的程序员是傻X.
1. Code is the KING. Documentation is just close behind it. So, write code such that it IS the documentation and it works.
代码为王, 文档紧随其后. 所以使代码成为文档并且能(正确)运行.
1. Code is the KING. Documentation is just close behind it. So, write code such that it IS the documentation and it works.
恩对这条表示赞同
老大第一条翻译错了!
你是舜联的?
6. 回家时不时做点菜,是的,真正的做菜。这会教会你菜谱和做饭的不同。菜谱告诉你这道菜需要什么样的食材,而你实际去做需要考虑的是你现在手上有什么……这就是其中的不同。(对于一个刚起步的公司,这是一个最大的教训)
有道理