謝邀。我覺得這是個很好的問題。
雖然都叫程序員，但是感覺程序員的世界天差地別。比如我是做系統(tǒng)的，可能做的就更偏工程一點。目前大概我一般項目的工作流程是這樣：由PM或者由我自己提出做一個項目，寫一個一到兩頁紙的proposal，大概就是目的是啥，要解決什么問題有什么好處，highlevel的方法要怎么做，然后給上層頭頭們審核，這個項目是不是有意義，是否值得做。如果這個項目大佬們說OK，然后我作為程序員會寫詳細(xì)的項目設(shè)計，從幾頁到幾十頁都寫過，會寫詳細(xì)的項目背景（有哪些類似項目，為什么要做這個項目），項目預(yù)期的scale是什么樣的（比如有多少Q(mào)PS），需要多少資源（多少人來做，多少服務(wù)器，多少內(nèi)存，多少CPU），具體項目的設(shè)計（比如API，存儲的數(shù)據(jù)結(jié)構(gòu)），可能的設(shè)計方案ABCD之間的tradeoff等，測試方案，預(yù)期效果，大概開發(fā)進展安排（幾周做完哪一步）。有時候為了寫這個，要做很多數(shù)據(jù)分析，甚至要做原型系統(tǒng)。寫完之后就找人審核，修改。比如有專門做security的組會來看有沒有安全隱患。比如要和用戶通信采集數(shù)據(jù)會有律師來審有沒有用戶隱私或者法律上的問題（這部分主要PM做，但是如果問到技術(shù)細(xì)節(jié)還是得程序員上）。然后還有其他高級別程序員一起開會討論方案，最后敲定ABCD到底做哪個。大家都同意你具體設(shè)計后，比如所有相關(guān)審核的人都signoff后，就照著設(shè)計開始開發(fā)咯。這時就是大概某種程度上不太需要動腦子的業(yè)務(wù)邏輯實現(xiàn)了，畢竟有時候原型系統(tǒng)早就寫好了。然后全部寫完后，就準(zhǔn)備測試上線了。最開始小規(guī)模，比如內(nèi)部測試，看看和最開始預(yù)期的效果是不是一致。如果不一致要分析，是當(dāng)時估算方法有問題，還是實現(xiàn)有問題?？纯从袥]有新的問題，怎么改。然后小規(guī)模外部測試，繼續(xù)看和預(yù)期是不是一致，收集運行數(shù)據(jù)。所有數(shù)據(jù)都非常優(yōu)美之后，找大佬做最后上線Review。然后因為我們做系統(tǒng)嘛，正式上線布置啥的，比如安排服務(wù)器啥，是由另外的組專門做，我就不管了。上線后維護，修Bug，不過這時其實一般比較輕松了。以上每個階段都可能迭代多次，或者被大佬把項目整個砍掉。估計絕大部分程序員和我們不太一樣，所以我說程序員干得活天差地別。順便隨著級別的升高，可能更多要干的事情是審別人的設(shè)計，負(fù)責(zé)找漏洞，提建議，帶小朋友做。而新手雖然也會走全過程，但是一般由更資深的帶，并且項目規(guī)模相對比較小。