- 成长：在行为中成长，不要在认知中成长，知行合一，已思考大于无思考，行动大于已思考，若有经验，先携带清晰的目的再去做东西，若无经验先去做东西在过程中优化
- 目标：在做任何事情要将目标清晰的写出来， 然后具体化要解决的问题，拒绝非强依赖问题增添
- 例如：对文档的设计需要思考“该文档是用来带来什么？所面向的角色是什么人？怎么才能将思考更好的进行呈现传递？”，根据目标进行具体化设计
- 具体化：切忌“只见森林不见树木”大而模糊的罗列，切忌“只见树木不见森林”小而脱离目标的细化，切忌使用所有不清晰的检验标准，切忌所有超越自身能力的目标，应直面所有待解决的问题，拒绝逃避，对所有问题都需要在理性上给出一个指标化的合理解释，拒绝使用感性强行让自己接受
- 清晰化：对被动感知模糊的东西主动的进行深度思考，对每个写出的东西都要进行自我提问要对概念理解极度清晰
- 例如文档的作用清晰化思考：我之前为了掌握知识才记下详细的文档，这是将目的和对应的具体方案搞混了，详细文档的本质效能是“信息的记录和传递”的载体（将思考可视化呈现，目的为自己复用、 为他人展示、 减少对知识的二次思考的时间），副作用才是少量的 “思考输入”，因为思考并非一直存储在脑子中，思考过后的想法很快转瞬即逝， 所以将思考不断的重复（语言是个好办法，因为语言中枢会不断冲击大脑）才能达到思考的优化存储过程，所以文档要解决的目标是怎样才能更好的去“呈现思考”，人一下就能理解这个文档在写什么？业务在做什么？让文档的设计、业务的设计要有简单容易理解的轮廓，图形化是一个不错的解决方式
- 效率：不要对任何事情进行提前设计，不要思考计划外的事情，对时间应有较高的敏感度，讲究效率，要休息好
一.业务需求解决规范
理解需求全貌（上下游，人员分配）很重要，业务问题多次询问时需进行反思
文档总分，核心有“理”，有“据”，自我提问，图形化， 同时写下所有流程性思考语言
- 业务层面
- 技术层面
- 架构层面是为了给功能性需求和非功能型需求做宏观指导
- 代码设计层面目的包含（设计模式）
- 宏观：所有的类结构设计都是为了在具体的业务场景下加快团队和个人对代码的理解速度、分析适用的增删频率去减少代码量、增加代码的重用率、提高可测试性、适应技术演进，促进团队协作，需要注意的是设计不足，过度设计
- 微观：所有的类中设计都是为了在业务的非功能的需求下加快团队和个人对代码的理解速度、增加资源占用率和性能优化的可能性、提高安全性、提升代码的可维护性细节、增强错误处理能力
- 表象：聚合度和耦合度（是抛弃实际场景去只考虑代码层面的考量）
