方法论-从'抽象化的OOP世界'说开去

随着技术的发展,我们现在所接触的大多属于对象型语言,对于开发者来说,能够很轻易的将生活化的需求转换成代码。

在软件设计领域,现在最热的前沿就是所谓“面向对象”的软件。一个面向对象的程序(OOP)实际上就是一个相对去中心化的、模块式的程序。对于一个OOP来说,它的一个“碎片”,就是一个独立成立、保持自身完整性的单元;它可以和其他的OOP“碎片”整合在一起形成一个可分解的指令结构。“对象”限制了程序漏洞所能造成的损害。和那种传统程序不同,OOP有效地对功能实行了隔离,把每一个功能都限制在一个可掌控的单元内,这样一来,即使一个对象崩溃了,程序的其他部分也能够继续运转,而对于传统程序来说,一个地方出了问题,整个程序就会崩溃。程序员可以把这个坏掉的单元换掉,就好像我们可以给一个汽车换刹车片一样。软件的销售商可以购买或者销售各种事先编制好的“对象”库给其他的软件研发人员,后者则可以基于这些库里的对象快速地组装起大型软件,而不用再像以前那样重新一行一行地编写新的代码。而到了要为这种大型软件升级的时候,你所要做的就是升级旧的对象或者加入新的对象。 - KK 《失控》

不仅仅软件是一个相对去中心化的,模块式的程序。硬件也是一样模块化的,如下图的iPhone肢解图。每一个单独的小模块都是由不同的厂商开发,最后在富士康组装的。

obj.png

这跟我们做一个App有区别吗?好像没有。

拿移动App来说,不管是系统,还是第三方开源lib,都给我们提供了很多独立模块。网络请求lib,数据库orm,图片缓存lib,UI组件等等一系列丰富的模块。

做为开发者,我们的职责是做什么呢?像不像流水线上的组装工?app workflow已经定制好了,我们在不同的节点做好相应的拼接就好。虽然说需要那么点技术,但也不算什么高难度的事情。

那么问题来了。你职责能cover的range有多广呢?

  1. 只会安装某个单一零件
  2. 会安装多个零件
  3. 负责一条生产线
  4. 负责整个生产线
  5. 设计生产线组合

这不就是程序员的走上人生巅峰的奋斗历程吗。

在我们掌握了’最小可行体系’之后,下一步该做什么?比如先给自己定个小目标,先挣它一个亿!!!

在一个系统之上做开发,代码只不过是排列组合变成具有特殊功能的载体。就像英语是由26个字母组合而成的。零散的没有生命,牛逼的排列组合却成了创新。但是26个字母的随机组合有那么多可能性,如果没有规则在里面,常人怎么学的会哇。

所以英语就有了前缀后缀与词根来缩小排列组合的范围。汉语就有了偏旁部首来作为规则。在你打算挣它一个亿之前,如果不事先了解这些规则技巧,想想你要花多少的时间去筛选那万分之一的有意义的东西呢。

从0到1的阶段不适合采纳别人的建议,按自己想的来。但往后的优化调整阶段,需要听取外界的反馈,从1到100是非常漫长的过程,想要少走弯路,必需借鉴他人成功的经验。也就是说,站在巨人的肩膀上,自己也能是’巨人’。

巨人可以是大公司,可以是牛逼的团队,可以是技术犀利的老大… 这个巨人越高,你能看到的更远,你的目标也就越明确,也更容易达到。

这些都没有?没有就想办法让自己有啊。没有条件上,就要拼命创造条件去上。

由于从1到100的战线过长,技术更新又那么快,难免会有迷茫。

到底是努力走到100?还是做个斜杠青年掌握多个从0到10?

其实大家都不想成为被随意GC的’对象’,而GC必要条件是不再持有该’对象’的引用。那么为了不被GC,这个对象就得变得重耦合。即每个生产线,每个部门都要持有这个’对象’。要做到这一步,至少需要掌握多个’最小可行体系’。即:上会产品,运营。下会架构,测试,ps。

这样看上去很美好,表面功夫做到位,耦合到每一个部门,但如果某一天忍痛重构了呢。这种无效耦和第一个要被清除吧(Stay最不怕的就是重构,开人也是如此)。如果是真牛逼,他肯定会聪明的做为’门面’(门面模式)对接外部与内部,而不是心力交瘁的盯着内部每一个部门运转。

大家是怎么看的呢?在工作中如何定位自己,是否还有上升空间?不妨想想看吧。

本篇为胡思乱想的番外,我说的,都是错的。欢迎指正。

​推荐阅读:
还需要再学习一门语言吗?
方法论-如何学习一门语言
方法论-最小可行体系

声明:本文为Stay原创,未经允许请勿转载 有心课堂(stay4it.com) 传递给你的不仅仅是技术~