【转】被诅咒的程序员的七宗罪

七宗罪（Seven deadly sins），13世纪道明会神父圣多玛斯·阿奎纳列举出各种恶行的表现。这些恶行最初是由希腊神学修道士庞义伐草撰出8种损害个人灵性的恶行，分别是贪食、色欲、贪婪、暴怒、懒惰、伤悲、自负及傲慢。

 

程序员生来不平等。有的伟大。有的渴望伟大。有的就是废物。

下面是一些程序员经常会走入的歧途。听起来很恐怖，但享用吧。上帝就在你身边，警惕这些危险的信号，跟随主救赎的指引。

1. 色慾（Lust）

凡犯色欲者：在硫磺和火焰中熏闷

作为程序员，这种罪恶的表现是不断的受绚丽的新事物的诱惑。下一代编程语言，最新的框架，最新的平台。

我们程序员天生好奇。我们受惑于追求高效，坚信所有的东西都要经过优化。只有用了那种最新的语言，我们才能工作。

虽然不断的追求改进是非常值得赞赏，但采用新事物也是有代价的。有避免不了的学习曲线。有适应问题。有未知的依赖问题。有未知的未知问题。

清除这些杂念。专心解决你手头上的问题。充分利用你知道的，停止贪恋那些光鲜新事物。

2. 贪食（Gluttony）

凡犯贪食者：强迫进食老鼠，蟾蜍和蛇

这是过度之罪。过度的企图多做，过度的扩展深度和广度。

不必要的功能特征溜进了产品里。大量无用的代码被生产出来。宝贵的编程时间被消耗，被浪费。

这些行为增加了不必要的复杂度，带来的高昂的维护代价。通常导致的结果是，预期不能完工。bug层出不穷。

警惕那些不该有的功能、警惕那些对不必要的复杂架构的伪辩护、警惕过早优化的迹象。让产品简洁。

3. 贪婪（Greed）

凡犯贪婪者：在油中煎熬

过度专业化和功能化会导致形成个人的领地。固步自封。我的代码。我的模块。我相干的区域。没有分享。没有合作。

一种不健康的对这些人的依赖会逐渐形成。所谓的“编程教父”，“编程巨星”和“编程领袖”就代表了这些趋势。

相反，应该建立一个崇尚代码集体所有和充分合作(比如结对编程或相互代码审查)的文化。

4. 怠惰（Sloth）

凡犯懒惰者：丢入蛇坑

根据Perl语言的创造者Larry Wall的话，懒惰是程序员的三个伟大美德之一。

但懒惰不能和冷漠混为一谈。长时间不理出现的问题。允许代码腐烂异味。不重构拷贝/粘贴过来的重复代码。

对软件开发中这些需要修改的东西要有一种紧迫感。事无巨细。这是保持软件健康的必要态度。

5. 暴怒（Wrath）

凡犯暴怒者：活体肢解

在有些地方，有些程序员是每个人都尊敬，也是每个人都害怕。你也许遇到过这样的火星极客。他们恃才放旷，为所欲为，其他人在他身边都惦着脚走。避免和他冲突。

他们喜怒无常，他们的怒气经常撒错方向。他们贬低他人，破坏团队和谐。

警惕这种不受约束的对峙气氛的滋生。拒绝忍受这样的撒野。立即辞掉他们。

6. 妒忌（Envy）

凡犯妒忌者：投入冰水之中

不满足于现有的工具和系统，有些程序员眼睛总是盯着别人的。

我曾经遇到过这样的经历，一个wiki系统正在使用中，另外一个却同时被引进，因为它的标记语法感觉更好一些。两个问题跟踪系统，多种聊天系统，不兼容的博客平台，等等。

如果你不喜欢某个工具，相信有比它更好的，那好，去找到它，使用它。但是，请完全放弃你现有的。吃着碗里又想占这锅里，只会得不偿失，给自己制造麻烦。

7. 傲慢（Pride）

凡犯傲慢者：轮裂

有些程序员喜欢孤芳自赏。对自己的能力过度自信。从不寻求帮助。

更 糟糕的，他认为所有的事情都应该由自己来完成。虽然他有能力完成任何的任务，但他却没能完成，因为他承担的太多了，无法集中精力。他分不清什么是核心什么 是次要的。在可以使用云服务时他建造自己的服务器，在能使用成熟的部署系统时他重新发明自己的，他开发出跟现有框架功能相同的框架，等等。

诚然，做研究是有趣的。这些研究经常被辩称为“基础”或“革新”，但却因没有更快捷的创造商业价值而使产品丧失市场先机。

小心“非我发明(Not Invented Here)”综合征。准确的定义你的核心目标，你的首要工作。其它的都是次要的，可以借用别人的。这没有什么好羞愧的。

 

原文转自：开源中国社区

 

Lionden 2014年10月8日

E-mail：hsdlionden@hotmail.com

转载请注明原文地址和博客园Lionden：http://www.cnblogs.com/lionden/

 

 

 

附件：英文原文

7 Sins of Doomed Teams

By Georges Auberger

 04 Nov 2013  People  team, performance, favorites  3 min read

 

Software development teams are not created equal. Some are great. Some aspire to be great. Some are very dysfunctional.

Here’s a run down of ways engineers can err. As dreadful as it sounds, rejoice. Salvation is right around the corner. Watch for those signs of trouble and lead the way to redemption.

1. Lust

With development teams, this takes the form of constantly being attracted to shiny new things. The next programming language, the latest framework, the newest platform.

As engineers we are curious by nature. We are also obsessed with efficiency and hold the belief that everything should be optimized. If only we used that newest language, we’d be set.

While continuous improvement is a very laudable endeavor, adopting something new has a cost too. There is always a learning curve. There are teething problems. There are unforeseen dependencies. There are unknown unknown.

Eliminate those distractions. Focus on solving your problem at hand. Stick with what you know and stop lusting after shiny new things.

2. Gluttony

This is the sin of excess. Trying to do too much, being too broad and far reaching.

Unnecessary features creep into the product. Too much code is needlessly created. Valuable programming hours are consumed and waste is generated.

This behavior perpetuates unneeded complexity and yields high maintenance cost. Often as a result, deadlines are missed and bugs pile up.

Watch for unwanted features sneaking in, bogus justifications for unnecessarily complex architectures and signs of premature optimizations. Keep the product lean.

3. Greed

Excessive specialization and compartmentalization creates fiefdoms. Hoarding mentality settles in. My code. My module. My area of concern. There is no sharing. No collaboration.

An unhealthy co-dependent relationship with those individuals develops. So-called “Ninjas”, “Rock Stars” and “High Priests” can exhibit those tendencies.

Establish a culture that values collective code ownership and focus on collaboration — such as pair programming or peer review — instead.

4. Sloth

According to Larry Wall, the author of Perl, laziness is one of the three great virtues of a programmer.

But laziness should not be confused with apathy. Leaving a build broken for too long. Allowing bad code smell to fester. Not refactoring cut-and-paste code duplications.

There should be a sense of urgency towards fixing those aspects of software development. These are not details. They are part of maintaining good engineering hygiene.

5. Wrath

In some places, there are engineers that everyone respect and fear equally. You’ve probably encountered those alpha geeks. They throw their weight around to get what they want, while others tip-toe around them, avoiding controversial topics.

They can be volatile and their anger is often misguided. They are demeaning to others and poison the environment.

Watch for those thriving on unwarranted confrontation. Refuse to be subjected to their wrath and replace them promptly.

6. Envy

Instead of being content with the tools and systems they have, some teams keep looking at what others have.

I’ve experienced situations where one wiki was in use but another one was introduced because the marking syntax was perceived to be superior. There were two issue tracking systems, multiple chats systems, disparate blogging platforms, etc.

If you’re dissatisfied with a particular tool and believe there is something better out there, great, consider adopting it. However, make sure that you commit fully to deprecate what you have. Being stuck in a half way state generates confusion and slows you down.

7. Pride

Some teams can be too smart for their own good. They are overconfident about their abilities. They never ask for help.

Worst, they think that everything should be done by themselves. And while they might be capable to do just about anything, they fail because they take on too much and get distracted. They don’t identify what’s core and what’s not. They build their own servers when they could use the cloud, they re-invent deployment systems instead of using proven ones, they create custom frameworks that duplicate existing ones, etc.

Sure, some of these pursuits are fun. They are often justified as “essential” and “innovative” but they take precious cycles away from creating business value in the product in the first place.

Keep an eye for NIH syndrome. Be rigorous about defining what your core mission is, your job #1. Everything else is secondary and can probably be borrowed from others. There is no shame in that.

 

 

Lionden 2014年10月8日

E-mail：hsdlionden@hotmail.com

转载请注明原文地址和博客园Lionden：http://www.cnblogs.com/lionden/