技术管理 | 酷壳 - CoolShell

Alan Cox：大教堂、市集与市议会

2013年07月08日 Leo 评论 20 条评论 28,522 人阅读

在网上搜到的Cox大叔于1998年在开源社区写的一篇文章，当时很轰动，明眼人一看就知道是针对ESR那篇《大教堂与市集》，从中可见Alan在项目管理风格上乃至个人性格上都与ESR、Linus等人不同之处。顺便说一句，Alan现在出于“家庭原因”已经离开了Linux项目，他曾经评价Linus是a good developer but a terrible engineer，甚至在Google+上直接说Linus就是一a*sh**e。不管如何，两位曾经十余年里并肩战斗惺惺相惜的大牛就此分道扬镳还是惹人唏嘘。

言归正传，以下为slashdot收录的英文原文：Cathedrals, Bazaars and the Town Council。

以下是一些我对市集模式的想法，我认为这值得分享，这种模式会教你如何完全毁掉一个自由软件项目。我还举了一个我称之为“市议会”(Town Council)效应的实例（虽然那些市议员们可不这么认为，注：此处指Linux项目开发者）。

关于软件开发人员，你必须去了解一些情况。首先要了解的是真正优秀的程序员相对来说并不普遍，不仅如此，在很多其它专业领域里“真正的程序员”和一些捣乱的家伙之间的区别要比“伟大”和“普通”之间的区别要大得多，研究表明生产效率上最好的同其余的比重是30:1。

其次，你需要了解的是一大堆妄想型码农(wannabe programmer)总是善于发表意见。其中很多人患上了一种叫做“流行性热词”(buzzword)疾病，或者对他们“非黑即白”(one true path)的思考方式有着特殊的偏执，网上很多讨论都是廉价的。

…

阅读全文 Read More

(21 人打了分，平均分： 3.62 )

IoC/DIP其实是一种管理思想

2013年07月05日陈皓评论 66 条评论 74,137 人阅读

关于IoC的的概念提出来已经很多年了，其被用于一种面象对像的设计。我在这里再简单的回顾一下这个概念。我先谈技术，再说管理。

话说，我们有一个开关要控制一个灯的开和关这两个动作，最常见也是最没有技术含量的实现会是这个样子：

然后，有一天，我们发现需要对灯泡扩展一下，于是我们做了个抽象类：

但是，如果有一天，我们发现这个开关可能还要控制别的不单单是灯泡的东西，我们就发现这个开关耦合了灯泡这种类别，非常不利于我们的扩展，于是反转控制出现了。

就像现实世界一样，造开关的工厂根本不关心要控制的东西是什么，它只做一个开关应该做好的事，就是把电接通，把电断开（不管是手动的，还是声控的，还是光控，还是遥控的），而我们的造各种各样的灯泡（不管是日关灯，白炽灯）的工厂也不关心你用什么样的开关，反正我只管把灯的电源接口给做出来，然后，开关厂和电灯厂依赖于一个标准的通电和断电的接口。于是产生了IoC控制反转，如下图：

…

阅读全文 Read More

(36 人打了分，平均分： 3.83 )

《Rework》摘录及感想

2013年03月11日陈皓评论 152 条评论 140,477 人阅读

读了《Rework》这本书好多遍，每次读都有不同的感想。但从来没有把这些感想记录下来，今天把《Rework》书中的一些章节做一些摘录，并把我的一些感想总结出来。供大家参考。这是一本平生以来让我中毒很深的书，也是一本让我思考得很多的书。希望看到这篇文章的人都能好好地读读这本书。这本书并不难读，是一本你可以一口气不中断就可以读完的书。

现实世界

“这在现实世界里面行不通”，当你向人们介绍一个新创意时，人们总是这么回答你。这个“现实世界”听起来如此令人沮丧，……只有人耳熟能详，习以为常的事情才会胜利，即使是这些事情已经漏洞百出陈腐低效。

揭开“现实世界”这个锅盖，你会发现居住在里的人都充斥着悲观主义和失望的情绪。更糟的是，他们想将别人拖进他们的坟墓。如果你是充满希望和野心的人，他们会试着说服你，你的想法是不可能的。他们会说你在浪费时间。

“现实世界”并不存在，那只是人的一个借口。只是某些人为了开脱自己的无所作为，跟你一点关系也没有。

感想：我经常会向一同事和朋友提及一些我的想法，朋友同事们经常会回答我——这个事某某人，某某团队做过了，没成功。或是对我说，你做这个事的时候，要小心这个要小心那个。我觉得，这个时候是最考验我们的时候了，要有一个清醒的头脑去分析别人的话，别人真不代表自己。这个世界上大多数人都是比较保守的，大多数都对这个现实世界都有或多或少的恐惧感。当然，你可以选择做大众，但是如果你想让你的人生有些不同，有些精彩，我还是建议你不要和大多数人想得一样，如果你和大多数人的想法一样，你必然会和大多数人一样的平庸。当然，如果你和大多数人不一样，你要么就是天才，要么就是傻瓜。要证明你自己是不是傻瓜，我们可以看看我们过去有没有过一些小成功或小成绩。如果有，那么就应该大胆地坚持自己的想法。

被高估的“从错误中学习”

你真的从错误和失败里面学到什么了吗？你也许学到了别再重蹈覆辙，但是这有什么意义吗？你仍然不知道接下来该做什么。

…

阅读全文 Read More

(97 人打了分，平均分： 4.60 )

持续部署，并不简单！

2012年06月25日马基雅弗利评论 48 条评论 54,085 人阅读

【感谢 @常新居士投递此文 】

这几年，持续集成随着敏捷在国内的推广而持续走热，与之相伴的持续部署也一直备受关注。自前两年，持续交付这个延续性概念又闯进了国内IT圈，慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”，而许多前CI的半吊子玩家换件衣服就接着干，有的甚至衣服都来不及换……。国内的这些土财主如果不巧请了某些所谓的战略家，除了建了一堆持续集成环境，以及每天嚷嚷着要这个要那个，混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念，而是打算谈谈对于大型软件企业，以持续集成为基础实现持续部署（交付）时，所要面对的问题以及可行的解决方案。地主老财们，夜黑风正猛，山高路又远，注意脚下……

And God Said, Let there be light: and there wa— GENSIS, Charpter 1, King James

一、起步

先来讲个故事……

几年前，一对留美的夫妇通过朋友找到我，让我帮忙在国内组建一个开发团队，该团队负责为其开发一款基于社交网络的客户关系管理软件,（暂且称之为项目A）。这个项目除了尚不清晰的需求范围和很紧的期限外，作为业内人士的老公Richard根据眼下流行的软件开发过程还提了诸多额外的要求：

功能要及早交付（以便拿去和潜在的投资人洽谈）
功能在部署到生产环境前要先部署的一个测试环境（Richard要试用后给予反馈）
功能必须经过测试（长期作为软件外包的甲方，对质量要求严格）
要减少后期维护的工作（美国人精贵，少雇一个是一个）
支持协同开发（以便维护人员及早介入）
……

这正是持续集成所要解决的典型场景。针对Richard的要求，我们只要建立一个基于Hudson（现在叫Jenkins）+Maven +SVN 的持续集成环境（再加上持续集成所要求的测试和过程）就可以很好地满足上述要要求，此方案的结构如下：

…

阅读全文 Read More

(28 人打了分，平均分： 4.04 )

我们需要专职的QA吗？

2012年04月11日陈皓评论 275 条评论 176,588 人阅读

这个文章必然是有争议的，我在我的微博上讨论过很多次了，每次都是很有争议的。有不同的观点，有争论总是一件好事，这样可以引发大家的思考。所以，对于我的这篇博文，如果你赞同我的观点，我会感到高兴，如果你会去认真地深入思考，我也会高兴，如果你反对，没关系，可以讨论。

在此之前，我想说明一下我观点里的这个“专职QA”是怎么定义的。

其是很多公司成立的专门做测试的技术人员，仅测试不开发。
这些QA对于软件开发技术并不熟悉，甚至不懂。

我经历过一些公司都有专职的QA团队（专职的测试人员），自从上个公司我的开发团队在一个项目上被QA部门搞得一团糟，我越来越怀疑专职QA存在在意义。我的观点不一定对，但请让我鲜明地表达一下——我觉得是不需要全职的QA的，甚至不需要QA这一专职角色或部门，因为，不懂开发的人必然做不好测试。就像不懂开发的研发经理必然管不好研发团队一样。我越来越觉得Dev应该应该是做测试最合适的人选，这必然是未来的趋势（因为我已经看到了中国程序员的进步，相比起10年前，今天的程序员已经是非常全面了，再来十年，必然证明我的观点是对的）。

在我正在展开说明之前，我想引用两篇文章：

两篇文章

一篇是 “On testers and testing”(中文翻译)，本文的作者Sriram Krishnan是一名程序员，曾在Yahoo和微软工作过，开发过很多软件，曾被纽约时报报道，写过一本书，本文是他的一篇博客。他在文章中表达了这几个观点——

大多数的开发团队并不需要一个独立的测试角色。即使要有，那么所有的开发时间比上所有的测试时间应该 >20:1的。。证据吗？光看看一些从古至今最成功的软件开发团队就知道了。不论是当今的Facebook，还是30年前最初的NT团队，很多伟大的产品都是出自没有或很少测试人员的团队。

开发人员应该测试自己的代码。没什么可说的。背后的道理并不重要。这包括单元测试，全覆盖的自动化测试或手工测试或组合测试。如果你的开发人员不能/不愿意或认为这“不归我管”，那你需要更好的程序员。

另一篇文章是邹欣的“现代软件工程讲义 9 测试 QA 的角色和分工”，这是一篇很不错的文章。他在文章里提到了分工的必要性，比如第三方的鉴定机构，并且也指出了分工的一些问题，比如，画地为牢的分工，无明确责任的分工，等，这些问题直接命中了分工的要害。我隐约觉得，我和邹欣的很多观点是相同的，我们内容上是相同的，只是形式上还有分歧。另外，我的观点太鲜明了，从而容易导向极端的理解。

你看，我们都同意，Dev要懂测试，QA要懂开发，只不过分工不同，既然你中有我，我中有你，那就不要分彼此了，一起携手开发测试吧。（另外，我个人觉得不懂开发的测试人员不可能测试得好）

—- update—- {

//本篇文章出来后，网上出现了一些对此讨论的文章，我一并更新在这里
【《对《我们需要专职QA吗？》的回应》作者：@段念-段文韬】
【《关于“我们需要专职的QA吗”》作者：@Jacky郭】
【《我们需要专职的QA吗？（评）》作者：@Monkey陳曄曄】
【《《我们需要专职的QA吗？》读后感》作者：@ 花生色魔叔】

}

…

阅读全文 Read More

(65 人打了分，平均分： 4.17 )

多些时间能少写些代码

2011年10月25日陈皓评论 119 条评论 101,570 人阅读

我在我的微博上说过这样一段话，我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以，越差的团队一般会越忙，而且还忙不完。

在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在Todd的《“品质在于构建过程”吗？》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点：

软件的精髓在于设计，设计是一件很费大脑的事件。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间，TCP或UDP，同步还是异步，数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式都需要仔细讨论。这些的东西需要时间和做前期尝试。

TDD、快速原型和迭代可能会对软件和团队产生负面影响。在一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。当然，那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你，这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。

重构是恶梦，重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情（参看《重构代码的7个阶段》）。如果一开始没有想好，你要面临的不单单是re-design, re-architect，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

…

阅读全文 Read More

(29 人打了分，平均分： 3.86 )

在新浪微博上关于敏捷的一些讨论

2011年08月12日陈皓评论 54 条评论 30,567 人阅读

自从我发布了“Scrum为什么不行”，并被CSDN推成首页头条后，我在我的新浪微博上就经常被敏粉们@去讨论他们的一些话题。他们似乎想要从我这里听到一些不同的声音，我很喜欢他们的这种态度，在这里先赞他们一个。既然，让我来评论他们的东西，我就不客气了，板砖自然是少不了的。我觉得我在微博上的观点比较散，所以在这里做一个汇总。我在所有批评敏捷的文章里都重复说过我的立场，这里还要再说一遍，因为那群人很敏感——“我承认敏捷中有一些东西我是认可的，但对敏捷社区的推广和思维方式我持否定态度”。

敏捷词汇表

我被@吴穹adam邀请进入了一个敏捷词汇表的微群，这个群就是想明确的定义一下敏捷的各种词汇，比如，他们想把TDD定义成就是UT。呵呵。我对这个群仅保持了30分钟的热度，我在里面发了一个“你们不想讨论技术吗？”的帖子，就再也不想关注了。因为我的观点如下：

我不知道干这件事有什么意义。标准化还是洗脑？One World, One Agile? – horse shit!
你能定义地好吗？定义好了大家都能干好了？ – 幼稚！
理解不同又有什么关系？价值观不同又能怎么样？为什么不能正视并接受世界的不同呢？ – 固执！

敏捷宣言

我看到很多人又把《敏捷宣言》拿出来说事，就好象他们把敏捷宣言是软件开发的普世的价值观一样。我对此的评论是—— …

阅读全文 Read More

(17 人打了分，平均分： 3.18 )

软件公司的两种管理方式

2011年07月06日陈皓评论 111 条评论 108,932 人阅读

这篇文章是我的一个外国的同事Gareth推荐给我的，我和他一起工作过一段时间。他之所以觉得非常不错，是因为这篇文章让他身有体会，他觉得我也一定会有体会，并让我考虑一下翻译到我的blog上来。我看完后觉得很有代表性，而且觉得说得太对了，所以翻译过来，希望大家都读一读，最好转给你的公司老板。

这篇文章来源于 StakeExchange上的一个问题——“为什么BA和PM的薪水要比程序员要高？”，顶在一楼的回复分析了这个原因，并指出了两种管理文化。

———————————————————正文开始————————————————————

一个简单的回答应该是——“因为在我们的社会里，我们总是会认为薪水和会和职位的层次绑在一起”。但是，这个答案同时也折射出一个事实——我们的薪资是基于我们的所理解的价值，但这并没有解释

为什么PM（Project Manager）和BA（Business Analysts）在很多软件公司里在组织的上层？
为什么软件项目团队总是在最底层？

这两个问题真是非常地值得我们去问，去思考。

总体来说，这个世界上存在两种不同的软件公司的组织结构。我把他们叫做 Widget Factory（小商品工厂）和 Film Crews（电影工作组）.

Widget Factories 想要去解决怎么去激发被X理论所影响的人。X理论由 McGregor提出，这个理论是说，一般人的本性是懒惰的，工作越少越好，可能的话会逃避工作，大部分人对集体（公司，机构，单位或组织等）的目标不关心，因此管理者需要以强迫，威胁处罚，指导，金钱利益等诱因激发人们的工作源动力。于是，经理总是要去做他下属的工作。于是，基于这种前提下所思考出来的管理方式，很自然的就是——整个团队能够容易地被经理一个人所取代，这种团队中的每一个人都很容易被别人取代，在这种团队里，经理的工作能力不断地被加强。因些，这种公司一般使用树形层级的组织结构，而不是水平式的工作角色。

…

阅读全文 Read More

(59 人打了分，平均分： 4.64 )

怎样做一个 Program Manager

2009年03月10日陈皓评论 5 条评论 16,520 人阅读

我个人认为，这是一篇不错的文章，虽然我不是Program Mananger，但是我几乎在做着和这个职位很相似的工作。在这里，我把这篇文章推荐给所有的程序员，我相信，这篇文章会让你明白，只有技术是远远不够的，因为没有Program Manager这个角色，程序员们只不过一些手中拿着利器却不知所措的散兵游勇。我希望我的导读和原文能给所有的程序带来启示。

原文在这里：
“How to be a program manager”
http://www.joelonsoftware.com/items/2009/03/09.html

这篇文章的作者叫Joel Spolsky，在Microsoft做过Program Manager，这篇文章非常值得一读。下面是我给大家做的一个导读：

首先，他讲了两个人，一个是负责WYSIWYG 字处理的天才级的Program Manager——Charles Simonyi，第二个是上世纪80年代的负责Mac OS上的Excel项目的程序员Jabe Blumenthal，他发现了程序员和市场人员的代沟，Marketing的人很难通过把MBA-Speaking翻译成实际的Feature，并且，有太多的和编码不相关的工作，比如说，和用户交谈，运行usability测试，Reivew竞争者的产品，并且得冥思苦想怎么能让事情变得更简单，而我们的程序员通常来说即不具备这样的时间，也不具备这样的能力。于是，Jabe开始了他的Program Manager的生涯。

…

阅读全文 Read More

(6 人打了分，平均分： 2.33 )

酷壳 – CoolShell

享受编程和技术所带来的快乐 – Coding Your Ambition

Browsed by
分类：技术管理

Alan Cox：大教堂、市集与市议会

2013年07月08日 Leo 评论 20 条评论 28,522 人阅读

IoC/DIP其实是一种管理思想

2013年07月05日陈皓评论 66 条评论 74,137 人阅读

《Rework》摘录及感想

2013年03月11日陈皓评论 152 条评论 140,477 人阅读

现实世界

被高估的“从错误中学习”

持续部署，并不简单！

2012年06月25日马基雅弗利评论 48 条评论 54,085 人阅读

一、起步

我们需要专职的QA吗？

2012年04月11日陈皓评论 275 条评论 176,588 人阅读

两篇文章

多些时间能少写些代码

2011年10月25日陈皓评论 119 条评论 101,570 人阅读

在新浪微博上关于敏捷的一些讨论

2011年08月12日陈皓评论 54 条评论 30,567 人阅读

敏捷词汇表

敏捷宣言

软件公司的两种管理方式

2011年07月06日陈皓评论 111 条评论 108,932 人阅读

怎样做一个 Program Manager

2009年03月10日陈皓评论 5 条评论 16,520 人阅读