在當今數(shù)字化(huà)浪潮中，軟件(jiàn•±✔λ)開(kāi)發不(bù)僅是(shì)技(jì)術(shù)φ≥領域的(de)核心驅動力，更是(shì)企業(yè)創新與商業(yè)成功的(de)戰略支點。特别≥÷✘是(shì)軟件(jiàn)定義汽車(chē)的(de)時(shí)代，↑→∞軟件(jiàn)開(kāi)發的(de)規範化(huà)管理(lǐ)成為(wèi)車(ch♥π•♦ē)企的(de)難言之痛：軟件(jiàn)版本如(rú)此多(duō)，如(rú)何測試？全量測ε®試還(hái)是(shì)采樣測試？軟件(jiàn)版本發"₹"布如(rú)何管控？軟件(jiàn)質量如(rú)£♣×何保障？軟件(jiàn)功能(néng)為(wèi)什(shén)麽總是 '↑(shì)趕不(bù)上(shàng)造車(chē)的(de)節奏？軟件(jià♥®n)是(shì)如(rú)何集成的(de)？敏捷會(huì)讓車(chē)企的(de)軟件∑ ≠(jiàn)開(kāi)發一(yī)夜之間(jiān)發生(shē♥£ng)神奇的(de)變化(huà)？….

      本篇文(wén)章(zhāng)以科(kē)普的('×γ de)方式探討(tǎo)軟件(jiàn)開(kāi)發理(lǐ)論¶₽↕基礎、關鍵模型、實戰技(jì)巧以及組織與人(r↔¶én)才發展等重要(yào)議(yì)題↔✘，旨在為(wèi)讀(dú)者提供一(yī)幅全✘♥ 景式的(de)軟件(jiàn)開(kāi)發導圖。

      一(yī)、軟件(jiàn)開(kāi£∑♠<)發基石：軟件(jiàn)開(kāi)發生(shēn®'g)命周期模型的(de)選擇

      軟件(jiàn)開(kā≤✔i)發生(shēng)命周期模型是(shì)組織軟件♠∑(jiàn)開(kāi)發活動的(de)框架，它定義了(le)開 ★>÷(kāi)發過程中的(de)階段、順序、叠代方© λ式以及各階段間(jiān)的(de)關聯（見(jiàn)圖1）。

圖1

      軟件(jiàn)開(kāi)發÷'生(shēng)命周期模型，大(dà)家(jiā)耳熟能(néng)詳的(de)是(shì)經典的₹≠(de)瀑布模型和(hé)敏捷開(kāi)發模型。

      瀑布模型：

      瀑布模型遵循嚴格的(de)線性§&順序，從(cóng)需求分(fēn)析到(dào)詳細設計(jì)，再到(dào)編碼、測試和(♣₩hé)維護，每個(gè)階段必須在前一(yī)階段完全完成後才能(néng)開(kāi)±Ω始。瀑布模型适用(yòng)于需求穩定、技(jì↓™π€)術(shù)路(lù)徑清晰的(de)項目→∞±₽，但(dàn)其僵化(huà)性可(kě)能(nβ•éng)導緻應對(duì)變化(huà)的(de)能(néng)力較弱，一(yī)旦前期需求定§‌≈義有(yǒu)誤，後續階段修正的(de)成本極高(gāo)。

      關于瀑布模型，我們需要(yào)知(zhī)道(d'​ào)，目前看(kàn)到(dào)的(de)瀑布模型（見(jià÷>n)圖2）更多(duō)是(shì)停留在了(le)理(l←γ✔ǐ)論模型基礎之上(shàng)。實際上(shàng)，在198¥¥ε≈0s, Fred Brooks, 著名的(de)産品開(kāi)發暢銷書(shū)《人αβ←π(rén)月(yuè)神話(huà)》作(zu ✘ò)者，圖靈獎獲得(de)者，在NASA內(nèi)部會(huì)議(yì)上(shà¶♠×"ng)指出，“在超過370億美(měi)金(jīn)的(de)投資項目中'‍∏ ，隻有(yǒu)2%的(de)項目使用(yòng)了(le)純粹的(de)瀑布模型，75₩$$÷%的(de)項目或夭折或沒有(yǒu)使用(yòng).”

圖2

      在現(xiàn)實α♦¶≈的(de)世界裡(lǐ)，更多(duō)的(de)是(shì)采用(€λ​yòng)了(le)基于瀑布模型演化(huà)的€"★(de)進化(huà)模型，如(rú)螺旋模型、V模型等。他(tā)們都(dōu)融合了(le)瀑布模λ★型的(de)結構化(huà)特點與叠代思想。螺旋模型特别适用(yò¥÷★ng)于高(gāo)風(fēng)險項目，通(tōng)過反複的(de)風(fēng)σ♠δ險評估和(hé)原型叠代降低(dī)不(bù)确定性；而V☆δ™模型（見(jiàn)圖3）強調開(kāi)發與測試♠∑®≥的(de)對(duì)應關系，确保每個(gè)階段的(d±→e)驗證與确認工(gōng)作(zuò)緊密相(xiàng)連。

      V模型成為(wèi)了(le)産品工(gō→φ•ng)程，特别是(shì)軟硬一(yī)體(tǐ)的(d×£ e)嵌入式産品開(kāi)發的(de)核心骨架，也(yě)是(shì)産品開(∏↕>≤kāi)發使用(yòng)最為(wèi)廣泛的(de)模型。像汽車(chē)行(xíng)業(yè)的(de)ASPICE标準、功能(néng)安全的(de)ISO26262‌ε≥标準、信息安全的(de)ISO21434标準，基本都(dōu)是(↕₹§÷shì)根據V模型制(zhì)定了(le)相(xiàng)應的(de)規範要(yào)求。

圖3

      ©∏> 敏捷模型：

      敏捷開(kāi)發模型則以★≥'快(kuài)速響應變化(huà)為(wèi)宗旨，倡導叠代'<±≥開(kāi)發和(hé)持續集成。它強調團隊協作(zuò)、用(yòng)"÷β戶參與以及适應需求的(de)靈活性，通(tōσ∞ng)過短(duǎn)周期的(de)叠代（如(rú)Scrum中的(de)Spri γnt）快(kuài)速産出可(kě)用(yòng)軟件(jiàn)，并根據反饋進行§↓™$(xíng)調整。敏捷模型更多(duō)地(dì)關注了(le)軟件(jiàn)開(π<☆★kāi)發過程中的(de)工(gōng)程實踐，對(duì)于軟件(jiàn)交付後的(d←♦φ→e)運營提及不(bù)多(duō)。交付後的(de)管理(l♠€€₩ǐ)更多(duō)的(de)還(hái)是(shì)采用(yòng)傳統的®☆(de)軟件(jiàn)生(shēng)命周期管理(lǐ)的(de)模式。

      敏捷軟件(jiàn)開(k₩••āi)發模型同樣存在多(duō)種實操模型，例如(rú)XP、FDD，等。

      目前應用( ♠yòng)最廣的(de)還(hái)是(shì)團隊級敏捷SCRUM模型（見(jiàn)圖4）

圖4

      敏捷開(kāi)發在實際落地(dì)過程中有™∞✔(yǒu)兩種具體(tǐ)的(de)項目管理φα©(lǐ)方式：基于時(shí)間(jiān)盒的(de)叠代計(jì)劃（見(jiπ₩≤àn)圖5）和(hé)基于流的(de)叠代計(jì)劃（見(jiàn)圖6）。采用(yòng)不(bù)同的(de)叠代計 φ•$(jì)劃，将決定了(le)敏捷項目每個(gè)沖刺（SPRINT）的(de)交付內(nèi)容。我們需要(yào)注意的(de)是(shì)，因為 £λ←(wèi)産品形态及産品技(jì)術(shù)架構的(de)複雜(zá)度不(b>€≥ù)同，組織架構的(de)不(bù)同，如(rú)果叠代規劃方式選擇與之不(bù)匹配，敏&$捷反而會(huì)引入更多(duō)的(★λ‍de)混亂和(hé)內(nèi)卷。

      例如(rú)，如(rú)果産品是(sh₩α×ì)單一(yī)架構的(de)（monolith≤φ±≠ic Architecture）且功能(néng)依賴多(duō)，如(rú)果采用(yφ•✘òng)時(shí)間(jiān)盒的(de)叠代®₽規劃方式，會(huì)出現(xiàn)待開÷✔↓(kāi)發的(de)新功能(néng)不(bù)得(de)不(bù↓¶)削足适履，進行(xíng)功能(néng)分(fēn)拆用(yò≥₹ng)戶故事(shì)，确保能(néng)在一(yī)個(gè)時(shí)間(jiān)€λ盒的(de)窗(chuāng)口交付，反而導緻大(dà)量的(de)模塊之間(÷αjiān)的(de)相(xiàng)互依賴，交易★>成本（Transaction Cost）劇•™™•(jù)升，協調工(gōng)作(zuò)冗長(cháng)。從(cóng)系統論的(deΩ→ ✘)維度看(kàn)下(xià)來(lái)，反而是(shì)降低(dī)♥'了(le)效率。針對(duì)這(zhè)種情況，要(yào₹•♣)麽是(shì)改變時(shí)間(jiān)盒的(de)跨度，πΩ®≥要(yào)麽是(shì)采用(yòng)基于流的(de)叠代工(gōng)作(zβ☆​uò)模式。

圖5 （來(lái)源：From Prince2 Agile）

圖6（來(lái)源：From Prince2 Agile）

      軟件(jià± →£n)開(kāi)發的(de)模型選擇：

      “There's πγ©→no singular technique or process that will brin‍<↓g about significant impr™↕ovements in software development productivity”

      - No Sil±¶¶σver Bullet—Essence and Accideε®nts of Software Engineering

      Gerald Weinber₽Ω★£g, Fred Brooks, and Grady B™×φooch

      面臨亂花(huā)漸欲迷人(rén)眼以及病急亂投醫(y≥ &↑ī)的(de)汽車(chē)軟件(jiàn)開(kāi₩≥φ®)發，到(dào)底如(rú)何選擇自(zì)己的(de)軟件(jiàn  )開(kāi)發模式呢(ne)？正如(rú)Fred Brooks所言，β♣♦沒有(yǒu)單一(yī)技(jì)術(shù)或模型能(néng)夠顯著提成軟件₹✔¶(jiàn)開(kāi)發效率。我們需要(yào)的(de)是(shì)因地(dì)制(zhì)宜，選擇适合自(zì)ε∞≤≈己組織和(hé)産品屬性的(de)研發活動的(de)模型。

      在實際工(gōng)作(↑∏zuò)中，我們應該且必須學以緻用(yòng)，靈活适配合≤‍≠适的(de)軟件(jiàn)開(kāi)發模型，而不(bù)是(shì)簡單地(dì)照(zhà$€o)貓畫(huà)虎，仿照(zhào)各種敏捷框架，如(rú)站(zhàn)會(h>σuì)、結對(duì)編程......（題外(wài)話(huà)：其實，适配✔δ​÷性（Adapability）才是(shì)業(yΩ✘÷è)務敏捷的(de)精髓所在）。

      不(bù)管選擇何種開(kāi)發€→∑γ模型，其核心目的(de)是(shì)更快(kuài)、更好(hǎo)地(dì)交付客戶價值和(h♠¶ é)業(yè)務價值。具體(tǐ)來(lái)講，可(kě)以基于Stacey矩陣，選擇合适的(de)開× (kāi)發模型（圖7）。當然，除了(le)Stacey矩陣提供的(de&↑γ♣)需求确定性和(hé)技(jì)術(shù)确定性的(de)兩個(gè)維度外(wài)，還→  π(hái)需要(yào)考慮團隊的(de)成熟度，團隊成員(yuán×∑)的(de)技(jì)能(néng)經驗，Ω♥工(gōng)作(zuò)地(dì)點分(fēn)布，團隊規模以及組織文(wén)化(hδ♦ ×uà)等因素。

圖7

二、需求分(fēn)析與架構設計(jì)的(de)藝術(shù)

      軟件(jiàn)開(k&&āi)發始于需求的(de)獲取與需求開(kāi)發的(de)過程（通(tōng)常将這(zhè)個(gè)過程稱為(wèi)需求工(gōng)程階段）。✘φ需求的(de)獲取主要(yào)是(shì)從(cóng)市©∞♦¥(shì)場(chǎng)需求、用(yòng)戶需求、業(yè)務等維度©β展開(kāi)，理(lǐ)解并分(fēn)析企業(yè)所在的(de)行(xíng₩≈₹÷)業(yè)、國(guó)家(jiā)、地(dì)區(qū)适"&±‍用(yòng)的(de)法律法規等，綜合定義‌ •軟件(jiàn)産品的(de)需求。 

      近(jìn)幾年(nián)來(lái)，随₽₽↕著(zhe)國(guó)內(nèi)互聯網造車(ch•✘‍αē)的(de)興起，互聯網用(yòng)戶需求分(fēn)析的("¥§de)工(gōng)具也(yě)逐步引入到(dào)垂直行(xíng)業(yè)，也(<∞↑≥yě)成為(wèi)國(guó)內(nèi)傳統造車(chē)企業(y♣✔₽"è)紛紛攘攘去(qù)學習(xí)的(de)重心。但(dàn)從(cóng​붣)第一(yī)性原理(lǐ)來(lái)看(kàn)，需求獲$$♥取的(de)原理(lǐ)沒有(yǒu)改變，變化( ∏™huà)的(de)是(shì)傳統企業(yè)缺∞£☆少(shǎo)需求獲取的(de)數(shù)字化(huà)手段，缺少(shǎo)人(rén)物÷•↑(wù)畫(huà)像的(de)細節管控。

      需求獲取的(××de)方法手段很(hěn)多(duō)，我們總結如(rú)圖8所示。

圖8

      在對(duì)軟件(jiàn)産<★品功能(néng)進行(xíng)定義的(de)過程中βσ，往往是(shì)綜合采用(yòng)多(duō)種方法，确保功能(néng)能(nénφσ☆g)夠滿足最大(dà)數(shù)量的(de)用(yòng)戶期₩σ$$望。同時(shí)，我們要(yào)關注，↔'對(duì)于ToC業(yè)務與ToB業(yè)務的(de)需求獲取方法，也(yě)≤σ©存在著(zhe)差異。無論是(shì)從(cóng)調研對(duì)Ω¶₽λ象，調研數(shù)量以及調研方法，在實際過程中，要(yào)注重理(lǐ)© ₹論與實踐的(de)結合。

      這(zhè)裡(lǐ)，特别給大(d©¶à)家(jiā)推薦一(yī)個(gè)用(yòng)來(lái)識别或改進産β™‌品可(kě)用(yòng)性功能(néng)需求（Usability）的(de™≤γ)強大(dà)工(gōng)具–用(yòng)戶曆程地(dì)圖（題外(wài)™ ‌γ話(huà)：對(duì)于其他(tā)如(rú)非功能€♣←(néng)性需求的(de)定義與改進，建議(yì)采用(yòng)其他(tā)™σ∑工(gōng)具方法）。圖9展示了(le)對(duì)電(♠φ₽diàn)車(chē)用(yòng)戶充★§​電(diàn)活動的(de)用(yòng)戶曆程地(dì)圖，通(tōng)過一(yī)λφ γ張紙(zhǐ)，可(kě)以清晰地(dì)将産品功能(néng)的(de)優劣©↕ ✔以及待創新的(de)功能(néng)點描述清楚。

圖9

     §∑♣♠ 需求獲取隻是(shì)開(kāi)啓了(le)整個(gè)軟件(jiànγ€)開(kāi)發的(de)序幕。我們下(x↔€ià)一(yī)步要(yào)做(zuò)的(de)是(shì)需求的(de)确 ©<認。需求的(de)确認，是(shì)确保軟件(jiàn)産品的(de)開(kā≈β✔>i)發“做(zuò)正确的(de)事(shì)”。需求确認的(de)方法包括了(le)VO€×C，焦糖布丁法，Y分(fēn)析法，數(shù)據分(fēn)析法等等。

      為(wèi)什(₩​±shén)麽要(yào)進行(xíng)需求的(de)确認呢$ (ne)？其實，這(zhè)涉及到(dào)了(le)人(ré≤ n)類認知(zhī)的(de)過程，如(rú)圖10所示，當我們看(kॱ¥<n)到(dào)現(xiàn)實的(de)人(rén)形機(jī)器(qì)人(rénα→•‍)圖片時(shí)，我們會(huì)根據自(zì)己的(de)認☆ ∞•知(zhī)(Perception)和(hé)我們個(gè)人(₩✘>☆rén)的(de)知(zhī)識（Knowledge）對(duì✔★αα)其進行(xíng)描述。然後，我們将我們自(zì♥≤€')己腦(nǎo)海(hǎi)裡(lǐ)，經過自(zì)己認知(λ$↔zhī)過濾過的(de)圖片，用(yòng)自(zì)己的(de)知(zhī)識，< ♦包括文(wén)字語言對(duì)其進行​™↔(xíng)描述，這(zhè)個(gè)過程，将不(→λ↓bù)可(kě)避免的(de)引入人(rén)為(wèi)的(de)錯(cuò)誤。所以，在專<₽§業(yè)的(de)産品研發環境中，我們意識到(dào)這(zhè)個(gè)人(rén)類♦±認知(zhī)的(de)過程偏差，所以需要(yào)建立規範的✘£(de)工(gōng)具方法，如(rú)需求文(wén)檔的(de)評審、需求撰寫的(de♣₩© )規範等，作(zuò)為(wèi)“獲取正确需求”的(de)底線保障，确保最大(&↕dà)可(kě)能(néng)地(dì)不(bù)失真。而敏捷思 ↑∏>想裡(lǐ)強調的(de)“客戶合作(zuò)勝于客戶合同”，也(yě)正是(shì)基于這(zh£γè)個(gè)不(bù)可(kě)更改的(de)事(shì)實做(zuò)出的(♥∑de)更合理(lǐ)的(de)過程建議(yì)。

圖10

      需求的(de)開(kāi)發包括需求分(fē→←φn)析與需求的(de)分(fēn)解與分(fēn)配的(de)過程。它是(shì‍₽)軟件(jiàn)産品開(kāi)發“正确做(zuò)事(π∑₩®shì)”的(de)過程。這(zhè)個(gè)過程可(kě)以使用(yòng)類似FAST功能(néng)分(fēn)←≠★ 析圖、EFFBD圖、UML建模或者其他(tā)建模工(gōng)具實現(xi×​♠¶àn)，也(yě)可(kě)以使用(yòng)其它不(bù)同的(de)工(gōσ₹<☆ng)具方法，如(rú)KJ法、KANO法、QFD法、Pugh矩陣↔₽法等等，幫助我們有(yǒu)效工(gōng)作(zuò)。

      需求開(kāi)發從(cóng)産品定義♣ ‍€語境出發，逐步細化(huà)分(fēn)解功能(n♥↑$éng)，最後分(fēn)配到(dào)子(zǐ)系統和(hé)模塊。這(zhè)個(gè)過程是(sh✘​∞★ì)用(yòng)戶可(kě)見(jiàn)的(de)功能(néng)和(hé∏δ)可(kě)感知(zhī)的(de)非功能(néng)性期望，轉化(huà)為(wèi)我們軟件α≠€(jiàn)産品能(néng)力的(de)過程。如(rú)果是(shì)0到(dào)♠♠↕1的(de)産品開(kāi)發，這(zhè)個(gè)過程與産品架構✔↔♣<設計(jì)交互叠代，最終形成産品的(de)雛形；如(rú)‍↕♣果是(shì)基于原有(yǒu)産品架構的(de)功能(néng)增加≠←₽，則更多(duō)的(de)工(gōng)作(z★ &​uò)是(shì)基于原有(yǒu)架構進行(xíngΩ¥≤λ)需求分(fēn)配的(de)過程。當然♠<↕，不(bù)排除原有(yǒu)系統需要(yào)重構，才能(néng)滿足客戶€® ‌的(de)功能(néng)要(yào)求的(de)情況。

      而架構設計(jì)則是(shì✔✘)将技(jì)術(shù)需求轉化(huà)為(wèi)系統的(de)藍(lán)圖，  ✘涉及功能(néng)模型定義、架構評估方法選擇、物(wù)理(lǐ)架構布局等多(duō)個(♣>αgè)環節。軟件(jiàn)産品常見(jiàn)的(de)技(jì)術(shù)↓★架構包括了(le)C/S架構、MVC架構、分(fēn)層的(de)SOA架構等。但(dàn)具體(→✔δtǐ)的(de)架構設計(jì)，要(yào)考慮的(de)不(bù)僅關乎技(jì)術(shù)實現(xδ​‌♠iàn)，更是(shì)一(yī)種權衡藝術(shù)（Tra↕♣₩de-Off），需要(yào)在功能(néng)、成本、時(sh™‍✘í)間(jiān)、用(yòng)戶期望等多♥♥♦♥(duō)種因素間(jiān)尋求最佳平衡。

      如(rú)圖11，當面對(duì)客戶₩α“過河(hé)”的(de)需求，架構設計±♦§Ω(jì)可(kě)能(néng)需要(yào)考慮橋梁、船(chuán)≠↑→隻、潛水(shuǐ)艇，飛(fēi)機(jī)等多(duō)種解決方案，每種方案↔&α背後代表了(le)不(bù)同的(de)技(jì)術(shù)複雜(zá)度、投資規模與時γ£(shí)間(jiān)周期，系統架構就(jiù)是(shì)需要(↔≥yào)在不(bù)同的(de)解決方案中選擇♣✔δ​最合适的(de)，而不(bù)僅僅是(shì)技(jì)術(shù)最優的∞↔(de)。

圖11

      在架構設計(jì)過$✘程中，可(kě)以運用(yòng)啓發式問(wèn)題法、KJ法、QFD等工 ÷"₹(gōng)具進行(xíng)評估與決策，有(yǒu)助于​↓₩≠識别最合适的(de)架構。同時(shí)ε€，評估軟件(jiàn)架構的(de)有(yǒu)效性，還(hái)可(kě)以通(tōng)£★↕δ過創建原型、叠代開(kāi)發、模型模拟等方式獲取直≤§觀反饋，必要(yào)時(shí)引入量化(huà)指标進行(xíng)深度分(fēn)析。

      康威定律揭示了(•×le)一(yī)個(gè)重要(yào)規律≠Ω±：軟件(jiàn)架構往往反映出組織內(nèi)部的(de)結構'₩。這(zhè)意味著(zhe)，良好(hǎo)的(de)組織設計(jì)有(yǒu)助于催生(←¶→shēng)高(gāo)效、協調的(de)軟件(jiàn)架構，反之亦∏£↑然。因此，在軟件(jiàn)開(kāi)發過程中，應充分(fēn)考慮₽ ✔∑組織架構對(duì)技(jì)術(shù)實現(x★÷♦↔iàn)的(de)影(yǐng)響，确保架構€"設計(jì)既能(néng)滿足功能(néng)需求，又(yòu)能(n€✘σéng)順應組織協作(zuò)模式。

三、軟件(jiàn)編碼與測試：質量之盾

      軟件(jià​→★★n)編碼是(shì)将設計(jì)轉化(huà)為(wèi)可(kě)執行(β♠≥xíng)代碼的(de)過程，需要(yào)遵循相(xiàng)應的(de)編程語言規範和(h&‌é)組織內(nèi)部編碼标準（例如(rú)，谷歌(gē)C++代碼規範：Google_Cpp_Style_guide_C™•N.pdf (sosohu.github.io)），輔以靜(jìng)态代碼掃描、動态測試及代碼評審等工(gōng)作(zuò)，₩₩确保代碼質量。

      伴随著(zhe)AIGC的(de)泛化(huà)，AI 輔助編碼和(hé)代碼評審也(yě)逐÷π步成為(wèi)現(xiàn)實，比如(rú)Github Copilot X，可(kě)以協助程序員(yuán)實現(xi₹←àn)結對(duì)編程。同樣，類似ChatGPT，也(yě)可(kě)以幫助我們實現(xiàn<‍)代碼評審的(de)工(gōng)作(zβ∞uò)。例如(rú)，我們把下(xià)面這(zhè)段> 冒泡算(suàn)法的(de)C代碼（圖12）輸送給ChatG↓α→PT，GPT會(huì)給出非常中肯的(d∏✔ e)評審建議(yì)以及重構後的(de)代↑₹÷碼，大(dà)大(dà)減少(shǎo)了(le)代碼評審的(de) €Ω★工(gōng)作(zuò)量。

圖12

      圖13是(shì)ChatGPT重構後的(de)代碼。GPT的(de)反饋如(rú)下(xià)。☆₹≈φ他(tā)不(bù)僅僅反饋了(le)代碼的(≤δαλde)邏輯錯(cuò)誤，對(duì)程序的(de)性能(néng)也(yě)給出了(l®φe)建議(yì)（第2條反饋）

1. 冒泡排序算(suàn)法的(de)內(nèi)層循環條件(jiàn)for (j = α ↕↓0; j < len - 1 - i; j++)中的(de)len - σ©ε 1 - i可(kě)能(néng)會(huì)導&≥緻數(shù)組越界。應該将內(nèi)層循環條件(jiàn)修改為(wèi)fγ™ or (j = 0; j < len ®€- 1; j++)。

   
   

2. 在冒泡排序算(suàn)法中，如(rú)果數(shù)組已經是(shì)有(yǒu)序的(d↕↓↑'e)，仍會(huì)執行(xíng)完所有(yǒu)的(de)比較和®→(hé)交換操作(zuò)，造成了(le)性能(né₩ ‌∏ng)上(shàng)的(de)浪費(fèi)。可(k<♣ě)以在內(nèi)層循環中增加一(yī)個(gè)判斷條↕​§件(jiàn)，如(rú)果沒有(yǒu)發生(shēng)交換，即β₹α可(kě)提前退出循環。

圖13

      需要(yào)注意的(de)是(shì)目前GPTε☆™←仍然是(shì)概率算(suàn)法，他(tā)的‌☆(de)反饋需要(yào)一(yī)定的(de)人($☆ rén)工(gōng)複核，确保剔除AI給出的(de)噪音(yīn)→Ω♦©反饋。

圖14

      測試則是(shì)軟件(j±≤iàn)質量的(de)守護神，涵蓋單元測試、集成ε✘₽★測試、功能(néng)測試、系統測試及驗收測試等不(bù)同層次，目的(de≥÷₹×)是(shì)盡早發現(xiàn)問(wèn)題、減少(shǎo)後期修複成本&↔₩ 、确保軟件(jiàn)符合客戶需求與期望。無論是(shì)在V模型或者敏捷開(kāi)發模型中，軟件(jiàn)測試活動的(de)目的(‌✘de)是(shì)一(yī)緻的(de)，而測試活動貫穿整個(gè)開(kāi)發周期（圖1Ωβ≈≤4所示的(de)V模型）。早期集成測試能(néng)有(yǒu☆↕)效縮短(duǎn)交付周期，提高(gāo)€≤客戶滿意度。

圖15

      測試執行(xíng)過程從"↔<×(cóng)時(shí)間(jiān)順序上(sh¶©àng)可(kě)以分(fēn)為(wèi)三大(dà)部分(fēn)：單元測試，​β集成與功能(néng)測試和(hé)系統驗證與驗收測試（圖15）。單元測試聚焦單個(gè)代碼單元的(de)功能(néngπ✔™∞)正确性；集成與功能(néng)測試檢查模塊間(j¥§iān)交互與整體(tǐ)功能(néng)完整性ε∑λ；系統與驗收測試則驗證軟件(jiàn)系統在真實環境下(xià)的(de)表現(£₩xiàn)是(shì)否滿足需求。

      通(tōng)→Ω過及早發現(xiàn)問(wèn)題，測試不(bù)僅能(néng↓∑₩)節約成本，還(hái)能(néng)提升軟件(jiàn)的(de)穩定性和(hé)可(> kě)靠性，為(wèi)市(shì)場(chǎng) ≤↓★成功奠定堅實基礎。在實際操作(zuò)過程中，無論是(shì)敏捷或是(shì)V模型，測≤✔♦₩試過程并沒有(yǒu)這(zhè)麽嚴格的(de)順序區(qū)分(fēn)，₽∑β往往是(shì)循環叠代的(de)反複過程。對(duì)于如(rú)何确保已經驗證的(de § ♣)功能(néng)仍然是(shì)可(kě)信的(de)，往往是★←γ(shì)需要(yào)經驗和(hé)智慧的(de)積累。

      關于軟件(jiàn)測試，我們必須清晰地(dì) ∞認識到(dào)“測試不(bù)是(shì)銀(yín)彈。窮盡測試是(shì)不(b¶≠×ù)可(kě)能(néng)也(yě)不(bù)㱩現(xiàn)實的(de)”。所以，端到(dào)端的(de)軟件(jiàn)質量保障，從(c& óng)需求到(dào)設計(jì)，從(cóng)編碼到(dào)測試，全鏈路(lù)的(de)∏•保障才是(shì)我們需要(yào)竭盡全力的(de)目↑♣∞ 标。

圖16

      伴随著(zhe)AGI及數(shù)字•↔γγ化(huà)技(jì)術(shù)的(de)發展，測試技(jì)術(shù)手段也(yě)λ​'​在日(rì)益改進，新的(de)測試技(jì)術(shù)開(kāi)始逐步開(≠α§kāi)始向RPA，AI賦能(néng)的(de)測試手段方向發展（見(jiàn)圖16）。

      而對(duì)汽車(chē)行(xíng)業(yè)軟件(ji₽γ$​àn)開(kāi)發而言，自(zì)動化(huà)測試技(jì)術(shù)、RPA、AI、新的∞™→←(de)應用(yòng)場(chǎng)景的(de)測σλ試也(yě)慢(màn)慢(màn)開(kāi)始滲透，成為(wèi)測試團隊的(de)新挑戰± 。

四、軟件(jiàn)發布：舞(wǔ)動的(de)韻律

      軟件(㧀jiàn)發布的(de)全過程是(shì)一(yī)個(gè)嚴謹有≤♠σ∑(yǒu)序且不(bù)斷叠代前行(xíng)的(de×‍)。進入開(kāi)發階段後，采用(yòng)CI/CD（持續集成/持續部署）的(de)實踐，包括代碼提交、規ε‍γ¶則檢查、代碼評審、預編譯、軟件(jiàn)包構建、內(nèi)部發布、測試驗證¶✔→∑以及對(duì)外(wài)發布等一(yī)整套流程，确保軟件(jiàn)質量的(de)持續性和(hé)穩定性。在這(zhè)一(yī​<δ&)過程中，構建Sanity、自(zì)動♠÷化(huà)測試以及各類環境下(xià)的( πde)驗證是(shì)必不(bù)可(kě©₹)少(shǎo)的(de)環節（見(jiàn)圖17）。CICD在軟件(jiàn)開(kāi)發全生(shēng)命周期中體(tǐ)現(xiàn)<×♠的(de)核心思想是(shì)快(kuài​'€)速反饋、頻(pín)繁交付和(hé)可(kě) ♣≈靠質量。通(tōng)過自(zì)動化(huà)構建和(hé)部署流水(shuǐ)線，讓開(k♥↕‍"āi)發團隊能(néng)夠迅速響應變化(huà)，減少(shǎo)人(rén)工€↕ (gōng)幹預帶來(lái)的(de)延誤和(hé)錯(cuò)誤，确←π'保軟件(jiàn)在各個(gè)階段都(dōu)能(néng)高(gβ>āo)效地(dì)完成集成、測試和(hé)部署，最終達到(dào)高(gāo)質$♥量、高(gāo)效率的(de)産品交付目标。

圖17

      在軟件(jiàn)的(de)維護階段，針對(duì)λφφ'存在的(de)問(wèn)題和(hé)錯(cuò)誤進行(xíng)及時(shí) &®↕修複，根據用(yòng)戶反饋和(hé)市(shì)α∑® 場(chǎng)需求持續進行(xíng)功能(néng)改進與性能(néng)優化(hu★≠≥'à)。對(duì)于汽車(chē)行(xíng ×)業(yè)的(de)嵌入式軟件(jiàn)而言，還(hái)涉及↕&€到(dào)與硬件(jiàn)結合的(de)複雜(zá)集成測試，以及類✘↔似FOTA，SOTA（空(kōng)中下(xià)載技(jì)術(s¶φ↕₹hù)）更新等特殊的(de)軟件(jiàn)升級場(chǎng)景。此外(wài)，汽車(chē)行(xíng)業(yè)軟件(jiàn)發布遵循項目生(shēng)✘☆¥®命周期的(de)各個(gè)階段，如(rú)工(g•≠ōng)程樣車(chē)（EP）、産品及過程驗證（PPV）、預試生(shēng)産（PP）‌βα、試生(shēng)産（P），直至正式投産（SOP）。在整個(gè)過程中，項目質  ↕€量管理(lǐ)扮演著(zhe)關鍵角色，不(b↕↔σù)僅要(yào)保證軟件(jiàn)産品的(de)質量和(hé)性能(néng)，還(hái₽↑<)要(yào)确保軟件(jiàn)開(kāi)發與發γ®布過程符合既定的(de)質量标準和(hé)國(guó)标、企$®标。

五、研發基礎：技(jì)術(shù)研發與産品研發的(de)φΩα“雙輪驅動”

      技(jì)術(shù)研發與産品姀∏研發雖同屬創新範疇，但(dàn)各有(yǒu)側重。

• 技(jì)術(shù)研發著(zhe)眼于長(cháng)遠(yuǎn)，追求技(✔± jì)術(shù)先進性與知(zhī)識積累，目标是( ∞↓shì)開(kāi)發出具有(yǒu)競争優勢的(de)技(jì)術(s→£∞hù)成果，為(wèi)未來(lái)的(de)市(shì)場(chǎng)×≥™化(huà)産品提供技(jì)術(shù)支持（TPF過程）。
• 産品研發更直接面向市(shì)場(chǎng)，關注産品創新​≤♥♦與商業(yè)化(huà)進程，旨在快(kuài)速Ω​$±推出符合用(yòng)戶需求的(de)新産品，創造價值與利潤（PMF過程）。

      如(rú)圖18所示 ★，技(jì)術(shù)研發和(hé)産品∏™研發在生(shēng)命周期、市(shì)場(chǎng)定位、技(jì)術(shù)‌₹©$難度、管理(lǐ)手段等方面存在顯著差異，₩↕λ但(dàn)均需緊密圍繞用(yòng)戶需求展開(kāi)。技(j£δ←ì)術(shù)研發往往領先數(shù)年(nián)，承擔探索未知(zhī)、孵化(huà)前沿技(jì)術 α(shù)的(de)角色；産品研發則緊跟市(shì)場(chǎ<φng)脈搏，力求在短(duǎn)期內(nèi)實現(xiàn)産品的(de)更新換代。二者相(xi£≠àng)互依賴，共同推動企業(yè)技(jì)術(shù)創新≥ε≥與産品叠代的(de)良性循環。當然，因為(wèi)技(jì)術(shù)研發與産品研發的(de)↕•→×定位不(bù)同，企業(yè)在實際管理(lǐ)過程中，不(bù)能(né♦ <ng)把産品研發的(de)管理(lǐ)手段，比如(rú)某款車(chē)型研發，簡單地(dì)套用(yòng)到(dào)技(jì)術(shù)研發管理(lǐ)中（比如(rú)，某款新材料、新動力電(diàn)池或平台©∏'£架構等）。

圖18

六、研發基礎：組織與人(rén)才發展的(de)軟實力構建

      軟件(jiàn)開(kāi)發的(de)成功離(lí)不‌$★ε(bù)開(kāi)強大(dà)的(de)組織支撐與人(rén)才隊伍建設。

     π¥← 研發組織應注重能(néng)力建設，涵蓋組織​πα架構設計(jì)、業(yè)務流程梳理(l♣βγǐ)、數(shù)字化(huà)工(gōng)具鏈集成（如(rú)禅道α ✔(dào)管理(lǐ)軟件(jiàn)，CICD工(gōng)具鏈★δ，雲端軟件(jiàn)DevOPS工(gōng)具鏈等）、知(zhī)識管理₹↓≤(lǐ)、信息安全等多(duō)個(gè)維度。同時(shí)，建立健全績效考核與激勵機(jī)制≠ (zhì)，确保人(rén)才的(de)成長(cháng)與發展與組織¶÷戰略目标相(xiàng)一(yī)緻。

      人(rφεén)才發展方面，提供管理(lǐ)與專業(yè)技(jì)術↔₹(shù)兩條晉升通(tōng)道(dào₽β)，滿足不(bù)同類型人(rén)才的(de)職業(yè)發展需求。管理(lǐ)路(lù)線涵蓋研發主管、經理(lǐ)、總監等。專業(yè)技(j₹φγ>ì)術(shù)路(lù)線包括了(le)高(gāo)級項目經理(lǐ)、産品經理γ♣(lǐ)、質量經理(lǐ)等專業(yè)角色；專業(yè)技(jì)術(shù)路(≈♣®lù)線還(hái)包括了(le)技(jì)術(shù)專家(jiā)、高(gāo)γ€級專家(jiā)、資深專家(jiā)等技(jì©∑→)術(shù)精英。通(tōng)過明(míng)确的(de)±♣♣職業(yè)發展路(lù)徑，激發人(rén)才潛能(né©∑←ng)，形成穩定且富有(yǒu)活力的(de)人(rén)才梯隊σ↕​，避免“重技(jì)術(shù)，輕職業(yè☆±€©)化(huà)”的(de)問(wèn)題。根據PRTM的(de)産品開(kāi)發能(néng)力成熟度評估模型（圖19），軟件(j∞↑✔iàn)開(kāi)發組織的(de)成熟度可(kě)以分(fēn)為(←'wèi)5級。

      建議(yì)優秀÷ →δ的(de)車(chē)企應該向成熟度4級（Stage 3∞↑♥）努力，提升組織的(de)核心競争力，确保打赢汽車(chē)智能(néng)化(huà)和(h≥☆≤é)汽車(chē)産業(yè)數(shù)字化(huà)這(zhè₹←)一(yī)仗！

圖19 （Source：PRTM 産品開(kāi)發能§↕"(néng)力）

      結束：本文(wén)為(wèi)我們勾勒出一(yī)幅從(cóng)理(&♣≤φlǐ)論到(dào)實踐、從(cóng)模型選擇到(dà 'o)組織構建的(de)全景圖。無論是(shì)初涉軟件(jiàn)行↑&ε÷(xíng)業(yè)的(de)新人(rén)，還(háσ<α¥i)是(shì)尋求優化(huà)研發流程 ≠★'的(de)企業(yè)管理(lǐ)者，都(dōu)可(≈∑kě)以從(cóng)中汲取寶貴的(de)知(zhī)識與經♣↓→&驗，助力在瞬息萬變的(de)科(kē)技(jì)浪潮中穩操勝券​Ω‌₹。軟件(jiàn)開(kāi)發并非孤立的(de)編程活動，而是↑÷>✔(shì)涵蓋了(le)需求分(fēn)析、架構設計(jì)、編碼實踐、測試保障、技₹→(jì)術(shù)研發、産品研發、組織管理(¶γ>☆lǐ)與人(rén)才培育等多(duō)元要(yà★∑☆↑o)素的(de)系統工(gōng)程。唯有(yǒu)深入理(lǐ)解并妥善駕馭這™φ(zhè)些(xiē)要(yào)素，方能(néng)™εΩ在激烈的(de)市(shì)場(chǎng§σ≤)競争中立于不(bù)敗之地(dì)。

轉自(zì)水(shuǐ)輕言