代码的本质

• 好的框架，是好的状态框架
  • 业务实体或者业务环节的不同
• 如果一个框架不能长期维护下去，将可能导致沉重的技术债务。
  • 技术宅区
• 不同的，要考虑兼容性；相同的，考虑共用。
• 缓存要有过期时间。
  • 如果不会过期的缓存越来越多，缓存重启将成为问题。 Redis 内存使用持续上升，但是又不知道里面的数据是不是有用，是否可以拆分和清理。
  • 一个 Redis 的实例用了那么大的内存，里边到底存了啥？都有哪些 key？每个 key 占用了多少空间？
  • 目标：缓存分级、监控清理机制、可预见性和可见性、缓存的利用率。
• 不严格统一，长期必然导致异化。
• 可测量性很重要。
• 好的软件架构是敏捷的。拥抱变化而不是遵循计划。
• 开发时更重视构建时间，发布时更重视尺寸。
• 基础架构与部署架构：基础架构是设计层面的，部署架构是实现层面的。

CSS

• CSS框架
  • CSS框架
• 跨设备兼容
  • 使用rem：识别不同的设备，给<html/>设定不同的基础值；
  • 巧用rem和em：
    • Global Sizing：相对于<html/>,使用rem；
    • Local Sizing：相对于父元素，使用em；
• 布局思考：
  • 现代浏览器(都支持flexbox)统一使用flexbox，考虑兼容另当别论；
  • flexbox的优势在：一维(横向、纵向)、简单二维、更轻量；
  • grid的优势在：二维及复杂多维；

浅谈框架

• 框架的层次
  • 业务耦合型、强业务关联。
  • 剥离业务型、框架独立。
  • 框架内核/外壳独立性。
• 框架的演进
  • 框架随着时间会不断演进(升级、重新设计等)；
  • 演进的过程必然要考虑项目整体代码的升级。有些升级是向前兼容的，有些是不兼容的。
  • 中型项目(20万行代码以上)的整体框架升级是痛苦的，假设一个模块化的项目有10个业务模块，每块2w行代码：
    • 一次性的迁移成本是巨大的；
    • 分次迁移要考虑模块间依赖不同版本框架的兼容性。
• 如何用好一个框架

一个好的项目

• 好的架构设计：
  • 模块化。基于业务流程、业务实体模块化。同时，各模块独立互不依赖、涉及到模块间共用代码(框架、配置等)一定要做好方案。
  • 模块间框架统一。各模块间除了业务不同(业务实体或者业务环节的不同)，代码应严格统一技术栈：一是学习成本低，降低了维护成本；二是避免混乱，保证项目长期的可维护性。

前端思考

• 相比于Java、Ruby等，前端的框架的生命周期中都比较短。

软件管理

• 协作文档的归类设置
  • 例如：开发人员通过并遵守“工作规范”，接收到“迭代需求”或“项目需求”中一个需求，对应“项目文档”中一个“项目”里开始工作。
• 技术能做的，不要让产品做;产品能做的，不用让运营做;运营能做的，不要让销售做;销售能做的，不要让商家和用户做

架构设计的思考

• 用户:
  • 会员:
    • 可分级
    • 使用即会员
  • 支持白名单(可切分)
• 业务:
  • 按环节分: 前、中、后

SEO思考

• 首先，SEO是重要的。
• 移动端SEO意义不大。移动端一般不通过搜索进入。
• 桌面端SEO意义较大，可以着重优化。