Robin。

代码的本质

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

CSS

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

浅谈框架

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

一个好的项目

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

前端思考

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

软件管理

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

架构设计的思考

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

SEO思考

  • 首先,SEO是重要的。
  • 移动端SEO意义不大。移动端一般不通过搜索进入。
  • 桌面端SEO意义较大,可以着重优化。
- - - - - -
written by 陈烨彬 Robin Chen , and published under (CC) BY-NC-SA.