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

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

前言

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

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

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

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

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

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

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

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

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

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

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