打开一个工程，浏览几个类，手不自觉地捂住了鼻子......
好几个没有使用过的变量
IO流没有关闭（我相信只是忘记关闭而已，因为程序丸总是会说“我先这样写，后面会补上的”）
一个方法几百行，干了十件事
注释要不没有，要不就不知道写的啥
......
即使把工程写得像榴莲熏得人发慌，也没有妨碍这个项目的成功：符合业务的欢心、客户满意、性能ok，还能获奖。真是前面客户称赞，后面程序丸骂娘。
做软件是一项社会活动
如果做软件中技术最重要，世上就不会有那么多失败的项目了。
一旦有一群人在一起做软件，人与人之间的关系和互动，就构成了一个小社会，软件过程会充满了社会活动，这些社会活动是软件成功与否的关键。
譬如，需求谈不清楚，软件使用最高精尖的技术也没有用。需求如何能变清楚？就是在软件过程中通过人与人不断沟通而变得清楚。
如果团队是一个分布式团队，一部分在城东，一部分在城西，如何保证软件各项进展顺利？这不是用技术能解决的。
业务逻辑有无限种实现方式
用充满设计模式来实现的功能，也可以用几个粗暴的长方法来实现，它们的区别只是好不好维护、好不好交接和好不好扩展而已，但是业务逻辑是一样的，即亦是说核心是一致的，用不一样的成本来提供同样的业务价值。
所以，程序丸知道代码写得很烂，也会因为业务逻辑没有问题而懒得修改。
所以，这就是为什么发臭的代码也能撑起一片天，它们虽然臭，但是一直为企业为组织为社会源源不断地产生价值。
如何少写发臭的代码
虽然发臭的代码也能抗起一片天，但是就不等于应该满足于此，毕竟对这类代码付出的代价也会越来越大。那如何改善呢？
- 抽空读一下《重构》这本书，好好学学怎么写代码
- 掌握几种常用的设计模式（是掌握，不是了解）
- 积累代码规范和业界公认的良好实践
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。