是谁弄脏了个人代码

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

呵呵，那你误会个人意思了，我可没说哪一种公司很差，我以为经历过的都好。固然咱吐槽仍是要吐的，喷完了领导们，这篇文章来喷本身好了。如今不喷产品不喷测试不喷“领导”，仅仅从程序猿的角度说说，你都有作过哪些“凑合”的事，而后就“凑”出了一锅粥。

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自身创建的例子。从总体上看，咱们可以抽象出下面这些观点：

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

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

献丑了，晚安！