請不要讓程序員在黑暗中摸索

不知道各位有沒有玩過魔獸、X-COM、文明帝國、紅色警惕之類的策略遊戲。

這些遊戲使用了所謂的「戰爭迷霧」。剛進入遊戲的時候，每個玩家的地圖都是被黑暗籠罩的，想要前行的惟一途徑就是不斷的摸索。隨着咱們不斷地移動，地圖愈來愈可見化。

這種戰略的劣勢是：玩家看不到周圍的危險、障礙以及機會。每一次的成功都須要一點點的運氣。

有木有感受這種情景有點熟悉？

「戰爭迷霧」完美地形容了開發人員的工做處境。他們老是被要求去搞定某一段特定的代碼，可是卻不告知任務的相關狀況，等因而在讓他們本身在黑暗中摸索。

對於開發人員，看到「整個的遊戲地圖」頗有必要。對全局有一個清晰的把握有助於他們作出正確的決策。下面這些問題是他們所須要知道的：

• 爲何要建立這個功能？它爲客戶提供了哪些方便？

• 圍繞這個功能的代碼經歷了怎麼樣的一個發展過程？

• 此功能會影響應用程序的其餘哪些部分？

• 這是否會影響業務的其餘部分？

• 咱們如何衡量這個項目的成功（或失敗）？

當開發人員掌握整個框架以後，纔能有針對性地開始工做。他們的深思熟慮謀定然後動很是有助於項目的成功。

同時也有巨大的激勵效應。Joe Stump 總結道：

開發人員對於任務背後的問題每每得本身摸索，這意味着對於給定的對象可能開發人員並不能真正地思考到點子上。

可是若是夠負責的話，開發人員會沉浸於這個問題的思考，由於其工做具體說來，更爲依賴於在商業上的成功。

舉個例子，若是我是後端開發人員，你告訴我去實現一些 API 端點，我須要考慮一下爲何你須要這些端點。

這突顯了了解每一個項目背後的目的和任務的重要性：

• 目的：咱們爲何要這麼作？

• 任務：目標是什麼？作到怎麼樣的程度算完成？

在瞭解了目的和任務以後，開發人員也就成爲了規劃進程中有價值的合做夥伴。他們能夠預見一些潛在的「地雷」，以避免你踩到從而付出高昂的代價。在一篇雜誌文章中，Paul Boag 描述了將開發人員摒棄在一些相關會議以外的危險：

在 Digg 的鼎盛時期，Daniel Burka（Digg 的首席設計師）和 Joe Stump（其主要開發人員）之間就一個 Digg 按鈕曾舉行過一次會議討論。Daniel 想要更改其設計，由於從他的角度看，變化不大。可是對於 Joe 來講，他發現這個小設計將會對網站的性能產生很大的影響，迫使 Digg 由於這麼一個按鈕而升級它的處理能力和服務器架構。

你能作什麼

首先咱們應該負責任地參與到產品、支持和工程規劃的會議討論中去。

並能夠提出本身有建設性的建議，除了應用開發人員，不多會有人注意到應用開發的安全性問題，這時就須要程序員根據本身的經歷、經驗、以及相關研究所得出的結論：藉助專業的第三方安全平臺——移動應用安全智能服務提供商，來達到保護的目的！

會後，咱們能夠建立接下來所須要的有關規範文件。

管理人員不是將軍，開發人員也不是戰士

有時候，管理人員搞的好像這個項目是什麼緊要機密同樣，只給出一些「須要知道的基礎知識」。

可是這種保護措施卻不會致使更好的代碼、更受歡迎的項目，也不會增長銷售。不要讓開發人員在黑暗中摸索，應該邀請他們一塊兒參與到總體的戰略討論中來。