軟件行業(yè)待了這么多年,抽空 總結(jié)一下,畢竟好記性不如爛筆頭。另外一個(gè),想的明白,說的清楚,才能寫的準(zhǔn)確,也是檢驗(yàn)一下知識(shí),同時(shí)也是系統(tǒng)化一下。
軟件的定義
回歸初心,看看軟件的定義。第一個(gè)印象是從學(xué)校來的:
軟件 = 程序 + 文檔
程序 = 數(shù)據(jù)結(jié)構(gòu) + 算法
這個(gè)定義太樸素,太簡(jiǎn)單化。 只是從輪廓外面描述軟件的特點(diǎn), 軟件是由可以運(yùn)行的程序,以及客戶可以看懂的如何操作的文檔組成。 但是也抓住一個(gè)特征,軟件是給人用的。
再?gòu)膚iki上面看看軟件是如何定義的,
Computer software, or simply software, is a part of a computer system that consists of data or computer instructions, in contrast to the physical hardware from which the system is built.
這個(gè)定義軟件是計(jì)算機(jī)系統(tǒng)的一部分,是數(shù)據(jù)和計(jì)算機(jī)指令組成和計(jì)算機(jī)硬件不一樣。 這個(gè)定義也是從外部看的,和上面的定義沒有什么不一樣。
對(duì)于自己的理解,軟件對(duì)外而言,就是一個(gè)工具,通過解決特定問題給用戶提供價(jià)值。其實(shí)也是一個(gè)商品。 對(duì)內(nèi)而言,軟件本身就是思維固話,由概念和邏輯組成。所以就有下面這個(gè)定義。
軟件, 是一個(gè)工具,商品或者服務(wù),通過解決特定問題給用戶提供價(jià)值,其本身是思維的固化, 主要包含概念和邏輯組成。
這個(gè)概念包含兩件事,軟件是給客戶提供服務(wù)的,軟件是否成功取決于是否解決真正問題,滿足用戶的期望。 不管是開源軟件,還是商業(yè)軟件,這個(gè)是很關(guān)鍵。在軟件行業(yè)里面,簡(jiǎn)單來說,Do right thing。這個(gè)在軟件開發(fā)中,就是需求分析,找對(duì)正確的問題。 看到太多失敗的案例,技術(shù)即使很好,但是客戶不認(rèn)可,只能付出東流。
另外軟件是一個(gè)服務(wù)或商品,一定需要考慮軟件本身的成本。所以在軟件開發(fā)中,投入產(chǎn)出比(ROI),一定一個(gè)需要持續(xù)關(guān)注的點(diǎn)。
另外一個(gè)就是軟件本身是思維活動(dòng)的固化,是對(duì)現(xiàn)實(shí)世界的認(rèn)識(shí)在計(jì)算機(jī)的映射。通過將現(xiàn)實(shí)問題理解抽象,在計(jì)算機(jī)里面變成概念和 邏輯。設(shè)計(jì)和編程就是將思維活動(dòng)固化的過程,也就是軟件的實(shí)現(xiàn)。 簡(jiǎn)單來說,Do thing right。
從萬(wàn)米高空俯視,討論軟件開發(fā)就是兩個(gè)視角,一個(gè)是關(guān)注領(lǐng)域問題和價(jià)值,另外一個(gè)關(guān)注實(shí)現(xiàn)。
Do Right Things
Do Things Right
軟件的特點(diǎn)
隨著計(jì)算機(jī)的普及,軟件已經(jīng)無所不在,已經(jīng)軟件吞噬世界。那我們來看看軟件有哪些特點(diǎn):
- 軟件是邏輯產(chǎn)品,是思維的固化
- 復(fù)雜度是軟件最大的敵人
- 軟件質(zhì)量,貫穿一軟件整個(gè)生命周期
- 軟件產(chǎn)品是持續(xù)演化
- 軟件開發(fā)中的協(xié)作,是軟件的關(guān)鍵
軟件團(tuán)隊(duì)協(xié)作是軟件開發(fā)中一個(gè)重要特點(diǎn)。軟件功能越來越復(fù)雜,不可能有幾個(gè)人幾桿槍就做出來。一個(gè)復(fù)雜軟件,需要不同角色不同技能,持續(xù)投入才可能開發(fā)出一個(gè)產(chǎn)品。期間不同人之間必然需要溝通協(xié)作,這個(gè)也是軟件開發(fā)的常態(tài),也是軟件復(fù)雜度的一個(gè)重要來源。所以也單獨(dú)列出來作為軟件構(gòu)建過程中的一個(gè)特點(diǎn)。
1. 軟件是邏輯產(chǎn)品,是思維的固化
軟件是大腦思維活動(dòng)的一個(gè)固化。實(shí)現(xiàn)軟件的過程,就是將思維以概念和邏輯的形式固化下來。思維活動(dòng)的一些特點(diǎn),比如無法衡量,抽象,因人而異這些特點(diǎn)都被軟件繼承下來。同時(shí),一個(gè)概念的變化,對(duì)于其他概念或認(rèn)識(shí)有指數(shù)般的影響,如同蝴蝶效應(yīng)一般。
思維無法衡量,導(dǎo)致傳統(tǒng)的工作量的衡量-可以基于計(jì)件計(jì)時(shí)來衡量,但完全沒有辦法對(duì)應(yīng)到軟件開發(fā)里面吧。 你很難說一天寫100行代碼的人比寫一行代碼的人的產(chǎn)出高。這個(gè)時(shí)候以結(jié)果導(dǎo)向更好一些。如果將it工作如同傳統(tǒng)工作那樣計(jì)時(shí)或者計(jì)代碼量,那是一個(gè)悲催。
-每個(gè)人的思維方式都不一樣。每個(gè)人因?yàn)樽约旱闹R(shí)經(jīng)驗(yàn)閱歷利益都不一樣,對(duì)事物的認(rèn)識(shí)也不可能盡相同。即使是同樣的人,不同時(shí)間段,用的思維的方式也會(huì)發(fā)生變化。
不同人的思維活動(dòng)不一樣。不同人對(duì)于同一個(gè)問題有不同的看法和解。傳統(tǒng)的生產(chǎn)可以細(xì)化到細(xì)節(jié),按部就班新的那樣子,所有人的認(rèn)識(shí)都統(tǒng)一,一刀切的方式,軟件完全與之不同。不同的認(rèn)識(shí)抽象,或許都對(duì),只是側(cè)重點(diǎn)不一樣而已。
-軟件是抽象的。軟件的思維是基于概念和推理,而不是基于事物的表象(外觀,聲音,圖片等)。不懂軟件的人,形容軟件是“看不見摸不著而且能量還不小”,很難理解軟件是如何工作的。所以在軟件的整個(gè)生命周期,一直都有可視化的需求。 USM中用戶和需求的全景圖,項(xiàng)目管理的甘特圖和燃燒圖(burndown chart),數(shù)據(jù)處理的流程圖, demo中的原型圖,架構(gòu)中的5大視圖,代碼的類圖和時(shí)序圖,jenkins 上的印象深刻的blue-ocean以及曾經(jīng)起名的“樂高腦圖”。可視化的需求可以促進(jìn)軟件溝通理解,貫穿于軟件整個(gè)生命周期里。
軟件的發(fā)布成本接近于0。曾經(jīng)發(fā)布為安裝包,以光盤的形式發(fā)布,到網(wǎng)盤直接下載, 以及到現(xiàn)在的按需下載,甚至現(xiàn)在云上面拿來就用無需下載,以及現(xiàn)在持續(xù)發(fā)布。 這個(gè)過程將軟件邏輯產(chǎn)品的屬性發(fā)揮到極致。
軟件只有邏輯折舊,沒有物理折舊。邏輯不會(huì)如同物理客觀事物磨損折舊,但是會(huì)隨著時(shí)間變化更新,環(huán)境變化法規(guī)更新,認(rèn)識(shí)的提升,都會(huì)對(duì)軟件產(chǎn)生變化。每一次變化,軟件不能及時(shí)更新升級(jí),那么就是一次折舊。隨著變化的積累,軟件價(jià)值較少,最后淪為無用之物。這個(gè)過程就是邏輯折舊,后面軟件演化會(huì)涉及到。
軟件需要一個(gè)運(yùn)行環(huán)境。 軟件是需要一個(gè)運(yùn)行環(huán)境,最常見的就是計(jì)算機(jī)。物理的東西都會(huì)有折舊或者損壞,比如硬盤讀寫壽命,網(wǎng)絡(luò)的不穩(wěn)定,以及本身可能會(huì)燒掉。如此等等潛在的折舊會(huì)導(dǎo)致的異常失敗,這些和軟件本身的邏輯問題交織在一起,會(huì)大大增加軟件的復(fù)雜度。軟件開發(fā)一直追求將開發(fā)環(huán)境隔離,減少環(huán)境問題。從mental machine的管理,到VM,現(xiàn)在Docker ,以及到 對(duì)待環(huán)境由寵物到牲口的而變化(pets vs cattle),以及Infrastructure as a code理念 , 都是對(duì)于干凈運(yùn)行時(shí)環(huán)境的持續(xù)追求。
2. 復(fù)雜度是軟件最大敵人。
下圖感受一下復(fù)雜度。
一個(gè)普通大小的軟件里面概念數(shù)量種類狀態(tài)聯(lián)系遠(yuǎn)遠(yuǎn)要超過上圖。那么復(fù)雜度有哪些影響?
Complexity is the enemy of flexibility. It entangles us in unintended consequences. It blocks our attempts to change. It hides potential defects, making it impossible to be sure our systems will function correctly. Performance, transparency, security — all these highly desirable attributes leak away in the face of increasing complexity.
復(fù)雜度是靈活性的敵人。它讓我們陷入不可預(yù)期的結(jié)果( 想想regression). 它是阻礙我們?nèi)L試修改,拒絕修改和害怕修改(想想遺留代碼)。 它隱藏潛在的bug, 使得不可能保證軟件功能正確(想想測(cè)試用例無限的)。 性能,透明性,安全--所有這些我們期望的屬性,隨和復(fù)雜度的增加,這些變得遙不可待。 在<<人月神話>>里面講這種狀況描述為,焦油坑。 陷入里面,掙扎折磨,是一種煎熬。
復(fù)雜度都是哪里來的?
本質(zhì)復(fù)雜度和偶然復(fù)雜度
現(xiàn)實(shí)世界本身就是復(fù)雜的。這個(gè)是本質(zhì)復(fù)雜度。 事物的種類多, 數(shù)量大,狀態(tài)多,關(guān)系復(fù)雜,之間會(huì)有交互,數(shù)據(jù)信息互換。 現(xiàn)實(shí)已經(jīng)很復(fù)雜,理解起來已經(jīng)有挑戰(zhàn),但是對(duì)于理解這些系統(tǒng)的人,知識(shí)視角 的不同,對(duì)于信息理解的偏差,以及溝通時(shí)候造成的誤解更進(jìn)一步增加挑戰(zhàn)。現(xiàn)實(shí)世界是變化的,軟件也需要更新的,這些概念和邏輯發(fā)生變化,同時(shí)需要參與軟件開發(fā)的人的大腦里面的認(rèn)知模型也要變化。
技術(shù)實(shí)現(xiàn)也是復(fù)雜的。把對(duì)現(xiàn)實(shí)世界的理解映射到計(jì)算機(jī)數(shù)字世界,本身也是復(fù)雜的。 這個(gè)過程中技術(shù)選擇,表達(dá)抽象思維的過程,其中還需要處理技術(shù)本身問題,如空指針,內(nèi)存釋放不正確,堆棧異常,并行競(jìng)爭(zhēng),硬件環(huán)境也會(huì)有bug和出錯(cuò)等等,問題進(jìn)一步復(fù)雜了。
隨著時(shí)間的推移,記憶的丟失和人員的變化,使得復(fù)雜度進(jìn)一步提升。隨著時(shí)間流逝,組織團(tuán)隊(duì)的人員流動(dòng),一些信息丟失了。只留下僅有的可以工作的代碼和沒有及時(shí)更新的文檔,這個(gè)時(shí)候去添加新功能修bug,需要先了解代碼反推之前的信息和決策,這個(gè)是一個(gè)逆向工程,難度比剛開始的問題難度又有了一個(gè)數(shù)量級(jí)的提升。
實(shí)際的情況可能更糟糕,語(yǔ)言文化思維方式的不同,組織文化溝通個(gè)人技能的差異都會(huì)使得問題更加糟糕。
應(yīng)對(duì)復(fù)雜度
降低復(fù)雜度和提高處理復(fù)雜度的能力兩個(gè)方面入手。
降低復(fù)雜度,抽象,分解,信息隱藏是常用手段;“高內(nèi)聚低耦合”, 獨(dú)立演化,軟件可測(cè)性的追求;代碼的本身復(fù)雜度,代碼結(jié)構(gòu),包類方法測(cè)試命名方法,clean code;這些降低復(fù)雜度。 強(qiáng)大的工具IDE,標(biāo)準(zhǔn)化,復(fù)用,環(huán)境標(biāo)準(zhǔn)化,自動(dòng)化,快速反饋工程實(shí)踐...... 軟件生命周期的各個(gè)階段,每個(gè)階段的方方面面都來提高控制復(fù)雜度的能力。復(fù)雜度控制住,那么隨之而來是提高軟件開發(fā)效率,和軟件質(zhì)量。這一部分太多理論和實(shí)踐。后續(xù)繼續(xù)討論。
復(fù)雜度的列表 +1表示提高控制復(fù)雜度能力或者降低復(fù)雜度;-1反之
實(shí)踐 | 復(fù)雜度增加 或減少 |
---|---|
需求是否實(shí)例化 | + 1 |
軟件架構(gòu)圖是否清晰 | +1 |
團(tuán)隊(duì)對(duì)于軟件架構(gòu)是否理解 | + 1 |
cvs | + 1 |
自動(dòng)化build 工具 | + 1 |
項(xiàng)目中第三方依賴管理 | + 1 |
開發(fā)環(huán)境是不是一步搭建 | + 1 |
本地是否可以調(diào)試 | + 1 |
是否有單元測(cè)試 | + 1 |
代碼是否經(jīng)常重構(gòu) | + 1 |
是否追求clean code | + 1 |
是否有CI | + 1 |
是否有CD | + 1 |
對(duì)于環(huán)境態(tài)度(pets vs cattle) | + 1 |
是否docker來作為發(fā)布的形式 | + 1 |
項(xiàng)目中開發(fā)語(yǔ)言沒多一個(gè) | - 1 |
直接依賴庫(kù)多一個(gè) | -1 |
軟件架構(gòu)中多一個(gè)元素 | -1 |
代碼量每增加10000行 | - 1 |
團(tuán)隊(duì)是否review | +1 |
團(tuán)隊(duì)是否 retrospective | + 1 |
團(tuán)隊(duì)是否regular learning or sharing | + 1 |
......
歡迎大家補(bǔ)充
沒有根除軟件復(fù)雜的銀彈
現(xiàn)實(shí)問題是復(fù)雜的,當(dāng)然技術(shù)本身實(shí)現(xiàn)也會(huì)帶來復(fù)雜度,協(xié)作開發(fā)也會(huì)帶來額外的復(fù)雜度。即使有再好的的語(yǔ)言,庫(kù),框架,架構(gòu),這部分其他兩部分復(fù)雜度也不會(huì)降低。如同人月神話,在軟件整個(gè)世界里面沒有銀彈。
3 軟件質(zhì)量,貫穿一軟件整個(gè)生命周期
軟件質(zhì)量重要性無需多說。一次一次重大事事故都是一次又一次的提醒我們。最常談到的軟件質(zhì)量問題就是bug,是軟件的行為達(dá)不到實(shí)際的期望。
Software will change the world, but bug will destroy it.
但是軟件這質(zhì)量有兩個(gè)視角,一部分是用戶可以感知到底外部質(zhì)量,比如正確性,健壯性,可靠性,性能等外在屬性; 另一個(gè)視角是開發(fā)人員感知的內(nèi)部質(zhì)量,比如項(xiàng)目一鍵編譯,模塊的劃分接口,代碼的結(jié)構(gòu),類方法的命名大小,這強(qiáng)調(diào)代碼可讀性, 可維護(hù)性,所謂 clean code。其實(shí)就是軟件內(nèi)部和外部質(zhì)量。 外部質(zhì)量差,功能或性能達(dá)不到客戶的預(yù)期。內(nèi)部質(zhì)量差,開發(fā)者體驗(yàn)差;還有-另外一個(gè)說法,技術(shù)債。從長(zhǎng)遠(yuǎn)來看,內(nèi)部質(zhì)量肯定會(huì)影響到外部質(zhì)量。
軟件質(zhì)量是貫穿到軟件的整個(gè)生命周期中,從需求,設(shè)計(jì),實(shí)現(xiàn),測(cè)試,部署,環(huán)境,運(yùn)維和修復(fù)。
軟件bug的成本,其實(shí)和變化一樣,發(fā)現(xiàn)的越晚,修復(fù)成本越高。在最終交付給客戶的產(chǎn)品或者服務(wù)時(shí)發(fā)現(xiàn)的bug, 比引入階段發(fā)現(xiàn)的bug,那影響和修復(fù)成本不知道要高多少倍。想想汽車的召回,與如果這些問題在設(shè)計(jì)時(shí)候發(fā)現(xiàn),其成本何止幾十倍。
每一個(gè)階段,但是引入的bug的數(shù)量也是不一樣的,這個(gè)和我們直覺一樣。
每一個(gè)階段都會(huì)引入潛在的bug,不同階段引入bug的數(shù)量也是差異很大,其成越靠后越高。那么提高軟件的質(zhì)量需要從全局考慮,每一個(gè)階段都有不同的方法。
- 需求溝通的bug
這個(gè)階段需要團(tuán)隊(duì)對(duì)的問題和價(jià)值本身理解,并考慮不同需求的優(yōu)先級(jí)。這個(gè)是軟件的啟點(diǎn)和基礎(chǔ)。
DesignThinking,是一個(gè)理解問題確認(rèn)需求的框架,對(duì)于一個(gè)全新的產(chǎn)品是一個(gè)不錯(cuò)的選擇。
基于USM(user story mapping) 和 BDD開發(fā)結(jié)合起來是一個(gè)不錯(cuò)的選擇。感覺這個(gè)是 sbe( specific by example)的理念的落地。
這個(gè)階段不但要考慮要解決的問題是不是一個(gè)真正的問題,不但需要考慮對(duì)于客戶或者用戶,同樣需要考慮企業(yè)的戰(zhàn)略。畢竟商業(yè)軟件是公司來贊助的。
設(shè)計(jì)中的bug
設(shè)計(jì)是承上啟下,向上滿足需求功能和非功能的屬性。向下需要指導(dǎo)實(shí)現(xiàn)。 同時(shí)設(shè)計(jì)時(shí)要考慮軟件的測(cè)試性。一個(gè)可測(cè)試的軟件,說明其依賴清楚,容易被隔離,容易創(chuàng)建,被調(diào)用和驗(yàn)證。那么一定就是一個(gè)高內(nèi)聚低耦合的,那是一直追尋的屬性。如今流行的微服務(wù)架構(gòu),對(duì)于每一個(gè)服務(wù)也是比之前的單體應(yīng)用可測(cè)性要好一些。-
開發(fā)中, 盡可能避免bug
這個(gè)階段bug引入最多,那么需要在開發(fā)階段盡可能的減少避免引入bug。這個(gè)階段是開發(fā)人員最關(guān)注的的,有很多工程方法,有流程。比如
兩個(gè)人 pair programming( 基于團(tuán)隊(duì)的mobprogramming), code review, code inspect, static scan ,
Unit test, TDD,以及將一切都自動(dòng)化集成起來的CI和CD pipeline,從而將bug扼殺在開發(fā)的階段。這是性價(jià)比最高的。當(dāng)然不要忘記人的因素。流程工具是有用,但是最有效的當(dāng)然是優(yōu)秀的人和團(tuán)隊(duì)。不是說上面的方法流程工具沒有作用,而是說軟件最終的質(zhì)量還是要靠人。否則所有的流程工具都會(huì)留于形式。 比如看到過為了提高單元測(cè)試的覆蓋率,居然還有沒有斷言的測(cè)試這么個(gè)解。
測(cè)試中, 盡可能發(fā)現(xiàn)所有的bug。
常規(guī)的測(cè)試金字塔,讓一切問題盡可能靠下面測(cè)試自動(dòng)化,讓一切盡早發(fā)現(xiàn)反饋。好的測(cè)試需要速快,穩(wěn)定,幫助位定問題。
但是也不能忘記探索性測(cè)試(ET)。 自動(dòng)化的測(cè)試路徑是固定的,ET很好的彌補(bǔ)這點(diǎn)。 軟件有一個(gè)比較好的質(zhì)量基礎(chǔ),那么基于探索測(cè)試,發(fā)現(xiàn)軟件里面不尋常的路徑,組合。這是自動(dòng)化不能代替的或者成本太高承擔(dān)不起來的。
各種測(cè)試都有,其相互重疊肯定有的。勿忘初心我們是提高軟件的質(zhì)量,同樣也要考慮軟件是一件商品有成本的。基于每種測(cè)試的特點(diǎn),考慮其性價(jià)比(ROI)。運(yùn)維中, 盡可能早的發(fā)現(xiàn)警報(bào)。
傳統(tǒng)軟件發(fā)布是一個(gè)安裝包,最終軟件運(yùn)行在用戶的環(huán)境上。對(duì)于問題,查看log或本地環(huán)境盡量重現(xiàn),抑或遠(yuǎn)程支持,這個(gè)都是成本很高的。尤其是哪些不能重現(xiàn)的問題。現(xiàn)在如果服務(wù)上云,軟件運(yùn)行的環(huán)境可以自己掌控,對(duì)于問題本身直接可以重現(xiàn)。但是影響也是嚴(yán)重的。 這個(gè)就需要運(yùn)維團(tuán)隊(duì),盡早發(fā)現(xiàn)問題,減少影響。 監(jiān)控有三個(gè)方面,運(yùn)行環(huán)境的監(jiān)控,應(yīng)用程序的黑盒監(jiān)控(cpu,memory,request response time,jvm heap size等 ),以及l(fā)og的信息。 尤其是log里面的warning 和error一定要去留意,尤其是error。如果不留意問題容易擴(kuò)大化,所以盡早發(fā)現(xiàn),早日采取行動(dòng),扼殺在搖籃中。如果發(fā)現(xiàn)bug,盡可能快的修復(fù)。
修復(fù)bug,這個(gè)是開發(fā)人員的基本功。但是快速修復(fù),這個(gè)是一個(gè)挑戰(zhàn)。常見的四部修復(fù)法(本地重現(xiàn),定位,修復(fù),回歸),但是對(duì)于云上面應(yīng)用程序,或許不能直接用debugger。 那么只能借助log查找原因。這個(gè)時(shí)候log的重要性無需置疑。
考慮到高可用性,如果真的有問題一定要快速修復(fù)。這個(gè)一個(gè)大的挑戰(zhàn)。
另外兩個(gè)辦法就是對(duì)比(TDD, 折半查找,git blame)以及還原法(這個(gè)不常用,但是有時(shí)候會(huì)有奇效)。對(duì)于bug,做RCA(Root -Cause -Analysis)
這個(gè)是一個(gè)回顧和反省的學(xué)習(xí)的過程,而不是尋找背鍋俠。頻率不需要高,但是很有效果。這個(gè)也是系統(tǒng)學(xué)習(xí)的一個(gè)過程。 從曉梅那學(xué)到(10w + 5 hat)的框架是一個(gè)不錯(cuò)RCA框架。
傳統(tǒng)的軟件質(zhì)量是由測(cè)試部門負(fù)責(zé),希望在發(fā)布前將所有的,盡可能多的bug都發(fā)現(xiàn)。傳統(tǒng)軟件,或者一些發(fā)布之后難以修改或者造成的損失很嚴(yán)重的(比如航空航天以及嵌入式的軟件),依舊前調(diào)在軟件前盡可能多的發(fā)現(xiàn)大多數(shù)bug。 如果軟件本身可以持續(xù)發(fā)布,同時(shí)有問題很快發(fā)現(xiàn)和修復(fù),同時(shí)對(duì)于用戶體驗(yàn)沒有那么差,那么速度和質(zhì)量可以折中,那么對(duì)于這種大規(guī)模的發(fā)布前去測(cè)試,完全是沒有必要的。 這個(gè)時(shí)候去QA化,不是說軟件不需要測(cè)試,而是將軟件質(zhì)量從更高的層面來團(tuán)隊(duì)負(fù)責(zé)。
4 - 軟件需要持續(xù)演化
軟件是一個(gè)邏輯產(chǎn)品,而邏輯不會(huì)隨著時(shí)間物理磨損而折舊, 軟件也不會(huì)物理折舊, 但是軟件會(huì)隨著問題本身的變化而需要改進(jìn),這是軟件邏輯折舊。 如果軟件需要延延長(zhǎng)壽,需要軟件本身隨著時(shí)間可以演化,支持新的變化。
同樣功能也會(huì)演化,新的需求,新的認(rèn)識(shí),新的法規(guī),新的安全,等等入錯(cuò)之類都會(huì)需要適應(yīng)新的變化。 軟件要解決的問題會(huì)隨著外部世界的變化而變化。 比如說之前是桌面版,變成C/S版, 又變成網(wǎng)頁(yè)版,緊接著又是手機(jī)版,可以看到語(yǔ)音版,VR或AR 版, 以后或許人機(jī)對(duì)話。 用戶消費(fèi)方式一直放生變化。或者變化是殺死軟件的最后一根稻草。
對(duì)于軟件變化是必然的,所以對(duì)以產(chǎn)品的維護(hù)是肯定的。從整個(gè)生命周期開開,軟件的開發(fā)成本,軟件的運(yùn)營(yíng)成本,以及軟件維護(hù)成本,維護(hù)成本不會(huì)低的。軟件里面的技術(shù)債,就是對(duì)于軟件內(nèi)部質(zhì)量而長(zhǎng)時(shí)間付出的成本。考慮到一個(gè)大的項(xiàng)目,如果其成本隨著時(shí)間越來越高,維護(hù)成本與獲取利潤(rùn)慢慢持平。長(zhǎng)久以往,這個(gè)項(xiàng)目沒有大的改動(dòng),會(huì)被淘汰。
5. - 軟件開發(fā)中的協(xié)作,是軟件的關(guān)鍵
軟件越來越復(fù)雜,分工是協(xié)作是必然的。 上幾百人幾十個(gè)團(tuán)隊(duì)做一個(gè)產(chǎn)品,如何協(xié)調(diào),分工,溝通都是挑戰(zhàn)。尤其是軟件行業(yè)里面,這樣一個(gè)知識(shí)密集行業(yè)。Scale scrum team 常用的兩個(gè)模型: LeSS 和SAFe.
Conway‘s Law,軟件的架構(gòu)和團(tuán)隊(duì)的架構(gòu)是相互反映。一個(gè)產(chǎn)品分成模塊,由不同的team來完成; 模塊之間要通訊,之間定義接口交換數(shù)據(jù),而這些接口是由團(tuán)隊(duì)之間溝通和定義。 那么軟件最終的架構(gòu)和團(tuán)隊(duì)的架構(gòu)存在某種映射關(guān)系。 在那本DDD書籍里面,團(tuán)隊(duì)之間的關(guān)系可以微妙影響到軟件的架構(gòu)。比如一個(gè)團(tuán)隊(duì)對(duì)于另外一個(gè)團(tuán)隊(duì)的代碼不放心,會(huì)加一個(gè)防層:)
團(tuán)隊(duì)協(xié)作,實(shí)際上對(duì)于個(gè)人的表達(dá)展現(xiàn)演講能力由很大要求,當(dāng)然也是機(jī)會(huì)。
完美軟件不存在的,但是這個(gè)是我們追求的。那么如何將發(fā)布的軟件做到團(tuán)隊(duì)最高水平,需要管理技能,更需要好的文化好優(yōu)秀的人一塊努力。團(tuán)隊(duì)一塊努力,學(xué)習(xí)共同成長(zhǎng)。之前看到mobprogingng,或許是一個(gè)理想的方式。
技術(shù)和商業(yè)的關(guān)系
軟件開發(fā)有兩件事,解決正確的問題和實(shí)現(xiàn)正確的問題, 其實(shí)就是商業(yè)和技術(shù)之間的關(guān)系。
商業(yè)上的決定強(qiáng)勢(shì)于技術(shù)團(tuán)隊(duì),這個(gè)往往是現(xiàn)實(shí)的常態(tài)。如何商業(yè)的成功,會(huì)更加給技術(shù)團(tuán)隊(duì)以壓力。技術(shù)有一定的彈性,如果壓力過于大,技術(shù)上會(huì)有某種折中。但是往往這種折中長(zhǎng)期來看會(huì)有副作用(又是技術(shù)債),影響代碼的可讀性和可維護(hù)性。 如果后面不以糾正和補(bǔ)償,那么技術(shù)會(huì)報(bào)復(fù)商業(yè)上的成功。 比如代碼越來越難維護(hù),越來越難于理解,質(zhì)量越來越差,最終使得產(chǎn)品不可用或者甚至崩潰, 商業(yè)上的成功不可持續(xù)。 當(dāng)然以技術(shù)主道的產(chǎn)品,不去考慮市場(chǎng)那也是不可持續(xù)的,比如Docker。
對(duì)于一個(gè)技術(shù)人員而言,一個(gè)成功的產(chǎn)品,必須具備兩個(gè)因素,商業(yè)上的成功和技術(shù)上的創(chuàng)新。比如google的搜索引擎和廣告發(fā)布系統(tǒng)。否則都不可持續(xù)。