封装思考

  做软件的时候，最有用的东西就是封装，把合适的物品放到合适的位置。

  主要讲究代码可重用，系统容易拓展。而且一样的功能做好分类是对整个项目的思考。

  写代码的时候需求变动，有时候不清楚哪里会成定型，有一定的结实。都是先实现现有功能，通过以后的拓展，慢慢发现那个地方是实的。需要更健壮。

  往往涉及业务繁琐的地方，里边思考流比较多的地方，就给分开处理。或者说整理一下，分层一下每一层思考的归属，依赖一些上下关系使得这些业务思考流在代码里变得清晰。

  接触的信息里，很少有文章谈及封装。大体上都 不清楚他们在说些什么。没有实际做事时该如何思考。

  项目分层，代码分块。在写代码的时候并不能明确想明白这片代码大概属于那一块，只能先放到一个大概归属的位置。等项目流程思路流一遍遍冲刷到这里，再对既有的功能进行微小的移动。一步步冲刷，一步步朝着更合理封装。

  实际项目接触过来，可能是外包，完成就结束了。除非是成熟的需求， 也有了成熟的参考，不然项目是需要一直改进，调整自身适应原本的需求和需求的成长。项目从开始起，就一直在优化路上。除非企业一直不成长，不然用户环境成长，软件就一直跟着成长和变动。

  这时候里边的思考，就会涉及的符合需求的发展。对功能封装的时候，要考虑到需求的发展。

  有时候公司业务，可能并不是自然的发展方向。不同的决策团队，受周围环境的影响，会做出并不合适的选择。这种选择会破坏需求的发展，也会使得项目变得有些凌乱。这时公司业务出问题，已经不是软件项目能左右。

  在健康的环境下，软件项目茁壮成长。需要理解公司的发展方向。软件负责人算是公司决策团的一部分。如果公司业务健康发展，软件也很容易茁壮成长。

  写代码像是一种叠罗，把相应的代码放在附近的位置，每一个同样大小的代码单元负责着差不多大小的业务逻辑。业务逻辑的思考量在代码中是平铺的，也是清晰的。当某个业务逻辑进行了成长，就分担到更多的代码带单元中。每个单元都是平价。这种平价的划分，组合，根据具体业务抽象成的对象进行决定。业务成了对象之间的配合，每个对象又简单、可追溯。