在上一次文章中我们探讨了一下编写代码是否有边界的问题。主要表达的观点是：代码本身在在结果正确的前提下随意编写不是不可以，但是好的代码具有很强的扩展性有可读性，没有标准或者规范的编写很难对系统进行大量的扩展工作。因此寻找代码和架构的公因式成为我们一个潜在思路，这在宏观上或许是指导意义，但是在业务代码实现上可能就有些不知所措。因为我们无法明确边界问题。
为啥要想这些看起来很飘的事情主要还是作者在工作中发现对于一个项目，不同的人开发不同的模块。就会有不同的编码特色。有些同志喜欢复用代码，有些人逻辑上写的非常复杂。喜欢复用代码的人往往把所有的复用逻辑放到一个公用类中，然后这个公用类为了公用而不断的往里边添加代码，直到最后一个小需求带来的是巨大的工作量。逻辑很复杂的代码其实业务并不复杂，复杂的原因是各种冗余不执行的代码。员工的更新换代最后导致项目整体上处于”百花齐放“的状态。那么这玩意到底有没有一个比较灵魂的东西，因为我们无法总说经验呀什么的。为此作者买了《重构-改善既有的代码设计》《代码简洁之道》。其中《代码简洁之道》中主要还是讲了一些编码问题，个人觉得书中主要表达的观点是代码的整洁程度和代码的质量成正比，书中对类、方法、变量定义等等都做了相关说明，主要的一个目的还是通过对常见的编码进行整洁化，但是本人觉得它并没有触及到那种灵魂深处，通过思考，作者还是认为设计模式和边界是主要问题，所以准备找时间看看《重构》和《设计模式》。由于作者资历浅所以目前只能感悟到这个程度。
高度压力下的环境产生不了优雅的代码，除非你对压力无感！很多程序员为了快速完成上司交办的开发任务，只关心时间和结果，对代码设计往往归零。根本原因是压力下的开发人员主要思考的是如何转移压力，而不是如何自我实现，这是一个主要问题。同样的道理对于脑力劳动还是要营造严肃活泼的氛围。但是如果从根本上感觉不到设计的存在，那压不压力就没有丝毫意义了。
重构第一章的示例代码基本就是是80%的开发人员写的线上运行的代码。毫无疑问，作者就是这么写代码的。这也是作者感到不安的地方，也是看书的动力源泉。因为我知道那本不该如此。
看完第一章，对我启迪挺大。首先我们日常编写代码基本都是将业务聚合在在一个函数中。通过查看这个函数，基本就知道了所有信息。因此这个函数往往都是同时跨越模块做功能实现，作者认为这种编码的实现其实很像能力强的人经常单挑，核心类和函数干了其他类的工作，其他类在本质上就是在假装干活。上层干的火热，底层冰冷无比。而重构之后的代码则是上次只进行调度，底层进行具体实现，而底层逻辑实现则是以自己为中心，保证不夸模块，意思就是自己做好自己领域之内的事即可。
这让我想到之前跟前任领导参与的一个DDD项目，当时在开发过程的领域层只对该领域负责，只操作自己本身。业务的实现全部都在领域层，调度层只进行逻辑调度。所以调度层逻辑非常简洁和清晰，看到代码就能明白具体做了哪些事情。
看完第一章之后，作者觉得我们所谓的边界问题其实的本质就是自己管好自己，并将自己做到最好。其实这么理解也对，毕竟除去自己，别人有很多。你再膨胀也没有宇宙之大，所以正如那篇墓志铭所说的做好自己才能改变别人。不知道这种想法是否和重构这本书的开篇所要表达的含义相一致，但是以作者现阶段的思考，本人认为是这样的。
除此之外在第一章，还使用了策略模式，对原有代码进行了改善。但是我觉得那已经是战术上的问题。原则的问题我觉得目前已经解决了。战术上的问题以后咋再逐个往过慢慢品。
