Fourty Two

有关新项目的方法论

《四十二篇系列 · 第一》

能从项目中重用哪些工具

类似 OSS 管理这种公司内部项目,我们希望它们能够迅速启动并投入生产环境发挥效用。对这些项目而言,脚手架、项目结构、组件库、UI 框架之类的东西,就完全可以重用。不过重用总是会出问题,比方说要统一用哪个 UI 框架就是个问题。我常听到人们说他们如何喜欢使用 Ant Design,讨厌 Element UI。倘若撇开审美这种投人所爱的影响因素,仅从重用的角度考虑,那么使用两种不同的工具带来的不同点到底在哪儿呢?

也许问题的关键在于,要看哪一套工具的方法论更完善。我们都知道解决问题的能力是重要的,但是脑子本身确实懒惰的,喜欢跟随他人前进而不是独立解决问题(非贬义)。对应到可重用的工具,哪个工具的方法论更加完善,便意味着我们能投入更少的精力去学习,把时间省下来投入其他事情,获得更大的产出。所以长远来看,建立公司级别的 UI 规范及组件库是必须要去做的事情。

让专业的人做专业的事儿

向公司运营人员推广内部项目的过程中,我听到过“如果运营觉得项目不好用,那么首先应该让运营去参加培训、学习如何使用项目”这种观点。其实内部项目由于开发周期紧凑,往往没有专职产品、设计这些专业职能的参与。仅仅是由开发人员糊出来的页面,一旦涉及稍微复杂的功能,交互和流程就处理得很糟糕。ToB 项目本身对界面的要求是要“清晰、明确、高效”的,开发人员不能将这些东西一步到位。所以我认为“运营觉得项目不好用”,其实是项目真的不好用。

附:别再让前端背设计和交互的锅了!让专业的人做专业的事儿,同理,让专业的人背专业的锅,前端不是背锅侠。

如何向非技术人员解释技术问题

曾经看过的《信息设计之美》,在第一章就简洁明了地指出,人们只能通过他们已经知晓的事物理解新的事物。换句话说,要想理解一个新的事物,必须依赖类比的力量。

业务逻辑是什么

打代码时,我们总是面向数据。数据从操作库中取出,从后端层层数据抽象一路向前,到达前端之后经过解抽象、再抽象过程,最后再反向操作,奔回数据库。处理数据间的关系以及变化,就是处理业务逻辑。

讨论数据的时候,就应该讨论数据,而不是状态,所以我们也许应该更多地看齐函数式编程,而不是用上各种状态管理。应用程序本身可能有各种状态,比如“黑暗模式的开启或关闭、侧边栏的打开或否”,但业务数据中的状态就少的可怜。

前端业界一流的状态管理框架可能加以百计,他们有着针对状态的,不同的管理模式。如 Vuex,将应用程序的状态封装到框架内部,用可预测的规则保证状态只在有限范围内变化。可以想象,如果你把业务数据(通常繁杂、晦涩、深奥)放到 Vuex 这种状态机中,会带来额外多倍的代码量和更多心智负担。尽管状态管理框架本身是函数式的,这并不意味着在 JS 与其跛脚的函数式的上下文中,使用 Vuex 能更好的管理业务数据。写页面时,很多时候我们需要的只是数据管理框架,而不是状态管理框架。至于数据管理框架是什么,我也没有一个定论,可能他们并不是非此即彼的关系,而是有一定程度的耦合。

在更深入探索之前,我也许应该更多接触一些“函数式”的东西。函数式声称它能减少甚至消除程序中的状态,降低状态维护网络状地状态变化带来的心智成本,这是好的。

一些无厘头内容

  • 悠闲午饭时光:我比较好奇其他公司的开发在中饭或午饭时间内,讨论技术问题和非技术问题的时间占比是多少?占比是如何随着人际关系的改变而改变的?
  • 代码的宗教:人们是不是喜欢使用“Walk”作为递归函数的命名胜过“Traverse”?如果是的话,是因为“短”还是“拟人”呢?
  • 个人的终结:当学习新事物的人情消耗殆尽时,还能重新激发吗?有什么条件呢?
  • 传达的困境:面对面交流、邮件交流、通过中间人交流... 不同的传达方式对信息失真的影响是怎么随着人员的增减而变化的?
  • 项目的大王:面对离职人员的糟糕代码,我们可以在对接时(不远的将来)使用包装器将其隔离;那假使离职人员对项目架构有坏的设计,当其他人察觉这种影响时,项目是不是往往已经陷入无法回头的地步?
  • 精准的数学家:当一项优化内容能减少 5 分钟成本时,若每个月它执行了 10 次,那么每一年,它就能减少其他人员 10 小时的时间成本(保守到零度的估计)。

Copyright © 2024 Lionad - CC-BY-NC-CD-4.0