站长网 资讯 软件开发提效哪有那么简单

软件开发提效哪有那么简单

1、产品经理/UI设计师与开发者之间的交接浪费 很多人都看到了产品经理要写一遍 PRD 稿,然后开发者照着翻译一遍。UI 设计师要画 UI 稿,然后前端开发要照着还原 UI。如果能够减少这个交接环节产生的浪费,让 PRD 稿,UI 稿能直接进入下一个环节,岂不美哉。

1、产品经理/UI设计师与开发者之间的交接浪费

很多人都看到了产品经理要写一遍 PRD 稿,然后开发者照着翻译一遍。UI 设计师要画 UI 稿,然后前端开发要照着还原 UI。如果能够减少这个交接环节产生的浪费,让 PRD 稿,UI 稿能直接进入下一个环节,岂不美哉。

这条路走下去的坑可能是什么?PRD 稿和 UI 稿存在的意义在于减少返工。如果没有前一道工序,让客户一句话需求直接对接开发。那很有可能做出来了,就不是客户想要的。这个时候要去改代码,比修改 PRD 稿和 UI 稿的代价要大多了。所以 PRD 稿和 UI 稿的优点就是改起来快,没有可运行的代码那么多要求,可以很随意。如果要求 PRD 稿和 UI 稿能够直接翻译执行,那势必要添加语法和语义规则限制。这可能会损害“低成本可修改可讨论”这个优点,产品经理和 UI 设计师要花更多的时间来让产出物符合规范上,而不是花更多的时间和客户讨论反复修改上。

2、开源的库和框架提供的可复用代码太少了,做过很多中后台项目,仍然有大量重复的代码

这个浪费是说,开发者复用的库和框架都是非常底层非常基础的数据结构,RPC通信这些东西。做了个几个项目之后,就会得出自己是 CRUD boy 的想法,觉得总这么重复下去不是办法。如果能够搞出几个开源的库和框架,那岂不是造福人类?

这条路走下去的坑可能是什么?开发者是无法反向约束客户需求的。任意两个客户,即便就是 CRUD 也会有不同的细微差别。比如 list / detail 是上下,还是左右,还是弹框,还是跳页?列表是分页还是无限下拉,是有筛选,还是有搜索?开源库之所以都是那些基础的东西,就是因为那些东西共性大。稍微往靠近用户的一侧靠一些,花样就百出。

然后第二个可能的想法是满足 80% 的需求,那剩下的 20% 让开发者去传参数,传 callback,写 patch,写 DSL 来满足。之前那些开源库的作者没有做到这一点,是因为他们笨(划掉),是因为我有更牛x的代码生成/组件插件技术/xxx

这条路走下去的坑可能是什么?不讨论是不是有什么牛 x 的技术就能大幅改进在已有代码上做定制的体验,我个人经验是不存在这样的技术,不管运行时的还是编译期的,能力上都基本上等价。即便有这样的技术,一方面写 20% 的人至少要知道 80% 是哪 80%,他需要知道已有的库和框架提供了什么,需求是什么,然后 diff 出 20% 的部分。然后还要知道在这个指定的库和框架上怎么写那 20%,没有两个框架提供的扩展方式是一样的,都有自己独特的搞法。

上世纪80年代的时候,流行组件市场的传说。写好业务组件,然后拿出去卖钱。但是从历史来看,最终组件市场的形态是 github 这个最大同性交友社区。最佳的代码复用方式是拿来主义,直接 fork 一份,在别人的代码基础上做修改。啥参数化,插件化,callback,都没有直接改源代码来得直接,好用。

3、现有的代码认知负担太大,新人要很长时间才能接手。反馈周期很长,没法快速修改快速迭代。

观察人是如何阅读代码修改代码的,不难得出这两个主要浪费的点。

认知负担

反馈周期

认知负担:代码读起来很复杂,不好理解。一份代码要交接给另外一个人来写,他要很长时间才能达到你之前的水平。甚至按照 Programming as Theory Building 的观点,没有人可以达到作者一样的理解程度。理解一份代码最好的方式可能是重新写一遍。

这条路走下去的坑是什么?有的人提议,我们需要用 Event Sourcing。有的人又提议,不对,我们应该 Reactive。有的人又提议,我们应该 Structured State Machine。每个人都会提出自己所谓的“认知负担”最低的表述方式。但是坑在于,每个人的思维习惯,过往经历是不同的。不是所有的 GUI 都一定要 React,要 Reactive,有的人,有的项目,可能 jQuery 直接改 DOM 才是“低认知负担”的解决方案。有一个说法是 Simple v.s. Easy,就是可能一个解决方案是 Simple 的,但是因为不是代码的阅读者所熟悉的模式(比如 Haskell Do Applicative),那对他来说就不是 Easy 的。编程范式这个东西,炒来炒去,就那么几种。如果有一种显著强与其他的,天下早就统一了。不存在什么未知的逻辑表述方式还没有发现出来,早就被枚举完了。

反馈周期:另外很多人也看到,修改 GUI 代码,要很长时间才能知道改得效果是什么。如果能够所见即所得,可以极大地缩短反馈周期,可以在同样的时间内,修改更多次。类似的,在本地无法获得生产环境数据,无法运行完整的代码的情况下,需要上线或者提交到某个特殊的环境才能跑,这样也会导致反馈周期很长。如果能够降低认知负担,能够缩短反馈周期,岂不美哉?

这条路走下去的坑是什么?编程语言茫茫多,运行时平台年年换,框架和库城头变幻大王旗。这些缩短反馈周期的工具和技术,都强依赖于项目使用的编程语言,运行时平台,框架和库。甚至还有可能要侵入到业务代码的逻辑代码写法。你可以在 Python 中用 viztracer,PHP 中有么,Closure 中有么?给 Html + Vue 好不容易整了个 Vite 出来,迭代速度快了,明天业务就改成用微信小程序了,之前的技术都用不上了。

本文来自网络,不代表站长网立场,转载请注明出处:https://www.zwzz.com.cn/html/biancheng/zx/2021/0524/5158.html

作者: dawei

【声明】:站长网内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。
联系我们

联系我们

0577-28828765

在线咨询: QQ交谈

邮箱: xwei067@foxmail.com

工作时间:周一至周五,9:00-17:30,节假日休息

返回顶部