写代码写不动了，没有那么精细。退远一点发现什么都可以操控，只不过代码逻辑间距变得很大。倒是更容易从全局看到局部，容易全局掌控。
看一些写代码的讨论，怎么设计一个代码分类，也就是代码优化。
最开始带有类的编程考虑了这些事，把一个事物的各种描述和与它相关的处理方法都放到类里。后来对一个web服务，写程序的时候还考虑分成几层来处理。哪个和用户交互，哪个用来处理交互数据，哪个用来处理保存。把相应的功能朝某一个层来分。实际编码的时候似乎并没有这些考虑，在哪个地方最容易达成目的一般就写在哪里。
这些归类到层里或者归类到一个类里，或者从代码编排角度，这些层或者类的编写方式可以有统一的规则，可以用来集成化、自动化开发。首先是第一步的归类。
并不局限于类或者是层。也并不是在主要考虑把相关的功能聚合。是把这件事抽象成 程序和业务都能理解的处理步骤。 两表相关联，一个主表放着主要信息，一个从表放着一些不常用的辅助信息。当数据量越来越大，从程序角度来看，查一条数据就要翻阅整个从表，它俩的距离显得越来越远。从业务角度看，一个表内的数据有固定的用途。数据产生之后备份给不同的“部门”，每个部门需要的数据并不一样。部门之间的数据很少同步。如果辅助信息放得特别远，业务上也是需要单独存放，用到的时候进行整理查阅，这样就可以做从表关联；如果辅助信息放得比较近，和主要信息放在一起共同使用，可以考虑直接放在一个表；如果主要信息是全部信息的一个特殊摘要，供给特定的部门使用，那它会有特定的方式和主要信息表做对接，更新程度也随业务。
业务到程序的抽象里，找到哪些是最基本的信息，哪些是朝外的分搭。一个功能入口获取的信息，相对于集体功能来说，是否可以作为主表，或者可以以怎样的方式搭建到主表上。主表又是怎么被各个功能入口共同抽象出来，出现怎样的（多个主表）内部层叠和交互关系。业务有一条清晰的线，这些线从功能进入，经过内部处理，形成整体过程。最开始实现功能，从基本需求起手设计相应字段，模拟拼合出一个整体实现过程。从这个临时搭建的构想中，抽象出基本信息们和它们之间的交互。事件产生信息，分发到不同的部门，每个部门做自己特有的处理。
第二步的归类，也是同时进行的集成。
对表的操纵经历一些步骤，取出数据放到相应的载体里，进行处理并放回去。对控表的编码有繁复的操作规范。取了表的数据放到方便使用的载体里，也有相应的交流规则。整理业务的时候需要和这些规则灵活打交道。控表和便捷的载体在业务驱动下也相互制约。可以有统一的规范和通用的功能集合来封装这些处理。
当底层封装过多偏向于sql的灵活生成，就偏向了sql的思维。有单独的层面来封装这些思维，会显得上级逻辑步骤清晰。同时也会增加开发步骤。把相似的封装做统一，自动生成相关代码。
这样会减少精细部分的处理，可以从远处操控。