打开一个工程,浏览几个类,手不自觉地捂住了鼻子......设计模式
好几个没有使用过的变量
IO流没有关闭(我相信只是忘记关闭而已,由于程序丸老是会说“我先这样写,后面会补上的”)
一个方法几百行,干了十件事
注释要不没有,要不就不知道写的啥
......分布式
即便把工程写得像榴莲熏得人发慌,也没有妨碍这个项目的成功:符合业务的欢心、客户满意、性能ok,还能获奖。真是前面客户称赞,后面程序丸骂娘。性能
若是作软件中技术最重要,世上就不会有那么多失败的项目了。设计
一旦有一群人在一块儿作软件,人与人之间的关系和互动,就构成了一个小社会,软件过程会充满了社会活动,这些社会活动是软件成功与否的关键。代码规范
譬如,需求谈不清楚,软件使用最高精尖的技术也没有用。需求如何能变清楚?就是在软件过程当中经过人与人不断沟通而变得清楚。变量
若是团队是一个分布式团队,一部分在城东,一部分在城西,如何保证软件各项进展顺利?这不是用技术能解决的。扩展
用充满设计模式来实现的功能,也能够用几个粗暴的长方法来实现,它们的区别只是好很差维护、好很差交接和好很差扩展而已,可是业务逻辑是同样的,即亦是说核心是一致的,用不同的成原本提供一样的业务价值。重构
因此,程序丸知道代码写得很烂,也会由于业务逻辑没有问题而懒得修改。软件
因此,这就是为何发臭的代码也能撑起一片天,它们虽然臭,可是一直为企业为组织为社会源源不断地产生价值。程序
虽然发臭的代码也能抗起一片天,可是就不等于应该知足于此,毕竟对这类代码付出的代价也会愈来愈大。那如何改善呢?