最重要的写在开头：道术合一，知行合一
现在是讯息爆炸的时代，搜索引擎降低了学习的门槛，凡是都能从百度谷歌了解个一二。正因为这随手就来的一二，带来了想要的“结果”，让大家只掌握了术，但忽视了道。我认为“道术合一，知行合一”，术是千变万化的，但是道确实永远的，做减法就是我自己的代码之道。
可怕的观点：执行效率是第一
我经常听到一种观点，代码需要的是更快的执行效率。以及由这个观点产生的衍生观点，例如：设计模式并不重要等等，因为我们可以绕过框架或者现有的方法，用更“原生”的方式实现一样的结果，这样会运行的“更快”。这是一个可怕的观点，可怕就可怕在看上去没错。软件行业发展到现在已相当成熟，我们绝不能用单一指标衡量代码，如同我们不能用百公里加速来衡量一个车，如果这样想，无疑要选比亚迪，实际情况真的是这样么？
代码是一种业务的体现：全方位的评估才合理
代码是一种业务能力的体现，举个例子：小轿车是个人出行业务的体现，全方位评估软件工程带来的结果才更合理。尤其在国内，人天的成本大幅度的提高，技术团队每天的开支相比其他传统行业近乎天文数字，我们对于迭代周期要求非常的高，单个sprint产出的价值太重要，甚至于正版软件相较于人力成本也已经变得是一个合理的支出范围。所有，我更倾向于，在初期掌握一支小型化技术团队，把握住业务的核心，最大程度整合资源，打通外部内部数据，且团队要能不停的适应业务的变化。而且不光是技术团队，所有业务团队其实都应该如此。
业务好等于代码好：好业务是不停迭代出来的
很多人都告诉我，自己的代码写的多么多么的好，一次写完永久运行。但这样好么，我可以负责的说，这样的代码不值钱。互联网业务是不停的试错出来的，业务好不好对公司来说就是赚钱不赚钱，也就常常带来一个问题，需求肯定不停的变化。我以为业务的打磨是好事，因为没有人能一下找到赚钱的模式，再牛X的业务都是不停的迭代变化出来的。所以，要做到能快速的迭代，我们必须让代码能够快速的变化。可能有些负责通知或者工具类的运维小脚本，写完之后可以静静的躺着运行若干年，但不代表这个代码是好的，只是代表业务是死的。但唯有赚钱的业务才需要不停的修改不停的改变，所以我的观点就是代码是不停的在迭代改变的，同样的我很悲观，盖房子的还能看到楼房屹立100年，作为软件从业者，你的作品可能只能在世界上存活3个月，这是一个非常残酷的事实。
代码变化的本质：反应业务的变化
业务随着时间的推移，往往公司从一开始一个人管全部到后来的运营分工精细化，这背后涉及的是人员和部门的变化。所以当设计系统的时候必然会参考业务部分的划分，使用者划分，和场景的划分等来做设计。如果能在动手写代码之前闭上眼睛看到使用者工作的状态，线下业务转线上的整个过程，思考出每个节点，那就是一种正确的模式，因为你看到了业务，看到了代码的真正价值体现！
语言的进化：都是为了业务
面向过程编程之所以进化到了面向对象，是因为我们发现所有的业务都是存在现实世界中事物对照的，以及他们的关系。有了面向对象，抽象让我们可以更好概括真实世界，多态让代码中事物拥有同时对应多个现实世界事物的能力，继承让我们能够复用大量的代码。进化到了面向切面，我们发现业务不停的在做微调，所谓的微调无非是一些业务逻辑在场景中顺序的改变，有了AOP这样棒的工具，代码的组织变得更合理，当然阅读性会差点。所有的代码特性进化其实本质都是为了更好的表达业务，包括可以用trait来实现一些非通用的多继承，用生成器让函数的返回变得“动态”起来。
最后
业务是一组代码的集成，如同你开了一个面馆，没有必要非自己磨出面粉做出的面条才是最好的。站在一个更高的格局看系统，你需要的是有限的资源下，包装面馆，整合所有。把握最核心，例如浇头做核心，抓大放小。夸张的说，即使只开了一个小店，但是想着一个跨国企业规模。还是那句话，尽可能的在年轻的学习阶段过度设计自己的系统，然后不停的做减法，就能真正的感悟系统，最后你会特别理解罗斯科的作品，真的不用太复杂。
最最后
谨以此文，把自己的小小感悟献给刘锦，一个任劳任怨，每天认真工作学习的安庆少年，未来的安庆马克·罗斯科。