開發與設計中那些共同的隱喻
設計師/產品經理：“他會在萬眾矚目中出現， 身披金甲圣衣， 腳踏七彩祥云，咔咔咔把我的設計全部實現!”
引子
偶然跟設計師同事聊天，談到他們眼中的程序員應該是什么樣的。
大叔：“好的程序員不應該三心二意，上來就學很多不同的語言，應該精通一門語言!”
小九：“那設計師會在Photoshop，Pixelmater，Sketch，balsamiq等等這些工具中，只精通一樣，而不去學習別的嗎?”
大叔：“這不一樣，編程語言怎么能跟這些工具相提并論，比如Sketch比較適合快速實現一些Hi-Fi的高保真原型，Photoshop善于處理位圖，balsamiq用于畫一些Low-Fi的線框圖，這些工具都是在不同情境和需求下使用的。”
小九：“我倒覺得這跟編程語言一樣一樣的。當需要寫后臺服務端的時候，我們用Java;要快速寫工具腳本的時候用Ruby;要寫頁面交互的時候用Javascript;要寫底層高性能代碼的時候，用C或者C++。每個語言都有自己的特點，也有自己的使用場景。設計師應該不會說只要精通Photoshop或Sketch，其它工具就不用學了吧。怎么能為了一滴水，而放棄整片海洋!每一種設計工具都有自己獨特的魅力，在學習中都會體會到不一樣的樂趣 ”
語言/工具 vs 特性
熟悉PS的都知道，Photoshop中有濾鏡、蒙版、圖層等一系列特性，我們也往往是先學習工具，順便就學會了這些特性。然而，其實這些特性比工具本身具有更高的復用性。現在幾乎任何一款繪圖軟件，都會帶有圖層功能。
程序員也一樣，往往是從語言開始，來認識語言的特性的。比如我們學習了C++，順便知道了Template;從Java中知道了Exception的處理方法，從Javascript中知道了閉包，從Scala中知道了Monad等等。這些特性、思想在程序設計中的應用往往要比語言本身更重要。
除了語言，其實還有一些別的，也是程序員和設計師可以類比的。
思維方式
在程序世界里，有3種比較經典的編程范式：面向過程，面向對象和函數式。
- 面向過程的編程范式，簡單的講就是把一個大的任務拆分成N多個步驟，只要一步步從上到下的實現即可。
- 面向對象則是把所有程序中的概念都想成是一個個具體的對象，每個對象有自己的屬性、行為，每個對象可以完成自己應該完成的一些事情。通過對象間的彼此互動，來完成復雜的功能。
- 函數式則是更側重于用數學函數的方式來思考，把現實中的復雜問題轉換成各種不同類型的函數，通過數學的思維方式來解決問題。
這是程序員的三種不同的思維方式，而映射到設計師，可以理解成平面設計師習慣的平面思維和工業設計師習慣的立體思維。
模式
程序世界中的設計模式，是前人大量經驗的總結，是在實戰中形成的一些在面對具有一定共性的問題時所采用的***實踐。
在產品設計中，也同樣有一些模式可以遵守，比如現在的提醒功能，往往會使用內含數字的小紅點模式。
再比如說消息通知功能，往往是采用消息中心的模式 。
再比如說一些常用的組件，如輸入的文本框，在交互上共有諸如auto suggestion之類的模式。
有了這些模式之后，不管是在做程序設計還是界面設計，都可以有效的降低設計的復雜度。
Clean Code -|- Human Interface Guidelines
大部分情況下，我們不是一個人工作，而是一個團隊工作。
作為一個程序員，我可能會閱讀、修改團隊內任何一個人的代碼，這時候一套統一的規范就很重要，而《Clean Code》就是這么一套規范，讓我們寫出的代碼可讀性大大提高，便于團隊彼此共享編輯代碼。
而作為一個設計師，也有這么一套規范，比如iOS中的《Human Interface Guidelines》，或者Android的Material Design，這些規范用于指導我們在做界面設計的時候該如何選擇合適的控件，應該有何種樣式，如何在界面中合理的布局，并在團隊中形成共識，好讓大家可以在同一個工程中協調工作。
***
綜合上面說的：看起來程序員和設計師的工作好像差得很遠，但其實大家做的事情是有很多相通之處的。細細體味其中的不同，可以填補之前一些unknow unknow的空白，說不定還可以給你現在的工作帶來一些新的靈感。
【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】
