iOS老司機聊聊實際項目開發中的<<人月神話>>

本文正在參加「金石計劃 . 瓜分6萬現金大獎」

前言

• 有這麼一本書, 計算機學院的大學老師可能推薦過、職場上的前輩可能安利過、豆瓣計算機項目管理類書籍排行榜上可能霸榜過.
• 這本書就是互聯網軟件相關行業從業人員必讀的經典書<<人月神話>>.

• 文章純手打, 拋磚引玉, 如有錯誤還請評論區指正, 先行謝過了:)

  六千五百萬年前, 恐龍這樣的巨獸還橫行於地球上, 現在出土的很多恐龍化石的成因是因為這些遠古巨獸陷入了焦油坑, 拼死掙扎卻越陷越深. 作為一線開發人員, 不論你願意不願意, 我們負責的項目, 都面臨着類似於困住巨獸的"焦油坑". 與很多同事一起開發的項目, 隨着項目複雜度的提升, 慢慢地變得很難擴展更新, 當在原有基礎上新增功能的投入產出比過低時, 就不得不推倒重來. 這種"焦油坑"不單隻出現在軟件開發行業, 其他行業的複雜項目中也有可能發生.

  軟件項目中的"焦油坑"產生的原因有很多, 其中的一個原因就是程序員的"樂觀主義". 我們辛辛苦苦寫了一段功能代碼, 在編譯運行快捷鍵觸發之前, 已經在我們的腦海中過了好幾遍, 內心肯定樂觀的想着, 跑起來肯定沒問題, 但是往往事與願違, 各種報錯產生了. 這是很多一線開發的日常, 羅永浩星巴克表情包.jpg.

  軟件項目中的樂觀主義不止體現在代碼開發中, 項目估時的單位(人/月 或 人/日)本身就是樂觀主義的體現. 如果項目出現延期, 一些PM可能就會想着以"人/日"為衡量標準, 多去增加人手, 在DeadLine之前發佈. 這種做法可行嗎? 可行, 但是有坑! 這種發版往往是各種妥協的產物, 增加人手加班加點, 總得有個產出吧. 問題的關鍵是, 軟件開發這種針對複雜度本身的高級抽象, 往往寫代碼只佔了工作的1/3, 更多的是項目功能梳理、團隊溝通、解決不斷新產生的問題. 這就造成了新增人手可能會帶來新的溝通問題, 培訓熟悉項目也需要很長的時間. 慢慢地這種大型項目就如同遠古巨獸那樣, 陷入了項目上的"焦油坑".

  生活中我們都渴望民主, 做抉擇時並不希望被強權控制. 但是這種民主不適用的地方有很多, 比如做手術時, 你是想有一個主刀醫生把控全局還是希望一羣醫生相互討論? 我想我應該會選擇一個主刀醫生的"貴族專制". 能成為主刀醫生本身就代表着經過了無數的手術試煉, 是可靠的. 同樣在軟件項目中, 作者認為也需要一個類似於主刀醫生這樣的"貴族專制", 那就是軟件行業中的"架構師". 架構師需要一直跟着項目才能對項目的架構有個具體深入的理解, 架構師應該對一些關鍵問題做技術把控及拍板決策, 這樣就能讓項目擁有"概念完整性". 在項目的生命週期中, 文檔應該跟着項目一起成長, 每次版本更新都應該對應着文檔更新. 好記性不如爛筆頭, 有了一個好的文檔體系, 才能讓項目開發人員夠做到心中有數. 以後面對需求變更, 也能根據文檔更加從容, 避免把過去做過的功能重複做浪費寶貴的人力資源.

  "溝通"在各種複雜項目中的作用, 可能比行動落地本身更加重要. 溝通能力並不只是一個"軟技能", 同時也是技術能力的一個體現, 因為只有真正能理解一些技術底層, 我們才能把一件複雜的事用"簡單"的方式"説出來". 這也就是所謂的"説到點子上", 抓重點. 在多人合作時, 溝通的作用就顯得更為重要, 你不但要自己明白, 還要能跟團隊夥伴們解釋清楚. 人都不是機器, 在團隊溝通的過程中, 我們還需要考慮到當時的環境上下文場景, 順勢而為方能事半功倍. 溝通的過程中, 我們可以利用各種工具, 比如説功能"流程圖", 但是流程圖的作用在作者看來也不能被一味地神化, 流程圖也不是解決項目管理問題中的特效"銀彈". 流程圖只是方便溝通, 並且不能太複雜, 最好一頁紙畫清楚.

  除了功能流程圖我們還有很多的備選"銀彈", 比如高級語言、OOP(Object Oriented Programming)、POP和高性能的機器, 只是解決了軟件項目中的次要矛盾. MOP市場驅動開發往往才是我們面臨的實際問題, 我們開發的項目是給用户使用的. BOP(Boss Oriented Programming)面向老闆開發也不能長久. 有沒有完美解決軟件項目中的"銀彈"? 作者的觀點是悲觀的, 沒有普適的完美解決方案. 只有適合各個項目的接地氣解決方案, 這顆"銅製子彈", 需要我們實時的跟進, 定期的補充, 不斷地優化~

發文不易, 喜歡點讚的人更有好運氣👍 :), 定期更新+關注不迷路~

ps：歡迎加入筆者18年建立的研究iOS審核及前沿技術的三千人扣羣：662339934，坑位有限，備註“掘金網友”可被羣管通過~

本文正在參加「金石計劃 . 瓜分6萬現金大獎」