不寫業務代碼的程序員工作內容是什麼樣子的？

01-14

本人是一隻今年7月畢業的本科生碼畜。目前在寫業務代碼，大致內容內容就是：用mvc框架，寫html、css（基本都是用bootstrap）、js（jquery），然後用C#實現一些業務邏輯，db的話用Entity Framework或者寫存儲過程。
自從上了知乎，發現我這類被歸為碼畜。十分不甘心，想有所轉變。所以想知道不寫業務代碼的大佬，日常工作中寫的都是什麼樣的代碼，實現什麼樣的需求？（順便能給個學習方向就更感激不盡了。）

1、這是一個好問題。

2、不寫業務，就只能寫基礎架構中的功能模塊，或者做模塊優化。

3、模塊優化，往往就要向c/c++、演算法、指令上使勁了。有這塊需求，要麼公司大、並發高，要麼業務少、性能要求高的商業技術方案，要麼是核心模塊。看你拿得動么？

4、設計並實現功能模塊，要麼架構師把所有介面細節全部規定好，要麼自己兼一部分介面細節調整設計。接收什麼樣的數據、返回什麼樣的數據、同步/非同步，跟業務邏輯息息相關。

5、架構抽象和業務抽象。業務寫多了，就會發現一部分操作流程是可以抽象出來的，一部分變成業務流處理，一部分變成架構設計。如何抽象、現有抽象好不好，很大程度上取決於業務複雜度如何。沒有一定的業務經驗和業務複雜度鍛煉，很難做好架構設計。

6、業務解讀與解構能力。做架構、寫模塊是需要一定前瞻能力的，因為需求是一定會變的，猜測需求的實際用途、預留多少彈性是需要大量實踐經驗的事情。

7、關鍵不是寫不寫業務，是要多想、多想、多想....

用「金融衍生品」的概念打個比方，非業務代碼可以叫做「業務衍生品」代碼，因為最終所有事情都是要和業務掛鉤的，不能提升業務價值的事情都是泡沫。

無論是做 UI 框架、分散式存儲還是做 CDN、數據中心，都是要為業務服務的。跟直接做具體業務的區別是，這些技術有可能能夠服務於多項業務。

如果你想做這樣的事情，你最好去大一點的公司，否則你沒有足夠多的「客戶」來支撐你的開銷。所謂「客戶」，其實就是指具體業務。你永遠要記著，你的開銷必須小於客戶能夠得到的回報，因此客戶不夠多不夠大，你就沒有事情可以做。舉個例子，如果你們公司只有一個產品，那就沒有必要做太複雜的 UI 框架了，因為做出來也只能服務於一個產品。但如果你們公司有眾多產品線，那性價比就不一樣了。再舉一個極端例子，數據中心之間的大規模數據傳輸是只有 Google 這個量級的公司才有的問題，對於一個只有幾台伺服器的公司來說你能解決這個問題也沒必要解決。

想做這樣的事情需要有一定的抽象能力，能夠找到業務的共性，然後解決多項業務共有的問題。

基本上就是每天閱讀剩下幾千個寫業務代碼的人的代碼，看看他們都在幹嘛，好造輪子。

你們不要反覆邀請我了呀。。。。我是老碼畜。04年開始搞業務代碼，直到現在，也只是精進如何讓業務代碼更容易寫而已。

知乎用戶千千萬，學生用戶一多半。再加上些剛工作的小朋友。他們能見到的世界，就是他們能講給你聽的世界。他們是無法理解業務架構設計，domain knowledge這些的，他們眼中只有他們能看到的那些而已。知乎編程三板斧唄：一言不合寫操作系統，一言不合寫編譯器，一言不合看spring源碼。

碼畜就碼畜唄，碼三葉蟲，碼單細胞也好。搞業務的是大多數。難道程序員世界，那麼多公司的中高級程序員，都是不搞業務的？天天造輪子？怎麼，這是編程界，還是米其林世界？

改開源框架，改開源輪子，覺得不好用，造自己的框架，造自己的輪子，然後各種吹逼給別人用，然後運維，然後加feature，然後Devops，然後oncall，然後猝死

估計就是這位老哥的樣子

圖片來源網路，侵刪

那就是做演算法和框架的。

1、架構師

我們公司是做幫歐美那邊的客戶做醫療設備支持的桌面和移動軟體公司。

公司PC端框架非常老，是03年幾位嵌入式大神開發的。據說當時是因為更多地考慮醫療設備對接的問題。

由於UI以及底層高度耦合，後面的人一直沒能參與修改，都是小增小補，敢修改底層立馬給你報n個bug…

玩嵌入式的開發桌面軟體…各位可以腦補一下框架多糟糕…

去年，公司重組了一個小組，旨在重構整個項目架構。我是被抽去的其中之一。

那是心理暗爽，以為自己終於脫離業務了變身架構師。準備走向人生巔峰。

沒想到更酸爽。

1.設計架構，依然要參考原項目。

由於醫療設備對接軟體涉及非常多的心電血氧之類的演算法，所以還是要拿原來架構參考，每時每刻都在琢磨別人寫的爛代碼，然後自己再寫一遍更爛的代碼。

尤其是老代碼而且沒有過多注釋，一個宏函數就能琢磨一個上午。簡直心累

2.寫業務是面向需求，寫架構時是面向開發人員。

跟寫業務不同的是，框架的每一個介面都必須完完整整地注釋，並且寫說明文檔。還得得按照規範格式。

以前寫業務最多簡單注釋就行，現在

還要琢磨怎麼讓業務組那幫龜孫子以及後來的新人看得懂自己弄的屎。

其次，由於面向開發人員，必須以他們角度思考，或者怕他們不明白某個介面作用，還得特地親自寫一大段。

大部分時間並不是在編程，而是思考和寫文檔。

3.思維不同，更多考慮全局和底層。

寫業務，遇到不懂基本靠百度就行。最多一本語法書。

寫架構身邊常備各種參考書。什麼圖形學設計模式uml之類大學的書都搬來了。

做了架構設計才知道，API設計有大學問，每一個細節都必須死摳。介面命名，參數列表，回調函數虛函數，每一個都能搞死不少腦細胞。

再加上這種軟體涉及各種心電圖，血氧，心跳之類的數據，所以對數據精度要求非常嚴格，簡直是每天的噩夢。

（要是有什麼重大失誤，客戶那邊死了人我們擔當不起）

每天都在高度燒腦。頭髮掉了不少。

3.協同性

寫業務各寫各的，最多偶爾互通一下。

重構是整個小組跟著我們組大神一起行動，而且任務高度耦合，小組每天能產生爭論，從早上吵到下班。

一個singleton就三四種寫法你不服我，我有我的理。

不過完成後還是挺爽挺有成就感的。

年底上線後，每次看著研發部那幫龜孫屁顛屁顛跑過來專門問架構問題，一口一個大佬前大佬後地圍著轉，心理還是暗爽，2333333

當然…還是要經常要幫他們擦屁股( ￣??￣? )

——————分割線——————

再說下做演算法的吧。

我們公司的演算法部基本都是在我們公司的實驗室工作，由於工作關係，跟他們打交道還挺多的。

估計整個公司最清閑的，除了人事部那兩個妹子，就是他們了…

1.演算法部的同事大部分時間在做實驗，每次去實驗室，基本都看到其中一個身上各種儀器，插著各種管子。其實工作也沒啥，就是記錄下數據。

2.偶爾會看到他們在看論文資料。其實只是借口，大多數時候在上網刷微博。

3.極少寫代碼，曾經看過他們用過matlab，除此之外就沒見寫過其他了。

4.都是牛逼哄哄的大神，牛逼哄哄的出身。一個留美回來的博士，其他全部985碩士。而且都有孩子了…跟我們這幫單身屌絲氣質完全不一樣

聊天

把軟體工程的理論和實踐學好，根據自己擔任的角色來決定自己的工作範圍。

需求分析?需求定義?構成管理?計劃立案?功能分析?簡單設計?詳細設計?編碼?單體測試?結合測試?系統測試?運營測試?運營維護

憑藉你的程序員經驗，軟體工程的每個階段，都有你發揮的空間。不寫業務代碼，對應不同的階段，你可以做下面的事情。

與客戶溝通，決定需求的取捨
設計原型，驗證項目的可行性
功能劃分與基礎框架的定義與邊界劃分
設計軟體架構
項目配套的持續集成與自動化管理
review設計文檔
review代碼與重構
測試範圍與指南的定義
性能指標等的定義
培訓新人與項目干係人

之前是一直圍著 API 轉，各種封裝 API 並給 API 加功能。

現在是也是圍著 API 轉，各種給客戶解釋 API 的功能。

寫運維工具,寫監控工具,寫通用框架,負責各類中間件...

見識尚淺，不比較評價寫業務還是造輪子，講下自己的經歷供題主參考。

上學期間先後在三家不同領域的公司實習，寫過java，c#，js，vb。業務領域橫跨電信，建築，搜索引擎。畢業後決定做底層一些的工作。

幾年來，參與了一些項目：

分散式配置管理：Qihoo360/QConf
類Redis大容量存儲：Qihoo360/pika
分散式KV存儲：Qihoo360/zeppelin
一致性庫：Qihoo360/floyd

每個項目都可以說是在造輪子，但每個項目都有實際針對的需求場景，在公司內廣泛使用後也在社區獲得不少的關注。

日常工作主要包括：

自研系統的設計，開發，測試，維護
優秀開源代碼的閱讀學習
基礎知識學習積累
領域論文的精讀泛讀

不定期的會寫一些博客積累總結：Welcome | CatKang的博客，歡迎閱讀交流

看成了「不務正業的程序員……」

我是做端游的。現在純遊戲的業務代碼確實寫的比以前少了，但也並不算完全脫離遊戲，主要做一些偏基礎的模塊，甚至還包括更外圍的一些東西。

說白了也就是造一些輪子……

比如把遊戲的UI全套腳本化與插件化，最終形成類似魔獸與劍三類似的UI插件框架，讓策劃也能寫UI。

進而更激進的把客戶端也腳本化了，抽象出了一套模塊機制，主要支持熱重載，改了代碼也不重開客戶端。

後來又被抓壯丁，給遊戲加過場動畫功能以及配套的編輯器。完成編輯器後要加個畫面實時壓縮與視頻導出，研究了一番ffmpeg與nvdia的GPU視頻壓縮。

基於各種原因，組織決定拋棄Scaleform，於是實現了一套遊戲UI框架，對上層腳本透明，完成以後無縫切換至新UI。期間做文本的排版真是被虐的要死要活，集成CEF到客戶端實現web瀏覽也遇到不少坑。

以後就是做各種優化。LUA的性能調優啦，內存使用調優啦，GC機制的調優啦，貼圖顯存的優化啦，等等等等。

沒寫具體遊戲業務邏輯的結果就是，我是一塊磚，哪裡需要往哪搬……

其實都沒差，其實同樣也是業務代碼，只是業務不一樣了而已啊……

刷題，刷知乎，刷github，刷書

什麼是業務代碼？

對金融應用來說，對賬算業務。

對政務來說，政府要求算業務。

對電商來說，出貨算業務。

對中間件團隊來說，保證穩定，高可用，安全，算業務。

對資料庫開發人員來說，事務，強一致性，算業務。

對前端人員來說，css，像素，位置，算業務。

即使對編譯器的開發者來說，也是在解決業務問題。

很多人反感寫業務代碼，不樂意熟悉業務，我也理解，太複雜，技術含量不高，天天變來變去。我之前也這麼想，現在卻有些改觀了。

你更想做什麼樣的業務，更想做偏「技術」方面的業務，是嗎？

你所說的業務，是更「框架」類的東西，是嗎？

下面的東西很重要！

對於大部分甚至絕大部分人來說，平台，決定了百分之九十的事情。你找了一個寫業務代碼的部門，基本上就只能安靜的寫業務代碼。所以那句話叫：選擇比努力更重要。我認為這話有道理，你有異議，我也不反對。

所以如果不想寫業務代碼，就去找一個非業務代碼的平台，去工作。

如何找一個「非業務」的平台呢，非常方便。現在所有的有實力的公司，最缺的是什麼？是人！他們比你渴望一份「非開發」工作，更渴望招到幾個靠譜人。所以他們玩兒命的寫軟文，出書，開發布會，開技術峰會，各種搞事情，各種催牛逼，就為了能吸引一下你的眼球。

有幾個技術峰會的分享，不是催完牛，順便招個聘的。

你想去，有人想要，那麼問題來了，怎麼去呢。總得面試吧。

面試能過嗎？

不好意思，百分之九十，過不了。因為我面試的，百分之九十多，都要pass。我們也單獨開會討論過，是不是要求太高。

不是！

學歷，本科以上，這個是不是非常高。經驗，三年以上，很高吧，要14年以前工作的呢。然後就高了。

問：除了傳統關係型資料庫，你用過什麼存儲。

大家都提hadoop。

問：除了使用，你還對hadoop做過什麼，晚上睡覺的不算。

然後就下一個問題了。

問：你們應用的高可用怎麼做的？答：對不起我聽不懂(一般沒有這麼直白)。

問：如果你們的資料庫宕機了，你們的應用會怎麼樣？

答：不可用！(如果能直接告訴我，我感激不盡的)

問：redis為什麼讀取速度快？

答：因為內存的呀！(我也沒說和誰比啊)

……

回過頭來，說說每天寫題主所說的不寫「業務」代碼，工作內容是什麼樣的：你來體驗一下啊，親。

看論文，看代碼，然後粘在一起，改改參數什麼。

逃～～～

大概是這樣？

騙你的，上面還是業務代碼...

跑題了，以後回來更新。

怎麼可能不寫業務代碼？你要使你的代碼脫離業務抽象出來，那你就要比寫業務代碼的更懂業務，寫過更多的業務代碼才行。要不然，就變成了純粹的紙上談兵了，絕逼會坑死十萬人的。

碼畜？哈哈哈，為何要邀我這個十年碼畜工程師？

下次面試我就問候選人，你覺得你是碼畜還是工程師？

不管是內部系統也好，外部也好，都是相對而言的。

開個玩笑說，做過淘寶的看其他電商系統就跟看一個內部系統一樣。

寫業務代碼最怕什麼呢，來來回回都是那些東西嘛對吧，前台請求，後台處理業務邏輯，然後增刪改查再返回，如果每個需求都不加任何思考，搬起鍵盤就是干，那確實很容易出現所謂的，N年工作經歷，卻只有一年的工作經驗。

舉個例子，兩個業務系統對接，很典型的需求場景吧。A同學擼起袖子直接寫了個send方法，也不管是否成功。B同學寫在服務端增加了返回值，只有客戶端接收到返回值才算成功。

再往下，是不是還可以增加超時的判斷，retry的機制，怎麼保證兩邊處理成功，是不是可以引入MQ，兩步提交等等，這就是典型的分散式CAP的問題。

把上面的問題處理好，抽離出公共的東西讓大家共同優化共同使用，這不就是自己造輪子嗎？