程序员|让我们遍体鳞伤的“程序员思维” 银行

文章图片

文章图片

最近在看文章的时候，发现了很多关于 “程序员思维”的讨论，这是感觉上被大肆吹捧的“思维模式” ，有的观点认为掌握了这种思维模式，就能让人变得“聪明” ，还有一种观点认为现在世界正在悄悄地被“程序员思维”所吞噬。个人感觉，这是一种很无聊的说法。
首先， “程序员思维”并没有一种被广泛认可的解释，就个人认识来看，其构成主要包含三个部分：抽象业务逻辑并转化为流程，使用判断保证流程的正确性，以及借助前人的轮子重新认识世界。
抽象业务逻辑并转化为流程，这是很多程序开发者每天的工作之一，具体的过程类似于：用户想买一个苹果，那么我就设计一个流程，确保用户能够执行注册、检索（找苹果）、选规格下订单（买一个还是一斤）、完善快递地址、付款直到最后的收货。嗯，这样看起来，很有条理性，对，条理性，这是程序员思维的一大优点。
使用判断保证流程的正确性，这是对上述流程的一个补充，比如，如果用户并不在配送范围（加钱都不行，比如人在南极），那么在上述的“完善快递地址”这一步完成后，会通过判定地址不在配送范围，而阻止用户付款，从而规避后续发生的一系列问题。嗯，这样看起来，很严谨，对，严谨性，这是程序员思维的第二大优点。
借助前人的轮子重新认识世界，这是一种工程化思维， “万物皆工具” ，如果我没有，最方便的就是直接用别人现成的轮子。就像，我们没有办法由于我们自己的物流太弱了，完全无法满足新增用户的需求，从而导致了各种各样的问题。这个时候，我们发现设计模式中有一种叫做“委托”的模式，嗯，为什么不直接把“配送”这个环节委托出去，让我们不再关注我们不熟悉的业务，而专注做我们的交易平台呢？嗯，这样看起来，很有思路，对模式的复用，让程序员看起来能够更加聪明的解决业务问题。
综合上述三点，我们发现具有“程序员思维” ，会让我们更加有条理，更加严谨，甚至更加“聪明” 。这么看起来，这种思维模式很棒啊，这种东西不应该立即被广为推广，甚至应该把编程作为高考的一部分！
换个角度，程序员的烦恼或者程序员的痛苦是什么？可能很多人会说是“需求变更” ，而“需求变更”的本质是什么？是我们没有解决“根源”问题，是我们甚至没有找到“根源问题” ，是只有一次一次的变更，才能让我们更加接近所谓的“根源问题” 。
举例：我是一家锁具公司的开发人员，我们公司现在陷入了一个困境就是越来越多的用户向我们反馈“忘记带钥匙，找了专业拆锁的人员，也拆不掉锁，最终只能破门而入” 。 “锁的安全性”本身就是就是我们产品的一大卖点，然后我们应该如何解决这个问题？或者说用户的真实需求是什么？
我方预估需求1：降低安全性，在不破坏门的情况下，能够拆出锁具，但要承担不实宣传的法律风险。
我方预估需求2：保证安全性，在各城市找代理，能够使用专业工具，在不破坏门的情况下，安全拆除锁具。
我方预估需求3：与某银行建立合作管理，利用其贵重物品保管服务存放我方用户的钥匙，并考虑让银行提供限时配送业务。
我方预估需求4：降低安全性，向自动取款机学习，使用钥匙或者密码的开门方式，忘记带钥匙，使用密码开门。
我方预估需求5：引进生物体征技术，使用钥匙或者密码或者指纹或者人脸或者瞳孔识别等不同技术，通过设置不同的验证策略，进行开门操作，几乎杜绝此类问题。