前篇文章一发，立马有程序猿说：解气呀，我也待在这样的一个公司，所以我怎么能做出好的东西呢。

呵呵，那你误会我的意思了，我可没说哪种公司不好，我觉得经历过的都好。当然咱吐槽还是要吐的，喷完了领导们，这篇文章来喷自己好了。现在不喷产品不喷测试不喷“领导”，仅仅从程序猿的角度说说，你都有做过哪些“凑合”的事，然后就“凑”出了一锅粥。

1. 单元测试

首当其一的我觉得就是这个，你可能会想哎现在就这么两三条枪，UT那是大团队的事，我这有啥事吼一嗓子都解决了。可是一旦你公司的开发“战线”有点长，比如APP/WEB/第三方接口都做的情况下，测试变得困难起来，API OK了APP没到位，或是上了线了才发现出了问题。

一旦这个流转的线路拉长、层级增多，就有人开始“巧合性编程”，自测就基本靠猜了。尤其是那些隐藏得很深的操作，在APP和WEB上点一次都很麻烦，就更别说反复的测试了。

更重要的一个缺点是组织结构是涣散的，今天想起来加一个，明天谁喊嗓子再加一个。这种"无组织无纪律”的行为是压垮骆驼的那根稻草。

2. 组件模块

接上面，还是体现在系统思考上，如果所有的思维都在功能点上，没人爬上山顶向下看看这房子是不是要倒了，所有的力量都是在盖楼、盖楼，最终的结果可能就是楼歪歪了。

事实上这个“盖高楼”的观点并没错，对企业发展来说，“时间就是生命”。但忽略了模块思维其实是在浪费更多的时间。组件的价值在于可重复验证的程序和可定势识别的操作，无论对开发的工作量化还是对用户的使用体验，都有较高的实施优势。

实际中也有很多优秀的方案可以直接拿来用，对于启动者来说，更该做的是找到匹配的方案，做好胶水层把多个体系、模块、组件更顺畅的组织起来。

3. 持续重构

软件工程相对现实中机械、地产的工程，我觉得一个很大的优势就是可以拿到实际环境里检验的同时随时调整结构。如果可能，让不同人拥有不同的工具包，在保障整个系统的稳定性和每个人特长发挥的同时，持续的将其中优秀的工具、范例集成到公共库。

4. 基础样例

想要新来的人入门快，最好的办法就是能用最简单的方式告诉他该怎么做，拷贝一个随便改改就能工作起来的范例是个好主意，不至于来了新人不但没给团队带来力量提升还把事情搞得更糟。

太晚了（2015/3/7 0:02），眼睛睁不开了，先这样吧。其实我想说的就是，你的代码是你自己弄脏的，今天省了事了明天就摊上大事了，老老实实的写UT，认真的把枝干拾掇干净吧。最后贴上我最爱的《K.I.S.S》与诸君共勉：

KEEP IT SIMPLE, STUPID!

编写只做一件事情，并且要做好的程序；编写可以在一起工作的程序，编写处理文本流的程序，因为这是通用的接口。这就是UNIX哲学。所有的哲学真正的浓缩为一个铁一样的定律，高明的工程师的神圣的“KISS 原则”无处不在。大部分隐式的UNIX哲学不是这些前辈所说的，而是他们所做的和UNIX自身建立的例子。从整体上看，我们能够抽象出下面这些观点：

模块原则：写简单的，通过干净的接口可以被连接的部件。
清楚原则：清楚要比小聪明好。
合并原则：设计能被其它程序连接的程序。
分离原则：从机制分离从策略，从实现分离出接口。
简单原则：设计要简单；仅当你需要的时候才增加复杂性。
节俭原则：只有当被证实是清晰，其它什么也不做的时候，才写大的程序。
透明原则：为使检查和调试更容易而设计。
健壮原则：健壮性是透明和简单的追随者。
表现原则：把知识整理成资料，于是程序逻辑能变得易理解和精力充沛的。
意外原则：在接口设计中，总是做最小意外的事情。
沉默原则：一个程序令人吃惊什么也不说的时候，他应该就是什么也不说。
补救原则：当你必须失败的时候，尽可能快的吵闹地失败。
经济原则：程序员的时间是宝贵的；优先机器时间节约它。
产生原则：避免手工堆砌；当你可能的时候，编写可以写程序的程序。
优化原则：在雕琢之前先有原型；在你优化它之前，先让他可以运行。
差异原则：怀疑所有声称的“唯一真理”。
扩展原则：为将来做设计，因为它可能比你认为来的要快。

注：以上文字为了整洁我有极小的不妨害理解原标准翻译的改动。

献丑了，晚安！