隨著技術的發展，我們現在所接觸的大多屬于對象型語言，對于開發者來說，能夠很輕易的將生活化的需求轉換成代碼。
在軟件設計領域，現在最熱的前沿就是所謂“面向對象”的軟件。一個面向對象的程序（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最不怕的就是重構，開人也是如此)。如果是真牛逼，他肯定會聰明的做為'門面'(門面模式)對接外部與內部，而不是心力交瘁的盯著內部每一個部門運轉。
大家是怎么看的呢？在工作中如何定位自己，是否還有上升空間？不妨想想看吧。
本篇為胡思亂想的番外，我說的，都是錯的。歡迎指正。
