有关新项目的方法论
能从项目中重用哪些工具
类似 OSS 管理这种公司内部项目，我们希望它们能够迅速启动并投入生产环境发挥效用。对这些项目而言，脚手架、项目结构、组件库、UI 框架之类的东西，就完全可以重用。不过重用总是会出问题，比方说要统一用哪个 UI 框架就是个问题。我常听到人们说他们如何喜欢使用 Ant Design，讨厌 Element UI。倘若撇开审美这种投人所爱的影响因素，仅从重用的角度考虑，那么使用两种不同的工具带来的不同点到底在哪儿呢？
也许问题的关键在于，要看哪一套工具的方法论更完善。我们都知道解决问题的能力是重要的，但是脑子本身确实懒惰的，喜欢跟随他人前进而不是独立解决问题（非贬义）。对应到可重用的工具，哪个工具的方法论更加完善，便意味着我们能投入更少的精力去学习，把时间省下来投入其他事情，获得更大的产出。所以长远来看，建立公司级别的 UI 规范及组件库是必须要去做的事情。
让专业的人做专业的事儿
向公司运营人员推广内部项目的过程中，我听到过“如果运营觉得项目不好用，那么首先应该让运营去参加培训、学习如何使用项目”这种观点。其实内部项目由于开发周期紧凑，往往没有专职产品、设计这些专业职能的参与。仅仅是由开发人员糊出来的页面，一旦涉及稍微复杂的功能，交互和流程就处理得很糟糕。ToB 项目本身对界面的要求是要“清晰、明确、高效”的，开发人员不能将这些东西一步到位。所以我认为“运营觉得项目不好用”，其实是项目真的不好用。
附：别再让前端背设计和交互的锅了！让专业的人做专业的事儿，同理，让专业的人背专业的锅，前端不是背锅侠。
如何向非技术人员解释技术问题
曾经看过的《信息设计之美》，在第一章就简洁明了地指出，人们只能通过他们已经知晓的事物理解新的事物。换句话说，要想理解一个新的事物，必须依赖类比的力量。
业务逻辑是什么
打代码时，我们总是面向数据。数据从操作库中取出，从后端层层数据抽象一路向前，到达前端之后经过解抽象、再抽象过程，最后再反向操作，奔回数据库。处理数据间的关系以及变化，就是处理业务逻辑。
讨论数据的时候，就应该讨论数据，而不是状态，所以我们也许应该更多地看齐函数式编程，而不是用上各种状态管理。应用程序本身可能有各种状态，比如“黑暗模式的开启或关闭、侧边栏的打开或否”，但业务数据中的状态就少的可怜。
前端业界一流的状态管理框架可能加以百计，他们有着针对状态的，不同的管理模式。如 Vuex，将应用程序的状态封装到框架内部，用可预测的规则保证状态只在有限范围内变化。可以想象，如果你把业务数据（通常繁杂、晦涩、深奥）放到 Vuex 这种状态机中，会带来额外多倍的代码量和更多心智负担。尽管状态管理框架本身是函数式的，这并不意味着在 JS 与其跛脚的函数式的上下文中，使用 Vuex 能更好的管理业务数据。写页面时，很多时候我们需要的只是数据管理框架，而不是状态管理框架。至于数据管理框架是什么，我也没有一个定论，可能他们并不是非此即彼的关系，而是有一定程度的耦合。
在更深入探索之前，我也许应该更多接触一些“函数式”的东西。函数式声称它能减少甚至消除程序中的状态，降低状态维护网络状地状态变化带来的心智成本，这是好的。
一些无厘头内容
- 悠闲午饭时光：我比较好奇其他公司的开发在中饭或午饭时间内，讨论技术问题和非技术问题的时间占比是多少？占比是如何随着人际关系的改变而改变的？
- 代码的宗教：人们是不是喜欢使用“Walk”作为递归函数的命名胜过“Traverse”？如果是的话，是因为“短”还是“拟人”呢？
- 个人的终结：当学习新事物的人情消耗殆尽时，还能重新激发吗？有什么条件呢？
- 传达的困境：面对面交流、邮件交流、通过中间人交流... 不同的传达方式对信息失真的影响是怎么随着人员的增减而变化的？
- 项目的大王：面对离职人员的糟糕代码，我们可以在对接时（不远的将来）使用包装器将其隔离；那假使离职人员对项目架构有坏的设计，当其他人察觉这种影响时，项目是不是往往已经陷入无法回头的地步？
- 精准的数学家：当一项优化内容能减少 5 分钟成本时，若每个月它执行了 10 次，那么每一年，它就能减少其他人员 10 小时的时间成本（保守到零度的估计）。