在這個行當，不做程式員也得懂技術

先來捋一捋思路，關于各個崗位合作打造（移動端）産品的一點想法：

1. 為什麼隻有程式員是不夠的
2. 如何做一個好的非程式員

聲明：

本人是程式員，截止到目前，我用的設計都是自己設計的，我用的産品政策都是自己的思考。

本人并非專業設計師或 PM，如果勘誤，歡迎指正。

本文并非對設計師和 PM 的吐槽，但如果您覺得您作為設計師或 PM 或其他職業者被冒犯了，我隻能說我并無此意，請您立刻關閉此頁面。

首先要消除一下歧義，我們見過無數的一人獨挑大梁完爆數十人團隊的例子，是以事實證明，隻有一個程式員，某些時候是足夠的。不夠背後隐含的是，這個程式員做了很多非程式員崗位的事情，這種情況下其實相當于是一個 Product Creater 在做東西，他（她）不僅僅是程式員這麼簡單。

即便是在移動端出現之前，大家在 PC 上用軟體，也是需要有人來做設計，有人來思考産品的。

使用者完成一個操作，需要做幾次操作，需要做什麼樣的操作，PC 上是滑鼠左擊、右擊、滑動還是其他，移動端是滑動、點按、長按亦或重按。這個産品解決了什麼樣的問題，用什麼方式解決的，其他産品解決了這個問題嗎，它們是怎麼解決的，你和它們相比有什麼不同……這款産品有自己的設計風格嗎，如果是依照平台的風格，那麼有什麼地方沒遵循平台的規範嗎，能不能先破再立，開創一個新的形态……

類似的問題太多太多，于是有了【程式員+設計師+PM】的模型。

最近想明白了一件事情：為什麼身邊好多人我明确地知道他們代碼寫的比我好，但是做不出好東西？

去年 8 月份我做了自己的第一款在 App Store 上架的 App，花了 12 天，2000 行 Swift。這個項目如果是現在做的話，從 0 到打包 ipa，兩天以内，最多 800 行代碼就可以搞定。然而就是這份臃腫不看、風格醜陋的代碼，帶領這個 App 殺進了 App Store 中國區付費榜 Top 50。

還有就是現在的編碼能力相比從前有了十足的進步，面向協定程式設計、函數式程式設計也都有了了解，對可以重構的項目大刀闊斧地更改，改代碼的時候心潮那叫一個澎湃啊，覺得自己寫出了多麼多麼厲害的代碼。等寫完了，冷靜一看，原來不過如此。代碼是變了，App 表現起來和原來并沒有什麼差別，這種努力使用者是看不見的。

是以逐漸開始認識到，代碼和産品是多麼割裂開的事情。當然好的程式員可以把這些事情想辦法聯系起來，融會貫通，知道什麼樣的 App 導航模式可能對應背後什麼樣的設計模式（舉了個不好的例子）。但說到底這是完全不同的兩件事。

做外包的經常覺得甲方很蠢、各種難溝通，所謂隔行如隔山，甲方或許會說出 “這個設計看着不大氣啊” 或者 “我想做一個淘寶那樣的網站，得多少錢” 這樣的話，然後乙方就在内心嘲笑人家，但是身體上還要表現的無所謂，最終把錢搞到手。

但其實真的沒必要這樣，因為對方是來提出需求的，假如讓我進入一個完全沒有概念的領域，比如說挑選木材，我也隻能說我想要像什麼什麼一樣的木材，我叫不上名字的。是以甲方這樣無可厚非。但同時我們也知道，一個好的甲方，我們可能希望他懂技術、懂設計、懂産品，和我們交流起來縱享絲滑。

程式員、設計師、PM 三方對接的時候，其實就是這麼個甲乙方的關系，而理想狀況下，這三方中的任何一方充當甲方的時候，都應該是一個可以進行無障礙對接的甲方。

比如說顔色，設計師眼裡的顔色是這樣的：

KUWAZOME

同樣的東西在程式員眼裡是這樣的：

let kuwazomeColor = UIColor(red: 100/255, green: 54/255, blue: 60/255, alpha: 1)
           

那麼好的設計師應該是以這樣的方式把這個顔色傳遞給程式員的：

# 顔色
KUWAZOME: R 0.39 - G 0.21 - B 0.23
           

而不是：

KUWAZOME: #6B4449
           

作為設計師，你可以不會寫代碼，你可以不知道什麼是 UIColor 什麼是 CGColor 什麼是 NSColor，但是你要知道用你的東西的人此時此刻是以 RGB 或 HSB 的方式用的，而不是 CSS HEX，這是非常基本的要求。再甚者你還應該知道你的程式員使用的 IDE 可能不會幫他補全 <code>/255</code> 這一内容，是以為了讓他不再打出無數個 <code>/255</code> ，你給他的值應該是 <code>R: 0.39</code> 而不是 <code>R: 100</code> 。

那麼作為程式員，你應該能看得懂 <code>#6B4449</code> 是什麼意思，并具有把它轉換成 RGB 或 HSB 數值的能力，這樣可以保證你在遇到了相對糟糕的設計師的時候，也能完成任務。

好的設計師應該把程式員培養成設計領域的廢人，程式員指定圖檔名，設計師這邊把相應圖檔導出，名稱、尺寸分毫不差，并附帶 1x、2x、3x 給 iOS，各種 dpi 給 Android。而程式員這邊即便隻拿到了 .psd 或 .sketch 檔案也能把項目做完。

另外，無論是程式員、設計師還是 PM，都應該了解大家共同面對的這個平台，依然拿 iOS 舉例。

UIAlertController

上面這個是 iOS 系統提供的控件 - UIAlertController，這個東西在程式員眼裡表現起來是這樣的：

let alert = UIAlertController(
    title: "A Short Title Is Best",
    message: "A message should be a short, complete sentence.",
    preferredStyle: UIAlertControllerStyle.ActionSheet)

alert.addAction(UIAlertAction(title: "Cancel",
    style: UIAlertActionStyle.Cancel,
    handler: nil))
alert.addAction(UIAlertAction(title: "Choice One",
    style: UIAlertActionStyle.Default,
    handler: nil))
alert.addAction(UIAlertAction(title: "Choice Two",
    style: UIAlertActionStyle.Default,
    handler: nil))
           

是以程式員此時需要的資訊是：

# UIAlertController
title: "A Short Title Is Best"
message: "A message should be a short, complete sentence."
Action: "Cancel" - Cancel
Action: "Choice One" - Default
Action: "Choice Two" - Default
           

這樣就足夠了。當然你可以把上面那張圖也做出來給程式員預覽，防止出錯，但是你要明白這個東西是 iOS 系統提供的，UIAlertController 是現成可調用的 API，你要做的是隻是提供調用這個 API 需要的參數，而不是做一個一模一樣的 UIAlertController，還把圖檔裁成 1x、2x、3x 以為這個東西是程式員手動做的。如果這個東西真的是程式員手動做的，那麼顯然你應該把 Cancel、Choice One、Choice Two 這三個東西分開提供圖檔資源，否則怎麼可能會有三個可點選的地方？!

又或者說某個可點選控件被點選之後的效果，iOS 有自己的 Human Interface Guidelines，Android 有 Google 提供的 Material Design，你隻要給 Button 提供裡面的 Image 資源就可以了，告訴用戶端開發的程式員陰影模糊幾像素、向右偏移幾像素、向下偏移幾像素是極其不專業的行為。同樣的，作為設計師，你可以不懂 UIButton 怎麼建立，但是你要搞清楚 “iOS 裡面的 Button” 或者 “Android 裡面的 Button” 到底是什麼，了解你的設計應該以怎麼樣的形式被融入到程式員的工作中，這才是設計，否則隻是美工，更何況連圖檔資源都不能正常提供，連美工都算不上。

類似的例子太多太多了……

或許這篇文章的标題還可以改成：

• 在這個行當，不做設計師也得懂設計
• 在這個行當，不做産品經理也得懂産品

不想吐槽，隻想分享一點自己的看法，我覺得真正的專業，不僅是把自己份内的事做好這麼簡單，因為常常和你合作的人并不能把他份内的事做好。