独立开发者或小团队，擅长某一个方面，其他方面有短板

• 当然，虽然需要全方面的能力，只不过初期有优先级的区分1 所以很是可以胜任。
• e.g. 前端开发者对运维不熟悉

e.g 登录 权限 支付

• 可能的路径
  • 在支撑业务的过程中，逐步积累这些原子能力。
  • 由于本身即通用能力，通用化方面的设计倒是不用考虑太多。

业务实施工作

• 需要先搭个架子
  • 主要包括构建配置、常用组件库、项目目录结构等
  • 相对于代码，更需要一个面向业务的稳定的标准来解决那些通用的 80% 的业务，即所谓的低代码、无代码平台想做的事情。
• 实施初期过分 over design
  • 业务初期最忌 over design

为什么业务实施会很慢？

• 这里不包括通用非业务的模块，单纯实施业务也非常慢。
• 这里的主要问题是沟通，即需求和实现的不一致。
• 需求和实现不一致是不可避免的
  • 一方面是需求方对自己想要什么刚开始只有模糊的想法
  • 理解的不一致
• 只能通过不停的迭代来逐步满足业务真实需求
  • 需求方拿到一期产品，逐渐知道自己想要什么，不要想什么
  • 技术方通过写了代码，逐渐理解需求方的真实需求
• 所以我目前总结出来的最好的方案就是==加快迭代效率 ==

代码可维护性差，抗拒重构，也很难复用

• 一方面就是上面提到的，要有面向业务的标准层
• TDD test driven，保证后续重构无风险
  • 重构场景
    • 是当一期完成的 feat ，用户认为需要修改、扩展。也就是有需求再重构。
    • 后续的新 feat，能够
  • 问题：如何轻松写 test #task

最终是k8s

监控标准化