狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

前言

知乎上有一個提問：在小公司編程是一種什么樣的體驗？

今天，我們就這個話題，一起來做個討論。

這里有沒有曾經待過小公司或者現在正窩在小公司的程序員？如果有，這個問題相信你是最有發言權的。

一個軟件產品從前期的調研到中途的開發直至最后的發布環節，不知道整個鏈路跟蹤下來，你是否感覺這中間的每一步步驟你們都做的足夠規范？哪些環節是你忍不住想吐槽的？歡迎大家在評論區，展開討論。

我的回答

我自己曾經經歷過人數在0-50的小公司多年，后面也經歷過人數超過10000的大公司，結合我自己的背景，來嘗試著回答一下這個問題。

我覺得在小公司編程，最大的優勢當然是靈活了，你要做一件事情，不用受太多條條框框的束縛，想干就干。開發同學的技術選型，也基本都是開發同學自己說了算，比較自由。

但缺點也比較明顯：沒有統一規范作為制約與指引，每個人基本都是按照自己的喜好來做事，本著怎么方便怎么來的原則。所以容易出現信息不對稱、溝通效率低下，最終也及其容易引發諸多安全事故，給公司造成不可估量的經濟損失。

這里所謂的“規范”一詞，我認為一般涉及如下三個方面：需求階段、設計階段、發布階段。

接下來，讓我們一一來拆解一下。

需求階段

正常來說，產品經理在調研完相關需求后，經過自己的整理，最終會形成一份完備的需求文檔。然后他會組織相關人等(開發、測試等)進行第一輪的需求評審會議，目的也是想和大家對其一下本次需求的內容事項。

如果需求內容本身比較簡單、清晰明了，一般一輪會議就能敲定。開發理解了需求后，就可以進入下一個階段，比如詳細設計。(遇到比較復雜的業務需求，可能需要經歷多輪討論，經過多次修訂后，這個需求的內容才能真正確定下來)。

注意，上述一切都是在比較規范的前提下展開的。但往往很多小公司，是做不到按部就班按這個流程來走的。

有些小公司或許也有產品經理一崗，有的產品經理，前期也會簡單的整一份需求文檔。在文檔中，簡單的用純文字描述一下，本次待開發的需求內容。至于拉會評審這一環節，是沒有的，他會選擇直接把整理好的文檔，丟給開發同學，然后附言一句：如果有問題，可以隨時找他溝通。

開發同學，拿到文檔，在還沒看之前，其實是很懵逼的，完全不清楚要干什么，里面有多少內容。懷揣著忐忑的心情，只能硬著頭皮打開文檔。(我們固然希望里面的內容越少越好，至少看下來，不要讓我們有猜測的成本)

事實證明還是我們一廂情愿了，那一段一段密密麻麻的文案，看的真心想吐，很多時候真的要多看幾遍，才能明白，文案想表達的意思。

整個文檔，肯定會有幾處地方，是不得電話或當面溝通，才能明白它的意圖的。

如果你說這很糟糕啊，那我想跟你說的是，還有比這更甚的。有些需求壓根你就看不到文檔。產品同學就直接在聊天工具里面，密密麻麻、啰啰嗦嗦的把他想要的需求內容，輸出給你，當然最后也會附上那句熟悉的話：如果有不明白的地方，隨時可以找他溝通，24小時在線。

還有就是關于需求的迭代或功能變動(最可怕的是，完全推翻重做)，小公司基本都是某些人一兩句話的事情，然后就要開發評估工作量，并要求用最快速度上線。

編碼設計

在座的各位，不知道有沒有在編碼之前，有做詳細設計的習慣。大公司一般團隊內部都有規范，在編碼之前，要求先撰寫詳細設計文檔，等你寫完后，需要組織相關人等，進行設計評審。評審過后，你才能進入編碼工作。

當然我相信，很多小公司，其實壓根就不存在這個環節。等整理完要開發的需求內容之后，一般直接就開始擼代碼了，如果真的遇到問題，他們會停下腳步，做一番思考，實在搞不定，再找人尋求幫助。

這里有什么問題？大家不妨先思考一下。我覺得對于一些簡單的功能需求(工作量在3天以內的)，直接擼代碼，也沒多大問題。為什么？因為這本身就說明，此次待開發的需求事項，內容比較清楚、明確，產品本身確實只需要用一兩句話，就能描述清楚，開發同學，看了需求后，也胸有成竹，知道自己具體要干什么。

但，對于復雜的需求，比如工作量在1周甚至兩周以上的那種，不寫詳細設計文檔，我認為可能會是個災難。因為直接編碼，那么注定前期你根本沒時間經過深思熟慮的思考，很多細節難免會有遺漏，沒考慮進去的情況。一些方案選型，在沒有充分調研、預演的情況下，說用就用，后期做著做著又發現滿足不了，只能返工，推到重來。

而所有的這一切，如果前期，你都能在文檔中體現出來，然后在評審會議上一一與大家做介紹。那我相信，一些問題，一定能提前曝光出來，然后團隊內部，就可以提前做一番討論，最終，把相關方案給敲定下來，這樣后期的開發，就會順利很多，不會出現時不時卡頓、返工的情況。

發布階段

開發同學完成代碼編寫后，就進入了提測階段。等測試同學按照他們的用例測試、驗證完后，最后項目就進入了發布階段。

大公司一般對于發布這件事會比較謹慎，比如會有同學，需要撰寫相應的發布計劃：上面需要詳細羅列清楚此次發布的內容；發布的注意事項；同時也要做好回滾計劃，萬一新功能上線，影響了原有的功能，那需要立即代碼回滾。

發布也需要提交相關申請單，等相關審批人員審批通過后，然后在具體時間段，正式進行發布。(根據自己公司的業務情況，避免在高峰期發布，影響業務穩定性)
但一些小公司，這一塊就比較隨便了，發布是隨時隨地、一句話的事情。而且開發同學一般都有較大的自主權。

他們可謂超級管理員的存在，數據庫表結構可以自己隨意新增、修改；線上數據也可以自己隨意訂正；想要發布，一個命令的事情，也完全不管什么業務高峰、低峰期，想發就發。
有時候，還蹭別人不注意，偷偷的發，當不經意發現自己寫的某個線上bug，做到神不知鬼不覺。

~END

本文內容摘自公眾號：「陶朱公Boy」一文，歡迎關注與轉載，轉載請保留出處。