随着技术的发展，我们现在所接触的大多属于对象型语言，对于开发者来说，能够很轻易的将生活化的需求转换成代码。
在软件设计领域，现在最热的前沿就是所谓“面向对象”的软件。一个面向对象的程序（OOP）实际上就是一个相对去中心化的、模块式的程序。对于一个OOP来说，它的一个“碎片”，就是一个独立成立、保持自身完整性的单元；它可以和其他的OOP“碎片”整合在一起形成一个可分解的指令结构。“对象”限制了程序漏洞所能造成的损害。和那种传统程序不同，OOP有效地对功能实行了隔离，把每一个功能都限制在一个可掌控的单元内，这样一来，即使一个对象崩溃了，程序的其他部分也能够继续运转，而对于传统程序来说，一个地方出了问题，整个程序就会崩溃。程序员可以把这个坏掉的单元换掉，就好像我们可以给一个汽车换刹车片一样。软件的销售商可以购买或者销售各种事先编制好的“对象”库给其他的软件研发人员，后者则可以基于这些库里的对象快速地组装起大型软件，而不用再像以前那样重新一行一行地编写新的代码。而到了要为这种大型软件升级的时候，你所要做的就是升级旧的对象或者加入新的对象。 - KK 《失控》
不仅仅软件是一个相对去中心化的，模块式的程序。硬件也是一样模块化的，如下图的iPhone肢解图。每一个单独的小模块都是由不同的厂商开发，最后在富士康组装的。
这跟我们做一个App有区别吗？好像没有。
拿移动App来说，不管是系统，还是第三方开源lib，都给我们提供了很多独立模块。网络请求lib，数据库orm，图片缓存lib，UI组件等等一系列丰富的模块。
做为开发者，我们的职责是做什么呢？像不像流水线上的组装工？app workflow已经定制好了，我们在不同的节点做好相应的拼接就好。虽然说需要那么点技术，但也不算什么高难度的事情。
那么问题来了。你职责能cover的range有多广呢？
- 只会安装某个单一零件
- 会安装多个零件
- 负责一条生产线
- 负责整个生产线
- 设计生产线组合
这不就是程序员的走上人生巅峰的奋斗历程吗。
在我们掌握了'最小可行体系'之后，下一步该做什么？比如先给自己定个小目标，先挣它一个亿！！！
在一个系统之上做开发，代码只不过是排列组合变成具有特殊功能的载体。就像英语是由26个字母组合而成的。零散的没有生命，牛逼的排列组合却成了创新。但是26个字母的随机组合有那么多可能性，如果没有规则在里面，常人怎么学的会哇。
所以英语就有了前缀后缀与词根来缩小排列组合的范围。汉语就有了偏旁部首来作为规则。在你打算挣它一个亿之前，如果不事先了解这些规则技巧，想想你要花多少的时间去筛选那万分之一的有意义的东西呢。
从0到1的阶段不适合采纳别人的建议，按自己想的来。但往后的优化调整阶段，需要听取外界的反馈，从1到100是非常漫长的过程，想要少走弯路，必需借鉴他人成功的经验。也就是说，站在巨人的肩膀上，自己也能是'巨人'。
巨人可以是大公司，可以是牛逼的团队，可以是技术犀利的老大... 这个巨人越高，你能看到的更远，你的目标也就越明确，也更容易达到。
这些都没有？没有就想办法让自己有啊。没有条件上，就要拼命创造条件去上。
由于从1到100的战线过长，技术更新又那么快，难免会有迷茫。
到底是努力走到100？还是做个斜杠青年掌握多个从0到10？
其实大家都不想成为被随意GC的'对象'，而GC必要条件是不再持有该'对象'的引用。那么为了不被GC，这个对象就得变得重耦合。即每个生产线，每个部门都要持有这个'对象'。要做到这一步，至少需要掌握多个'最小可行体系'。即：上会产品，运营。下会架构，测试，ps。
这样看上去很美好，表面功夫做到位，耦合到每一个部门，但如果某一天忍痛重构了呢。这种无效耦和第一个要被清除吧(Stay最不怕的就是重构，开人也是如此)。如果是真牛逼，他肯定会聪明的做为'门面'(门面模式)对接外部与内部，而不是心力交瘁的盯着内部每一个部门运转。
大家是怎么看的呢？在工作中如何定位自己，是否还有上升空间？不妨想想看吧。
本篇为胡思乱想的番外，我说的，都是错的。欢迎指正。
