质量管理始终是各行各业始终无法回避的问题，而质量的提升始终是一个不断迭代升级的过程。在IT领域中，质量的话题主要聚焦在两个领域：数据质量管理和代码质量管理。
数据质量管理，有相对系统的管理模式，比如，一般我们会从数据的准确性、完整性、唯一性、一致性、及时性、有效性等。
关于代码的管理，主要有可扩展性和可读性等。本文就来围绕“代码的可扩展性”来稍微展开聊一下。
WTFs/min有这样一幅在网上流传了很多年的漫画：
相信每一个从事过编程行业的人员，看到这幅漫画，都会“会心一笑”……
漫画中，对比了好的代码和差的代码的代码评审会议的状态，得出了这样一个结论：
“衡量代码质量的唯一有效标准是，代码评审过程中每分钟听到的WTF次数”
仔细思考了一下，觉得很有道理。
代码的终极宿命：可读性差虽然，我们会提到各种衡量代码质量的标准，比如可靠性、可扩展性、效率等。但最终总能落脚到代码的可读性上。
一段代码都很难阅读，相信你不可能不对其可靠性产生质疑，不可阅读的代码，可维护、可扩展也就无从谈起。而代码的效率，其实并不只有执行效率一方面，还有编写的效率、阅读的效率、扩展的效率等。
可靠性差、可扩展性差的代码，一定会在需求反复变更的逼迫下，被修改的面目全非，最终的结果，要么是写者痛心（实在改不动了），要么是读者落泪（太辣眼睛了）。
可读性差与代码的可用性，其实存在一种说不清道不明的辩证关系。一段代码被反复修改，从某种意义上说，它可能一直有用，在发挥功效，应对各种变化的需求。一段代码如果从写下来，就从来没有改过，也许只是因为这段代码从来没有被执行过。
难而正确的事我们很容易把事情搞得一塌糊涂，但是，我们要一直费力才能保证一切井然有序，至少看起来是竟然有序的。
当然，底层更加本质的是“熵增原理”在发挥作用。
所以，很多时候，正确的事情，需要不断注入能量，不管是体力、脑力还是心力，只有能量才能对抗熵增。
代码可读性的追求，也是同样的道理，即便“可读性差是代码的终极宿命”。
可读性差的代码，可能要忍受无数声WTF，有些WT甚至来自于自己……
当然，当你对着自己曾经的代码发出WTF的声音时，从另一方面来说，也许是你的编码水平进步了，或者至少见过不少优雅的代码了。
无论从个人维护还是团队协作的角度，都应该努力提升代码的可读性。
甚至，代码可读性的价值不止局限于技术范畴。
需求方口头或者文字的描述、产品原型、PRD文档等，在定义需求时，都存在一定的模糊性。
而当下运行的代码的状态，真是、精准记录了正在运行的真实的业务需求。
当然，有个前提，程序员没有错误理解从各个方面传递过来的模糊的需求。
