業務開發扯淡

2021-10-05 18:58:08 字數 1835 閱讀 5201

書接上一回,業務架構扯淡,今天我們聊聊業務開發。

做技術的人,心中總會有技術偏執,多少會有寫中介軟體的傾向,做基礎架構,做開源專案,以技術改變世界,或者起碼改變身邊,產生自己的影響力。能做到的同志可能不少,但是回顧現實,很多時候,我們更多的時候是在做業務開發。這很尷尬不是嗎?面試的時候,聊天的時候,提到業務開發,聊天物件心裡面產生的第乙個感覺是否就是很無語的增刪改查?很不幸,這事我也沒辦法,正如很多廣東人至今認為出了廣東就是北方,北方冬天下雪,小學語文課都這麼教,沒毛病。

我們能做的,只能是做到更專業的自己,更高的交付,那麼下面我嘗試從幾個方面扯淡。

很悲劇,2023年並不友好,開局一場疫情,外貿奔潰,網際網路,實業一片涼涼,身為開發的我們,承受的是更少的資源,更快的發布節奏,整個行業都在玩優化,沒辦法,我們只能跟著優化自己。

如何正確的做事情,這事應該不用扯,老生常談,專案無非就是範圍,資源,質量,進度這幾個要素之間博弈後的結果。身為開發,我們基本影響不到資源(2020只會更少),我們能影響的因素:範圍,質量,進度。

假設在進度,質量,資源不變的情況下,決定我們最終交付的成果的,相當大的因素是專案開始時,圈定的範圍,每個排期確定的發布內容。這很好理解,但是我想表達的是,開發不應該只是埋頭接受。當環境壓力大起來的時候,我們應該主動參與決策,而非僅僅被動擼**,要參與,承擔範圍(即發布內容)重要程度,優先順序的review。

有很多原因逼迫我們幹這事。比方說,產品同學會有自己的強迫症,可能會覺得多展示乙個資訊,會讓使用者更舒服;a產品提了自己需求,b產品也來了;老闆緊急需求;諸如此類,這些需求帶來的效益是多少?紛亂複雜的多個需求下來怎麼玩?這裡有幾個事得做:

全域性思維:

請放到公司層面思考業務。把我們負責(或者即將開發)的系統套進公司的業務鏈條中去思考。我們負責的系統,佔據什麼樣的位置,和其他系統怎麼互動,如何影響和干預最終的結果(讓公司掙錢)。本次開發的功能,是核心業務功能,還是非核心?是否可以通過替代方案或者臨時運維。

理解業務

對業務的理解也應當抽象,如同設計,比如說,這個業務的資訊流是怎樣的,業務流程是怎樣的(資金流,物流,互動等),業務本質上就是商業邏輯的系統化方案。我們可以參考jvm怎麼優化**的,先構造出乙個圖,區分控制流和資料流,演算法一匹配,完事,業務梳理也是這個思路,殊途同歸。有了這樣的抽象思維和對細節實現的把控(產品同學通常不熟悉細節,並且對資料流的把控不如開發),下次圈範圍pk的時候,飛龍騎臉是必須的。

28原則

按照最經典的,重要程度/緊急程度區分四個界限,畫個圖,把堆積的需求列一列,再配合對業務的理解(請注意,公司視角),相信排期出來的,永遠2.8原則裡面2的部分會全部在排期中,8的部分會包含一部分,剩下一部分通過運維或者溝通,小步快跑,積極調整。(這裡再附送乙個個人心得,80%不重要的功能,只要拖上一兩個版本,很快業務可能忘掉,不用謝)

和產品溝通

最後,我們開始和產品溝通,結果只有兩個:

質量大致上分為,可維護性,擴充套件性。這裡的細節和見解太多,只闡述個人認為的在高強度進度壓力下的最低標準:**要做到結構化,可讀性,足夠的日誌

在此之上,可以根據排期緊急程度酌情提高要求,比如單元測試覆蓋率。單元測試很重要,也很費時間,高質量的單元測試,對比設計,擼**的時間佔比大概要去到1:1:1。可測試性,個人認為在中等壓力下面應該納入最低標準。可測試性也是**質量最重要的標準之一,也是提高個人設計水平的重要工具。

進度沒啥好說,加班唄。。

現實就是我們壓力越來越大,年紀也越來越大,只好保證自己在有限的時間裡都在做最重要的事情,並且調整自己的工作方式盡量做到更好。

by da01.chen

扯淡雲計算

關於雲計算,它是網際網路 的基礎,未來的世界都應該是基於網際網路的相關服務的增加 使用和交付模式,高大上的說法是ott化生存,我的說法是雲上人間,比如現在的電視節目真心覺得超級傻蛋,開啟乙個頻道,使用者不得不按廣電大爺排好的順序去觀賞,不管你愛或不愛,這真是out了,未來的廣電一定要全部ott,否則...

扯淡印度軟體

嚴格意義上來講,阿蒙只不過是中國軟體業這個大染鍋裡乙個在掙扎著的程式設計師,貼金來說也可以是乙個創業者,因此俺沒去過印度是非常容易理解的事情,之所以在此扯淡印度,主要是因為剛閱讀了2006年5月份的 資訊週刊 中的乙個系列文章 走進印度 有那麼一點點感想,也有那麼一點點夢想,感想與夢想在這個資訊 的...

開發人員自測能力提公升扯淡筆記

一 和功能質量的保證僅僅靠測試人員的測試是不夠,自測是保證 質量最基本要求。至於測試專業術語對開發人員並不了解,不重要,筆記下日常遇到的測試技巧,僅 思路,以下名稱都是自取的。1 拆分測試,經常我們會遇到乙個功能或者乙個方法,裡面很龐大,但是我們修改bug的時候,僅僅是涉及到裡面的某個介面 或其它 ...