经过一段时间的flask框架学习，对于抽象和分层思想有了一定的理解，而对其进行的一系列思考让我开始思考分层治理，抽象思维的思考方式和对项目的管理理念。
（不懂的也可以看看，不复杂）
从web网站数据库看抽象：
从flask的web开发网站看，分层和抽象不仅仅体现在代码上，更是体现在整个项目：
①项目组成部分命名及类调用清晰
②数据库的管理安全，防止了误操作
③网站结构清晰，各“部门”分工明确
一、项目组成部分命名及调用清晰：
主要是体现在，引用新的库后，对其进行了再命名或者严格大小写。一眼就能看出是类对象还是方法对象，例如使用骆驼命名，或者大小写命名，以及再命名使易于辨识。
其次是如果有新的可以分层和抽象的对象，就一定会新建一个对象，使得修改代码非常简单：
举例来说，网站的用户有不同的角色（例如管理员，普通用户，协管员，匿名用户），每个角色有不同的权限（例如管理整个网站，写文章，评论他人文章，赞他人，处理删除他人文章），在设计上有角色这个概念，则在代码中，用不同的权限组合出一个元组，对应一个角色名。那么在给用户赋予权限的时候，直接赋给他对应的角色就行了。这样做的另一个好处是，当需要添加新角色时，只需用权限组合出一个新角色就行了。
即角色=职业，用户=玩家，权限=技能，可以轻松的用技能组合出一个新职业，管理玩家的职业比管理一大堆技能要容易得多，这种尽量分层来使管理清晰的方法，细想意义非凡。
二、数据库的管理安全，防止了误操作
这个做法在很多大型公司已经是共识了，不管是mysql还是sql server等等数据库，它们的增删修改等操作都十分多样，语言复杂，如果在删除和修改的时候误操作了，或者操作时出现了前后操作不完整引起数据错误，对于数据库的影响是很大的，毕竟数据量一上来，数据库错误排查是很困难的。
那么，就要在粮库的入口处严厉把关，在中间设一个检查站，对于数据库的操作都必须通过这个检查站规定的方法来操作。具体在代码上的实现，就是将几个数据库操作语言组合并封装成一个类方法并提供接口操作，不符合规范的报错且不执行，保持数据库的安全。
举例：
--类方法：新增一个用户
--数据库操作语言：增加一个用户，默认主键递增，默认下为匿名，写日志。。。。。。
这个类方法提供接口，那么在新增用户的时候，只能通过这个类方法来添加这个用户，就保证了数据库安全，这个类方法不仅审核了信息，还规范了操作，后台程序员不需要懂数据库操作语言，也可以增加用户。所以封装在一定程度上使得分工明确，也减少了因程序员误操作造成的数据错误。
三、网站结构清晰，各“部门”分工明确
这个是很常规的代码管理，对于各个不同的模块，进行清晰的命名和分类，建立文件夹css存放css文件，建立templates文件夹存放网站html模板代码，创建db_respository文件夹存放数据库迁移仓库，建立requirements.txt文件保存所需环境和库的版本以便在异地重建环境。
但我觉得很重要的是，这些思维当初是如何产生，并一步步形成目前的项目管理思维的，从管理问题出现，到思考一个web网站的组成部分，到哪些部分是大类，到哪些模块重要到需要单独建立文件夹，到各个模块之间的连接和引用，细绘制一张图的话，我认为能得到代码之外的，对信息管理和分类的一种思维模式。（现在图未绘完，以后有机会发文补上）
跳出代码看封装和分层思想：
将复杂的东西通过抽象和分层简单化，使得不熟悉的人和很久没使用后的自己能够很快的熟悉操作，使得一件完整的事情在操作中可以按层级推进、减少出错以及记录责任归属。
思考到对任何项目管理，
①例如土木工程制图CAD，相同的线条和转角，可以建立模块，对画图处直接放置模块，放置下的对象的共同的父类是这个模块，那么一旦涉及到图案某个参数的修改，对这个模块的所有子类来说，只需要修改这个父类模块的数据，就修改了所有的图案。进一步的看，对于整个CAD图，在工程量变大以后，以模块化的管理来绘图，不管是查看简单，修改也会简单很多倍。
②例如对于人事和项目管理，一个部门做好相关的“接口”，例如一个报销账目流程，对每一步都要求记录来到人员和操作，严格按照层级操作，那么出现问题，有综可循，责任归属明确，并且不同部门和项目成员不用理解另一个部门的情况，只需要按照部门要求操作，也能顺利完成整套项目流程。
分层和封装不仅是一种编程术，更是软件开发者多年以来总结出的思维方法，跳出代码本身，从整体上来看分层和封装抽象，不管是什么行业什么项目，都还有很多的可以应用的地方
不看细节，难以落地为术，不看宏观，难以上升为道，目前我还不能理解得很深，但相信会逐渐理解它，如有想法，欢迎交流。
--Dylan 9/18/2016