程序員的精神分裂——扮演上帝和木匠
轉自：圖靈教育
哲學園鳴謝
編程可謂是一項純腦力勞動，程序員們專註於代碼，並用它構建起一個虛幻的世界。
而這個虛幻世界可以不大，但世界範圍內的每一個細節都要足夠夯實，甚至是裡邊的一塊磚都要實實在在地被考慮和實現。
所以在編程的過程中，各位猿們往往是一個腦袋，兩種身份！
於是乎，程序員在構建世界的時候，出現了一種獨特的精神分裂現象：起初他像個上帝一樣開天闢地，指點江山，甚是過癮，我們就叫它上帝模式。
可是一旦框架搭建完成，規則制定完畢，世界裡被構建的每一個物種或者建築都要細細地一筆一筆雕刻完成，極度辛苦，我們就稱它為木匠模式。
正是因為這兩種身份的思考方式差異巨大，心情差異也巨大，經常來回切換，不得不讓我們猿們感到「精神分裂」。
那你什麼時候做上帝又什麼時候做木匠呢？
01
上帝模式：開天闢地，指點江山
「上帝模式」，聽名字就覺得很高大上，其實他離大家並不遠。最普通的，當你在設計類的封裝和繼承時，你已經在和上帝打交道了。
程序員當上帝的時候，在幹什麼呢？
處於上帝模式的時候，程序員似乎在充當一個造物者，是他們最有成就感的時候，能極大地感受到編程的樂趣。
上帝模式乾的最主要的工作是，如何把代碼更高效地組織起來。把小的東西組合成大的，添加簡單的東西慢慢變複雜，讓靜的東西變動。
上帝模式中有幾個技術層次。
最底層是類（或結構體）的封裝和繼承設計，還有流程設計。
建立在這之上呢，有各種設計模式。
很多人以為設計模式就頂天了，其實上面還可能有架構模式，就是大家經常用的各種框架。
而架構模式之上，還要考慮到物理架構，到底跑在哪些機器之上。
上帝模式的特點如下。
技術發展不會那麼快。木匠模式的技術，變化周期大概一兩年。而上帝模式的技術，變化周期大概是 10 年、20 年甚至更長。這對大齡程序員是個好消息，因為有充足的時間去消化新技術。
它的知識點比較散，比較虛，讓你列出來吧，又沒那麼好歸納。其中設計模式和架構模式前人已經總結得非常好了。但除此之外，還有好多技巧比較散，不是那麼好把握。很多選擇只能是具體問題具體分析。
由於應用場景不一樣，好壞的標準很難精確，所以最後每個人的領悟可能會不一樣。
即使有提高，但效果不會立竿見影，還需要長期的磨練和檢驗。
積極活躍的技術分享者相對少。
雖然上帝模式的技術，是每個程序員應該追求的目標。不過，這個過程不僅需要持續地嘗試，更需要自己的思考和總結。演示圖如下：
以上步驟，反覆歷練，你定會悟到屬於自己的東西。
和產品設計的爭奪
產品設計原本不是一個獨立的工種，起初是程序員自己兼著干。
21 世紀初，隨著互聯網的迅猛發展，產品設計作為一個專門的細分行業橫空出世了。但就是這麼一個不經意的不起眼的行業細分，讓程序員在上帝模式中退避三舍，這就值得我們好好聊聊了。
上帝模式中的產品設計
在上帝模式中，還有一個很重要的模塊，因為它比較特殊，不涉及編程，但是其重要性不亞於任何代碼的架構設計，這就是產品設計。
從事產品設計的人，即便不管人，也一般稱為「產品經理」。如果程序員想當經理，那麼轉產品設計是個很好的途徑，只要轉過去，就變成了「經理」。
在多次和產品經理打交道的過程中，你可能對產品設計的重要性深有體會。比如，遇到原有設計難以使用的情況，產品經理通過更改用戶操作的流程，大大降低了難度。也遇到過本來挺簡單的事，產品經理為了滿足一個小需求而大大增加了難度，導致整個系統架構變得很複雜。
如今，很多程序員對產品設計者有著不同程度的誤解。
首先，誤解他們就是負責產品的界面設計的。
但情況遠不止如此，你得懂交互吧？你得懂視覺吧？還得懂市場吧？拿產品經理自己的話來說：產品設計的首要職責是決策該做什麼，不該做什麼？要達到的指標是什麼？如何拆分優先順序並落地？上線後的效果跟進以及之後的迭代優化等。界面呢，只是最終的一個呈現。背後的邏輯和思考才是最耗時、最考驗人的。
其次，誤解他們的工作內容至少比編程更容易、更簡單。
實際上不是這樣的，產品設計更需要經驗和靈感。初級程序員寫出來的爛代碼，只要能運行，用戶是不知道的。但產品設計者一旦弄出一個糟糕的設計，其欠缺之處用戶會一目了然，這是躲不掉的。
而且產品經理也要不斷地去溝通和反覆修改自己的設計，這不比程序員調試代碼更容易。
程序員和產品設計者的關係
自從產品經理這個角色誕生以來，他們和程序員的關係變得非常微妙。
在產品設計者的眼裡，程序員就是將他們腦子裡的設計化為實物的勞動力而已。程序員是受他們間接指揮的，每一個細節設計都是對程序員的命令。
產品設計者比程序員掌握更多的信息。產品或項目的規划進展以及其中各種幕後的曲折和妥協，程序員可能都無從知道。此外，產品設計者思考的角度也處於程序員的前面。例如，針對用戶的需求，或者用戶不知道自己有這方面的潛在需求，產品經理會首先將這些東西具體化，程序員得到的是最終的決定。
因此，產品經理和程序員在慢慢的長期博弈中，很自然就佔領了主導權。隨著產品經理這個角色的出現，他們實際上瓜分了相當一部分程序員處於上帝模式中的工作。反過來講，這無形中讓程序員把更多的精力放在木匠模式的工作中，同時也降低了資深程序員的價值。
這聽起來著實讓人沮喪，幸好事情還遠沒有到悲觀的程度。
和 IT 相結合的行業是很廣的，並不是每個行業都有必要請產品經理。實際上，很多產品設計還是由資深程序員兼任的。
對於上層的應用軟體來講，也就是對廣大用戶提供操作界面的程序，其產品設計是非常重要的，好的設計能讓編程架構事半功倍。但軟體領域也是很廣的，並不是所有軟體都是直接面向普通大眾用戶的。例如，在數據挖掘系統中，產品經理基本退化到「項目管理」的功能了，最主要的驅動力還是程序員自己。
而每個程序員也應該具有產品經理的思維。程序員作為第一手的用戶，如果多花點心思去體驗，理應對該產品有最深的理解。所以，如果發現界面設計的問題，應該勇於發表自己的看法。
但請注意：一定要站在用戶體驗的角度去和產品經理爭論，這樣才能佔領制高點。切不可直接站在實現難度的角度去爭論，這是大忌諱！尤其是雙方剛合作處於磨合期時，對方搞不清楚到底是真的實現困難，還是你技術能力不行。
02
木匠模式：致富只有勤勞一條路
程序員在木匠模式下，處理的是最細節、最瑣碎、最具體的實現，每行代碼都一絲不苟地完成，還要確保它們沒有 bug。
在編程中，大多程序員大部分時候是做木匠，扮演上帝的時間其實挺少的。可見，木匠的工作效率對於當前整個項目的開發效率是決定性的。
雖然長期來看，上帝比木匠更重要。但每次輪到當下，木匠又比上帝更重要。
那麼，如何才能成為一個高效的木匠呢？
中華民族 2000 年的歷史告訴我們：想要致富，必須勤勤懇懇，沒什麼捷徑可走。而程序員的木匠模式能力的積累，也是這樣的，沒有捷徑可走。
隨著互聯網的普及，各種木匠模式的資料也得到極大發展，很多資料規整得更好，容易搜到，容易看懂。除非特別前沿的技術，否則針對一般具體問題，你都能比較容易地找到相關信息。尤其是開源代碼的流行，更能直接幫助初學者去提高，去積累。所以，現在的初級程序員比前輩要幸福，上手更容易。
隨著時代的發展，木匠模式的門檻越來越低，也意味著競爭壓力也越大。雖然門檻低，容易學，但並不意味著做木匠很幸福。長期看，木匠很被動，因為木匠們所積累的知識點，隔三差五可能被清零。針對這個特點，剛畢業的程序員會覺得很爽，因為剛畢業就和工作 10 年的人面對差不多一樣的處境。而工作 10 年的人就覺得很受傷，經常被逼著反思要不要繼續程序員生涯。
上帝的生存很優雅，雖然他的工作內容也在進化，但進化的時間軸要慢許多。木匠的使用工具進化很快，稍一懈怠，學習速度就可能趕不上新的變化。你必須認識到：一個程序員若想依靠純技術而體面地度過漫長的中年危機，必須在上帝模式中有充足的積累。
所以各位猿們加油吧！
本周小編再次力薦這本《代碼里的世界觀》，這本也是圖靈編委會老師近期最想讀的圖靈新書 No.1。深受大家歡迎！
作者余葉老師是現任 IBM 的架構師，這是他對自己 13 年編程生涯的總結和思考。沒有浮誇的大道理，都是平時工作中積累下的硬核經驗。除了上帝模式和木匠模式之外，余葉老師也在書中談到，程序員如何在技術成長道路上打怪升級，以及程序員的中年危機如何度過等熱門話題。
TAG:哲學園 |