2022-01-09點(diǎn)擊量：163

是的，軟件開發(fā)絕不是在公園里散步。我們經(jīng)常解決無(wú)法預(yù)見的問(wèn)題，如果你不犯這些常見的軟件開發(fā)錯(cuò)誤，許多問(wèn)題是可以避免的。我將引導(dǎo)大家解決錯(cuò)誤，這些錯(cuò)誤可能會(huì)破壞自己的辛勤工作并使有前途的項(xiàng)目白白失��！作為開發(fā)人員、分析師、產(chǎn)品負(fù)責(zé)人、主管或CTO，我遇到過(guò)這些所有問(wèn)題，盡管有些看起來(lái)很基礎(chǔ)，但它們?nèi)匀粫?huì)傷害你的團(tuán)隊(duì)。請(qǐng)與我深入了解～不了解產(chǎn)品為什么軟件開發(fā)如此令人興奮？對(duì)我來(lái)說(shuō)，這是因?yàn)橛袡C(jī)會(huì)學(xué)到很多行業(yè)的知識(shí)。通過(guò)引入該領(lǐng)域的項(xiàng)目來(lái)創(chuàng)造并塑造它們的未來(lái)。比如人們有機(jī)會(huì)在人力資源、醫(yī)療保健、金融和各種行業(yè)的產(chǎn)品上創(chuàng)造價(jià)值。雖然了解不同領(lǐng)域令人興奮，但也極其具有挑戰(zhàn)性。如果你渴望構(gòu)建成功的產(chǎn)品，則必須了解其行業(yè)背景。對(duì)于我而言，軟件開發(fā)不是編碼，而是關(guān)于在盈利的同時(shí)為最終用戶尋找最佳解決方案。軟件工程師的關(guān)鍵要點(diǎn)是——了解業(yè)務(wù)核心和應(yīng)該實(shí)現(xiàn)的每個(gè)功能。如果你只是一個(gè)聽命令的機(jī)器人，那開發(fā)可能是工作鏈條中最昂貴的部分，每個(gè)錯(cuò)誤并不便宜。我相信技術(shù)咨詢和代碼審查任務(wù)是技術(shù)專家的附加價(jià)值，他們可以糾正最初雇用你的公司業(yè)務(wù)人員的錯(cuò)誤觀點(diǎn)。而能夠交換意見是團(tuán)隊(duì)相對(duì)于個(gè)人的最大優(yōu)勢(shì)。假設(shè)即事實(shí)決策是每個(gè)產(chǎn)品開發(fā)的核心部分。很自然地，人們對(duì)以前的項(xiàng)目和假設(shè)看法會(huì)發(fā)揮作用。請(qǐng)注意這些問(wèn)題，猜測(cè)比詢問(wèn)別人更簡(jiǎn)單，但它很危險(xiǎn)！如果你碰巧做對(duì)了，那么幸運(yùn)的，但如果不是，在開發(fā)周期的后期如果出現(xiàn)問(wèn)題，那將會(huì)付出很昂貴的代價(jià)。如何避免這種悲傷但常見問(wèn)題呢？與你的團(tuán)隊(duì)保持聯(lián)系，互相支持。如果你處理一個(gè)超級(jí)復(fù)雜的問(wèn)題并且無(wú)法就最終結(jié)果達(dá)成一致，請(qǐng)咨詢或準(zhǔn)備一個(gè)小型實(shí)踐。咨詢?cè)擃I(lǐng)域的專家或用戶可以對(duì)這件事有新的認(rèn)識(shí)。假設(shè)和實(shí)驗(yàn)特征的結(jié)果非常適合收集反饋，它允許人們實(shí)現(xiàn)一個(gè)可能是錯(cuò)誤的行為，但已經(jīng)具有驗(yàn)證其正確性的機(jī)制。該機(jī)制可能是一個(gè)指標(biāo)、一項(xiàng)調(diào)查、一個(gè)關(guān)于該功能的實(shí)驗(yàn)性質(zhì)的可預(yù)見警告，包括獲取用戶反饋的簡(jiǎn)單方法，然后由你和團(tuán)隊(duì)為特定假設(shè)選擇最優(yōu)機(jī)制。缺乏溝通溝通很重要。真的么？這句話你聽過(guò)多少次？天天說(shuō)無(wú)數(shù)次。然而在與各種規(guī)模和性質(zhì)的團(tuán)隊(duì)合作后，這仍是一個(gè)問(wèn)題。而創(chuàng)建一個(gè)沒有人害怕發(fā)言的安全開放的環(huán)境，是避免無(wú)聲的積壓改進(jìn)、制定毫無(wú)意義的沖刺計(jì)劃和漫無(wú)目的的每日Scrum會(huì)議最行之有效的方法。如果您想要的不僅僅是將項(xiàng)目從一列移動(dòng)到另一列，請(qǐng)找到一位能幫助您指導(dǎo)開發(fā)的導(dǎo)師。比如你遵循Scrum框架但沒有ScrumMaster，則應(yīng)該去找一個(gè)。就像足球運(yùn)動(dòng)員不會(huì)在沒有教練的情況下比賽。當(dāng)你意外發(fā)現(xiàn)只有10%的后端為你剛剛完成的新FE功能做好了準(zhǔn)備，或者實(shí)現(xiàn)的API調(diào)整不兼容時(shí)，去專注于溝通吧，它可以避免你在sprint結(jié)束時(shí)有意外驚喜。關(guān)鍵要點(diǎn)是什么？建立團(tuán)隊(duì)精神，讓人們喜歡彼此分享想法，如果覺得溝通太困難，請(qǐng)找一位ScrumMaster或教練來(lái)簡(jiǎn)化整體流程。商業(yè)與技術(shù)語(yǔ)言的障礙相互理解是有效團(tuán)隊(duì)的基石。軟件開發(fā)將兩個(gè)通常不知道如何溝通的世界結(jié)合在一起。以下是一些事情向南而失去意義的例子：技術(shù)人員用技術(shù)術(shù)語(yǔ)，業(yè)務(wù)人員不明白；技術(shù)人員希望業(yè)務(wù)人員做出技術(shù)決策，但業(yè)務(wù)人員不知道如何做出決定，因?yàn)樗麄儾涣私饧夹g(shù)觀點(diǎn)；商務(wù)人士用商業(yè)術(shù)語(yǔ)，技術(shù)人員不明白；業(yè)務(wù)人員試圖在不理解的情況下使用技術(shù)術(shù)語(yǔ)；在商業(yè)和技術(shù)中使用不同含義的相同詞匯。是不是很熟悉？如果想誠(chéng)實(shí)地交流，而不是假裝交流，請(qǐng)了解您的聽眾并使用他們理解的詞語(yǔ)。從上下文開始，概述問(wèn)題，提出解決方案，解釋結(jié)果，提供示例，并確保你的聽眾完全理解。錯(cuò)誤404：未找到上下文假設(shè)為功能準(zhǔn)備新需求。你可以簡(jiǎn)單地描述該功能應(yīng)該做什么，為什么重要，以及它將如何讓它更接近目標(biāo)�；蛘�，您可以概述從A到Z的所有內(nèi)容，而一點(diǎn)沒有討論的余地。哪一個(gè)更好？我相信大多數(shù)開發(fā)人員會(huì)更喜歡第一種方法。新需求是討論的起點(diǎn)，而不是最終作業(yè)。因此，產(chǎn)品負(fù)責(zé)人應(yīng)該始終從上下文描述和反饋收集開始。了解問(wèn)題及其背景的團(tuán)隊(duì)成員更有可能提出更好的想法。讓開發(fā)人員按照所寫的內(nèi)容精確地編程會(huì)浪費(fèi)工程師們的潛力，并會(huì)導(dǎo)致誤解�！盀槭裁吹膯�(wèn)題”不是不信任或攻擊性的表現(xiàn)，而是興趣的表現(xiàn)，它是區(qū)分成功團(tuán)隊(duì)和不成功團(tuán)隊(duì)的關(guān)鍵。是什么讓產(chǎn)品負(fù)責(zé)人重蹈覆轍？時(shí)間壓力是一個(gè)答案，但不能成為借口。有時(shí)需求完成得太晚了，開發(fā)人員的反饋沒有空間。設(shè)計(jì)已完成，文檔已編寫。在這種情況下，停止并丟棄需求可能具有挑戰(zhàn)性，但如果您沒有找到原因的答案，這仍然是值得的。一些資源被浪費(fèi)了，但許多資源被節(jié)省了，所以這里的教訓(xùn)是——盡快共同參與并從為什么開始。團(tuán)隊(duì)內(nèi)部孤島你的團(tuán)隊(duì)由后端、Web、移動(dòng)、業(yè)務(wù)或測(cè)試人員的不同孤島組成。你需要所有這些都有意義地進(jìn)行，沒有人可以做所有的事情。每個(gè)氣泡或筒倉(cāng)都應(yīng)該有自己的沖刺目標(biāo)嗎？我們從產(chǎn)品的角度來(lái)看。從一個(gè)項(xiàng)目開始，項(xiàng)目和用戶故事都不應(yīng)該被孤島隔開。他們不應(yīng)該指定哪個(gè)倉(cāng)可以完成這項(xiàng)工作。重要的是為sprint評(píng)審提供一個(gè)可交付部分——最終用戶可用的東西。如果團(tuán)隊(duì)經(jīng)常無(wú)法在一個(gè)sprint中交付完整功能，要么是backlog項(xiàng)太大，要么是團(tuán)隊(duì)結(jié)構(gòu)錯(cuò)誤，要么是sprint太短。讓孤島合作來(lái)改進(jìn)工作流程，永遠(yuǎn)不要將孤島分配給順序沖刺，讓它們相互等待積極主動(dòng)，走出孤島，從一開始就精誠(chéng)合作，調(diào)整流程并盡可能實(shí)現(xiàn)自動(dòng)化。最后當(dāng)然，沒有硬技能就不可能編碼。無(wú)論您處于什么職位，合作、溝通或演說(shuō)技巧等軟技能將決定將項(xiàng)目推進(jìn)何種成功程度。優(yōu)秀的公司不會(huì)尋找能夠勝任工作的人士，而是尋找能夠提供附加值的人才。合作，理解他人，永遠(yuǎn)追求最好！本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：146

有些人重視代碼編寫技巧，而輕視軟件開發(fā)的工程屬性。有些人在對(duì)需求缺乏真正理解的時(shí)候就急于編寫代碼。有些人重視軟件的功能實(shí)現(xiàn)，輕視文檔對(duì)于軟件開發(fā)和軟件作品的重要性。這些問(wèn)題導(dǎo)致軟件宕機(jī)、返工等質(zhì)量問(wèn)題時(shí)有發(fā)生。01了解基本原則的工程師，代碼質(zhì)量和開發(fā)效率更勝一籌關(guān)于軟件質(zhì)量，業(yè)界普遍認(rèn)為有3個(gè)決定性要素：人、過(guò)程和工具。如何基于這些要素提升代碼的質(zhì)量和開發(fā)效率，是軟件工程研究者和實(shí)踐者一直在努力的方向。不同的公司有不同的文化背景，雖然開發(fā)不同的軟件項(xiàng)目有不同的實(shí)踐過(guò)程，但所要遵守的基本原則都是一樣的。大量實(shí)踐證明——了解軟件開發(fā)基本原則的工程師，比那些不了解基本原則的，編寫代碼的質(zhì)量和開發(fā)效率明顯勝出一籌。原則1質(zhì)量第一QUALITYIS#1無(wú)論如何定義質(zhì)量，客戶都不會(huì)容忍低質(zhì)量的產(chǎn)品。質(zhì)量必須被量化，并建立可落地實(shí)施的機(jī)制，以促進(jìn)和激勵(lì)質(zhì)量目標(biāo)的達(dá)成。即使質(zhì)量沒達(dá)到要求，也要按時(shí)交付產(chǎn)品，這似乎是政治正確的行為，但這是短視的。從中長(zhǎng)期來(lái)看，這樣做是自殺。質(zhì)量必須被放在首位，沒有可商量的余地。EdwardYourdon建議，當(dāng)你被要求加快測(cè)試、忽視剩余的少量bug、在設(shè)計(jì)或需求達(dá)成一致前就開始編碼時(shí)，要直接說(shuō)“不”。原則7盡早把產(chǎn)品交給客戶GIVEPRODUCTSTOCUSTOMERSEARLY在需求階段，無(wú)論你多么努力地試圖去了解客戶的需求，都不如給他們一個(gè)產(chǎn)品，讓他們使用它，這是確定他們真實(shí)需求的最有效方法。如果遵循傳統(tǒng)的瀑布式開發(fā)模型，那么在99%的開發(fā)資源已經(jīng)耗盡之后，才會(huì)第一次向客戶交付產(chǎn)品。如此一來(lái)，大部分的客戶需求反饋將發(fā)生在資源耗盡之后。和以上方法相反，可在開發(fā)過(guò)程的早期構(gòu)建一個(gè)快速而粗糙的原型。將這個(gè)原型交付給客戶，收集反饋，然后編寫需求規(guī)格說(shuō)明并進(jìn)行正規(guī)的開發(fā)。使用這種方法，當(dāng)客戶體驗(yàn)到產(chǎn)品的第一個(gè)版本時(shí)，只消耗了5%～20%的開發(fā)資源。如果原型包含合適的功能，就可以更好地理解和把握最有風(fēng)險(xiǎn)的客戶需求，最終產(chǎn)品也就更有可能讓客戶滿意。這有助于確保將剩余的資源用于開發(fā)正確的系統(tǒng)。原則17只要可能，購(gòu)買而非開發(fā)IFPOSSIBLE,BUYINSTEADOFBUILD要降低不斷上漲的軟件開發(fā)成本和風(fēng)險(xiǎn)，最有效的方法就是，購(gòu)買現(xiàn)成的軟件，而不是自己從頭開發(fā)。確實(shí)，現(xiàn)成的軟件也許只能解決75%的問(wèn)題。但考慮一下從頭開發(fā)的選擇吧：支付至少10倍于購(gòu)買軟件的費(fèi)用，且要冒著超出預(yù)算100%且延期的風(fēng)險(xiǎn)（如果最后能夠完成！），并且最終發(fā)現(xiàn)，它只能滿足75%的預(yù)期。對(duì)一個(gè)客戶來(lái)說(shuō)，新的軟件開發(fā)項(xiàng)目似乎最初總是令人興奮的。開發(fā)團(tuán)隊(duì)也是“樂(lè)觀的”，對(duì)“最終”解決方案充滿了希望。但幾乎很少有軟件開發(fā)項(xiàng)目能夠順利運(yùn)行。不斷增加的成本通常會(huì)導(dǎo)致需求被縮減，最終研發(fā)出的軟件可以滿足的需求也許跟現(xiàn)成的軟件差不多。作為一個(gè)開發(fā)者，應(yīng)該復(fù)用盡可能多的軟件。復(fù)用是“購(gòu)買而非開發(fā)”原則在較小范圍內(nèi)的體現(xiàn)。原則22技術(shù)優(yōu)先于工具TECHNIQUEBEFORETOOLS一個(gè)沒規(guī)矩的木匠使用了強(qiáng)大的工具，會(huì)變成一個(gè)危險(xiǎn)的沒規(guī)矩的木匠。一個(gè)沒規(guī)矩的軟件工程師使用了工具，會(huì)變成一個(gè)危險(xiǎn)的沒規(guī)矩的軟件工程師。在使用工具前，你應(yīng)該先要“有規(guī)矩”（即理解并遵循適當(dāng)?shù)能浖�開發(fā)方法）。當(dāng)然，你也要了解如何使用工具，但這和“有規(guī)矩”相比是第二位的。我強(qiáng)烈建議，在投資于工具以對(duì)某項(xiàng)技術(shù)“自動(dòng)化”之前，先手工驗(yàn)證這項(xiàng)技術(shù)，并說(shuō)服自己和管理層：這項(xiàng)技術(shù)是可行的。在大多數(shù)情況下，如果一項(xiàng)技術(shù)在手工操作時(shí)不靈，那么在自動(dòng)操作時(shí)也不靈。原則37要承擔(dān)責(zé)任TAKERESPONSIBILITY在所有工程學(xué)科中，如果一個(gè)設(shè)計(jì)失敗，工程師會(huì)受到責(zé)備。因此，當(dāng)一座大橋倒塌時(shí)，我們會(huì)問(wèn)“工程師哪里做錯(cuò)了？”當(dāng)一個(gè)軟件失敗了，工程師很少受到責(zé)備。如果他們被責(zé)備了，他們會(huì)回答，“肯定是編譯器出錯(cuò)了”，或“我只是按照指定方法的15個(gè)步驟做的”，或“我的經(jīng)理讓我這么干的”，或“計(jì)劃剩余的時(shí)間不夠”。事實(shí)是，在任何工程學(xué)科中，用最好的方法也可能產(chǎn)出糟糕的設(shè)計(jì)，用最過(guò)時(shí)的方法也可能做出精致的設(shè)計(jì)。不要有任何借口。如果你是一個(gè)系統(tǒng)的開發(fā)者，把它做好是你的責(zé)任。要承擔(dān)這個(gè)責(zé)任。要么做好，要么就壓根不做。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：129

關(guān)于SDV的話題已經(jīng)討論了很多了，雖然對(duì)SDV究竟是一個(gè)趨勢(shì)，還是一種方法論、一種模式，乃至是一個(gè)技術(shù)領(lǐng)域等，至今還有各種討論甚至爭(zhēng)論的存在，但是，這些都不能阻礙大家對(duì)SDV的研究。無(wú)論SDV究竟是什么，以下的幾點(diǎn)是已經(jīng)達(dá)成共識(shí)了：1.軟件將越來(lái)越多的影響整個(gè)汽車的產(chǎn)業(yè)鏈，最終引起整個(gè)汽車產(chǎn)業(yè)鏈的關(guān)系重構(gòu)2.軟件的比重將在整車開發(fā)中逐漸增加，并占據(jù)重要的位置3.汽車行業(yè)的商業(yè)模式將被軟件和相關(guān)技術(shù)的應(yīng)用所逐漸改變4.符合SDV期望的車將可以常用常新、千人千面還有一個(gè)觀點(diǎn)：實(shí)現(xiàn)了SOA（ServiceOrientedArchitecture，面向服務(wù)的架構(gòu)）就是實(shí)現(xiàn)了SDV。對(duì)于這個(gè)觀點(diǎn)我一直是持有保留態(tài)度的。首先，SOA是一種設(shè)計(jì)理念，具體的實(shí)現(xiàn)方式有多種：如SOME/IP、DDS等，而且還一定會(huì)有新的技術(shù)出現(xiàn)。如果實(shí)現(xiàn)了某種技術(shù)就是實(shí)現(xiàn)了SDV，這就把SDV的概念搞小了。如果SDV是一個(gè)趨勢(shì)的話，那么技術(shù)的發(fā)展一定是持續(xù)的推動(dòng)這個(gè)趨勢(shì)在前進(jìn)，而技術(shù)一定會(huì)更新迭代，那么當(dāng)新的技術(shù)出現(xiàn)的時(shí)候，難道SDV就過(guò)時(shí)了嗎？我覺得還是不要把SDV和某種具體的技術(shù)綁在一起更好一些，因?yàn)镾DV的內(nèi)涵遠(yuǎn)遠(yuǎn)超越了某種具體的技術(shù)，它將是整個(gè)汽車產(chǎn)業(yè)鏈格局、開發(fā)流程體系、人員和相關(guān)的技術(shù)等等的變革（相對(duì)于原來(lái)的造車模式），而且這個(gè)變革將不斷深化，最終變得讓所有人都目瞪口呆。很多時(shí)候，我都在懷疑SDV是否被過(guò)度炒作了，汽車行業(yè)真的會(huì)像手機(jī)行業(yè)一樣發(fā)生那么大的變化嗎？可是這個(gè)世界就是這么奇怪：當(dāng)大多數(shù)人都開始相信一個(gè)觀點(diǎn)的時(shí)候，這個(gè)觀點(diǎn)就可以變?yōu)楝F(xiàn)實(shí)。就好像股市中大多數(shù)人都相信股市會(huì)下跌的時(shí)候，股市就真的會(huì)下跌一樣�，F(xiàn)在大家既然都相信了軟件會(huì)改變整個(gè)汽車行業(yè)，那么就會(huì)不計(jì)代價(jià)的在軟件上投入，從而推動(dòng)這個(gè)趨勢(shì)的盡快實(shí)現(xiàn)。就像軍備競(jìng)賽一樣，你如果不參與就一定會(huì)落后；而你如果參與的話，那么一定要投入巨額的資源，在大家的資源都是有限的前提下，一定會(huì)有人因?yàn)槌掷m(xù)的投入和短時(shí)間內(nèi)沒有回報(bào)而堅(jiān)持不下去。關(guān)于SDV究竟是什么就不再探討了，總之，軟件在這個(gè)世界將發(fā)揮越來(lái)越重要的作用，這是毋庸置疑的。手機(jī)已經(jīng)被改變，汽車正在被改變，還會(huì)有更多的東西被改變。其實(shí)現(xiàn)在的趨勢(shì)應(yīng)該叫做SDW（軟件定義世界，SoftwareDefinedWorld），哪個(gè)行業(yè)或者事物脫離了硬件的主導(dǎo)，而軟件起的作用越來(lái)越大，那么軟件就定義了什么�，F(xiàn)在讓我們看看汽車行業(yè)會(huì)怎么被軟件所改變。一切還是從下面這張正向開發(fā)的V模型圖開始，汽車的開發(fā)最初的起點(diǎn)還是車輛的屬性和功能。現(xiàn)在的車與十年前的車從功能上最大的差異就是在網(wǎng)聯(lián)和智能駕駛方面。網(wǎng)聯(lián)方面的功能說(shuō)穿了就兩大類：聯(lián)網(wǎng)和娛樂(lè)。隨著移動(dòng)通信技術(shù)的不斷發(fā)展，聯(lián)網(wǎng)類的功能也越來(lái)越普及，數(shù)據(jù)量越來(lái)越大，種類也越來(lái)越豐富。而支撐這些大數(shù)據(jù)量的豐富應(yīng)用的，只有兩個(gè)東西：硬件（屏幕和算力）和生態(tài)。這個(gè)可以完全類比手機(jī)，手機(jī)發(fā)展的驅(qū)動(dòng)力的基礎(chǔ)其實(shí)也是硬件（屏幕和算力）和生態(tài)。在摩爾定律支撐下的硬件的快速迭代，沒有不斷發(fā)展的生態(tài)，就不可能有手機(jī)行業(yè)的今天。而軟件則是可以發(fā)揮硬件能力的催化劑，也是構(gòu)建生態(tài)的必要條件。對(duì)于智駕類功能，無(wú)論是Level幾的自動(dòng)駕駛，基礎(chǔ)也只有兩個(gè)東西：硬件（傳感器和算力）和算法。算法是必須借助軟件才能發(fā)揮作用的，否則只是一堆寫在紙上的公式而已。而算力是將各種傳感器采集來(lái)的海量數(shù)據(jù)進(jìn)行融合，并能在限定的時(shí)間內(nèi)做出決策，從而轉(zhuǎn)化為橫向與縱向控制的基礎(chǔ)。而且，車輛越智能，需要處理的數(shù)據(jù)就越多，算法也越復(fù)雜，對(duì)算力的要求也就越高。從而，我們可以看出，車輛向智能化發(fā)展的基礎(chǔ)還是硬件性能的提升。在同樣的硬件平臺(tái)下軟件性能的改進(jìn)提升一定是有限的。不管大家如何看待軟件，軟件最核心的東西還是功能與系統(tǒng)的設(shè)計(jì)和需求。所有的軟件開發(fā)都是從需求開始的。而在整車開發(fā)中，功能才是起點(diǎn)，是功能的設(shè)計(jì)產(chǎn)生的各種需求，再加入性能要求而產(chǎn)生的需求才最終形成了軟件開發(fā)所需要的需求。沒有需求就不會(huì)有軟件，沒有算力支撐的算法只能是空中樓閣。所有的軟件設(shè)計(jì)最終還是要落實(shí)到零部件中的，還是要靠硬件來(lái)實(shí)現(xiàn)的。雖然這么說(shuō)，硬件卻是大家都可以買來(lái)的，無(wú)論是各種超強(qiáng)算力的芯片，還是整個(gè)PCB，只要花錢，總是可以用錢來(lái)解決的，而如何讓這些硬件發(fā)揮出應(yīng)有的作用，卻是要靠軟件來(lái)解決，而軟件卻是不那么容易可以直接花錢解決的。談到軟件，可以有很多種分類的方法，我們這里就以AUTOSAR的一個(gè)圖為例來(lái)詳細(xì)的討論一下。直接與ECU的硬件打交道的是BasicSoftware，也可以稱為基礎(chǔ)軟件，或者是底層軟件。這一層基本不需要OEM自己來(lái)搞定，因?yàn)槭强梢曰ㄥX買來(lái)的，有各種NB的供應(yīng)商可供選擇，如：Vector，EB，ETAS，QNX等等，目前還有一些國(guó)內(nèi)的公司也在大舉進(jìn)入。對(duì)于這個(gè)部分來(lái)說(shuō)而且只要肯花錢，質(zhì)量絕對(duì)是可以保證的�？墒侨绻�自己要是有特別要求的話，就不能直接買來(lái)了，一般可以選擇和這些供應(yīng)商定制，或者自己在上面進(jìn)行二次開發(fā)。這里的“自己”這個(gè)詞指ECU的Tier1或者OEM。下面圖中的ComplexDrivers一般來(lái)說(shuō)就屬于要定制開發(fā)的部分。另外，BasicSoftware中包含的范圍比較廣，各種診斷、網(wǎng)絡(luò)服務(wù)等都可以被劃歸到這類軟件中，總之，這些東西因?yàn)榛�本都是按照各種標(biāo)準(zhǔn)開發(fā)的，購(gòu)買的性價(jià)比相對(duì)來(lái)說(shuō)可以更高一些。上面說(shuō)的是ClassicAUTOSAR的劃分方法，下面這個(gè)圖是AdaptiveAUTOSAR的架構(gòu)圖，其實(shí)共同的特點(diǎn)都是底層是硬件相關(guān)層，最上面是Application層，中間是操作系統(tǒng)和各種系統(tǒng)服務(wù)。因?yàn)锳pplication層在最上面，我們就將其稱為上層軟件。這些上層軟件體現(xiàn)的是各個(gè)主機(jī)廠自己的核心的設(shè)計(jì)，是一輛車區(qū)別于另外一輛車的根本不同，是體現(xiàn)每個(gè)主機(jī)廠的DNA的東西。拿特斯拉來(lái)舉例。除去加速、操穩(wěn)等常規(guī)性能，特斯拉在人機(jī)交互友好性方面的創(chuàng)新基本都是通過(guò)軟件設(shè)計(jì)來(lái)實(shí)現(xiàn)的，很多人只看到了大屏或者取消了儀表等外在的東西，其實(shí)這些都是可以輕易抄襲的，可是那種毫無(wú)違和感與流暢的使用體驗(yàn)卻是靠軟件來(lái)實(shí)現(xiàn)的。而前面說(shuō)過(guò)“軟件最核心的東西還是功能與系統(tǒng)的設(shè)計(jì)和需求”，代碼只不過(guò)是一種實(shí)現(xiàn)的手段。就像一個(gè)好的建筑一定是要首先有一個(gè)好的設(shè)計(jì)圖紙和各種規(guī)范、標(biāo)準(zhǔn)，然后才是鋼筋、水泥、木材等建筑材料。自動(dòng)駕駛性能也是一樣，大家都可以在車上安裝各種攝像頭和雷達(dá)，但是能夠把自動(dòng)駕駛性能和功能做到這種水平的，目前好像只有特斯拉。而自動(dòng)駕駛的核心還是功能的設(shè)計(jì)與算法的設(shè)計(jì)。軟件只是一種實(shí)現(xiàn)手段。雖然我總是說(shuō)軟件是一種實(shí)現(xiàn)手段，可是軟件質(zhì)量的確有高低。就好像裝修房子一樣，同樣的設(shè)計(jì)，不同的裝修隊(duì)伍裝出來(lái)的效果就是不一樣，有些還會(huì)有質(zhì)量問(wèn)題。從現(xiàn)在的情況來(lái)看，特斯拉的裝修隊(duì)伍手藝還是不錯(cuò)的。應(yīng)用層軟件可以選擇的開發(fā)策略比較復(fù)雜，不同的細(xì)分領(lǐng)域，肯定要采取不同的策略。比如底盤控制，想重新搞一個(gè)ESP還是很難的，而且這個(gè)領(lǐng)域已經(jīng)比較成熟了，重新來(lái)過(guò)不見得劃算，到不如直接連硬件一起買來(lái)劃算。而車身控制與信息娛樂(lè)領(lǐng)域，相對(duì)來(lái)說(shuō)變化比較多，門檻也不高，還是可以自己去試一下的。新能源領(lǐng)域，目前已經(jīng)有很多OEM自己在搞VCU的軟件了。自動(dòng)駕駛領(lǐng)域，想要做得好，還是需要大量的投入的。而且，這個(gè)坑很深，沒有堅(jiān)定的決心和充足的準(zhǔn)備，一定要慎入。對(duì)于想自己做軟件的OEM來(lái)說(shuō)，還是選擇一個(gè)相對(duì)容易的領(lǐng)域來(lái)開始更好一些。在一個(gè)新的領(lǐng)域里面，還是保守一些風(fēng)險(xiǎn)更小�？偨Y(jié)一下：如果想做軟件，一定要記住這句話：“軟件最核心的東西還是功能與系統(tǒng)的設(shè)計(jì)和需求”（這是第三次重復(fù)了）。開始做軟件之前，一定要把功能與系統(tǒng)設(shè)計(jì)的基礎(chǔ)打牢，否則就只能靠所謂的敏捷開發(fā)和OTA來(lái)不斷的修復(fù)BUG了。主機(jī)廠自己做軟件已經(jīng)是一條看起來(lái)一定要走的路了�，F(xiàn)在大家要思考的不是走不走這條路，而是該怎么走。究竟該怎么走？每個(gè)人的選擇都可能不一樣，只是有兩個(gè)東西一定要先評(píng)估清楚：人+財(cái)。SDV時(shí)代的競(jìng)爭(zhēng)其實(shí)就是“人財(cái)”的競(jìng)爭(zhēng)。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：226

如今的汽車越來(lái)越智能化，無(wú)人駕駛亦非遙不可及，屆時(shí)人們只需要坐在車?yán)镄蓍e喝茶即可到達(dá)目的地。然而，在智能汽車的內(nèi)部卻是人們察覺不到的密密麻麻的線路以及無(wú)處不在的電子起件在工作，這就是汽車的“大腦”——電子控制系統(tǒng)。正是這套越來(lái)越復(fù)雜的電子控制系統(tǒng)完成輔助甚至替換駕駛員的動(dòng)作，實(shí)現(xiàn)對(duì)車輛運(yùn)行狀態(tài)的監(jiān)測(cè)與控制，使人們的出行更輕松、簡(jiǎn)單、安全。一、汽車電子控制系統(tǒng)發(fā)展過(guò)程——由簡(jiǎn)及繁回想七十年前的汽車，電子設(shè)備僅有起動(dòng)機(jī)、電池、車燈等為數(shù)不多的幾個(gè)，四十幾根導(dǎo)線就可以滿足整車的電子部件需求。上世紀(jì)八十年代，隨著IT技術(shù)的發(fā)展，汽車業(yè)掀起一場(chǎng)電子電氣化浪潮，各種安全配置隨之誕生。搭載軟件系統(tǒng)的電子控制器開始在汽車上生根發(fā)芽。隨著控制器數(shù)量逐漸增多，不同控制器之間需要解決通信問(wèn)題，CAN總線、LIN總線應(yīng)運(yùn)而生。2007年奧迪Q7和保時(shí)捷卡宴的線束總長(zhǎng)度突破6km,不斷增加的線束長(zhǎng)度以及越來(lái)越多的控制器給車企帶來(lái)巨大的成本壓力，隨后汽車電子控制系統(tǒng)開始向集中化發(fā)展。目前特斯拉ModelS以及Model3線束長(zhǎng)度大約3km和1.5km。汽車各大系統(tǒng)的軟件功能逐年快速增長(zhǎng)線束長(zhǎng)度的變化從側(cè)面反映出汽車電子控制系統(tǒng)由簡(jiǎn)及繁的巨大變化，軟件作為電子控制系統(tǒng)的重要組成部分，發(fā)展更趨于復(fù)雜化。二、汽車電子控制系統(tǒng)基本組成——傳感器、ECU、執(zhí)行器1、電子控制單元（ECU，含軟件）。ECU是汽車電子控制系統(tǒng)的大腦，它對(duì)各個(gè)傳感器輸入的電信號(hào)以及部分執(zhí)行器反饋的電信號(hào)進(jìn)行綜合分析與處理，給傳感器提供參考電壓，然后向執(zhí)行器發(fā)出控制信號(hào)，使執(zhí)行器按照控制目標(biāo)進(jìn)行工作。軟件系統(tǒng)集成存儲(chǔ)在電子控制單元中，核心是微處理器，這種微處理器通常采用單片機(jī)，功能擴(kuò)展容易，控制精度更高。完成數(shù)據(jù)采集、計(jì)算處理、輸出控制、系統(tǒng)監(jiān)控與自我診斷等。2、傳感器是汽車電子控制系統(tǒng)的信息采集者，類似于人類的眼睛耳朵...它將汽車的各種物理參量轉(zhuǎn)變?yōu)殡娦盘?hào)，并輸送給電子控制單元。3、執(zhí)行器是汽車電子控制系統(tǒng)的執(zhí)行者，類似于人類的手和腳，電子控制單元就是通過(guò)執(zhí)行器實(shí)現(xiàn)對(duì)被控制對(duì)象的控制。執(zhí)行器對(duì)電子控制單元輸出的控制信號(hào)做出迅速反應(yīng)，使被控制對(duì)象工作在設(shè)定狀態(tài)內(nèi)。三、汽車電子控制系統(tǒng)基本工作原理汽車電子控制系統(tǒng)事先將一系列的指令程序存儲(chǔ)在ECU中，這些指令程序在設(shè)計(jì)、制造時(shí)就已經(jīng)確定，等待各個(gè)傳感器輸入信號(hào)。工作時(shí)，ECU將接收到的傳感器信息與存儲(chǔ)器內(nèi)的“標(biāo)準(zhǔn)參數(shù)”進(jìn)行比較，然后根據(jù)結(jié)果控制執(zhí)行器采取相應(yīng)動(dòng)作。四、汽車軟件系統(tǒng)的開發(fā)過(guò)程隨著智能互聯(lián)、自動(dòng)駕駛、電動(dòng)汽車及共享出行的發(fā)展，軟件、計(jì)算能力和先進(jìn)傳感器正逐漸取代發(fā)動(dòng)機(jī)的統(tǒng)治地位。與此同時(shí)，這些電子系統(tǒng)的復(fù)雜性也在提高。以當(dāng)今汽車包含的軟件代碼行數(shù)（SLOC）為例，2010年，主流車型的SLOC約為1000萬(wàn)行；到2016年達(dá)到1.5億行左右。復(fù)雜性正如滾雪球般越來(lái)越高，不可避免地導(dǎo)致了與軟件相關(guān)的若干嚴(yán)重質(zhì)量問(wèn)題：這在近期若干起大規(guī)模車輛召回事件中屢有耳聞。根據(jù)ADAC（全德汽車俱樂(lè)部，德國(guó)最大的交通協(xié)會(huì)）統(tǒng)計(jì)，德國(guó)2004年有40%的車輛故障最終歸咎于軟件問(wèn)題或電子部件故障。為此，必須在保證電子系統(tǒng)整體可控的前提下研發(fā)新功能，于是出現(xiàn)先拆解研發(fā)而后在集成的流程。先將電子系統(tǒng)研發(fā)拆解為軟件系統(tǒng)、硬件系統(tǒng)、傳感器和執(zhí)行器四大部分，經(jīng)過(guò)V模型流程研發(fā)，最終再次集成。這個(gè)V模型涵蓋了從系統(tǒng)層面到軟件層面以及集成后的功能測(cè)試和系統(tǒng)測(cè)試等流程，是當(dāng)今汽車行業(yè)廣泛應(yīng)用的開發(fā)流程。軟件開發(fā)流程：1.分析終端客戶需求、定義邏輯系統(tǒng)架構(gòu)這一步是根據(jù)終端客戶的需求以及法規(guī)需求定義出整車軟件系統(tǒng)的邏輯架構(gòu)。其中包含各大功能塊的定義，功能塊接口定義和功能塊之間的通信定義。這一步僅考慮滿足原始需求，不會(huì)涉及任何技術(shù)層面的具體分析。2.分析邏輯系統(tǒng)架構(gòu)需求、定義技術(shù)層面系統(tǒng)架構(gòu)邏輯系統(tǒng)架構(gòu)為定義具體的技術(shù)層面系統(tǒng)架構(gòu)提供了基礎(chǔ)。在這一步中開始討論具體的技術(shù)問(wèn)題，哪些功能將通過(guò)軟件實(shí)現(xiàn)、軟件塊分裝在哪些電子控制單元以及電控單元之間采用什么通信協(xié)議等等。軟件系統(tǒng)初現(xiàn)雛形。3.分析軟件需求、定義軟件架構(gòu)這里開始具體到電控單元中對(duì)于軟件本身的需求分析。根據(jù)需求，定義出合適的軟件架構(gòu)。同時(shí)，還要考慮電控單元存儲(chǔ)資源的最優(yōu)使用、為滿足安全法規(guī)的冗余系統(tǒng)設(shè)計(jì)等等。這里，會(huì)把軟件進(jìn)一步細(xì)分為更小的軟件部件，定義各個(gè)部件之間的接口、分層和邊界。4.定義軟件部件針對(duì)每個(gè)軟件部件會(huì)繼續(xù)定義出需求。這里的需求集中在功能層面，尚不考慮具體的軟件實(shí)現(xiàn)方式等。5.設(shè)計(jì)、實(shí)現(xiàn)及測(cè)試軟件部件依據(jù)具體的需求，工程師開始分別搭建不同的軟件部件。在前面一系列的拆解、分析和定義后，終于抵達(dá)了軟件最核心最具體的世界——代碼。與人們熟知的程序員直接寫代碼稍有區(qū)別，傳統(tǒng)的汽車軟件研發(fā)采用的是基于模型開發(fā)。如下圖所示，邏輯運(yùn)算通過(guò)模型的方式表達(dá)出來(lái)，相比于代碼更加直觀，便于日后的標(biāo)定工作和維護(hù)。在一個(gè)電控單元中，有上千個(gè)這樣的功能函數(shù)，如下圖所示的功能模型組合到一起，會(huì)形成一份上萬(wàn)頁(yè)的文件。這份文件是接下來(lái)所有流程的基礎(chǔ)。當(dāng)然這套模型只是工程師之間便于交流的高級(jí)語(yǔ)言，最終它們會(huì)被人工或計(jì)算機(jī)轉(zhuǎn)為代碼進(jìn)入控制器中工作。早年間，模型到代碼中間的轉(zhuǎn)換工作由人工完成。這造成的問(wèn)題是，代碼無(wú)法統(tǒng)一化和標(biāo)準(zhǔn)化。面對(duì)一個(gè)軟件邏輯模型，程序員可以用多種方法完成代碼編譯工作，達(dá)到同樣的功能效果。但是，代碼運(yùn)行所占用的硬件資源或嚴(yán)謹(jǐn)度會(huì)大不相同。因此，近年來(lái)轉(zhuǎn)碼工作逐漸被機(jī)器取代。軟件工程師事先定義標(biāo)準(zhǔn)的編譯規(guī)范，保證最終代碼統(tǒng)一和標(biāo)準(zhǔn)。每一個(gè)軟件部件完成后，要進(jìn)行相應(yīng)的軟件測(cè)試。這里還不會(huì)聚焦功能層面的測(cè)試，僅僅針對(duì)軟件本身。例如軟件中是否因設(shè)計(jì)不當(dāng)產(chǎn)生死循環(huán)、每個(gè)信號(hào)定義的范圍是否恰當(dāng)、會(huì)不會(huì)造成溢出錯(cuò)誤或者會(huì)不會(huì)出現(xiàn)除以零的運(yùn)算情況等等。針對(duì)這些，工程師要事先定義測(cè)試方案，由計(jì)算機(jī)進(jìn)行全方位全覆蓋的軟件邏輯測(cè)試。例如，對(duì)于if,else語(yǔ)句需要把每一種可能的情況都測(cè)試檢查到。6.集成及測(cè)試軟件部件單一軟件部件研發(fā)測(cè)試完成后，將它們集成到一起就形成了每個(gè)電控單元中完整的軟件包。這套軟件包在集成后依然需要測(cè)試，檢查各部件之間是否兼容，是否有開放接口等等。7.系統(tǒng)集成及測(cè)試當(dāng)軟件包集成測(cè)試結(jié)束，它們將被刷進(jìn)每一個(gè)電子控制器中。每個(gè)控制器與相應(yīng)的傳感器、執(zhí)行器等用線束相連，最后控制器之間接通總線通信。這樣整套電子系統(tǒng)終于誕生。如新生兒一般，這套系統(tǒng)依然十分脆弱和稚嫩，還有很大的潛力等待被開發(fā)。系統(tǒng)集成后的第一批測(cè)試往往是問(wèn)題重重。因?yàn)橄到y(tǒng)高度復(fù)雜，各個(gè)研發(fā)部件被分工研發(fā)，即便之前有嚴(yán)格的測(cè)試流程，仍會(huì)有許多漏網(wǎng)之bug。如果分工研發(fā)的各部門之間沒有在開發(fā)過(guò)程中充分交流，集成后可能會(huì)出現(xiàn)各類兼容性問(wèn)題。針對(duì)每一個(gè)問(wèn)題，工程師們都不會(huì)忘記前面提到的拆解和掌控。拆解表象問(wèn)題，找到根源，修復(fù)軟件bug，掌控整套系統(tǒng)。8.標(biāo)定系統(tǒng)測(cè)試結(jié)束后將進(jìn)入軟件標(biāo)定階段，這也是軟件開發(fā)中的重要階段。在軟件實(shí)現(xiàn)階段，工程師會(huì)在軟件中預(yù)留一些可標(biāo)定參數(shù)而不是固定的數(shù)值，等待標(biāo)定。這是基于成本考量，車型繁多的整車廠不可能為每款車型單獨(dú)開發(fā)一套軟件系統(tǒng)。一般的解決方案是研發(fā)平臺(tái)軟件，適用于多款車型。然而每款車型都有自己的特點(diǎn)，平臺(tái)軟件無(wú)法讓這些特點(diǎn)發(fā)光，標(biāo)定可以。通過(guò)改變不同的參數(shù)數(shù)值，可以讓車輛實(shí)現(xiàn)不同的駕駛性能，這也給了標(biāo)定工程師很大的發(fā)揮空間。9.系統(tǒng)測(cè)試及接受度測(cè)試標(biāo)定完成后，就進(jìn)入了整套流程的最終階段。依據(jù)流程一開始提出的需求，忽略那些具體的技術(shù)實(shí)現(xiàn)手段，站在整個(gè)系統(tǒng)的高度檢驗(yàn)它是否達(dá)到了終端客戶的需求。到了這一步，整套軟件系統(tǒng)已經(jīng)十分成熟。在正式進(jìn)入量產(chǎn)前會(huì)從一個(gè)時(shí)間點(diǎn)開始，停止所有軟件和標(biāo)定變更，為最終量產(chǎn)做準(zhǔn)備。整套V模型走下來(lái)可以看到，左側(cè)和右側(cè)的每個(gè)環(huán)節(jié)相互對(duì)應(yīng)。需求為定義測(cè)試方案提供基礎(chǔ)，而測(cè)試結(jié)果又會(huì)帶動(dòng)進(jìn)一步的開發(fā)和完善。你或許會(huì)問(wèn)，如果從V模型的左上角好不容易一路走到右上角，結(jié)果最后一步測(cè)試發(fā)現(xiàn)當(dāng)初第一步的系統(tǒng)構(gòu)架出了設(shè)計(jì)問(wèn)題，那豈不是為時(shí)已晚？難道還要一切重新來(lái)過(guò)？的確，軟件系統(tǒng)十分復(fù)雜，研發(fā)周期長(zhǎng)。如果只是沿著V模型慢慢悠悠從左到右走一遍，等最后一步才發(fā)現(xiàn)問(wèn)題，那確實(shí)一切都來(lái)不及了。因此，在實(shí)際研發(fā)中會(huì)持續(xù)不斷地集成、持續(xù)不斷地測(cè)試，工程師們會(huì)把V模型從左到右重復(fù)走許多遍。研發(fā)初期連原型車都還沒有的時(shí)候，軟件測(cè)試會(huì)依靠整車仿真系統(tǒng)在計(jì)算機(jī)中進(jìn)行，發(fā)動(dòng)機(jī)、變速箱、電子控制器、總線等都虛擬存在于工程師電腦中（SiL,SoftwareintheLoop）。在仿真系統(tǒng)中，汽車可以如真實(shí)般開動(dòng)，模擬各種工況提供給工程師測(cè)試。隨著車型研發(fā)推進(jìn)，某些電子控制器研發(fā)完成，他們可以取代那些虛擬的電子控制器進(jìn)入測(cè)試環(huán)境，但是其他部件仍為虛擬仿真（HiL,HardwareintheLoop）。直到有一天，原型車研發(fā)完成，軟件集成和測(cè)試進(jìn)入試驗(yàn)臺(tái)架。最終，原型車調(diào)試完畢落地，軟件測(cè)試進(jìn)入實(shí)車階段�？梢哉f(shuō)，軟件開發(fā)的起始點(diǎn)非常早，從虛擬到現(xiàn)實(shí)一路走來(lái)，一直延續(xù)到最后的量產(chǎn)前夕。其實(shí)目的只有一個(gè)，通過(guò)不斷集成和測(cè)試，盡可能發(fā)現(xiàn)所有問(wèn)題，保證汽車的駕駛性、舒適性和安全性。五、汽車電子軟件發(fā)展趨勢(shì)1、ECU整合度將提升早在去年，大眾就宣布力爭(zhēng)讓汽車上只有一個(gè)ECU。在一些供應(yīng)商巨頭內(nèi)部，確實(shí)也在這么做。特別是在ADAS和自動(dòng)駕駛下，整合的ECU架構(gòu)尤為重要。2、ECU將承載更多的傳感器未來(lái)汽車將需要更多的傳感器來(lái)感知環(huán)境，以及依靠傳感器來(lái)保證冗余設(shè)計(jì)。這對(duì)ECU的能力來(lái)說(shuō)也是考驗(yàn)。不過(guò)高級(jí)算法與機(jī)器學(xué)習(xí)的發(fā)展，有望取代一部分傳感器，減少傳感器數(shù)量。3、汽車以太網(wǎng)發(fā)展長(zhǎng)期以來(lái)，汽車ECU都是在一個(gè)封閉的網(wǎng)絡(luò)環(huán)境下。不過(guò)隨著智能汽車技術(shù)、物聯(lián)網(wǎng)的發(fā)展，很有可能會(huì)催生汽車以太網(wǎng)，實(shí)現(xiàn)跨域通信。不過(guò)如何保證功能安全，這將又是對(duì)汽車軟件的一大考驗(yàn)。數(shù)據(jù)量的提升、HAD的冗余要求、互聯(lián)環(huán)境下的安全保障，以及跨行業(yè)標(biāo)準(zhǔn)協(xié)議的需求很有可能催生汽車以太網(wǎng)，并使其成為冗余中央數(shù)據(jù)總線的關(guān)鍵助推因素。以太網(wǎng)解決方案可以實(shí)現(xiàn)跨域通信，并通過(guò)添加以太網(wǎng)擴(kuò)展，例如音-視頻橋接（AVB）和時(shí)間敏感網(wǎng)絡(luò)（TSN）等，來(lái)滿足實(shí)時(shí)性要求。本地互聯(lián)網(wǎng)絡(luò)、控制器區(qū)域網(wǎng)絡(luò)等傳統(tǒng)網(wǎng)絡(luò)將繼續(xù)在車輛上運(yùn)用，但僅用于封閉式的低級(jí)網(wǎng)絡(luò)，如傳感器和執(zhí)行器等。FlexRay和MOST等技術(shù)有可能被汽車以太網(wǎng)及其擴(kuò)展（如AVB、TSN等）取代。4、整車企業(yè)會(huì)嚴(yán)控與功能安全及HAD相關(guān)的數(shù)據(jù)互連，但將為第三方訪問(wèn)數(shù)據(jù)開放接口發(fā)送與接收安全關(guān)鍵數(shù)據(jù)的中央互聯(lián)網(wǎng)關(guān)將始終直接且僅連接到整車企業(yè)的后臺(tái)，第三方會(huì)被允許進(jìn)行數(shù)據(jù)訪問(wèn)（被監(jiān)管法規(guī)排除的場(chǎng)景除外）。然而，在車輛APP化的推動(dòng)下，資訊娛樂(lè)系統(tǒng)的新興開放接口將允許內(nèi)容和應(yīng)用程序供應(yīng)商加載內(nèi)容，而整車企業(yè)將盡可能嚴(yán)格地保持各自的標(biāo)準(zhǔn)。目前的車載診斷端口將被互聯(lián)通訊方案取代。通過(guò)接入整車物理端口來(lái)讀取車輛數(shù)據(jù)不再必要，登陸車企后臺(tái)即可。車企將在其后臺(tái)開放若干數(shù)據(jù)接口，以滿足若干特定場(chǎng)景的需求，如失竊車輛軌跡追蹤或個(gè)性化保險(xiǎn)等5、汽車將在云端結(jié)合車內(nèi)及車外信息雖然非車企以外的企業(yè)參與程度仍取決于監(jiān)管法規(guī)，非敏感數(shù)據(jù)（即非隱私或安全相關(guān)數(shù)據(jù)）仍然有望更多地在云端進(jìn)行處理。隨著數(shù)據(jù)量的增長(zhǎng)，大數(shù)據(jù)分析將被越來(lái)越多地應(yīng)用于數(shù)據(jù)處理，并將基于數(shù)據(jù)處理結(jié)果制定相應(yīng)的行動(dòng)方案。基于數(shù)據(jù)的自動(dòng)駕駛的應(yīng)用及其他各項(xiàng)數(shù)字化創(chuàng)新將依賴于不同企業(yè)之間的數(shù)據(jù)共享。當(dāng)然現(xiàn)在仍然不清楚不同企業(yè)間的數(shù)據(jù)共享將如何實(shí)現(xiàn)、由誰(shuí)實(shí)現(xiàn)，但主要的傳統(tǒng)供應(yīng)商和技術(shù)企業(yè)已經(jīng)開始建立有能力處理此種海量數(shù)據(jù)的集成化平臺(tái)。6、汽車將應(yīng)用雙向通信的可更新部件通過(guò)車載測(cè)試系統(tǒng)，汽車可以實(shí)現(xiàn)自動(dòng)檢查功能和集成更新，從而推動(dòng)生命周期管理，以及增強(qiáng)或解鎖產(chǎn)品的售后功能。所有ECU都會(huì)與傳感器和執(zhí)行器交換數(shù)據(jù)，并檢索數(shù)據(jù)包來(lái)支持創(chuàng)新性用例，如基于車輛參數(shù)的路線計(jì)算。OTA更新是HAD的前提條件，它還將有助于開發(fā)新功能、確保網(wǎng)絡(luò)安全，并使車企得以更快部署功能與軟件。事實(shí)上，正是OTA推動(dòng)了本文提及的多項(xiàng)整車架構(gòu)上的重大變革。為實(shí)現(xiàn)類似智能手機(jī)那樣的升級(jí)性，汽車行業(yè)須克服限制性的經(jīng)銷合同、監(jiān)管要求和安全與隱私問(wèn)題等諸多挑戰(zhàn)。整車企業(yè)將與該領(lǐng)域的技術(shù)供應(yīng)商密切合作，在OTA平臺(tái)上實(shí)現(xiàn)車隊(duì)標(biāo)準(zhǔn)化。車輛將在全壽命周期內(nèi)獲取功能性及安全性升級(jí)。監(jiān)管部門可能強(qiáng)制要求軟件維護(hù)，來(lái)確保車輛設(shè)計(jì)的安全完整性。更新和維護(hù)軟件的責(zé)任將在車輛維護(hù)與運(yùn)行領(lǐng)域催生新業(yè)務(wù)模式。中國(guó)將成為汽車軟件及電子產(chǎn)業(yè)發(fā)展的新高地中國(guó)的整車行業(yè)在過(guò)去幾年取得了有目共睹的巨大發(fā)展。國(guó)產(chǎn)汽車行業(yè)的進(jìn)展不僅體現(xiàn)在傳統(tǒng)能源汽車的研發(fā)及制造上，也同時(shí)體現(xiàn)在了諸如汽車電動(dòng)化、共享化、互聯(lián)網(wǎng)化、無(wú)人駕駛化等所謂“新四化”上。國(guó)產(chǎn)汽車軟件及電子的發(fā)展，也會(huì)借此東風(fēng)，不斷取得新發(fā)展。國(guó)內(nèi)一些車企在上面軟件發(fā)展趨勢(shì)中也有所動(dòng)作：ECU整合：比亞迪早前宣布在最新的e平臺(tái)上實(shí)現(xiàn)儀表、空調(diào)、音響、智能鑰匙等控制模塊10合1，使整車控制模塊線束大幅減少，降低模塊故障率以及提升生產(chǎn)裝配效率。汽車以太網(wǎng)：上汽集團(tuán)早前推出了基于全新電子電氣架構(gòu)的電動(dòng)車平臺(tái)——DoubleE架構(gòu)，核心亮點(diǎn)之一是采用了支持海量數(shù)據(jù)極速傳輸?shù)囊蕴�網(wǎng)技術(shù)。整車廠商開放數(shù)據(jù)接口：比亞迪早前上線了汽車智慧開放平臺(tái)，并通過(guò)該平臺(tái)將車內(nèi)信號(hào)封裝為數(shù)百個(gè)API。開放的API內(nèi)容涵蓋車身、行駛數(shù)據(jù)、車速、全景、空調(diào)、雷達(dá)、充電設(shè)備等18類數(shù)據(jù)。云端數(shù)據(jù)處理：阿里巴巴推出的AliOS智聯(lián)網(wǎng)汽車解決方案，其一大亮點(diǎn)是充分發(fā)揮了阿里云在云計(jì)算、大數(shù)據(jù)和人工智能的優(yōu)勢(shì)，借助阿里巴巴的生態(tài)能力，賦能合作伙伴更好探索“數(shù)據(jù)x智能”驅(qū)動(dòng)的新型業(yè)務(wù)模式。OTA：上汽與阿里巴巴合作的斑馬智行在2017年底/2018年初完成對(duì)近40萬(wàn)臺(tái)榮威/MG品牌乘用車的OTA升級(jí)，受到了業(yè)內(nèi)極大關(guān)注，堪稱是智能汽車在華發(fā)展的標(biāo)志性事件之一。汽車軟件和電子系統(tǒng)的新時(shí)代已經(jīng)開啟。此前業(yè)內(nèi)奉為圭臬的業(yè)務(wù)模式、客戶需求和競(jìng)爭(zhēng)格局都將發(fā)生劇變。我們對(duì)即將產(chǎn)生的產(chǎn)值和利潤(rùn)持樂(lè)觀態(tài)度。但若想從變革中獲益，汽車行業(yè)的所有參與者均應(yīng)根據(jù)全新的環(huán)境，重新思考和謹(jǐn)慎定位（或再定位）自身的價(jià)值主張。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：186

軟件功能安全開發(fā)中主要針對(duì)的是軟件的系統(tǒng)性失效。這里面主要是針對(duì)各階段開發(fā)活動(dòng)提出了相應(yīng)的規(guī)范性要求，并對(duì)不同ASIL等級(jí)軟件開發(fā)，所需要進(jìn)行的具體測(cè)試方法和內(nèi)容。軟件功能開發(fā)遵循V模型開發(fā)，即從需求開始，分層次進(jìn)行軟件的架構(gòu)設(shè)計(jì)、單元設(shè)計(jì)和具體的代碼開發(fā)。與每階段設(shè)計(jì)開發(fā)對(duì)應(yīng)的是相應(yīng)的集成和測(cè)試工作。ISO26262里對(duì)軟件開發(fā)的很多具體規(guī)范性要求很多，并且比較詳細(xì)。但對(duì)這些規(guī)范的合規(guī)性檢查就是不太容易操作的事情了。對(duì)于代碼的靜態(tài)分析和語(yǔ)義代碼分析，在開發(fā)中可以借助專業(yè)工具依據(jù)具體的規(guī)范標(biāo)準(zhǔn)（如MISRA-C等）進(jìn)行檢查，工具可以幫助查找所有錯(cuò)誤和不符合項(xiàng)。而對(duì)于一些設(shè)計(jì)規(guī)則，如軟件架構(gòu)設(shè)計(jì)要注意層次性，高內(nèi)聚，低耦合。這種指導(dǎo)性的要求，在實(shí)際開發(fā)中，開發(fā)者不太容易對(duì)開發(fā)產(chǎn)物進(jìn)行準(zhǔn)確評(píng)價(jià)。這里簡(jiǎn)單介紹一下業(yè)界使用比較廣泛的架構(gòu)設(shè)計(jì)標(biāo)準(zhǔn)和設(shè)計(jì)思路。汽車電子領(lǐng)域最常用的軟件架構(gòu)設(shè)計(jì)標(biāo)準(zhǔn)之一是AUTOSAR（AUTOmotiveOpenSystemArchitecture）。AUTOSAR標(biāo)準(zhǔn)是2003年歐洲寶馬為首幾家OEM聯(lián)合一些Tier1成立的聯(lián)盟，目標(biāo)是開發(fā)適用于汽車電子開發(fā)的支持分布式、功能驅(qū)動(dòng)的汽車電子軟件開發(fā)方法和軟件架構(gòu)標(biāo)準(zhǔn)化方案。AUTOSAR采用了分層式的設(shè)計(jì)，實(shí)現(xiàn)了軟件和硬件的分離。AUTOSAR通過(guò)中間層RTE(RuntimeEnviroment)作為虛擬總線，成功的實(shí)現(xiàn)上層應(yīng)用軟件層（ApplicationSoftwareLayer）和下層基于硬件的基礎(chǔ)軟件層（BasicSoftware）。采用AUTOSAR架構(gòu)設(shè)計(jì)，在進(jìn)行應(yīng)用層軟件開發(fā)時(shí)，可以不受硬件ECU的限制，擺脫了對(duì)硬件的依賴。RTE集合了所有AUTOSAR提供的通信機(jī)制。應(yīng)用軟件被劃分為各個(gè)組件，通過(guò)系統(tǒng)配置，軟件組件會(huì)被映射到指定的ECU上，而組件間的虛擬連接也同時(shí)映射CAN,FlexRay,MOST等總線上。軟件組件與RTE通信，是通過(guò)預(yù)先定義好的端口來(lái)實(shí)現(xiàn)的。各軟件組件之間不允許直接互相通信，RTE層封裝好COM等通信層BSW后，為上層應(yīng)用軟件提供RTEAPI，軟件組件再使用端口的方式進(jìn)行通信。AUTOSAR架構(gòu)中共分六層：1.應(yīng)用軟件層（ApplicationLayer）2.運(yùn)行環(huán)境RTE(RuntimeEnvironment)3.服務(wù)層（ServicesLayer）4.ECU抽象層（ECUAbstractionLayer）5.微控制器抽象層（MicrocontrollerAbstractionLayer）6.復(fù)雜驅(qū)動(dòng)（ComplexDeviceDrivers）微控制器抽象層是處理控制器依賴的各功能，包括IO驅(qū)動(dòng)、通信驅(qū)動(dòng)、內(nèi)存驅(qū)動(dòng)和微控制器驅(qū)動(dòng)。這一層也相當(dāng)于傳統(tǒng)嵌入式開發(fā)中的底層驅(qū)動(dòng)。ECU抽象層是基于ECU依賴的各功能，這一層經(jīng)過(guò)微控制器抽象層的隔離，已經(jīng)是不依賴特定的微控制器了。ECU抽象層主要包括IO硬件抽象層、通信抽象層、內(nèi)存抽象層和車載設(shè)備抽象層。ECU抽象層將微控制器抽象層各功能抽象為ECU層的功能。服務(wù)層主要包括了通信服務(wù)、內(nèi)存服務(wù)和系統(tǒng)服務(wù)。這一層可以隔離大部分ECU依賴的功能。而在開發(fā)中，一些極高實(shí)時(shí)性的傳感器采樣、執(zhí)行器控制等功能，需要通過(guò)專門的復(fù)雜驅(qū)動(dòng)來(lái)實(shí)現(xiàn)。軟件開發(fā)中采用AUTOSAR架構(gòu)，成功的將應(yīng)用層與底層隔離開了。這樣車廠或者Tier1可以專心進(jìn)行與產(chǎn)品功能直接相關(guān)的應(yīng)用層開發(fā)，在應(yīng)用層上建立起區(qū)別于對(duì)手的特征。對(duì)于中間層和底層，可以交由專業(yè)的供應(yīng)商來(lái)完成，而且這一部分有越來(lái)越趨同的現(xiàn)象。中間層和底層對(duì)用戶是不可見的，車廠對(duì)于這部分工作甚至可以采用共同的平臺(tái)供應(yīng)商，這樣對(duì)成本和產(chǎn)品成熟、穩(wěn)定性都是有很大幫助的。當(dāng)然，上面提到的AUTOSAR的優(yōu)勢(shì)只是理論上的。在實(shí)際產(chǎn)品開發(fā)中，應(yīng)用層開發(fā)方或者最終產(chǎn)品負(fù)責(zé)方是不可能真的做到完全不管中間層和底層實(shí)現(xiàn)的，只是這種參與和投入程度相比傳統(tǒng)的方式大大減少。作為系統(tǒng)開發(fā)和集成方，對(duì)于功能安全產(chǎn)品開發(fā)，其負(fù)責(zé)的工作不僅包括軟件開發(fā)，也包括達(dá)到標(biāo)準(zhǔn)對(duì)硬件指標(biāo)的要求。而對(duì)于硬件設(shè)計(jì)，其是與采用的控制器型號(hào)、外圍驅(qū)動(dòng)和通信設(shè)備、甚至電容電阻是直接相關(guān)的。對(duì)于硬件相關(guān)的診斷，大多需要相應(yīng)的軟件功能來(lái)調(diào)用和實(shí)現(xiàn)。對(duì)于很多軟件功能診斷，同樣會(huì)對(duì)硬件設(shè)備提出要求。在系統(tǒng)架構(gòu)設(shè)計(jì)上，需要兼顧軟硬件需求，合理設(shè)計(jì)系統(tǒng)架構(gòu)。汽車設(shè)計(jì)中常采用的架構(gòu)包括從傳統(tǒng)發(fā)動(dòng)機(jī)設(shè)計(jì)演變而來(lái)的EGAS三層架構(gòu)。在功能安全的系統(tǒng)架構(gòu)設(shè)計(jì)中，我們可以考慮借鑒類似EGAS這種業(yè)界比較成熟的架構(gòu)設(shè)計(jì)思路。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：263

原則1質(zhì)量第一QUALITYIS#1無(wú)論如何定義質(zhì)量，客戶都不會(huì)容忍低質(zhì)量的產(chǎn)品。質(zhì)量必須被量化，并建立可落地實(shí)施的機(jī)制，以促進(jìn)和激勵(lì)質(zhì)量目標(biāo)的達(dá)成。即使質(zhì)量沒達(dá)到要求，也要按時(shí)交付產(chǎn)品，這似乎是政治正確的行為，但這是短視的。從中長(zhǎng)期來(lái)看，這樣做是自殺。質(zhì)量必須被放在首位，沒有可商量的余地。EdwardYourdon建議，當(dāng)你被要求加快測(cè)試、忽視剩余的少量bug、在設(shè)計(jì)或需求達(dá)成一致前就開始編碼時(shí)，要直接說(shuō)“不”。原則2質(zhì)量在每個(gè)人眼中都不同QUALITYISINTHEEYESOFTHEBEHOLDER軟件質(zhì)量沒有唯一的定義。對(duì)開發(fā)者來(lái)說(shuō)，質(zhì)量可能是優(yōu)雅的設(shè)計(jì)或優(yōu)雅的代碼。對(duì)在緊張環(huán)境中工作的客戶來(lái)說(shuō)，質(zhì)量可能是響應(yīng)時(shí)間或高吞吐量。對(duì)成本敏感的項(xiàng)目來(lái)說(shuō)，質(zhì)量可能是低開發(fā)成本。對(duì)一些客戶來(lái)說(shuō)，質(zhì)量可能是滿足他們所有已知和未知的需求。這里的難題是，以上要求可能無(wú)法完全兼顧。當(dāng)優(yōu)化某人關(guān)注的質(zhì)量時(shí)，可能會(huì)影響其他人關(guān)注的質(zhì)量（這就是溫伯格的“政治困境”原則）。項(xiàng)目必須確定各因素的優(yōu)先級(jí)，并清晰地傳達(dá)給所有相關(guān)方。原則3高質(zhì)量軟件是可以實(shí)現(xiàn)的HIGH-QUALITYSOFTWAREISPOSSIBLE盡管我們的行業(yè)中有一些表現(xiàn)不佳、包含bug，或者根本無(wú)法滿足客戶需求的軟件系統(tǒng)的例子，但仍然有一些成功的例子。大型軟件系統(tǒng)可以以非常高的質(zhì)量構(gòu)建，但價(jià)格昂貴：每行代碼高達(dá)1000美元。例如，IBM為美國(guó)宇航局的航天飛機(jī)開發(fā)的機(jī)載飛行軟件，總共約300萬(wàn)行代碼，源于嚴(yán)謹(jǐn)?shù)能浖�開發(fā)過(guò)程，產(chǎn)品發(fā)布后每萬(wàn)行代碼中發(fā)現(xiàn)的錯(cuò)誤少于一個(gè)。作為軟件開發(fā)人員，應(yīng)該學(xué)習(xí)和了解已被驗(yàn)證、可以極大提高軟件質(zhì)量的方法。這些方法包括：讓客戶參與（見原則8）、原型設(shè)計(jì)（在全面開發(fā)之前驗(yàn)證需求；見原則11～13）、保持設(shè)計(jì)簡(jiǎn)單（見原則67）、審查代碼（見原則98）和雇用最優(yōu)秀的人（見原則130和131）。作為客戶，在追求卓越的同時(shí)，要意識(shí)到隨之而來(lái)的高額成本。原則4不要試圖通過(guò)改進(jìn)軟件實(shí)現(xiàn)高質(zhì)量DON’TTRYTORETROFITQUALITY質(zhì)量無(wú)法通過(guò)軟件的改進(jìn)來(lái)獲得。這適用于質(zhì)量的任何定義：可維護(hù)性、可靠性、適應(yīng)性、可測(cè)試性、安全性等。即使我們?cè)陂_發(fā)過(guò)程中十分努力，使軟件具備高質(zhì)量也是十分不易的。如果我們不努力，又怎么可能期望獲得高質(zhì)量呢？這就是絕不能將“一次性原型”轉(zhuǎn)換成產(chǎn)品的主要原因（見原則11）。原則5盡早把產(chǎn)品交給客戶GIVEPRODUCTSTOCUSTOMERSEARLY在需求階段，無(wú)論你多么努力地試圖去了解客戶的需求，都不如給他們一個(gè)產(chǎn)品，讓他們使用它，這是確定他們真實(shí)需求的最有效方法。如果遵循傳統(tǒng)的瀑布式開發(fā)模型，那么在99%的開發(fā)資源已經(jīng)耗盡之后，才會(huì)第一次向客戶交付產(chǎn)品。如此一來(lái)，大部分的客戶需求反饋將發(fā)生在資源耗盡之后。和以上方法相反，可在開發(fā)過(guò)程的早期構(gòu)建一個(gè)快速而粗糙的原型。將這個(gè)原型交付給客戶，收集反饋，然后編寫需求規(guī)格說(shuō)明并進(jìn)行正規(guī)的開發(fā)。使用這種方法，當(dāng)客戶體驗(yàn)到產(chǎn)品的第一個(gè)版本時(shí)，只消耗了5%～20%的開發(fā)資源。如果原型包含合適的功能，就可以更好地理解和把握最有風(fēng)險(xiǎn)的客戶需求，最終產(chǎn)品也就更有可能讓客戶滿意。這有助于確保將剩余的資源用于開發(fā)正確的系統(tǒng)。原則6促使開發(fā)者與客戶的目標(biāo)一致ALIGNINCENTIVESFORDEVELOPERANDCUSTOMER項(xiàng)目經(jīng)常會(huì)因?yàn)榭蛻艉烷_發(fā)人員的目標(biāo)不同（或不兼容）而失敗。一個(gè)簡(jiǎn)單的案例是，客戶希望在特定日期前獲得特性1、2、3，而開發(fā)人員希望最大化營(yíng)收或利潤(rùn)。為了最大化營(yíng)收，開發(fā)人員可能會(huì)嘗試完整地開發(fā)這三個(gè)特性，即使會(huì)導(dǎo)致項(xiàng)目延期。與此同時(shí)，客戶可能寧愿放棄其中一個(gè)特性的一部分功能，只要能按時(shí)交付其他特性。為使雙方的目標(biāo)達(dá)成一致，有如下方法：（1）按優(yōu)先級(jí)對(duì)需求排序（見原則50），以便開發(fā)人員了解它們的相對(duì)重要性。（2）根據(jù)需求的優(yōu)先級(jí)獎(jiǎng)勵(lì)開發(fā)人員（例如，所有高優(yōu)先級(jí)的需求必須完成；每完成一個(gè)中優(yōu)先級(jí)的需求，開發(fā)人員可獲得一些額外的小獎(jiǎng)勵(lì)；每完成一個(gè)低優(yōu)先級(jí)的需求，可獲得的獎(jiǎng)勵(lì)非常�。�。（3）對(duì)逾期交付實(shí)行嚴(yán)厲的處罰。原則7要快速地開發(fā)一次性原型BUILDTHROWAWAYPROTOTYPESQUICKLY如果你已經(jīng)決定開發(fā)一次性原型，那么就要用最快的方式。不用擔(dān)心質(zhì)量�？墒褂谩耙豁�(yè)紙”的需求規(guī)格說(shuō)明。不用擔(dān)心設(shè)計(jì)或編碼中的文檔�？梢允褂萌魏喂ぞ��？梢允褂萌魏尉幊陶Z(yǔ)言，只要能夠方便程序的快速開發(fā)。不用擔(dān)心編程語(yǔ)言的可維護(hù)性。原則8看到越多，需要越多THEMORESEEN,THEMORENEEDED在軟件行業(yè)，一次次見證了：提供給用戶的功能（或性能）越多，用戶想要的功能（或性能）就越多。當(dāng)然，這與原則7（盡早把產(chǎn)品交給客戶）、原則14（漸進(jìn)地?cái)U(kuò)展系統(tǒng)）、原則185（軟件會(huì)持續(xù)變化）以及原則201（系統(tǒng)的存在促進(jìn)了演變）互相支持。但更重要的是，你必須為不可避免的情況做好準(zhǔn)備。在管理和工程處理流程的每個(gè)方面都應(yīng)該做好準(zhǔn)備，一旦用戶看到產(chǎn)品，他們就會(huì)想要更多的東西。這意味著，所產(chǎn)生的每個(gè)文檔都應(yīng)該以有利于更改的方式進(jìn)行存儲(chǔ)和組織。這意味著，配置管理流程（見原則174）必須在距離交付很長(zhǎng)時(shí)間之前就就位。這也意味著，在軟件部署后不久，你就應(yīng)該準(zhǔn)備好，以應(yīng)對(duì)用戶口頭或書面請(qǐng)求的沖擊。這還意味著，你選擇的設(shè)計(jì)方案應(yīng)使容量、輸入速率和功能都很容易變更。原則9只要可能，購(gòu)買而非開發(fā)IFPOSSIBLE,BUYINSTEADOFBUILD要降低不斷上漲的軟件開發(fā)成本和風(fēng)險(xiǎn)，最有效的方法就是，購(gòu)買現(xiàn)成的軟件，而不是自己從頭開發(fā)。確實(shí)，現(xiàn)成的軟件也許只能解決75%的問(wèn)題。但考慮一下從頭開發(fā)的選擇吧：支付至少10倍于購(gòu)買軟件的費(fèi)用，且要冒著超出預(yù)算100%且延期的風(fēng)險(xiǎn)（如果最后能夠完成�。�，并且最終發(fā)現(xiàn)，它只能滿足75%的預(yù)期。對(duì)一個(gè)客戶來(lái)說(shuō)，新的軟件開發(fā)項(xiàng)目似乎最初總是令人興奮的。開發(fā)團(tuán)隊(duì)也是“樂(lè)觀的”，對(duì)“最終”解決方案充滿了希望。但幾乎很少有軟件開發(fā)項(xiàng)目能夠順利運(yùn)行。不斷增加的成本通常會(huì)導(dǎo)致需求被縮減，最終研發(fā)出的軟件可以滿足的需求也許跟現(xiàn)成的軟件差不多。作為一個(gè)開發(fā)者，應(yīng)該復(fù)用盡可能多的軟件。復(fù)用是“購(gòu)買而非開發(fā)”原則在較小范圍內(nèi)的體現(xiàn)�？蓞⒖荚瓌t84。原則10技術(shù)優(yōu)先于工具TECHNIQUEBEFORETOOLS一個(gè)沒規(guī)矩的木匠使用了強(qiáng)大的工具，會(huì)變成一個(gè)危險(xiǎn)的沒規(guī)矩的木匠。一個(gè)沒規(guī)矩的軟件工程師使用了工具，會(huì)變成一個(gè)危險(xiǎn)的沒規(guī)矩的軟件工程師。在使用工具前，你應(yīng)該先要“有規(guī)矩”（即理解并遵循適當(dāng)?shù)能浖�開發(fā)方法）。當(dāng)然，你也要了解如何使用工具，但這和“有規(guī)矩”相比是第二位的。我強(qiáng)烈建議，在投資于工具以對(duì)某項(xiàng)技術(shù)“自動(dòng)化”之前，先手工驗(yàn)證這項(xiàng)技術(shù)，并說(shuō)服自己和管理層：這項(xiàng)技術(shù)是可行的。在大多數(shù)情況下，如果一項(xiàng)技術(shù)在手工操作時(shí)不靈，那么在自動(dòng)操作時(shí)也不靈。原則11跟風(fēng)要小心FOLLOWTHELEMMINGSWITHCARE即使有五千萬(wàn)人說(shuō)傻話，那仍然是傻話。安那托爾·佛朗士（AnatoleFrance）大家都做的事情，對(duì)你來(lái)說(shuō)也不一定是正確的。也許它是正確的，但你也應(yīng)該評(píng)估它對(duì)你所處環(huán)境的適用性。這樣的例子包括：面向?qū)ο螅�軟件度量（見原則142、143、149、150和151），軟件復(fù)用（見原則84），過(guò)程成熟度（見原則163），計(jì)算機(jī)輔助軟件工程（CASE，見原則22至25），原型設(shè)計(jì)（見原則11、12、13、42）。在所有案例中，以上這些方法都提供了非常積極的幫助，體現(xiàn)在提高質(zhì)量、降低成本、提高用戶滿意度等方面。然而，這些好處只在它們能發(fā)揮作用的組織中才會(huì)顯現(xiàn)出來(lái)。盡管回報(bào)顯著，但是它們的作用常常被過(guò)度宣傳，其實(shí)它們并不是那么必然或通用。當(dāng)你學(xué)習(xí)“新”技術(shù)時(shí)，不要輕易接受與之相關(guān)的不可避免的炒作（見原則129）。要仔細(xì)閱讀，理性考慮它的收益和風(fēng)險(xiǎn)。在大規(guī)模應(yīng)用之前要進(jìn)行試驗(yàn)。但同時(shí)也絕對(duì)不要忽略“新”技術(shù)（見原則31）。Davis,A.,"SoftwareLemmingineering,"IEEESoftware,10,6(September1993),pp.79-81,84.類似的原則還有很多，以上內(nèi)容摘自《201PrinciplesofSoftwareDevelopment》中文版，書名是《軟件開發(fā)的201個(gè)原則》。給中國(guó)軟件工程師的寄語(yǔ)（節(jié)選）致我的兄弟姐妹們：和你們一樣，我的職業(yè)生涯始于軟件工程師，那是1975年，將近半個(gè)世紀(jì)之前。我認(rèn)為我們?cè)跁r(shí)間和國(guó)家方面的差異相當(dāng)微不足道。所以，我像和我的朋友、我的同齡人一樣與你交談。26年后的今天，當(dāng)我審視201PrinciplesofSoftwareDevelopment中的這201條原則時(shí)，我很高興地宣告，幾乎所有的原則都經(jīng)受住了時(shí)間的考驗(yàn)，就像物理學(xué)中的基本原理一樣。當(dāng)你做軟件架構(gòu)設(shè)計(jì)或“拋出代碼”時(shí)，不要忽視真正重要的事情。那是什么呢？是你的正直，這是你對(duì)自己的看法。如果有人要求你做一些你知道是錯(cuò)誤的事情，你有義務(wù)阻止它。軟件工程是一個(gè)美妙的職業(yè)，它使你能夠進(jìn)入數(shù)百個(gè)以軟件為支柱的專業(yè)領(lǐng)域。“生生不息，繁榮昌盛。”好好享受！201PrinciplesofSoftwareDevelopment作者AlanM.Davis2021年9月全書共9章，第1章為引言，后面8章將201個(gè)軟件工程的原則劃分為8個(gè)大的類別：一般原則、需求工程原則、設(shè)計(jì)原則、編碼原則、測(cè)試原則、管理原則、產(chǎn)品保證原則和演變?cè)瓌t。甚至你可以在空白處寫上簡(jiǎn)單的，聰明的你認(rèn)為的“原則”。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：344

導(dǎo)讀：隨著汽車電子技術(shù)在汽車產(chǎn)業(yè)的廣泛應(yīng)用，汽車電控系統(tǒng)和網(wǎng)絡(luò)日益復(fù)雜，而汽車產(chǎn)品更新越來(lái)越快，要求電控單元開發(fā)周期越來(lái)越短，汽車電子軟件開發(fā)管理難度增大，復(fù)用性和移植性變差，因此，采用規(guī)范的軟件開發(fā)平臺(tái)，提高軟件開發(fā)效率和質(zhì)量已迫在眉睫。本文主要介紹了構(gòu)建軟件開發(fā)環(huán)境的背景、可借鑒的實(shí)施技術(shù)方案、構(gòu)建統(tǒng)一管理平臺(tái)所取得的效果和遺留問(wèn)題對(duì)策。1、引言進(jìn)入21世紀(jì)，特別是最近十年，智能網(wǎng)聯(lián)和新能源車型的開發(fā)進(jìn)入快車道，汽車行業(yè)軟件開發(fā)在整車開發(fā)中的占比越來(lái)越高，軟件開發(fā)不再是一個(gè)小部門完成零部件類開發(fā)，而是需要從整車需求定義開始，整合電子電氣架構(gòu)開發(fā)，到系統(tǒng)架構(gòu)、軟件架構(gòu)、軟件代碼開發(fā)、單元測(cè)試、系統(tǒng)測(cè)試直到整車測(cè)試一整套完整的V-model模型開發(fā)流程支持。由于軟件開發(fā)對(duì)團(tuán)隊(duì)作戰(zhàn)、質(zhì)量控制提出了更高的要求，因此構(gòu)建一個(gè)全價(jià)值鏈軟件開發(fā)環(huán)境成為汽車研發(fā)產(chǎn)品開發(fā)管理中的重要一環(huán)。隨著電子技術(shù)的發(fā)展，商用車電子電氣系統(tǒng)越來(lái)越復(fù)雜，整車的安全性、舒適性、娛樂(lè)性包括發(fā)動(dòng)機(jī)控制及排放升級(jí)，任何一項(xiàng)新技術(shù)的應(yīng)用和提升都離不開電子技術(shù)。整車上的各種ECU（ElectronicControlUnit）越來(lái)越多，相互之間交互的信號(hào)越來(lái)越多、網(wǎng)絡(luò)的通信方式越來(lái)越復(fù)雜，如此復(fù)雜的電控系統(tǒng)對(duì)整車的功能、性能、成本、開發(fā)周期都有更高的要求，很多時(shí)候它決定了整車產(chǎn)品的性能和競(jìng)爭(zhēng)力達(dá)成。電控系統(tǒng)開發(fā)大部分工作集中在嵌入式軟件開發(fā)和測(cè)試階段，針對(duì)軟件開發(fā)和測(cè)試的管理，要求建立一套完善的軟件開發(fā)管理平臺(tái)。2、軟件開發(fā)環(huán)境建設(shè)必要性和緊迫性企業(yè)對(duì)業(yè)務(wù)需求梳理后認(rèn)為，建立軟件開發(fā)環(huán)境已經(jīng)刻不容緩，迫在眉睫。1）電控和智能網(wǎng)聯(lián)軟件開發(fā)在動(dòng)力總成及整車產(chǎn)品中占據(jù)越來(lái)越重要的地位，決定著產(chǎn)品性能和競(jìng)爭(zhēng)力達(dá)成。2）軟件開發(fā)是多部門、多任務(wù)、多地點(diǎn)的協(xié)同開發(fā)模式，提升軟件開發(fā)質(zhì)量、效率，保證數(shù)據(jù)安全。3）軟件開發(fā)目前不受控，各個(gè)項(xiàng)目組內(nèi)部管控，數(shù)據(jù)存放在個(gè)人手中，存在信息安全風(fēng)險(xiǎn)。4）軟件開發(fā)涉及開發(fā)經(jīng)驗(yàn)和技術(shù)能力的積累，需要軟件開發(fā)環(huán)境項(xiàng)目提供技術(shù)支持，將企業(yè)軟件開發(fā)知識(shí)資產(chǎn)積累和沉淀。5）當(dāng)前企業(yè)多個(gè)產(chǎn)品開發(fā)項(xiàng)目已進(jìn)入全面鋪開階段，項(xiàng)目之間急需協(xié)同開發(fā)，并對(duì)需求和代碼、測(cè)試進(jìn)行有效管控，急需一個(gè)成熟的系統(tǒng)平臺(tái)支持。3、軟件開發(fā)環(huán)境建設(shè)技術(shù)方案項(xiàng)目預(yù)研究階段，項(xiàng)目組調(diào)研獲悉國(guó)內(nèi)軟件開發(fā)行業(yè)已大部分建立了完整的開發(fā)體系，并通過(guò)了高等級(jí)的標(biāo)準(zhǔn)認(rèn)證。汽車行業(yè)部分企業(yè)已建立完成標(biāo)準(zhǔn)的開發(fā)環(huán)境。部分汽車企業(yè)也通過(guò)了A-SPICE（AutomotiveSoftwareProcessImprovementandCapacityDetermination）成熟度認(rèn)證。某企業(yè)在構(gòu)建軟件開發(fā)環(huán)境前，電控軟件開發(fā)環(huán)境處于空白，僅僅使用了部分開發(fā)工具軟件，沒有完整的軟件開發(fā)流程環(huán)境，軟件開發(fā)數(shù)據(jù)存放在個(gè)人計(jì)算機(jī)內(nèi)，軟件需求、代碼、測(cè)試未建立關(guān)聯(lián)關(guān)系，沒有版本管理和配置管理，軟件發(fā)放和交換靠人工拷貝或郵件，無(wú)系統(tǒng)追蹤記錄。與國(guó)內(nèi)同行業(yè)開發(fā)水平存在較大差距，不利于核心數(shù)據(jù)的信息安全和可靠性。在制定軟件開發(fā)環(huán)境技術(shù)方案過(guò)程中，首先考慮導(dǎo)入一款成熟的工程控制系統(tǒng)，其主要功能包含如下幾點(diǎn)：配置管理：梳理配置管理流程，配置管理包括代碼，模型以及相關(guān)文件，實(shí)現(xiàn)版本、分支、合并、變更以及對(duì)比等功能，利用項(xiàng)目變型支持并行軟件的開發(fā)。變更管理：定義變更管理、缺陷管理、質(zhì)量管理流程。定義變更的涉及范圍，定義變更流程，實(shí)現(xiàn)變更的可控和追蹤記錄。實(shí)現(xiàn)缺陷追蹤管理，實(shí)現(xiàn)測(cè)試結(jié)果和缺陷的追溯，結(jié)合質(zhì)量管理，將質(zhì)量和缺陷流程數(shù)據(jù)作為變更原因驅(qū)動(dòng)變更流程。檢查驗(yàn)證：測(cè)試用例管理、測(cè)試計(jì)劃管理、測(cè)試目標(biāo)管理、測(cè)試任務(wù)和測(cè)試結(jié)果。實(shí)現(xiàn)測(cè)試用例分級(jí)分類，實(shí)現(xiàn)需求和測(cè)試的雙向追溯，提供需求覆蓋度計(jì)算，測(cè)試執(zhí)行率計(jì)算等。軟件質(zhì)量：支持產(chǎn)品測(cè)試、評(píng)審等質(zhì)量活動(dòng)中產(chǎn)品缺陷的提出，缺陷具有分析、追溯流程。需求追朔性：所有工程文件必須關(guān)聯(lián)，需求與代碼、測(cè)試文件等建立關(guān)聯(lián)關(guān)系，具備可追溯性。能夠?qū)崿F(xiàn)需求與子需求之間的追溯。需求分解：定義需求結(jié)構(gòu)，需求管理流程。實(shí)施需求過(guò)程管理，包括：系統(tǒng)需求、軟件需求、硬件需求，同時(shí)在系統(tǒng)需求層面實(shí)現(xiàn)ISO26262功能安全部分。版本控制：軟件項(xiàng)目和軟件代碼的版本管理,基線管理以及軟件代碼的權(quán)限控制,主流IDE的集成。文檔管理：軟件開發(fā)環(huán)境中所有文檔具備樹形結(jié)構(gòu)化管理方案，文檔創(chuàng)建核發(fā)布有審批流程和生命周期狀態(tài)定義。導(dǎo)入系統(tǒng)平臺(tái)同時(shí)，需要同步制定企業(yè)軟件管理各種規(guī)范標(biāo)準(zhǔn)，具體包括項(xiàng)目管理、需求管理、軟件代碼、測(cè)試文檔等開發(fā)文檔的命名規(guī)范、評(píng)審規(guī)范，版本管理規(guī)范等。為了保證軟件代碼和相關(guān)文檔的信息安全，除了系統(tǒng)中設(shè)定相關(guān)權(quán)限管理外，利用當(dāng)前云桌面技術(shù)，所有應(yīng)用都在云桌面上運(yùn)行，包括軟件開發(fā)環(huán)境平臺(tái)、軟件開發(fā)工具等，所有涉及到的開發(fā)和測(cè)試數(shù)據(jù)都保存在云服務(wù)器上，并進(jìn)行適當(dāng)?shù)募用芴幚�。確保軟件數(shù)據(jù)的完整性和安全性。經(jīng)過(guò)項(xiàng)目組大量的評(píng)審和測(cè)試，最終確定應(yīng)用一款成熟的ALM(ApplicationLifecycleManagement)系統(tǒng)作為軟件開發(fā)環(huán)境基礎(chǔ)平臺(tái)，在平臺(tái)上實(shí)現(xiàn)軟件項(xiàng)目全過(guò)程的管理，包括需求分析、設(shè)計(jì)、開發(fā)、測(cè)試、代碼編譯發(fā)布等，并能夠按照業(yè)界實(shí)踐對(duì)其過(guò)程進(jìn)行管控和各過(guò)程間的連接，能夠充分滿足汽車行業(yè)客戶對(duì)于車載軟件研發(fā)管理系統(tǒng)平臺(tái)的功能訴求，過(guò)程示意如下：在軟件開發(fā)的全生命周期管理的全過(guò)程，能夠與常規(guī)應(yīng)用的工具進(jìn)行集成，包括matlab、MicrosoftWord、MicrosoftExcel、Eclipse、VisualStudio等。4、軟件開發(fā)環(huán)境平臺(tái)構(gòu)建實(shí)現(xiàn)效果1）完成需求過(guò)程管理，包括：系統(tǒng)需求、軟件需求、硬件需求，同時(shí)在系統(tǒng)需求層面實(shí)現(xiàn)ISO26262功能安全部分。2）完成測(cè)試管理：測(cè)試用例管理、測(cè)試計(jì)劃管理、測(cè)試目標(biāo)管理、測(cè)試任務(wù)和測(cè)試結(jié)果。實(shí)現(xiàn)測(cè)試用例分級(jí)分類，實(shí)現(xiàn)需求和測(cè)試的雙向追溯，提供需求測(cè)試覆蓋度計(jì)算，測(cè)試執(zhí)行率計(jì)算等。3）管理缺陷的追蹤流程，對(duì)缺陷、變更、質(zhì)量等問(wèn)題提供狀態(tài)分布圖、趨勢(shì)圖、分類圖、延誤圖，實(shí)現(xiàn)測(cè)試結(jié)果和缺陷的追溯。4）追溯關(guān)系，建立需求、測(cè)試、缺陷、模型、代碼之間的關(guān)聯(lián)關(guān)系和可追溯性管理。5）根據(jù)現(xiàn)有開發(fā)流程，定義配置庫(kù)結(jié)構(gòu)，定義主線和分支管理規(guī)則，軟件項(xiàng)目和軟件代碼的版本管理,基線管理以及軟件代碼的權(quán)限控制,主流IDE(IntegratedDevelopmentEnvironment)的集成。6）建設(shè)變更管理標(biāo)準(zhǔn)體系，實(shí)現(xiàn)數(shù)據(jù)過(guò)程版本管理，修改留有痕跡和記錄，避免犯同一錯(cuò)誤或同一錯(cuò)誤重復(fù)出現(xiàn)，借助系統(tǒng)進(jìn)行變更受影響范圍快速分析，對(duì)變更進(jìn)行的實(shí)時(shí)監(jiān)控。7）系統(tǒng)的集成，打通整個(gè)軟件開發(fā)工具鏈，整合電子電氣架構(gòu)開發(fā)工具到一體化的電控軟件開發(fā)環(huán)境平臺(tái)中，并實(shí)現(xiàn)與測(cè)試平臺(tái)集成，將電控軟件開發(fā)環(huán)境中測(cè)試計(jì)劃、測(cè)試報(bào)告?zhèn)鞯綔y(cè)試平臺(tái)。8）建立知識(shí)共享庫(kù)、集中共享企業(yè)和各專業(yè)的業(yè)務(wù)規(guī)范、將知識(shí)轉(zhuǎn)化為可以應(yīng)用的形式。9）實(shí)現(xiàn)產(chǎn)品數(shù)據(jù)的有效性和安全性控制，保證數(shù)據(jù)的準(zhǔn)確性、完整性和一致性，實(shí)現(xiàn)對(duì)知識(shí)資產(chǎn)的有效保護(hù)。10）標(biāo)準(zhǔn)合規(guī)性的支持，遵循國(guó)際和國(guó)內(nèi)標(biāo)準(zhǔn)，作為汽車行業(yè)A-SPICEHIS2級(jí)部分流程的編寫和管理工具，管理部分活動(dòng)和交付物。5、軟件開發(fā)環(huán)境平臺(tái)建設(shè)主要?jiǎng)?chuàng)新點(diǎn)和價(jià)值貢獻(xiàn)1）建立起一整套符合企業(yè)業(yè)務(wù)模式的軟件產(chǎn)品生命周期管理流程，并在搭建的電控軟件開發(fā)環(huán)境系統(tǒng)中落地。借助軟件開發(fā)環(huán)境，支持多項(xiàng)目開發(fā)，實(shí)現(xiàn)VModel開發(fā)模式，對(duì)軟件的配置項(xiàng)進(jìn)行過(guò)程管理，利用系統(tǒng)集成實(shí)現(xiàn)跨專業(yè)的協(xié)同。2）借助軟件開發(fā)環(huán)境平臺(tái)建設(shè)，企業(yè)實(shí)現(xiàn)軟件代碼開發(fā)全面云上運(yùn)行，一方面保證軟件代碼數(shù)據(jù)安全，另一方面，實(shí)現(xiàn)云上辦公，充分利用云上辦公資源，實(shí)現(xiàn)硬件資源的靈活部署和分配。同時(shí)，可以實(shí)現(xiàn)遠(yuǎn)程辦公，實(shí)時(shí)處理開發(fā)過(guò)程中遇到的各種問(wèn)題，大大提高了軟件開發(fā)效率和質(zhì)量。3）通過(guò)軟件開發(fā)環(huán)境搭建，對(duì)軟件開發(fā)過(guò)程進(jìn)行全面規(guī)范化，按照A-SPICE成熟度模型進(jìn)行完善軟件開發(fā)流程，并借助軟件開發(fā)環(huán)境固化流程，達(dá)到開發(fā)過(guò)程質(zhì)量受控，開發(fā)測(cè)試全過(guò)程可追溯、可審計(jì)，有力保證了軟件開發(fā)質(zhì)量，提高汽車產(chǎn)品可靠性。6、遺留問(wèn)題與對(duì)策軟件開發(fā)環(huán)境構(gòu)建完成后，軟件代碼在ALM系統(tǒng)中管理，企業(yè)產(chǎn)品數(shù)據(jù)變更管理在PDM(ProductDataManagement)系統(tǒng)中管控，如何將軟件代碼作為零部件進(jìn)行發(fā)布和變更，帶來(lái)另外一個(gè)問(wèn)題。即軟件代碼與產(chǎn)品變更單之間的關(guān)聯(lián)關(guān)系需要建立并管控。因此，企業(yè)需要在構(gòu)建軟件開發(fā)環(huán)境平臺(tái)同時(shí)，考慮建立ALM與PDM之間的接口集成，并監(jiān)控控制規(guī)范和校驗(yàn)流程，確保軟件代碼在準(zhǔn)確的時(shí)間，搭載到準(zhǔn)確的產(chǎn)品車型上，同步刷寫到下線產(chǎn)品車輛中，實(shí)現(xiàn)從產(chǎn)品開發(fā)到生產(chǎn)制造的一條龍管理。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：163

人們?cè)趪�繞軟件開發(fā)的討論中，幾乎不可避免會(huì)隨口引用一兩條原則。你可能聽過(guò)人們說(shuō)：“這行不通，因?yàn)椤甔法則’！”�；蛘摺澳悴恢�道‘Y原則’嗎？”你是哪種類型的軟件開發(fā)人員？有許多規(guī)律和原則可以引用，其中大部分都基于真理。然而，盲目地使用像上面這樣的絕對(duì)陳述來(lái)應(yīng)用它們肯定會(huì)導(dǎo)致自負(fù)和失敗。本文列舉了一些可以應(yīng)用于軟件開發(fā)的最流行的規(guī)律和原則。對(duì)于每條定律，我們將快速討論其主要內(nèi)容，然后探討如何將其應(yīng)用于軟件開發(fā)（也許何時(shí)不應(yīng)該）。帕累托原則（80/20法則）內(nèi)容帕累托原則指出，通常80%的結(jié)果來(lái)自20%的原因。數(shù)字80和20無(wú)論如何都不是精確的，但該原則的總體思路是結(jié)果通常分布不均。我們可以看到生活的許多領(lǐng)域遵守著這條規(guī)則，例如：世界上最富有的20%的人創(chuàng)造了世界80%的收入。80%的犯罪是由20%的罪犯所為（自2020年以來(lái)）。我們知道80%的病毒傳播來(lái)自20%的受感染人群。如何應(yīng)用在軟件開發(fā)中？我們可以從帕累托原則中獲得的主要好處是專注。它可以幫助我們專注于重要的事情（20%），而不是在不重要的事情（其他80%）上浪費(fèi)時(shí)間和精力。不重要的事情對(duì)我們來(lái)說(shuō)往往很重要，因?yàn)檫@樣的事情總是有太多（而且看起來(lái)很緊急）。但是最好的結(jié)果往往是通過(guò)關(guān)注重要的少數(shù)來(lái)達(dá)成的。在軟件開發(fā)中，我們可以使用它來(lái)專注于構(gòu)建正確的功能，例如：專注于實(shí)現(xiàn)80%產(chǎn)品價(jià)值的那20%的產(chǎn)品功能。專注于導(dǎo)致80%用戶使用異常的那20%的錯(cuò)誤。專注于實(shí)現(xiàn)80%的產(chǎn)品功能需要的那20%總構(gòu)建時(shí)間…只要問(wèn)“現(xiàn)在最重要的事情是什么？”就可以幫助建立下一個(gè)最重要的事情，而不是下一個(gè)最緊急的事情。順便說(shuō)一下，敏捷和DevOps等現(xiàn)代開發(fā)方法有助于獲得這種關(guān)注！具有定期用戶反饋的快速迭代允許對(duì)重要事項(xiàng)進(jìn)行數(shù)據(jù)驅(qū)動(dòng)的決策。諸如基于主干的帶有功能標(biāo)記的開發(fā)之類的實(shí)踐可以幫助軟件團(tuán)隊(duì)實(shí)現(xiàn)這一目標(biāo)。破窗定理內(nèi)容破碎的窗戶會(huì)招致破壞，因此很快所有窗戶都被打破。一般來(lái)說(shuō)：混亂會(huì)招致更多的混亂。如果我們的環(huán)境是原始的，我們就會(huì)有動(dòng)力保持這種狀態(tài)。環(huán)境中的混亂越多，我們添加混亂的門檻就越低。畢竟已經(jīng)混亂了……誰(shuí)在乎我們是否再添加一點(diǎn)呢？我們可以從這條規(guī)則中獲得的主要好處是我們應(yīng)該意識(shí)到我們周圍的混亂。如果它達(dá)到人們習(xí)慣于不再關(guān)心它的程度，那么最好為混亂帶來(lái)一些秩序。如何應(yīng)用在軟件開發(fā)中？在軟件開發(fā)中，我們可以將其應(yīng)用于代碼質(zhì)量：我們引入代碼庫(kù)的每一種代碼異味都會(huì)降低我們添加更多代碼異味的門檻。我們應(yīng)該[[StartClean]]并保持代碼庫(kù)干凈以避免這種情況發(fā)生。許多代碼庫(kù)如此難以理解和維護(hù)的原因是，破窗已經(jīng)悄然出現(xiàn)并且沒有足夠快地修復(fù)。我們也可以將這個(gè)原則應(yīng)用到測(cè)試覆蓋率上：一旦有一定數(shù)量的代碼進(jìn)入了未被測(cè)試覆蓋的代碼庫(kù)，就會(huì)添加更多未被覆蓋的代碼。這是保持100%代碼覆蓋率（應(yīng)該覆蓋的代碼的）的論據(jù)，因此我們可以在窗口破裂之前看到裂縫。奧卡姆剃刀內(nèi)容哲學(xué)剃刀是一種通過(guò)消除（或“削除”）不太可能的假設(shè)來(lái)幫助解釋某些事情的原則。奧卡姆剃刀表示，如果有多個(gè)假設(shè)，我們應(yīng)該選擇假設(shè)條件最少的假設(shè)（這很可能是解釋最簡(jiǎn)單的假設(shè)）。如何應(yīng)用在軟件開發(fā)中？我們可以在事件分析中應(yīng)用奧卡姆剃刀。您可能遇到過(guò)這樣的情況：用戶報(bào)告了您的應(yīng)用程序存在問(wèn)題，但您不知道導(dǎo)致問(wèn)題的原因。因此，您正在搜索日志和指標(biāo)，試圖找到根本原因。下次用戶報(bào)告錯(cuò)誤時(shí)，請(qǐng)維護(hù)事件調(diào)查文檔。寫下您對(duì)導(dǎo)致問(wèn)題的原因的假設(shè)。然后，對(duì)于每個(gè)假設(shè)，列出事實(shí)和猜想。如果假設(shè)被證明是正確的，則將其標(biāo)記為事實(shí)。如果一個(gè)假設(shè)被證明是錯(cuò)誤的，請(qǐng)將其從文檔中刪除或?qū)⑵錁?biāo)記為錯(cuò)誤。在任何時(shí)候，您現(xiàn)在都可以將時(shí)間集中在最可能的假設(shè)上，而不是浪費(fèi)時(shí)間轉(zhuǎn)移注意力。鄧寧-克魯格效應(yīng)內(nèi)容鄧寧-克魯格效應(yīng)表明，沒有經(jīng)驗(yàn)的人往往會(huì)高估自己的能力，而有經(jīng)驗(yàn)的人往往會(huì)低估自己的能力。如果你不擅長(zhǎng)某件事，你會(huì)認(rèn)為你擅長(zhǎng)它。如果你擅長(zhǎng)某事，你認(rèn)為你不擅長(zhǎng)-這可能導(dǎo)致冒名頂替綜合癥，這讓你懷疑自己的能力，以至于你在其他具有相似技能的人中感到不舒服（害怕別人認(rèn)為你說(shuō)的不正確）。如何應(yīng)用在軟件開發(fā)中？意識(shí)到這種認(rèn)知偏差已經(jīng)是朝著正確方向邁出的良好一步。它將幫助您更好地評(píng)估自己的技能，以便您可以尋求幫助，或者克服自我懷疑并自己行動(dòng)。有助于消除鄧寧-克魯格效應(yīng)和冒名頂替綜合癥的一種做法是結(jié)對(duì)或群體編程。你不是獨(dú)自工作，沉浸在自我懷疑或優(yōu)越感中，而是與其他人密切合作，邊工作邊交流思想、學(xué)習(xí)和教學(xué)。不過(guò)，這只適用于安全的環(huán)境。在個(gè)人主義被美化的環(huán)境中，結(jié)對(duì)或群體編程會(huì)導(dǎo)致更多的自我懷疑或更多的優(yōu)越感妄想。彼得原理內(nèi)容彼得原理指出，只要你在工作中表現(xiàn)出色，你就會(huì)得到晉升，直到你晉升得到一份你不稱職的工作。由于您不再成功，您將不再獲得晉升，這意味著您將生活在一份不會(huì)給您帶來(lái)滿足感或成功的工作中，通常是在您的余生中。前景黯淡！如何應(yīng)用在軟件開發(fā)中？在軟件開發(fā)中，當(dāng)您將角色從開發(fā)人員職業(yè)轉(zhuǎn)換為管理職業(yè)時(shí)，彼得原則通常適用。然而，成為一名優(yōu)秀的開發(fā)人員并不一定意味著你是一名優(yōu)秀的經(jīng)理。或者，您可能是一名優(yōu)秀的經(jīng)理，但不要在開發(fā)人員的工作上獲得經(jīng)理工作的滿足感，這意味著您沒有全力以赴（這就是我的情況）。在任何情況下，你都很悲慘，在你面前的職業(yè)道路上看不到任何未來(lái)的發(fā)展。在這種情況下，退后一步想想，你希望你的職業(yè)是什么樣子的。然后，轉(zhuǎn)換角色（或公司，如果需要）以獲得您想要的角色。帕金森定律內(nèi)容帕金森定律指出，工作總是會(huì)填滿分配給它的時(shí)間。如果您的項(xiàng)目在兩周內(nèi)有截止日期，則該項(xiàng)目將不會(huì)在此之前完成�？赡苄枰�更長(zhǎng)的時(shí)間，是的，但絕不會(huì)少于我們?yōu)樗�分配的時(shí)間，因?yàn)槲覀冋�在用不必要的工作或拖延�?lái)填補(bǔ)時(shí)間。如何應(yīng)用在軟件開發(fā)中？帕金森定律的主要驅(qū)動(dòng)因素是：拖延癥（“截止日期太遠(yuǎn)了，所以我現(xiàn)在不需要匆忙……”）范圍蔓延（“當(dāng)然，我們可以添加這個(gè)小功能，它不會(huì)花費(fèi)我們太多時(shí)間......”）為了對(duì)抗拖延，我們可以在幾天而不是幾周或幾個(gè)月內(nèi)設(shè)定最后期限。比如說(shuō)在接下來(lái)的2-3天內(nèi)需要做什么才能朝著目標(biāo)前進(jìn)？一個(gè)（健康的！）截止日期可以給我們足夠的動(dòng)力，不要陷入拖延癥的低谷。為了防止范圍蔓延，我們應(yīng)該非常清楚地了解我們?cè)噲D通過(guò)項(xiàng)目實(shí)現(xiàn)的目標(biāo)。成功的衡量標(biāo)準(zhǔn)是什么？這個(gè)新功能是否會(huì)增加這些指標(biāo)？那么如果每個(gè)人都明白這項(xiàng)工作需要更長(zhǎng)的時(shí)間，我們應(yīng)該添加它。如果新功能與使命宣言不匹配，請(qǐng)拋棄它。霍夫施塔特定律內(nèi)容霍夫施塔特定律指出“它總是比您預(yù)期的要長(zhǎng)，即使您考慮到霍夫施塔特定律”。即使您了解了這條定律，并增加了項(xiàng)目的時(shí)間分配，它仍然會(huì)比您預(yù)期的要長(zhǎng)。這與帕金森定律密切相關(guān)，即工作總是會(huì)填滿分配給它的時(shí)間。只是霍夫施塔特定律說(shuō)它填充的時(shí)間超過(guò)了分配的時(shí)間。這條定律得到了心理學(xué)的支持。我們?nèi)菀追杆�謂的“計(jì)劃謬誤”，即在估算工作量時(shí)，我們通常不會(huì)考慮所有可用信息，即使我們認(rèn)為我們已經(jīng)考慮了。我們的估計(jì)幾乎總是主觀的，很少是正確的。如何應(yīng)用在軟件開發(fā)中？在軟件開發(fā)中（以及任何其他基于項(xiàng)目的工作，真的），我們?nèi)祟惖臉?lè)觀主義占了上風(fēng)。估計(jì)幾乎總是過(guò)于樂(lè)觀。為了減少霍夫施塔特定律的影響，我們可以嘗試盡可能客觀地進(jìn)行估計(jì)。寫下關(guān)于項(xiàng)目的假設(shè)和事實(shí)清單。將每個(gè)清單元素標(biāo)記為假設(shè)或事實(shí)，以使數(shù)據(jù)質(zhì)量可見并管理預(yù)期。不要依賴直覺，因?yàn)槊總�(gè)人的感受都不一樣。寫下估算值，讓你的大腦思考它們。將它們與其他人的估計(jì)進(jìn)行比較，然后討論差異。即便如此，它仍然只是一個(gè)估計(jì)，很可能不能反映現(xiàn)實(shí)。如果估算不是基于統(tǒng)計(jì)數(shù)據(jù)或其他歷史數(shù)據(jù)，那么它的價(jià)值就非常低，因此與要求您估算的人一起管理預(yù)期總是好的——這總是會(huì)出錯(cuò)的。如果你讓它盡可能客觀，它就會(huì)減少錯(cuò)誤�？低�定律內(nèi)容康威定律指出，組織創(chuàng)建的任何系統(tǒng)都將類似于該組織的團(tuán)隊(duì)和溝通結(jié)構(gòu)。如果你有10個(gè)團(tuán)隊(duì)在一個(gè)系統(tǒng)上工作，你很可能會(huì)得到10個(gè)相互通信的子系統(tǒng)。如何應(yīng)用在軟件開發(fā)中？我們可以應(yīng)用所謂的逆康威機(jī)動(dòng)：創(chuàng)建最能支持我們想要構(gòu)建的系統(tǒng)架構(gòu)的組織結(jié)構(gòu)。沒有固定的團(tuán)隊(duì)結(jié)構(gòu)，而是要有足夠的靈活性來(lái)創(chuàng)建和解散團(tuán)隊(duì)，這對(duì)系統(tǒng)的當(dāng)前狀態(tài)是最好的。墨菲定律內(nèi)容墨菲定律說(shuō)，任何可能出錯(cuò)的事情，都會(huì)出錯(cuò)。它經(jīng)常在意外發(fā)生后被引用。如何應(yīng)用在軟件開發(fā)中？軟件開發(fā)是一個(gè)容易出錯(cuò)的職業(yè)。出錯(cuò)的主要來(lái)源是錯(cuò)誤。沒有任何軟件不存在挑戰(zhàn)用戶耐心的錯(cuò)誤或事件。我們可以通過(guò)在日常軟件開發(fā)實(shí)踐中養(yǎng)成減少錯(cuò)誤影響的習(xí)慣來(lái)抵御墨菲定律。我們無(wú)法完全避免錯(cuò)誤，但我們可以而且應(yīng)該減少它們對(duì)用戶的影響。對(duì)抗墨菲定律最有用的做法是特征標(biāo)記。如果我們使用像LaunchDarkly這樣的功能標(biāo)記平臺(tái)，我們可以在功能標(biāo)記后面將更改部署到生產(chǎn)中。然后，我們可以使用有針對(duì)性的發(fā)布來(lái)激活內(nèi)部dogfooding的標(biāo)志，然后對(duì)少量友好的Beta用戶發(fā)布，最后將其發(fā)布給所有用戶。通過(guò)這種方式，我們可以從越來(lái)越關(guān)鍵的用戶群體那里獲得關(guān)于變化的反饋。如果更改出錯(cuò)（并且在某些時(shí)候會(huì)出錯(cuò)），影響很小，因?yàn)橹挥幸恍〔糠钟脩艚M會(huì)受到它的影響。而且，該標(biāo)志可以快速關(guān)閉。布魯克定律內(nèi)容在經(jīng)典著作“人月神話”中，弗雷德·布魯克(FredBrook)有句名言：為遲到的項(xiàng)目增加人力會(huì)使項(xiàng)目更晚。盡管本書討論的是軟件項(xiàng)目，但它適用于大多數(shù)類型的項(xiàng)目，甚至是軟件開發(fā)之外的項(xiàng)目。添加人員不會(huì)提高項(xiàng)目速度的原因是項(xiàng)目的通信開銷隨著添加到項(xiàng)目中的每個(gè)人呈指數(shù)增長(zhǎng)。2個(gè)人有1條通信路徑，5個(gè)人已經(jīng)有120條可能的通信路徑。新人安頓下來(lái)并確定他們需要的溝通路徑需要時(shí)間，這就是為什么在項(xiàng)目中添加新人時(shí)，遲到的項(xiàng)目會(huì)更晚。如何應(yīng)用在軟件開發(fā)中？很簡(jiǎn)單。更改截止日期，而不是將人員添加到已經(jīng)遲到的項(xiàng)目中。對(duì)在軟件項(xiàng)目中增加新人的期望要切合實(shí)際。將人員添加到項(xiàng)目中可能會(huì)在某個(gè)時(shí)候提高速度，但并非總是如此，當(dāng)然也不是立即。人員和團(tuán)隊(duì)需要時(shí)間來(lái)適應(yīng)日常工作，而在某些時(shí)候，工作無(wú)法充分并行化，因此增加更多人是沒有意義的。仔細(xì)考慮一個(gè)新人應(yīng)該完成什么任務(wù)，以及在將該人添加到項(xiàng)目中時(shí)您期望什么。波斯特定律內(nèi)容Postel定律也被稱為穩(wěn)健性原則，它指出你應(yīng)該“在你所做的事情上保守，在你接受別人的事情上開放”。換句話說(shuō)，您可以接受多種不同形式的數(shù)據(jù)，以使您的軟件盡可能靈活，但您在處理這些數(shù)據(jù)時(shí)應(yīng)該非常小心，以免因無(wú)效或惡意數(shù)據(jù)而危及您的軟件。如何應(yīng)用在軟件開發(fā)中？該定律源于軟件開發(fā)，因此非常直接適用。您的軟件與其他軟件或開發(fā)人員之間的接口應(yīng)允許不同形式的輸入以實(shí)現(xiàn)穩(wěn)健性：為了向后兼容，新版本的接口應(yīng)該接受舊版本和新版本的數(shù)據(jù)為了更好的用戶體驗(yàn)，UI中的表單應(yīng)該接受不同格式的數(shù)據(jù)，這樣用戶就不必?fù)?dān)心格式。但是，如果我們?cè)敢饨邮懿煌�格式的�?shù)據(jù)，我們?cè)谔幚磉@些數(shù)據(jù)時(shí)就必須保守。我們必須審查無(wú)效值，并確保我們不會(huì)因?yàn)樵试S太多不同的格式而損害系統(tǒng)的安全性。SQL注入是一種可能的攻擊，它是通過(guò)對(duì)用戶輸入過(guò)于寬松而造成的�？似婊舴蛟�理內(nèi)容Kerchkhoff的原則指出，加密系統(tǒng)應(yīng)該是安全的，即使它的加密方法是公開的。只有您用來(lái)解密某些東西的密鑰才需要是私有的。如何應(yīng)用在軟件開發(fā)中？這很簡(jiǎn)單，真的。永遠(yuǎn)不要相信要求其加密方法是私密的加密系統(tǒng)。這被稱為“默默無(wú)聞的安全”。像這樣的系統(tǒng)本質(zhì)上是不安全的。一旦該加密方法向公眾公開，它就容易受到攻擊。萊納斯（Linus）定律內(nèi)容在關(guān)于Linux內(nèi)核開發(fā)的《大教堂與集市》一書中，埃里克·雷蒙德(EricRaymond)寫道：“有足夠多的眼睛，就可讓所有問(wèn)題浮現(xiàn)”。他將此稱為“萊納斯定律”以紀(jì)念萊納斯·托瓦茲。這意味著如果很多人看代碼比很少人看代碼可以更容易地暴露代碼中的錯(cuò)誤。如何應(yīng)用在軟件開發(fā)中？如果您想擺脫錯(cuò)誤，請(qǐng)讓其他人查看您的代碼。源于開源社區(qū)的一種常見做法是讓開發(fā)人員提出包含代碼更改的拉取請(qǐng)求，然后讓其他開發(fā)人員在將拉取請(qǐng)求合并到主分支之前審查該拉取請(qǐng)求。這種做法也進(jìn)入了閉源開發(fā)，但根據(jù)Linus定律，拉取請(qǐng)求在閉源環(huán)境（只有少數(shù)人查看它）中的作用不如在開源環(huán)境中（其中可能很多貢獻(xiàn)者都在看它）。其他為代碼添加更多眼睛的做法是結(jié)對(duì)編程和群體編程。至少在閉源環(huán)境中，這些在避免錯(cuò)誤方面比拉取請(qǐng)求審查更有效，因?yàn)槊總�(gè)人都參與了代碼的初始階段，這為每個(gè)人提供了更好的上下文來(lái)理解代碼和潛在的錯(cuò)誤。沃斯定律內(nèi)容沃斯定律指出，軟件變慢的速度比硬件變快的速度要快。如何應(yīng)用在軟件開發(fā)中？不要依賴強(qiáng)大的硬件來(lái)運(yùn)行性能不佳的代碼。相反，編寫經(jīng)過(guò)優(yōu)化以表現(xiàn)良好的代碼。這必須與（軟件開發(fā)定律：克努斯的優(yōu)化原則）的格言相平衡，該格言說(shuō)“過(guò)早的優(yōu)化是萬(wàn)惡之源”。與為用戶構(gòu)建新功能所花費(fèi)的精力相比，不要在使代碼運(yùn)行得更快上花費(fèi)更多的精力。通常，這是一種平衡行為�？伺�斯的優(yōu)化原則內(nèi)容DonaldKnuth在他的一部作品中寫了“過(guò)早優(yōu)化是萬(wàn)惡之源”這句話，這句話經(jīng)常斷章取意，并被用作根本不關(guān)心優(yōu)化代碼的借口。如何應(yīng)用在軟件開發(fā)中？根據(jù)Knuth定律，我們不應(yīng)該浪費(fèi)精力過(guò)早地優(yōu)化代碼。然而，根據(jù)沃斯定律，我們也不應(yīng)該依賴硬件足夠快來(lái)執(zhí)行優(yōu)化不當(dāng)?shù)拇�碼。最后，這就是我從這些原則中得出的結(jié)論：優(yōu)化可以輕松完成的代碼，無(wú)需太多努力：例如，編寫幾行額外代碼以避免經(jīng)歷可能包含大量項(xiàng)目的循環(huán)。優(yōu)化一直在執(zhí)行的關(guān)鍵業(yè)務(wù)的代碼。除此之外，不要在優(yōu)化代碼上花太多精力，除非你已經(jīng)確定了一個(gè)性能瓶頸。保持懷疑定律和原則是好的。這使我們能夠從某個(gè)角度評(píng)估某些情況，如果沒有它們，我們不可能了解這些情況的背后道理。然而，盲目地將定律和原則應(yīng)用于每種情況是行不通的。每一種情況都會(huì)存在微妙的變化，這可能意味著某個(gè)原則不能或不應(yīng)該適用。對(duì)你遇到的原則和定律保持懷疑。世界不是非黑即白的。作者：TECHflower原文：https://reflectoring.io/laws-and-principles-of-software-development/本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：135

計(jì)算機(jī)軟件開發(fā)合同分段付款的理解——（2020）最高法知民終1545號(hào)【裁判要旨】計(jì)算機(jī)軟件開發(fā)合同具有履行周期較長(zhǎng)、軟件功能需求隨開發(fā)進(jìn)程動(dòng)態(tài)調(diào)整等特點(diǎn)；與之相應(yīng)，計(jì)算機(jī)軟件開發(fā)領(lǐng)域具有分階段、按比例支付款項(xiàng)的商業(yè)習(xí)慣。鑒于各開發(fā)階段往往相互依存、緊密銜接，委托方每一階段支付的款項(xiàng)是否僅應(yīng)理解為其所對(duì)應(yīng)開發(fā)階段工作成果的對(duì)價(jià)，應(yīng)當(dāng)根據(jù)合同約定和履行情況具體確定。【關(guān)鍵詞】計(jì)算機(jī)軟件開發(fā)合同開發(fā)款分期付款工作成果對(duì)價(jià)【基本案情】上訴人武漢中新藍(lán)軟件有限公司（以下簡(jiǎn)稱中新藍(lán)公司）、李群與被上訴人武漢市精科綠源科技有限公司（以下簡(jiǎn)稱精科綠源公司）計(jì)算機(jī)軟件開發(fā)合同糾紛案中，精科綠源公司認(rèn)為，其委托中新藍(lán)公司開發(fā)水客168項(xiàng)目，開發(fā)成果形式為計(jì)算機(jī)軟件產(chǎn)品及相關(guān)文檔，合同總金額為27.5萬(wàn)元，分六期支付。涉案合同訂立后，精科綠源公司分兩次向中新藍(lán)公司付款11萬(wàn)元。之后，精科綠源公司認(rèn)為中新藍(lán)公司未按期完成軟件UI設(shè)計(jì)、未實(shí)際開發(fā)，且虛報(bào)進(jìn)度收取11萬(wàn)元進(jìn)度款，于2019年8月28日函告中新藍(lán)公司解除合同，并要求返還已支付的開發(fā)款。中新藍(lán)公司隨后函告精科綠源公司，決定暫停涉案軟件項(xiàng)目的開發(fā)。精科綠源公司遂向湖北省武漢市中級(jí)人民法院（以下簡(jiǎn)稱一審法院）提起訴訟，請(qǐng)求判決解除合同、判令中新藍(lán)公司返還全部開發(fā)款并承擔(dān)違約金和律師費(fèi)。中新藍(lán)公司向一審法院提起反訴，要求確認(rèn)涉案合同于2019年8月28日解除，并要求判令精科綠源公司支付第三、四階段開發(fā)費(fèi)用、逾期費(fèi)用利息、違約金和律師費(fèi)。一審法院認(rèn)為，精科綠源公司已支付的第二筆合同款項(xiàng)5.5萬(wàn)元系中新藍(lán)公司因?qū)嶋H投入開發(fā)工作而應(yīng)獲得的對(duì)價(jià)，中新藍(lán)公司無(wú)須返還。中新藍(lán)公司并無(wú)證據(jù)證明其在項(xiàng)目開發(fā)周期內(nèi)還完成了符合合同約定標(biāo)準(zhǔn)的其他階段性開發(fā)成果，故其已收取的首期款5.5萬(wàn)元無(wú)相應(yīng)的有效開發(fā)成果相對(duì)應(yīng)，其應(yīng)予返還。一審法院判決確認(rèn)合同已經(jīng)解除，判令中新藍(lán)公司返還合同款5.5萬(wàn)元，李群對(duì)中新藍(lán)公司返還義務(wù)承擔(dān)連帶責(zé)任。中新藍(lán)公司不服，向最高人民法院提起上訴，主張中新藍(lán)公司無(wú)須向精科綠源公司返還首期開發(fā)款、李群無(wú)須承擔(dān)連帶責(zé)任。最高人民法院于2020年12月29日判決維持一審判決關(guān)于確認(rèn)合同解除的判項(xiàng)，撤銷關(guān)于中新藍(lán)公司返還合同款5.5萬(wàn)元、李群對(duì)中新藍(lán)公司返還義務(wù)承擔(dān)連帶責(zé)任的判項(xiàng)�！静门幸庖姟孔罡呷嗣穹ㄔ憾�審認(rèn)為，計(jì)算機(jī)軟件開發(fā)合同履行過(guò)程中委托方分期給付的每一期開發(fā)款，除有明確約定外，并不要求均必須有相應(yīng)的開發(fā)成果為對(duì)價(jià)。一方面，計(jì)算機(jī)軟件開發(fā)合同的訂立通常是基于委托方對(duì)開發(fā)方技術(shù)實(shí)力的認(rèn)可與信任，故此類合同的履行具有一定的人身屬性，且合同履行周期一般跨度較長(zhǎng)，合同各方通常約定按照所設(shè)定工作事項(xiàng)的完成進(jìn)度分期付款，故履行周期較長(zhǎng)、分階段付款是此類合同的典型特征。另一方面，計(jì)算機(jī)軟件開發(fā)合同履行過(guò)程中，委托方對(duì)于軟件的功能需求往往并非一成不變，而是會(huì)在實(shí)際開發(fā)過(guò)程中根據(jù)具體情況對(duì)合同所欲實(shí)現(xiàn)的功能需求進(jìn)行相應(yīng)的調(diào)整，故計(jì)算機(jī)軟件開發(fā)合同除了呈現(xiàn)履行周期長(zhǎng)、分階段付款之特征外，還往往呈現(xiàn)軟件功能需求隨開發(fā)進(jìn)程動(dòng)態(tài)調(diào)整之特點(diǎn)。針對(duì)計(jì)算機(jī)軟件開發(fā)合同的上述性質(zhì)和特點(diǎn)，委托方基于合理管控交易風(fēng)險(xiǎn)的考量，采取分階段、按比例向開發(fā)方支付款項(xiàng)的做法符合商業(yè)習(xí)慣。但計(jì)算機(jī)軟件開發(fā)過(guò)程中各階段開發(fā)事項(xiàng)彼此是相互依存、緊密銜接的，某一階段所對(duì)應(yīng)的開發(fā)事項(xiàng)的完成情況和效果，往往決定了下一階段開發(fā)工作能否順利開展和完成效果，而下一階段開發(fā)工作的完成情況又可作為檢驗(yàn)前一階段工作成果的參照。因此，將委托方在每一階段支付的款項(xiàng)孤立地認(rèn)為僅是對(duì)應(yīng)該階段工作成果之對(duì)價(jià)的觀點(diǎn)，既不符合計(jì)算機(jī)軟件開發(fā)合同的特點(diǎn)，也不符合計(jì)算機(jī)軟件開發(fā)行業(yè)的特點(diǎn)和習(xí)慣。相反，委托方每一階段支付的款項(xiàng)均應(yīng)當(dāng)理解為是軟件開發(fā)整體工作對(duì)價(jià)的有機(jī)組成。另一方面，根據(jù)涉案合同第7.2條關(guān)于“付款方式”的約定，合同開發(fā)款分六期支付，首期款應(yīng)于合同簽訂后3日內(nèi)由精科綠源公司按合同總金額20%支付。涉案合同首期款既可以理解為是涉案軟件開發(fā)項(xiàng)目的啟動(dòng)資金，也可以理解為是作為涉案軟件委托方的精科綠源公司為軟件開發(fā)方中新藍(lán)公司組建研發(fā)團(tuán)隊(duì)、投入相關(guān)軟、硬件資源所提供的物質(zhì)條件。但是，于此階段即要求中新藍(lán)公司提交相應(yīng)的開發(fā)成果以作為取得首期開發(fā)款的對(duì)價(jià)，既缺乏合同依據(jù)，亦不符合計(jì)算機(jī)軟件開發(fā)行業(yè)的特點(diǎn)和習(xí)慣。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：148

1我對(duì)這些事情的看法改變了以下這些事情，在過(guò)去，我會(huì)爭(zhēng)論不休，但現(xiàn)在相信了。如果你所在團(tuán)隊(duì)成員的技術(shù)經(jīng)驗(yàn)水平參差不齊，那么使用強(qiáng)類型的編程語(yǔ)言會(huì)更好。開站會(huì)對(duì)于關(guān)注新人來(lái)說(shuō)其實(shí)很有用。只要是為了修正行動(dòng)路線，那么Sprint回顧就很有用，這并不是為了“敏捷”而敏捷，浪費(fèi)大家的時(shí)間。軟件架構(gòu)或許比其他任何東西都要來(lái)得重要。一個(gè)好的抽象層，即使它的實(shí)現(xiàn)像一坨屎，也不會(huì)給項(xiàng)目帶來(lái)純粹的傷害。但是，一個(gè)糟糕的抽象層會(huì)讓整個(gè)項(xiàng)目爛掉。Java并不是一種很糟糕的編程語(yǔ)言�？此坡斆鞯拇�碼通常不是好代碼。清晰度勝過(guò)一切。遵循任何一種范式都可能寫出糟糕的代碼。所謂的“最佳實(shí)踐”是與實(shí)際情況相關(guān)的，并非廣泛適用的。盲目追隨它們會(huì)讓你變成白癡。在非必要的情況下去設(shè)計(jì)一個(gè)可伸縮的系統(tǒng)，這會(huì)讓你成為一名糟糕的工程師。靜態(tài)代碼分析非常有用。DRY原則是為了避免某些特定的問(wèn)題，并不是其本身的最終目標(biāo)。一般來(lái)說(shuō)，RDBMS好過(guò)NoSQL。函數(shù)式編程是另一種可選的工具，但不是萬(wàn)能的。2這些年形成的新想法按照YAGNI、SOLID、DRY這樣的順序來(lái)。鉛筆和紙其實(shí)是最好的編程工具，但卻被忽視了。用純粹性來(lái)?yè)Q取實(shí)用性通常是個(gè)不錯(cuò)的選擇。添加太多的技術(shù)很少會(huì)是一個(gè)好的選擇。直接與客戶溝通總是能以更少的時(shí)間和更高的準(zhǔn)確性揭示出更多的問(wèn)題�！翱缮炜s”這個(gè)詞對(duì)于軟件工程師來(lái)說(shuō)有著一種神秘而令人震驚的力量，足以讓他們陷入一種墮落的瘋狂。雖然開發(fā)者被稱為“工程師”，但他們的大多數(shù)決策都是純粹的貨物崇拜（CargoCult），沒有分析、數(shù)據(jù)或數(shù)字作為依據(jù)。90%（可能是93%）的項(xiàng)目經(jīng)理可能會(huì)在未來(lái)消失，因?yàn)樗麄儾粫?huì)帶來(lái)效率上的提升。在做了100多次面試后，我發(fā)現(xiàn)面試這種形式徹底失效了，但我也不知道該如何讓它變得更好。3那些保持不變的舊想法那些強(qiáng)調(diào)代碼風(fēng)格、lint規(guī)則或其他細(xì)節(jié)的人都是瘋狂的怪人。代碼覆蓋率與代碼質(zhì)量毫無(wú)關(guān)系。在大多數(shù)情況下，使用單體系統(tǒng)就可以了。TDD純粹主義者是最糟糕的。他們脆弱的小腦袋無(wú)法容忍不同工作流的存在。等到了第10個(gè)年頭，我們?cè)賮?lái)看看哪些觀點(diǎn)又翻轉(zhuǎn)或發(fā)生了變化。原文鏈接：https://chriskiehl.com/article/thoughts-after-6-years本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：210

近年來(lái)，隨著移動(dòng)互聯(lián)產(chǎn)業(yè)的興起，移動(dòng)應(yīng)用軟件（Application，App）逐漸滲透到社會(huì)生活的各個(gè)領(lǐng)域，為大眾提供精細(xì)化場(chǎng)景化服務(wù)。在面向細(xì)分領(lǐng)域發(fā)展的同時(shí)，App種類和數(shù)量呈爆發(fā)式增長(zhǎng)，軟件開發(fā)工具包（SoftwareDevelopmentKit，SDK）被廣泛集成、應(yīng)用，為日益豐富的App功能、服務(wù)提供了技術(shù)上的解決方案。數(shù)字經(jīng)濟(jì)時(shí)代下，移動(dòng)應(yīng)用場(chǎng)景迅速擴(kuò)展，SDK逐步成為移動(dòng)業(yè)務(wù)價(jià)值拓展的重要組成部分。然而，由于SDK具有泛用性、靈活性等特點(diǎn)，一旦出現(xiàn)安全問(wèn)題，不僅自身業(yè)務(wù)受到直接影響，也會(huì)威脅到集成SDK的App業(yè)務(wù)安全和數(shù)據(jù)安全，嚴(yán)重的情況下甚至可能影響移動(dòng)應(yīng)用系統(tǒng)生態(tài)安全。隨著安全形勢(shì)不斷變化，SDK的安全合規(guī)問(wèn)題已經(jīng)進(jìn)入各方視野，SDK可能存在的安全漏洞、惡意行為，以及隱藏在App背后不透明地收集使用個(gè)人信息等問(wèn)題逐漸成為各方關(guān)注的焦點(diǎn)問(wèn)題。報(bào)告從場(chǎng)景分析、數(shù)據(jù)統(tǒng)計(jì)、政策標(biāo)準(zhǔn)方面分享了SDK行業(yè)發(fā)展現(xiàn)狀，對(duì)SDK行業(yè)面臨的合規(guī)風(fēng)險(xiǎn)、安全風(fēng)險(xiǎn)進(jìn)行了分析，面向SDK及App開發(fā)者提出了安全措施建議，并從實(shí)踐角度分享案例和經(jīng)驗(yàn)，為促進(jìn)SDK行業(yè)生態(tài)的健康發(fā)展提供參考。SDK通常無(wú)法獨(dú)立展示前臺(tái)頁(yè)面，其告知行為往往需要借助宿主App傳達(dá)給用戶，但由于部分SDK未向App告知或完整告知自身所收集的個(gè)人信息，或者SDK公開了收集使用規(guī)則但App未向用戶明示等原因，使得用戶對(duì)SDK收集個(gè)人信息行為毫無(wú)感知。還有部分SDK未經(jīng)用戶同意，私自調(diào)用權(quán)限隱蔽收集個(gè)人信息，私自通過(guò)自啟動(dòng)、關(guān)聯(lián)啟動(dòng)等方式收集個(gè)人信息。SDK未經(jīng)用戶同意收集個(gè)人信息，不僅增加了自身的違規(guī)風(fēng)險(xiǎn)，也會(huì)為宿主App制定收集使用規(guī)則，全面列舉收集使用的個(gè)人信息帶來(lái)障礙。SDK實(shí)際收集的用戶個(gè)人信息超出公開文檔所聲明的系統(tǒng)權(quán)限和個(gè)人信息。此類行為主要表現(xiàn)為SDK收集與其所提供服務(wù)無(wú)關(guān)的個(gè)人信息，強(qiáng)制申請(qǐng)非必要的權(quán)限，私自調(diào)用權(quán)限隱蔽收集個(gè)人信息，私自通過(guò)自啟動(dòng)、關(guān)聯(lián)啟動(dòng)等方式收集個(gè)人信息，自動(dòng)收集個(gè)人信息的頻度和時(shí)機(jī)不合理等。例如，部分SDK會(huì)收集非必要的設(shè)備信息、網(wǎng)絡(luò)環(huán)境信息，讀取用戶設(shè)備已安裝應(yīng)用程序列表，甚至超范圍收集用戶通訊錄、通話記錄、地理位置等敏感個(gè)人信息。SDK幫助App開發(fā)者實(shí)現(xiàn)登錄、支付、推送、數(shù)據(jù)統(tǒng)計(jì)分析等業(yè)務(wù)功能，存在未經(jīng)用戶授權(quán)使用個(gè)人信息的合規(guī)風(fēng)險(xiǎn)。一方面，SDK收集的個(gè)人信息可能涉及個(gè)人身份、財(cái)產(chǎn)等敏感信息，還可以通過(guò)App權(quán)限情況獲得位置信息、短信信息、鑒權(quán)信息等，如果未經(jīng)用戶授權(quán)使用，有可能嚴(yán)重?fù)p害用戶權(quán)益。另一方面，第三方SDK可能被各行業(yè)各類型的App集成，從而匯集多款A(yù)pp用戶個(gè)人信息，一旦相關(guān)信息被用于實(shí)施詐騙、社會(huì)工程攻擊等違法行為，其危害程度較單個(gè)App數(shù)據(jù)濫用事件更加嚴(yán)重。一方面，部分SDK存在明文傳輸用戶電話號(hào)碼、設(shè)備MAC地址等個(gè)人信息，或者私自向其他應(yīng)用或服務(wù)器發(fā)送、共享用戶個(gè)人信息的情況，可能被宿主App或本地惡意程序截獲，導(dǎo)致用戶個(gè)人信息泄露。另一方面，在未經(jīng)用戶同意的情況下，SDK有可能采取加密等方式私自傳輸收集的個(gè)人信息，如果SDK收集使用個(gè)人信息行為及相關(guān)信息未完全向宿主App告知，會(huì)為宿主App帶來(lái)額外的合規(guī)風(fēng)險(xiǎn)。目前許多App與SDK通過(guò)開放平臺(tái)在線簽署開發(fā)者服務(wù)協(xié)議來(lái)約定權(quán)利義務(wù)，然而開發(fā)者服務(wù)協(xié)議通常缺少專門約束數(shù)據(jù)安全的規(guī)定，同時(shí)App針對(duì)SDK收集個(gè)人信息行為進(jìn)行技術(shù)檢測(cè)存在一定難度，使得App對(duì)嵌入的SDK收集使用個(gè)人信息情況難以完全掌控，集成第三方SDK時(shí)容易引入個(gè)人信息合規(guī)風(fēng)險(xiǎn)。服務(wù)提供方應(yīng)如何合法、合規(guī)地收集、保存、使用個(gè)人信息，App如何對(duì)共享給SDK的個(gè)人信息、雙方權(quán)利義務(wù)及第三方SDK收集使用個(gè)人信息情況等加強(qiáng)管理監(jiān)督，正逐漸成為移動(dòng)應(yīng)用領(lǐng)域亟待解決的問(wèn)題。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：181

面向服務(wù)的架構(gòu)SOA的出現(xiàn)可以打破車內(nèi)靜態(tài)交互模型，并且建立功能靈活治理的系統(tǒng)架構(gòu)。確保新增功能的實(shí)現(xiàn)可以與車輛原有的系統(tǒng)架構(gòu)、驅(qū)動(dòng)方式、通信方式相匹配。（SOA）總體思路是設(shè)計(jì)組件模型，將不同的應(yīng)用功能服務(wù)進(jìn)行拆分，并通過(guò)定義恰當(dāng)?shù)耐ㄐ沤涌趯⑾鄳?yīng)的服務(wù)串聯(lián)起來(lái)。接口定義是獨(dú)立于實(shí)現(xiàn)服務(wù)的硬件平臺(tái)、操作系統(tǒng)和編程語(yǔ)言。確保構(gòu)建在不同系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。SOA是基于系統(tǒng)的概念，這種系統(tǒng)是由一組服務(wù)組成的，其中一個(gè)服務(wù)可以輪流使用另一個(gè)服務(wù)，應(yīng)用程序可以根據(jù)各自的需要調(diào)用一到多個(gè)服務(wù)。這一點(diǎn)上，SOA與Autosar的工作方式是一致的，因此，當(dāng)前自動(dòng)駕駛系統(tǒng)的開發(fā)中往往采用了基于Autosar的SOA設(shè)計(jì)模式�；�于Autosar的SOA軟件架構(gòu)基于SOA開發(fā)模式的軟件架構(gòu)（見下圖）主要在于通過(guò)軟件抽象層——運(yùn)行時(shí)環(huán)境(RTE)拆分獨(dú)立于硬件的應(yīng)用軟件（ASW）和面向硬件的基礎(chǔ)軟件(BSW)。一方面，這個(gè)抽象層能夠?yàn)镺EM自動(dòng)駕駛系統(tǒng)開發(fā)特定的、有競(jìng)爭(zhēng)力的軟件應(yīng)用程序。另一方面，它簡(jiǎn)化了獨(dú)立于OEM的基礎(chǔ)軟件標(biāo)準(zhǔn)化，其中，基礎(chǔ)軟件進(jìn)一步分為以下幾層，“服務(wù)”、“ECU抽象”、“微控制器抽象”。此外，它是ECU軟件可擴(kuò)展性的前提條件。運(yùn)行時(shí)環(huán)境RTE是從基礎(chǔ)軟件中抽象出應(yīng)用層，并組織它們之間的數(shù)據(jù)和信息流量。這構(gòu)成了在應(yīng)用層面向組件、獨(dú)立于硬件的軟件結(jié)構(gòu)的基礎(chǔ)，軟件模塊可以作為獨(dú)立的單元存在。例如，下一代自動(dòng)駕駛系統(tǒng)采用SOA軟件模塊架構(gòu)，其所有頂層功能都由底層軟件模塊實(shí)現(xiàn)。這些軟件模塊共同構(gòu)成了應(yīng)用程序。各個(gè)軟件模塊僅直接與RTE通信。因此，無(wú)論是在ECU內(nèi)還是超出ECU邊界，都設(shè)計(jì)了清晰的通信邊界。通過(guò)這種獨(dú)立性，可以在不了解使用或計(jì)劃的硬件情況下開發(fā)軟件組件，或者更確切地說(shuō)是在ECU之間分配現(xiàn)有軟件模塊�；�于SOA構(gòu)建軟件設(shè)計(jì)方法除了基于SOA的軟件架構(gòu)模塊設(shè)計(jì)外，AUTOSAR針對(duì)汽車軟件開發(fā)提出了一套標(biāo)準(zhǔn)化的方法論，構(gòu)建ECU中的軟件模塊，將各種ECU集成到具有不同總線系統(tǒng)的車輛通信網(wǎng)絡(luò)。它定義了通用工件和相關(guān)活動(dòng)，特別是活動(dòng)的依賴關(guān)系。在SOA的設(shè)計(jì)方法中可以使用AUTOSAR的相關(guān)信息，定義了一種具有語(yǔ)義約束的正式數(shù)據(jù)交換格式，這種數(shù)據(jù)信息作為標(biāo)準(zhǔn)描述了存儲(chǔ)在AUTOSARXML(.arxml)文件中，這種ARXML文件實(shí)際是由頂層SOA系統(tǒng)架構(gòu)設(shè)計(jì)者通過(guò)構(gòu)建相應(yīng)的SWC組件接口來(lái)生成的。軟件組件描述為應(yīng)用軟件提供了標(biāo)準(zhǔn)化的組件模型，系統(tǒng)描述定義了系統(tǒng)上的純軟件層與物理系統(tǒng)架構(gòu)之間的關(guān)系，許多工具使用這些描述來(lái)配置和生成AUTOSAR中RTE的基礎(chǔ)軟件�；�于SOA架構(gòu)的流程設(shè)計(jì)方法的原理如下圖所示。其中各框圖表示了帶有交叉鏈接的ECU實(shí)例。它描述了網(wǎng)絡(luò)拓?fù)�、每個(gè)通道的通信以及各種ECU上軟件模塊的分配。基于Autosar的SOA軟件架構(gòu)設(shè)計(jì)方法除了具備描述汽車行業(yè)E/E系統(tǒng)的基本能力外，還有許多方面需要實(shí)際交換格式的支持，例如可以通過(guò)技術(shù)文檔（包括規(guī)范、定義、技術(shù)要求等）、接口需求表等可追溯性來(lái)貫穿整個(gè)軟件生命周期。這種集成的變體管理允許OEM和供應(yīng)商共同深入到基本的AUTOSAR產(chǎn)品線，并在必要時(shí)與其合作伙伴交換相互的信息，對(duì)這些變體的共同理解和一致解釋是聯(lián)合開發(fā)項(xiàng)目成功合作的關(guān)鍵因素。SOA中的應(yīng)用程序接口用于確保應(yīng)用程序模塊與RTE進(jìn)行有效鏈接。其中，APAutosar并未標(biāo)準(zhǔn)化應(yīng)用程序的內(nèi)部功能流程，例如算法，而是將在應(yīng)用程序之間交換的信息。一方面Autosar使用專用語(yǔ)法將基本接口機(jī)制進(jìn)行了標(biāo)準(zhǔn)化。這種標(biāo)準(zhǔn)化接口規(guī)范允許軟件設(shè)計(jì)人員和開發(fā)人員獨(dú)立于任何特定硬件或ECU來(lái)開發(fā)軟件模塊，這種軟件模塊可以在包含其使用的數(shù)據(jù)類型、單位和縮放因子下進(jìn)行擴(kuò)展或重用。另一方面對(duì)車輛域主體中應(yīng)用程序接口的語(yǔ)義、內(nèi)涵、舒適性、動(dòng)力傳動(dòng)系、底盤以及乘客和行人保護(hù)進(jìn)行了標(biāo)準(zhǔn)化。重點(diǎn)是廣泛引入應(yīng)用程序的接口規(guī)范，以重點(diǎn)突破軟件模塊的重用和交換。最后，標(biāo)準(zhǔn)化應(yīng)用程序接口的使用對(duì)于應(yīng)用程序的重用至關(guān)重要。系統(tǒng)架構(gòu)-虛擬功能總線為了開發(fā)功能系統(tǒng)架構(gòu)，AUTOSAR引入了虛擬功能總線的概念——VFB（VirtualFunctionBus）。為了避免誤解，應(yīng)該明確指出：AUTOSAR已經(jīng)指定了VFB概念。這個(gè)概念在市場(chǎng)上可用的各種系統(tǒng)架構(gòu)工具中實(shí)現(xiàn)。VFB允許描述整個(gè)系統(tǒng)中應(yīng)用模塊之間的功能交互，此描述獨(dú)立于實(shí)際ECU的架構(gòu)和實(shí)施的網(wǎng)絡(luò)。通過(guò)這種方式，VFB將應(yīng)用程序從硬件中抽象出來(lái)，在這里，軟件組件被分配給ECU，在每個(gè)ECU中，VFB的功能由RTE和底層基礎(chǔ)軟件實(shí)現(xiàn)。在進(jìn)一步架構(gòu)構(gòu)建過(guò)程中，功能系統(tǒng)架構(gòu)被映射到物理架構(gòu)上或者說(shuō)在ECU和網(wǎng)絡(luò)拓?fù)渖稀�SOA中將單個(gè)應(yīng)用程序描述為軟件組件(SWC)。VFB既提供了它們之間的通信機(jī)制，也提供了使用基本軟件服務(wù)到軟件組件的機(jī)制，各種機(jī)制由所謂的端口表示。SOA軟件分層1、應(yīng)用軟件SOA軟件架構(gòu)的層模型將應(yīng)用軟件以軟件組件的形式放置在應(yīng)用層中，可以將軟件組件分組為在外部再次充當(dāng)軟件組件的組合。通過(guò)這個(gè)通用組件概念，可以將軟件組件的任何嵌套層次結(jié)構(gòu)實(shí)現(xiàn)為一個(gè)系統(tǒng)。應(yīng)用軟件可以獨(dú)立于硬件進(jìn)行設(shè)計(jì)和開發(fā)。軟件組件通過(guò)端口進(jìn)行通信，每個(gè)端口代表某種通信機(jī)制。應(yīng)用程序之間通信中最重要的機(jī)制是“發(fā)送方-接收方”用于由數(shù)據(jù)發(fā)送方發(fā)起的通信，以及“客戶端-服務(wù)器”用于接收方發(fā)起的通信。除此之外，還有用于過(guò)程控制（外部觸發(fā)事件）或用于訪問(wèn)某些參數(shù)（校準(zhǔn)、操作模式、非易失性存儲(chǔ)器）的更多端口。每個(gè)端口都有一個(gè)接口，用于確定要通信的數(shù)據(jù)類型。AUTOSAR已在編程語(yǔ)言C中定義了端口的精確映射。下圖顯示了ECU內(nèi)以及不同ECU中的應(yīng)用程序之間的通信路徑。軟件組件在AUTOSAR中由“軟件組件模板”做特定描述。除了端口和接口的描述之外，這還包含所謂的內(nèi)部行為。在AUTOSAR的上下文中，“內(nèi)部行為”是描述與時(shí)間或事件相關(guān)的過(guò)程控制（事件和調(diào)度）相關(guān)的組件。這包括“可運(yùn)行實(shí)體”的定義，即底層操作系統(tǒng)可在事件或時(shí)間上調(diào)度的最小軟件實(shí)體。需要說(shuō)明的是，要在組件中明確實(shí)現(xiàn)的算法不屬于“內(nèi)部行為”。在實(shí)踐中，有幾種典型的方法來(lái)填寫或編輯軟件組件描述。許多基于模型開發(fā)的設(shè)計(jì)工具如EA、Rapshody等，可以從圖形模型中生成軟件組件描述，并允許編輯相應(yīng)的條目。此外，RTE生成器通常允許編輯軟件組件描述。對(duì)于具有特定硬件要求的應(yīng)用程序，例如作為依賴于某些傳感器或執(zhí)行器的軟件，AUTOSAR提供了所謂的傳感器/執(zhí)行器軟件組件，其中可以在軟件組件描述中注明此類約束。2、實(shí)時(shí)運(yùn)行環(huán)境AUTOSAR運(yùn)行時(shí)環(huán)境(RTE)從基本軟件的任何實(shí)現(xiàn)細(xì)節(jié)和控制設(shè)備的硬件中提取應(yīng)用程序。它表示特定ECU上VFB的運(yùn)行時(shí)實(shí)現(xiàn)。RTE提供應(yīng)用程序之間的通信機(jī)制和訪問(wèn)基礎(chǔ)軟件服務(wù)的機(jī)制。這還包括為通信提供數(shù)據(jù)緩沖和排隊(duì)。RTE的實(shí)際程序代碼取決于應(yīng)用程序及其通信、使用的基礎(chǔ)軟件服務(wù)和調(diào)度。在實(shí)踐中，代碼是由RTE生成器根據(jù)軟件組件描述信息創(chuàng)建的。嚴(yán)格來(lái)說(shuō)，RTE是一種“中間件”層技術(shù)，它可以通過(guò)去中心化網(wǎng)絡(luò)實(shí)現(xiàn)應(yīng)用層組件的重新定位。3、基礎(chǔ)軟件基礎(chǔ)軟件通過(guò)RTE為應(yīng)用程序提供所有系統(tǒng)服務(wù)和功能。盡管基本軟件的功能對(duì)于應(yīng)用程序來(lái)說(shuō)是必不可少的，但車輛用戶通常不會(huì)很好地注意到這些功能。隨著對(duì)硬件的依賴性越來(lái)越大，基本軟件進(jìn)一步劃分為多個(gè)層次：即服務(wù)層、ECU抽象層和微控制器抽象層。反過(guò)來(lái)，每一層都包含代表精確指定功能范圍的單獨(dú)模塊。AUTOSAR基礎(chǔ)軟件總共包含大約80個(gè)不同的模塊，標(biāo)準(zhǔn)對(duì)每個(gè)模塊都有一個(gè)要求和軟件規(guī)范。其中模塊的功能行為及其接口是用C定義的，因此一個(gè)模塊的兩種不同但符合標(biāo)準(zhǔn)的實(shí)現(xiàn)可以直接互換�；�本軟件模塊的功能行為參數(shù)化及其配置使用與應(yīng)用程序組件相同的形式描述機(jī)制。控制單元基本軟件模塊的配置描述總結(jié)在ECU配置描述中�；�于Autosar的SOA服務(wù)服務(wù)層包括通信服務(wù)、診斷協(xié)議、存儲(chǔ)服務(wù)、ECU工作模式管理等系統(tǒng)服務(wù)，以及作為獨(dú)立模塊的AUTOSAR操作系統(tǒng)（OS）。AUTOSAROS基于實(shí)時(shí)系統(tǒng)標(biāo)準(zhǔn)OSEK/VDX，在某些領(lǐng)域得到擴(kuò)展，但在其他領(lǐng)域也受到限制。它是靜態(tài)配置和縮放的，并提供基于優(yōu)先級(jí)的實(shí)時(shí)行為和中斷處理。在運(yùn)行時(shí)，可以使用各種用于內(nèi)存訪問(wèn)或時(shí)間行為的保護(hù)機(jī)制。AUTOSAROS也適用于小型和較低性能的微控制器，同時(shí)也支持多核對(duì)代碼、數(shù)據(jù)使用和使用多個(gè)內(nèi)存分區(qū)，服務(wù)的模塊是獨(dú)立于硬件的操作系統(tǒng)。這些系統(tǒng)服務(wù)可通過(guò)RTE提供給應(yīng)用程序，應(yīng)用程序不能直接訪問(wèn)底層的基本軟件模塊。這是保留提供服務(wù)作為其功能的一部分從而訪問(wèn)ECU或微控制器資源。服務(wù)模塊及其底層模塊也稱為功能棧，例如FlexRay的通信棧。此類堆棧有時(shí)會(huì)作為一個(gè)大型軟件單元來(lái)實(shí)現(xiàn)和集成，而沒有AUTOSAR定義的底層模塊結(jié)構(gòu)。雖然這破壞了抽象原則并降低了靈活性，但由于實(shí)現(xiàn)的效率和性能可能更高，因此在AUTOSAR中使用函數(shù)堆棧進(jìn)行處理很普遍。硬件抽象服務(wù)層主要用于硬件抽象。首先，ECU抽象層將ECU布局（即外圍模塊如何與微控制器連接）與上層分離。盡管這一層是特定于ECU的，但它獨(dú)立于微控制器。下一級(jí)抽象是由微控制器抽象層實(shí)現(xiàn)的，其中包括微控制器特定的驅(qū)動(dòng)程序。例如，這些驅(qū)動(dòng)程序是用于數(shù)字輸入和輸出的I/O驅(qū)動(dòng)程序，或用于將模擬信號(hào)轉(zhuǎn)換為數(shù)字值的ADC驅(qū)動(dòng)程序。因此，AUTOSAR標(biāo)準(zhǔn)直接支持標(biāo)準(zhǔn)化硬件。復(fù)雜驅(qū)動(dòng)層用于處理特殊情況，例如，用于控制具有特殊實(shí)時(shí)要求或具有特定機(jī)電硬件要求的復(fù)雜傳感器或執(zhí)行器。此類模塊并未標(biāo)準(zhǔn)化為AUTOSAR基本軟件模塊，因?yàn)檫@里需要汽車制造商或供應(yīng)商的特定專業(yè)知識(shí)和知識(shí)產(chǎn)權(quán)。然而，復(fù)雜的驅(qū)動(dòng)程序和標(biāo)準(zhǔn)化的模塊必須滿足AUTOSAR基礎(chǔ)軟件中接口機(jī)制的要求�；�于Autosar的SOA系統(tǒng)配置在AUTOSAR的上下文中，系統(tǒng)是指網(wǎng)絡(luò)控制單元的組合或集成，其中可能包括車輛的所有ECU。系統(tǒng)配置遵循VFB級(jí)功能系統(tǒng)架構(gòu)的開發(fā)。在設(shè)計(jì)系統(tǒng)配置時(shí)，會(huì)根據(jù)系統(tǒng)的實(shí)際物理架構(gòu)做出決定。這些決定主要與系統(tǒng)拓?fù)溆嘘P(guān)，即哪些控制單元可用以及它們?nèi)绾芜B接。對(duì)于每個(gè)控制單元，都有關(guān)于處理器架構(gòu)、處理器容量、內(nèi)存、接口和外圍設(shè)備或信號(hào)方法的資源描述。網(wǎng)絡(luò)拓?fù)涞拿枋龇秶鷱目偩�系統(tǒng)到各個(gè)通道的通信矩陣。此外，它還包括確定哪個(gè)應(yīng)用軟件組件應(yīng)該在哪個(gè)控制單元上運(yùn)行，所有這些信息都記錄在系統(tǒng)描述中。在實(shí)踐中，這可以通過(guò)系統(tǒng)架構(gòu)設(shè)計(jì)工具以及VFB設(shè)計(jì)（也稱為系統(tǒng)生成器）或通過(guò)基本軟件模塊的配置工具來(lái)完成。系統(tǒng)配置成功需要通過(guò)對(duì)各個(gè)控制單元的進(jìn)一步配置，最后通過(guò)軟件集成來(lái)完成，每個(gè)ECU都是獨(dú)立的，即如果需要，它可以并行運(yùn)行。此外，某個(gè)控制單元的所有相關(guān)信息都被復(fù)制到系統(tǒng)配置之外的ECU描述中。這被命名為系統(tǒng)描述的ECU摘錄。ECU描述還匯總了每個(gè)基本軟件模塊的配置描述�；�本軟件配置的許多參數(shù)直接來(lái)自系統(tǒng)描述或軟件組件的描述。其余的自由參數(shù)通過(guò)使用基本的軟件配置工具來(lái)設(shè)置。在幾乎所有基本軟件模塊的配置步驟之后，屬于配置的代碼由生成器生成——就像在RTE中一樣。應(yīng)用軟件組件的實(shí)現(xiàn)是算法和編碼的創(chuàng)建，可以與系統(tǒng)配置完全并行完成，因?yàn)檫@一步獨(dú)立于硬件。最終，基礎(chǔ)軟件的整個(gè)代碼連同RTE代碼以及所有應(yīng)用軟件組件的代碼都集成到每個(gè)控制單元的ECU軟件中�？偨Y(jié)整體上講，面向服務(wù)的SOA架構(gòu)設(shè)計(jì)主要包含五個(gè)步驟：梳理整車功能、規(guī)劃SOA架構(gòu)、服務(wù)定義、服務(wù)矩陣和ARXML設(shè)計(jì)、服務(wù)驗(yàn)證和仿真；SOA不是一種具體的技術(shù)實(shí)現(xiàn)，而是一種模板軟件架構(gòu)，而APAUTOSAR則稱是一個(gè)模板SOA。如何利用Autosar構(gòu)建好的SOA模型是我們需要特別關(guān)注的。本文詳細(xì)闡述了面向服務(wù)的SOA軟件設(shè)計(jì)過(guò)程，以Autosar為基礎(chǔ)分析軟件架構(gòu)及其設(shè)計(jì)方法、系統(tǒng)配置、硬件抽象、軟件分層等。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：145

Aspice作為車載軟件過(guò)程中，關(guān)注于功能場(chǎng)景定義（functiondefinition）、架構(gòu)定義（SystemArchitecture）、系統(tǒng)設(shè)計(jì)（SystemDesign）、產(chǎn)品設(shè)計(jì)（ProductDesign）幾個(gè)大的方面。而下一代智能駕駛系統(tǒng)需要面向服務(wù)進(jìn)行相應(yīng)的功能設(shè)計(jì)和開發(fā)，實(shí)現(xiàn)軟硬件解耦。這種開發(fā)方式將對(duì)整個(gè)智能駕駛來(lái)說(shuō)產(chǎn)生顛覆性的影響，比如高性能計(jì)算平臺(tái)HPC包含多核異構(gòu)處理模式，通過(guò)Hypervisor技術(shù)實(shí)現(xiàn)對(duì)硬件抽象，Inter-Core通信技術(shù)使多篇和單片多核實(shí)現(xiàn)信息互通，計(jì)算單元趨于“云計(jì)算+中央計(jì)算+邊緣計(jì)算結(jié)合等多個(gè)方面的變革。如上這些設(shè)計(jì)原則更多的是基于SOA的架構(gòu)進(jìn)行的，這就大大增強(qiáng)了平臺(tái)的可拓展性，可移植性。當(dāng)前更多的主機(jī)廠選擇在智能駕駛中采用SOA的開發(fā)模式，這可以更加快速的實(shí)現(xiàn)從底層、中間層到應(yīng)用層的軟件開發(fā)，且相對(duì)較多的軟件只要接口定義得當(dāng)，就可以實(shí)現(xiàn)軟件本體和功能的遷移，同時(shí)可以大大的降低開發(fā)周期和成本。對(duì)于SOA的設(shè)計(jì)過(guò)程來(lái)講，其服務(wù)設(shè)計(jì)原則包括重用、抽象、封裝、協(xié)調(diào)在內(nèi)的多個(gè)層面。比如對(duì)于智能駕駛功能開發(fā)而言，如果需要多次用到某一邏輯元素比如車道線等環(huán)境信息，則應(yīng)該將車道線檢測(cè)模塊創(chuàng)建為重用（比如封裝到BuildingBlock中），則對(duì)該車道線檢測(cè)源（如不同方位的攝像頭）進(jìn)行調(diào)整，則由此對(duì)車道線檢測(cè)產(chǎn)生的任何更新改變都會(huì)對(duì)后續(xù)級(jí)聯(lián)的應(yīng)用實(shí)例產(chǎn)生影響。而上層應(yīng)用軟件端對(duì)于底層的如何獲取車道線，如何處理的細(xì)節(jié)也不需要深究，這就是實(shí)現(xiàn)模塊抽象的整個(gè)過(guò)程。抽象后的邏輯功能需要保證其體系相類似的功能需要集成到一起，比如自動(dòng)換道功能的控制邏輯可以在自動(dòng)激活后調(diào)用觸發(fā)換道相關(guān)的規(guī)劃控制模塊進(jìn)行車控。因此，觸發(fā)換道的規(guī)劃決策控制邏輯單元可以完全應(yīng)用于自動(dòng)換道模塊。系統(tǒng)工程師只需要保證定義的接口適用于觸發(fā)換道已經(jīng)發(fā)布或預(yù)定的數(shù)據(jù)流即可。對(duì)于自動(dòng)駕駛域控單元負(fù)責(zé)人而言，應(yīng)該保持邏輯系統(tǒng)結(jié)構(gòu)之間的協(xié)調(diào)和重用，包含對(duì)公共池中的元素排布，對(duì)局部域單元中的邏輯構(gòu)造，跨域之間的資源或模塊調(diào)度等。本文將以智能駕駛系統(tǒng)開發(fā)設(shè)計(jì)實(shí)例來(lái)講解和分析相應(yīng)的SOA為基礎(chǔ)下的架構(gòu)設(shè)計(jì)和軟件開發(fā)。面向ASPICE流程的SOA軟件架構(gòu)流程適用于SOA架構(gòu)的ASPICE軟件開發(fā)過(guò)程也是在敏捷開發(fā)的模式下進(jìn)行的系統(tǒng)開發(fā)流程。從智能駕駛功能開發(fā)層面上講，基于SOA架構(gòu)開發(fā)模式包括了系統(tǒng)功能、系統(tǒng)架構(gòu)、軟件功能、軟件架構(gòu)幾個(gè)方面。其中分別由分別稱之為產(chǎn)品負(fù)責(zé)人ProductOwner、功能負(fù)責(zé)人FunctionOwner、架構(gòu)負(fù)責(zé)人ArchitectOwner、子模塊負(fù)責(zé)人ModuleOwner的幾個(gè)角色共同承擔(dān)。功能設(shè)計(jì)是搭建功能架構(gòu)圖和依據(jù)產(chǎn)品工程師輸入的產(chǎn)品需求定義進(jìn)行功能分解定義，架構(gòu)負(fù)責(zé)人則根據(jù)整車架構(gòu)及功能負(fù)責(zé)人輸入的要素信息制定合適的軟硬件架構(gòu)。這里需要說(shuō)明的是很多情況下，功能負(fù)責(zé)人和架構(gòu)負(fù)責(zé)人往往是同一個(gè)人。模塊負(fù)責(zé)人則是根據(jù)功能定義編制相應(yīng)的系統(tǒng)軟硬件模塊、零部件軟硬件模塊以實(shí)現(xiàn)上層定義的功能需求。各負(fù)責(zé)人之間的角色定位將在如下分層流程圖中進(jìn)行詳細(xì)說(shuō)明。這里我們僅關(guān)注V模型中的與SOA相關(guān)度較高的設(shè)計(jì)開發(fā)部分，測(cè)試驗(yàn)證部分不在本文中進(jìn)行詳述。其中，各階段的開發(fā)輸出功能過(guò)程如下：1、項(xiàng)目功能定義項(xiàng)目功能元素（functionelement）包含與頂層設(shè)計(jì)相關(guān)的不同屬性，例如車輛類型、預(yù)期市場(chǎng)、項(xiàng)目功能以及功能發(fā)布計(jì)劃等。在實(shí)際開發(fā)中，這類輸出一般是產(chǎn)品策劃部門或市場(chǎng)部輸出的整車功能開發(fā)需求或整車裝備需求。本文將以開發(fā)智能駕駛系統(tǒng)功能中的點(diǎn)對(duì)點(diǎn)自動(dòng)駕駛NOP為例進(jìn)行詳細(xì)的分析說(shuō)明基于SOA的架構(gòu)設(shè)計(jì)是如何應(yīng)用于自動(dòng)駕駛系統(tǒng)開發(fā)的。如下圖舉例中，表示了實(shí)現(xiàn)下一代自動(dòng)駕駛系統(tǒng)NOP場(chǎng)景定義需求。2、系統(tǒng)架構(gòu)設(shè)計(jì)階段（SystemArchitectureDesign）這個(gè)階段涉及產(chǎn)品能力定義及模塊定義。用于描述智能汽車中的用戶功能，通過(guò)定義相應(yīng)的函數(shù)來(lái)指出使用哪些子系統(tǒng)或者零部件具備相應(yīng)的產(chǎn)品能力（ProductCapabilities，PC）并對(duì)其進(jìn)行相應(yīng)的實(shí)例化來(lái)實(shí)現(xiàn)此功能。（1）產(chǎn)品能力PC：這種稱之為產(chǎn)品能力的模塊主要是用于定義想要實(shí)現(xiàn)該功能模塊的傳感器或執(zhí)行器所具備的能力，這也是位于各個(gè)時(shí)序圖上各個(gè)節(jié)點(diǎn)的能力描述。通常，該產(chǎn)品能力的定義主要由產(chǎn)品工程師牽頭，功能所有者、架構(gòu)師和模塊所有者/設(shè)計(jì)者的跨職能小組共同決定。（2）產(chǎn)品能力實(shí)例化PCInstance：產(chǎn)品能力可以被認(rèn)為是一種高級(jí)服務(wù)，一些需要在汽車中實(shí)現(xiàn)的功能，但它沒有描述應(yīng)該如何實(shí)現(xiàn)。產(chǎn)品能力實(shí)例是PC的簡(jiǎn)單實(shí)例化，可以在平臺(tái)中擁有PC的不同變體。如果需要PC的不同變體實(shí)例以及在何處使用不同的實(shí)例，則模塊所有者負(fù)責(zé)。系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中定義了產(chǎn)品能力PC的不同類型，并確定哪些PC需要由跨職能團(tuán)隊(duì)才能完成。通過(guò)將當(dāng)前定義的PC和其他的需要PC建立依賴關(guān)系，我們可以建模一個(gè)完整的功能架構(gòu)，該功能層級(jí)的架構(gòu)無(wú)需研究實(shí)際的實(shí)現(xiàn)機(jī)制。這對(duì)于定義需要哪些高級(jí)服務(wù)(PC)以及分配誰(shuí)（哪個(gè)模塊）負(fù)責(zé)實(shí)施每個(gè)PC非常有幫助。如上過(guò)程一般是通過(guò)各種圖表（包含用例圖、序列圖、活動(dòng)圖等）來(lái)完成的。如下圖表示了一種活動(dòng)圖所示意的系統(tǒng)交互方式。由于在定義過(guò)程中還建立了與功能之間的連接，因此我們可以使用該模塊來(lái)規(guī)劃需要實(shí)現(xiàn)PC的順序，以便我們?cè)诿總�(gè)版本的集成階段開發(fā)出正確的功能。（3）模塊及實(shí)例ModuleInstance：模塊是整個(gè)模型甚至整個(gè)組織中非常核心的元素。從SOA的架構(gòu)設(shè)計(jì)上講，每個(gè)設(shè)計(jì)的PC都被分配到一個(gè)并且只有一個(gè)模塊（或者稱之為函數(shù)），該模塊負(fù)責(zé)實(shí)現(xiàn)PC，但在整個(gè)平臺(tái)生命周期內(nèi)維護(hù)和發(fā)展PC，規(guī)劃PC的演進(jìn)步驟，提供路線圖等。PC定義的功能在Component中實(shí)現(xiàn)，模塊實(shí)例可以確保在平臺(tái)中擁有模塊的不同變體。系統(tǒng)架構(gòu)師負(fù)責(zé)定義系統(tǒng)中存在哪些模塊，但模塊所有者負(fù)責(zé)領(lǐng)導(dǎo)模塊內(nèi)的工作，并負(fù)責(zé)維護(hù)和發(fā)展模塊。模塊所有者還負(fù)責(zé)是否需要模塊的不同變體實(shí)例以及在何處使用等。同時(shí)，模塊中的相關(guān)參數(shù)是在對(duì)應(yīng)構(gòu)建的系統(tǒng)功能規(guī)范中實(shí)現(xiàn)定義的。3、軟件架構(gòu)設(shè)計(jì)階段軟件組件SoftwareComponent：組件是模塊的實(shí)際設(shè)計(jì)和實(shí)現(xiàn)。組件可以是軟件或硬件組件，但在SOA的軟件架構(gòu)中，我們將主要處理軟件組件，組件定義了模塊需要哪些接口以及提供哪些接口。其中接口將包括SOA架構(gòu)所要求的服務(wù)、屬性和事件。在硬件組件上，接口可以是螺孔或電線連接器。軟件包SoftwarePackage：軟件包是將部署到特定運(yùn)行環(huán)境時(shí)的所有軟件組件、清單文件等的集合。為了實(shí)現(xiàn)面向SOA的架構(gòu)設(shè)計(jì)和開發(fā)過(guò)程，需要重點(diǎn)定義。4、底層驅(qū)動(dòng)設(shè)計(jì)階段中央控制單元ECU/處理器Processor/虛擬機(jī)VirtualMachine：一個(gè)ECU可以由一個(gè)或多個(gè)處理器組成，一個(gè)處理器可以運(yùn)行一個(gè)或多個(gè)虛擬機(jī)。不必對(duì)每個(gè)組件進(jìn)行建模，例如，如果ECU僅包含一個(gè)處理器，則僅對(duì)ECU進(jìn)行建模就足夠了。可以將各個(gè)軟件包部署到如上運(yùn)行時(shí)環(huán)境中的任何一個(gè)。網(wǎng)絡(luò)及連接器NetworkConnector：定義網(wǎng)絡(luò)以及連接到它的運(yùn)行時(shí)環(huán)境。運(yùn)行時(shí)環(huán)境可以由一個(gè)或多個(gè)網(wǎng)絡(luò)連接組成，這些網(wǎng)絡(luò)連接可以是CAN、CANFD、以太網(wǎng)、VLAN、LIN等。嚴(yán)格說(shuō)來(lái)，底層驅(qū)動(dòng)設(shè)計(jì)應(yīng)該屬于軟件架構(gòu)設(shè)計(jì)的其中一個(gè)部分，面向底層軟件設(shè)計(jì)部分，通常與頂層軟件開發(fā)團(tuán)隊(duì)不是一伙人，且具有較大區(qū)別，該開發(fā)過(guò)程由頂層軟件設(shè)計(jì)人員對(duì)底層軟件開發(fā)人員單獨(dú)提出需求及建議。一般的需求包括平臺(tái)軟件總體架構(gòu)及對(duì)相關(guān)AUTOSAR標(biāo)準(zhǔn)組件和復(fù)雜驅(qū)動(dòng)的調(diào)度框架設(shè)計(jì)、開發(fā)和集成要求；內(nèi)存、非易失性存儲(chǔ)、任務(wù)、中斷等等資源和權(quán)限分配；上下電流程和管理的設(shè)計(jì)；系統(tǒng)運(yùn)行狀態(tài)監(jiān)控、異常處理等功能的設(shè)計(jì)等方面�；�于SOA架構(gòu)模型設(shè)計(jì)分工基于SOA軟件模型架構(gòu)的設(shè)計(jì)過(guò)程實(shí)際是在研究如何在開發(fā)流程中進(jìn)行軟硬件解耦。包括構(gòu)建不同的分層來(lái)隔離硬件與軟件功能和服務(wù)。例如，將自動(dòng)駕駛相關(guān)的傳感器和執(zhí)行器邏輯與應(yīng)用程序邏輯分開，則能夠在中央系統(tǒng)中分配應(yīng)用程序，同時(shí)保持傳感器/執(zhí)行器盡可能的具體。程序之間可以利用SOA的服務(wù)模式實(shí)現(xiàn)軟件包的調(diào)用，傳感器和執(zhí)行器也可以作為組件或模組來(lái)進(jìn)行邊緣采購(gòu)，性能則是集中管控，中央系統(tǒng)可以將戰(zhàn)略軟件進(jìn)行分開，這就更容易進(jìn)行軟件模塊移植和處理。這一過(guò)程實(shí)際就是在提高上層應(yīng)用層軟件關(guān)鍵功能的復(fù)用性，瞄準(zhǔn)軟硬件功能與邏輯控制分離。這里需要說(shuō)明的是，軟硬件之間的協(xié)調(diào)和調(diào)度是通過(guò)中間件來(lái)實(shí)現(xiàn)。從如下圖所示，SOA的架構(gòu)從下至上分別底層驅(qū)動(dòng)功能管理，物理層功能管理，車輛控制服務(wù)，面向用戶的應(yīng)用服務(wù)，云端遠(yuǎn)程管理。底層驅(qū)動(dòng)功能管理：用于實(shí)現(xiàn)包含診斷、日志記錄、存儲(chǔ)管理、驅(qū)動(dòng)管理等相關(guān)功能。物理層功能管理：主要是設(shè)置I/O接口將原始傳感器數(shù)據(jù)進(jìn)行輸入，同時(shí)也是執(zhí)行到車端的控制單元（如電機(jī)、制動(dòng)卡鉗等）；車輛控制服務(wù)：車端控制包含上層ADAS發(fā)送的執(zhí)行指令到控制執(zhí)行器執(zhí)行該指令的相應(yīng)ECU（如控制電機(jī)的VCU、HCU或ESP），該車輛控制服務(wù)是綜合考慮了車身穩(wěn)定性與動(dòng)力學(xué)反饋模型得出的。應(yīng)用層服務(wù)：該層服務(wù)就是智能駕駛面向用戶級(jí)別的頂層開發(fā)功能，主要用于實(shí)現(xiàn)包含傳統(tǒng)的智能駕駛功能，比如HWP、NOP、TJP以及ALC等。云端管理服務(wù)：該層服務(wù)主要是面向遠(yuǎn)程監(jiān)控，遠(yuǎn)程控制，大數(shù)據(jù)存儲(chǔ)等特殊場(chǎng)景。通常該服務(wù)需要基于4G/5G網(wǎng)絡(luò)進(jìn)行遠(yuǎn)程連接。人機(jī)交互管理功能：人機(jī)交互管理功能一般是針對(duì)不同的車型呈現(xiàn)出不同的模式的，因此，這一塊一般是獨(dú)立于SOA的功能架構(gòu)。SOA通常只涉及底層對(duì)車輛控制邏輯，對(duì)于平臺(tái)化車型功能開發(fā)來(lái)說(shuō)，這一塊是無(wú)法為用戶所感知的。而HMI的顯示設(shè)置則是用戶能夠真切感知和控制的，因此，不同車型肯定是有極大的不同之處。因此，從協(xié)議上分析不難看出，SOA內(nèi)部的網(wǎng)絡(luò)架構(gòu)一般是基于以太網(wǎng)為基礎(chǔ)的交互方式，采用Some/ip的協(xié)議進(jìn)行通信控制。而如果在平臺(tái)化車型的開發(fā)過(guò)程中，HMI這一塊的通常仍然按照原始CAN/CANFD信號(hào)模式的通信協(xié)議進(jìn)行交互控制。這么做的原因是，智能駕駛的HMI行為比核心應(yīng)用功能更容易改變，特別是在不同車型開發(fā)后期通常會(huì)選擇不同的顯示和交互方式。同時(shí)，由于開發(fā)核心軟件和HMI設(shè)計(jì)需要不同的能力技能，因此，將HMI功能與其他應(yīng)用層軟件功能分離，為了實(shí)現(xiàn)這一點(diǎn)，一般需要使用Model-View-Controller，用戶輸入由Controller處理，Controller用于解釋用戶的意圖并操作模型。SOA服務(wù)實(shí)現(xiàn)過(guò)程隨著車載以太網(wǎng)技術(shù)的日益成熟，國(guó)內(nèi)大部分OEM都已經(jīng)著手SOA的設(shè)計(jì)工作，并將以太網(wǎng)通信矩陣生成ARXML文件，用于項(xiàng)目前期的網(wǎng)絡(luò)行為仿真和后期測(cè)試驗(yàn)證。對(duì)于已經(jīng)完成架構(gòu)搭建的SOA來(lái)講，需要將其建模后的成品導(dǎo)入到軟件團(tuán)隊(duì)進(jìn)行服務(wù)實(shí)現(xiàn)。其過(guò)程包含：以Some/Ip協(xié)議導(dǎo)入ServiceARXML，導(dǎo)入后新增ETH、TCP/IP、Some/IP模塊（BSW工程），建立與ServiceHandlerSWC（應(yīng)用層）中PortInterface連接，為所有ServiceHandlerSWC增加可運(yùn)行時(shí)間，定義WindowsServiceHandlerSWC和FeatureSWC到Simulink/Stateflow。通過(guò)符合Autosar的ARXML和Simulink進(jìn)行交互，將由軟件開發(fā)工程師繼續(xù)進(jìn)行算法設(shè)計(jì)并自動(dòng)生成代碼�？偨Y(jié)本文從SOA軟件架構(gòu)模型的構(gòu)建角度出發(fā)講解了相應(yīng)實(shí)現(xiàn)過(guò)程原理，利用了基于模型、集成式的可視化開發(fā)工具PREEvision進(jìn)行了智能汽車行業(yè)及相關(guān)領(lǐng)域E/E架構(gòu)開發(fā)并支持以太網(wǎng)SOA的架構(gòu)開發(fā)設(shè)計(jì)，本文以介紹SOA架構(gòu)設(shè)計(jì)模型為基礎(chǔ)展示了如何在EnterpriseArchitect中進(jìn)行SOA建模。同時(shí)，以系統(tǒng)工程師的角度說(shuō)明如何利用EnterpriseArchitect構(gòu)建SOA系統(tǒng)及軟件架構(gòu)設(shè)計(jì)、功能設(shè)計(jì)FunctionDesign和模塊設(shè)計(jì)ModuleDesign。對(duì)于SOA在整個(gè)智能駕駛系統(tǒng)設(shè)計(jì)原理有個(gè)清晰的把控。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：161

一背景和問(wèn)題我個(gè)人平時(shí)會(huì)比較慎用“架構(gòu)”這個(gè)詞一方面是覺得業(yè)界有很多架構(gòu)大師和架構(gòu)模式，而我的認(rèn)知和實(shí)踐有限；另一方面是因?yàn)檫@個(gè)詞看著挺高大上、有點(diǎn)務(wù)虛，如果不結(jié)合實(shí)際場(chǎng)景的具體問(wèn)題來(lái)討論，容易陷入“PHP是最好的語(yǔ)言”這樣的辯論賽中。而不同場(chǎng)景中又有各自的問(wèn)題，程序員們通過(guò)自己的理解和思考、針對(duì)實(shí)際場(chǎng)景對(duì)一些架構(gòu)模式進(jìn)行了擴(kuò)展實(shí)踐，以此來(lái)解決遇到的問(wèn)題，也會(huì)基于同一個(gè)模式延伸出一些派生概念。兵無(wú)常勢(shì)，水無(wú)常形。所以，我個(gè)人的觀點(diǎn)是：以要解決的問(wèn)題為出發(fā)點(diǎn)，去討論我們要采用的架構(gòu)模式（技術(shù)方案）。另外，由于我們是站在很多巨人肩膀上的，討論時(shí)可以站在一些如SOLID等軟件設(shè)計(jì)/開發(fā)原則的基礎(chǔ)上。寫這篇文章，我也是從解決一些問(wèn)題的目的出發(fā)的：最近和團(tuán)隊(duì)同學(xué)討論了相關(guān)話題，雖然大多數(shù)同學(xué)在實(shí)踐上基本一致，但具體到話術(shù)、名詞概念和具體使用的理解和實(shí)踐上有些差異（這是很正常的，因?yàn)闃I(yè)界對(duì)同一個(gè)模式的理解和實(shí)踐也不同）。我結(jié)合一些實(shí)際編碼場(chǎng)景做了一番陳述，為了避免后續(xù)重復(fù)大費(fèi)口舌，所以打算寫下來(lái)，以后有需要直接發(fā)文章鏈接。由于我個(gè)人的認(rèn)知和實(shí)踐有限，所以也希望能拋（huan）磚（ying）引（lai）玉（pen），讓我學(xué)到更多。雖然同一個(gè)架構(gòu)模式在不同業(yè)務(wù)/技術(shù)領(lǐng)域的實(shí)施會(huì)有區(qū)別，但同一個(gè)團(tuán)隊(duì)內(nèi)應(yīng)該保持一致性，因?yàn)檫@樣有助于日常的codereview、功能模塊的交接backup等活動(dòng)，尤其是有利于使用統(tǒng)一的單測(cè)建設(shè)方案來(lái)保障我們的產(chǎn)品質(zhì)量。實(shí)際問(wèn)題：我最近在開發(fā)商家合并發(fā)貨的功能，但由于之前基礎(chǔ)發(fā)貨功能的界面和邏輯并不是我開發(fā)的，所以我在修改原有代碼、支持有非常多細(xì)節(jié)邏輯的合并發(fā)貨能力時(shí)，就在擔(dān)心對(duì)原有發(fā)（zhong）貨（yao）能力的影響。而這時(shí)候，如果有單測(cè)的保障，我就可以更放心地進(jìn)行功能升級(jí)改造了——?jiǎng)e說(shuō)更復(fù)雜的合并發(fā)貨能力了，而這類訴求在復(fù)雜的交易場(chǎng)景里很普遍。提煉一下我遇到的具體問(wèn)題：在由不同開發(fā)人員持續(xù)迭代、進(jìn)行功能升級(jí)的軟件開發(fā)活動(dòng)中，如何保障具有復(fù)雜邏輯的商家經(jīng)營(yíng)工具的產(chǎn)品質(zhì)量。軟件開發(fā)活動(dòng)是整個(gè)流程的核心環(huán)節(jié)：接收產(chǎn)品和視覺設(shè)計(jì)需求/變更作為輸入，然后輸出客戶可用的終端產(chǎn)品。而統(tǒng)一的軟件開發(fā)架構(gòu)模式，則是我們保障軟件開發(fā)質(zhì)量的基礎(chǔ)。（這里就不具體展開WHY了）由于討論的是具體面向客戶使用的業(yè)務(wù)場(chǎng)景，少不了客戶操作交互的視圖層（View），所以我從MVC開始談起。二從表現(xiàn)層的MVC談起雖然我平時(shí)比較慎用“架構(gòu)”這個(gè)詞，但我平時(shí)喜歡隨手拍一些建筑物。因?yàn)榻ㄖ�之美，�?huì)讓我聯(lián)想到軟件的架構(gòu)也應(yīng)該有美感，畢竟SoftwareArchitecture這個(gè)概念也是起源于Architecture。這時(shí)候，架構(gòu)這個(gè)詞就會(huì)給我一種接地氣的感覺：有多少塊磚，每塊磚做什么用、放到哪里去，這塊磚和那塊磚怎么黏在一起或互相支撐。當(dāng)然，由于軟件的可移植性、可復(fù)用性，從某些角度來(lái)講，軟件架構(gòu)相比建筑架構(gòu)有其更復(fù)雜的地方。MVC誕生至今已經(jīng)超過(guò)40年了（Since1979），10多年前就得到過(guò)很廣泛的討論和實(shí)踐，穿越時(shí)空到今天肯定有其反脆弱性和內(nèi)在核心價(jià)值。雖然如今乍看起來(lái)好像已經(jīng)過(guò)氣、被討論過(guò)千百遍了，但仍然有很多程序員會(huì)有不同理解和看法，或多或少。這是很正常的，上面也提到了部分原因，這里具體再展開下。1MVC在經(jīng)典三層架構(gòu)里的位置MVC是一種通用架構(gòu)模式早期PC時(shí)代應(yīng)用在桌面客戶端，后來(lái)在Web時(shí)代變得流行（我以前寫PHP也用過(guò)相關(guān)MVC框架），如今在移動(dòng)互聯(lián)網(wǎng)時(shí)代也得到廣泛應(yīng)用。上面這三個(gè)場(chǎng)景的應(yīng)用，都是面向客戶的，需要交互表現(xiàn)的。從MVC命名中的View（視圖）也可以看出，MVC模式應(yīng)用在軟件系統(tǒng)架構(gòu)里的表現(xiàn)層。在業(yè)界某知名公司的官方文檔里，也明確把MVC放在WebPresentationPatterns下。我之所以沒有在上圖中對(duì)M-V-C添加箭頭線條，是因?yàn)樵谶@一點(diǎn)上，不同程序員也有不同理解和實(shí)踐。這是第一個(gè)需要明確的點(diǎn)：MVC架構(gòu)模式在多層系統(tǒng)架構(gòu)里的應(yīng)用范圍。左側(cè)業(yè)務(wù)表現(xiàn)層-業(yè)務(wù)服務(wù)層-基礎(chǔ)服務(wù)層是移動(dòng)端三層架構(gòu)模式，未涉及到C/S交互；右側(cè)是WebB/S場(chǎng)景的三層架構(gòu)模式。因?yàn)橛行��?yīng)用會(huì)比較簡(jiǎn)單，根本不需要業(yè)務(wù)服務(wù)或基礎(chǔ)服務(wù)層，純粹靠一個(gè)MVC（或者VC）就能交付出一個(gè)Mobile/WebApp；而且在一些業(yè)務(wù)系統(tǒng)里，Web前端/桌面客戶端/移動(dòng)App也可能會(huì)被簡(jiǎn)化為大前端/大終端表現(xiàn)層；所以可能基于不同信息，不同程序員對(duì)此會(huì)有不同認(rèn)知。但隨著用戶終端應(yīng)用的重要性和復(fù)雜度的提升，已經(jīng)從簡(jiǎn)單應(yīng)用發(fā)展到復(fù)雜多團(tuán)隊(duì)協(xié)同的平臺(tái)型或航母級(jí)應(yīng)用，僅靠一個(gè)MVC來(lái)完成交付是不合適的。我們也可以反過(guò)來(lái)想，程序員會(huì)把以下代碼放在客戶端代碼的哪一層：對(duì)Web引擎的擴(kuò)展邏輯。通信協(xié)議的結(jié)構(gòu)定義，以及相應(yīng)的socket連接和通信代碼。一個(gè)業(yè)務(wù)相關(guān)且UI無(wú)關(guān)的平臺(tái)開放能力。Crash捕獲、卡頓監(jiān)控、日志埋點(diǎn)等功能實(shí)現(xiàn)，比如Android在做APM相關(guān)事情時(shí)會(huì)采用AOP方式，利用ASM、AspectJ等方案來(lái)做字節(jié)碼插樁�！�…2業(yè)界基于MVC模式的不同實(shí)踐前面提到不同程序員對(duì)MVC模式的理解和實(shí)踐存在差異業(yè)界大廠亦然，以下會(huì)結(jié)合業(yè)界一些知名且有影響力的公司在MVC模式上的實(shí)踐，做進(jìn)一步的展開討論。知名公司A知名公司A在指導(dǎo)開發(fā)者使用MVC時(shí)，推薦下圖方式：可以看出在他們的實(shí)踐上：Controller可以引用View和Model。View可以引用Model。這里的Model傾向于是Passive。同時(shí)，他們建議：在強(qiáng)類型視圖場(chǎng)景，控制器從模型創(chuàng)建并填充ViewModel實(shí)例，該ViewModel實(shí)例包含要在該視圖上顯示的數(shù)據(jù)。當(dāng)控制器由于責(zé)任過(guò)多而變得過(guò)于復(fù)雜時(shí)，也就是業(yè)界戲稱的“MVCmeansMassiveViewController”，需要將業(yè)務(wù)邏輯從控制器移出并推入域模型中。知名公司B說(shuō)到MassiveViewController，知名公司B在移動(dòng)互聯(lián)網(wǎng)方興未艾的時(shí)候，推薦下圖所示的MVC實(shí)踐方案：上圖呈現(xiàn)出：Controller引用View和Model。Model通過(guò)一些松耦合方式來(lái)觸達(dá)Controller，如廣播通知、callback等，驅(qū)動(dòng)Controller做出響應(yīng)。View通過(guò)代理模式等方案弱依賴Controller，由Controller對(duì)各種用戶操作、UI渲染訴求做出響應(yīng)。而View和Model之間是隔離的，Model變化后對(duì)View的更新操作全部由Controller負(fù)責(zé)。不過(guò)相應(yīng)的官方文檔已經(jīng)被聲明是過(guò)期文檔了，并備注不一定是目前的最佳實(shí)踐。是的，隨著移動(dòng)互聯(lián)網(wǎng)蓬勃發(fā)展，十年前的“最佳實(shí)踐”被一路多種挑戰(zhàn)——在采用這種方案的開發(fā)領(lǐng)域中，如何重構(gòu)MassiveViewController為L(zhǎng)ighterViewController已經(jīng)成為了一個(gè)專題。對(duì)比和思考A和B的異同點(diǎn)相同點(diǎn)：Model包含所需的數(shù)據(jù)結(jié)構(gòu)封裝，以及相應(yīng)數(shù)據(jù)操作的方法定義。即Data+本地或遠(yuǎn)端的CURD。差異點(diǎn)：在知名公司A給的圖中，View可以引用Model，而在知名公司B給的圖中則不行。一些問(wèn)題和思考View有箭頭指向Model，這里的引用關(guān)系是指什么？是View持有Model.Data數(shù)據(jù)對(duì)象，還是View調(diào)用Model.CURD方法。Controller的本意是ControingLogic，那除了ViewController外，是否還可以有其它的XxController，比如DataSourceController、NotificationController？從命名上看，既然ViewController既有View又有Controller，那為什么把它放在C里面，而不放在V里面呢？比如當(dāng)我們?cè)趇OS/Android開發(fā)中引入MVVM模式后，ViewController或Activity屬于M-VM-V的哪部分呢，代碼放在哪個(gè)目錄下呢？我有類名使用ViewModel后綴就代表我使用MVVM模式了嗎？MartinFowler作為《重構(gòu):改善既有代碼的設(shè)計(jì)》、《企業(yè)應(yīng)用架構(gòu)模式》等著作的作者；敏捷軟件開發(fā)宣言創(chuàng)作者之一；MVVM模式誕生時(shí)參考引用的技術(shù)專家。MartinFowler給的MVC模式圖如下：和上面知名公司A和B的圖，又不一樣了，不過(guò)他這里也是認(rèn)為View可以引用Model的。MVC和DDDMartinFowler和《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》作者EricEvans也討論過(guò)MVC中Model的設(shè)計(jì)理念：貧血模型：將Model分為簡(jiǎn)（pin）單（xue）的Model數(shù)據(jù)對(duì)象，和處理操作數(shù)據(jù)對(duì)象的Service/Manager/BizLogic等。示例：為aPerson修改name，則由CitizenService.changeNameOfPerson(aPerson)這種方式來(lái)實(shí)現(xiàn)。充血模型：將對(duì)應(yīng)領(lǐng)域的處理邏輯放到領(lǐng)域模型中，使得這個(gè)領(lǐng)域模型更飽（chong）滿（xue）。示例：aPerson要刷牙，則由aPerson.brushTeeth()來(lái)實(shí)現(xiàn)。補(bǔ)充：充血模型更有面向?qū)ο缶幊痰奈兜�，尤其是搭配交易領(lǐng)域等業(yè)務(wù)場(chǎng)景，更有體感。不過(guò)稍微細(xì)想一下，可能就會(huì)發(fā)現(xiàn)DDD對(duì)設(shè)計(jì)的要求會(huì)更高，從而對(duì)研發(fā)周期和質(zhì)量保障提出了新的要求，并且可能引起對(duì)現(xiàn)有系統(tǒng)的大規(guī)模重構(gòu)。（盒馬的DDD實(shí)踐）也就是說(shuō)，大到MVC各個(gè)模塊的依賴引用關(guān)系，細(xì)到Model中的代碼設(shè)計(jì)方式，業(yè)界都有不同的理念和實(shí)踐。JavaWeb開發(fā)領(lǐng)域也對(duì)Model的設(shè)計(jì)產(chǎn)生過(guò)非常激烈的討論。小結(jié)先拋開具體模塊的代碼設(shè)計(jì)方案，基于以上幾種業(yè)界大廠或?qū)＜业拿枋�，我小結(jié)了以下這張圖并標(biāo)注了待解問(wèn)題：?jiǎn)栴}一：如何解決MVC中Controller的膨脹臃腫問(wèn)題？要回答如何解決，需要先思考為什么膨脹。問(wèn)題二：View能否引用Model？要回答能否引用，需要先定義引用關(guān)系是什么。是持有對(duì)象，還是調(diào)用CURD接口操作對(duì)象。又或者這兩者沒有必要區(qū)分，因?yàn)槌钟械膶?duì)象本身就可能帶CURD接口。參考上面相關(guān)資料，目前業(yè)界有的支持、有的反對(duì)。問(wèn)題三：存在View->Model，那么是否可以反過(guò)來(lái)存在Model->View？和問(wèn)題二在描述上相反但又有關(guān)聯(lián)，如果對(duì)問(wèn)題再進(jìn)一步提問(wèn)的話：使用->引用關(guān)系，是為了解決什么問(wèn)題？使用->引用關(guān)系，會(huì)產(chǎn)生什么問(wèn)題？如同文章開頭所說(shuō)，以上問(wèn)題需要結(jié)合具體場(chǎng)景來(lái)展開（見實(shí)際案例結(jié)合），盡量從務(wù)虛到務(wù)實(shí)。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...

2022-01-09點(diǎn)擊量：185

如今軟件已經(jīng)是大多數(shù)公司的主要組成部分之一，它被整合到所有主要系統(tǒng)中，從金融機(jī)構(gòu)到農(nóng)業(yè)生產(chǎn)，再到客戶服務(wù)和工業(yè)領(lǐng)域。軟件開發(fā)者已經(jīng)成了最受歡迎的職業(yè)之一，事實(shí)上，用幾個(gè)人和幾臺(tái)計(jì)算機(jī)就能完成高影響的項(xiàng)目是可能的，這使得這個(gè)領(lǐng)域吸引了所有那些有絕妙想法并想為他們開發(fā)軟件的人。幸運(yùn)的是，今天我們有了互聯(lián)網(wǎng)，這個(gè)無(wú)限的知識(shí)來(lái)源，成為一名軟件開發(fā)人員完全可以通過(guò)自學(xué)。重要的是要了解從哪里開始，什么是必要的基礎(chǔ)，根據(jù)我的個(gè)人經(jīng)驗(yàn)，編程更多的是一種激情，而不是一份工作，這條道路充滿了障礙和終點(diǎn)，所以重要的是慢慢來(lái)，不斷攻克難關(guān)，一步步走向成功。作為工匠的軟件開發(fā)人員研究表明，與藝術(shù)家在創(chuàng)作階段相比，編程是一種需要更多大腦容量的活動(dòng)。很多時(shí)候，當(dāng)我需要做一些困難或復(fù)雜部分的編程時(shí)，我經(jīng)常需要音樂(lè)和電腦進(jìn)入狀態(tài)，這樣我才能解鎖我的創(chuàng)造力，事實(shí)上，這個(gè)世界需要二者兼?zhèn)�，大多�?shù)時(shí)候，軟件開發(fā)人員等同于工匠，這意味著必須完成從a到Z的工作過(guò)程，為自己的風(fēng)格選擇負(fù)責(zé)。編程語(yǔ)言一個(gè)人學(xué)習(xí)的第一種語(yǔ)言有點(diǎn)像他們的母語(yǔ)，你將越來(lái)越多的減輕讀寫，如果您想要深化應(yīng)用程序的世界，我推薦C或Java，它們是在現(xiàn)實(shí)工作中最常用的編程語(yǔ)言，另一方面，如果你對(duì)數(shù)據(jù)科學(xué)或者網(wǎng)絡(luò)安全感興趣，我建議學(xué)習(xí)Python，Python學(xué)習(xí)起來(lái)非常簡(jiǎn)單，但是由于它是一門高級(jí)語(yǔ)言，你可能會(huì)忽略一些概念關(guān)注基礎(chǔ)知識(shí)軟件開發(fā)在大多數(shù)時(shí)候是一項(xiàng)非常有創(chuàng)造性的工作，但如果一直有沒能解決的Bug存在，那它也可能是乏味的，對(duì)于這一點(diǎn)，在我看來(lái)，無(wú)論你有什么編程經(jīng)驗(yàn)，以下方法都值得你學(xué)習(xí)：CI/CD、DevOps、軟件設(shè)計(jì)、測(cè)試、重構(gòu)等，它們是一組工具、技術(shù)和標(biāo)準(zhǔn)，如果使用得當(dāng)，任何人都能讀懂你的代碼，它們很重要，因?yàn)樗鼈冏屇隳軌蚋�快地發(fā)現(xiàn)并修復(fù)Bug。。如果項(xiàng)目是中等規(guī)模和/或團(tuán)隊(duì)由3個(gè)以上的人組成，那么幾乎必須使用這整個(gè)系列的技術(shù)。不管使用哪種編程語(yǔ)言，了解這些工具以最大化工作效率是很重要的。一點(diǎn)一滴地積累知識(shí)很多時(shí)候，有太多的東西需要學(xué)習(xí)，有很多工具可以做類似的事情，因此在開發(fā)軟件時(shí)，選擇何種工具經(jīng)常會(huì)碰到困難，這一切的原因都在于學(xué)習(xí)的不夠，帶著讓你開始編程的激情學(xué)習(xí)，了解自己的優(yōu)勢(shì)和局限是很重要的，例如，你還不是很熟悉對(duì)象，那么專注于對(duì)象的設(shè)計(jì)或者一開始就想要?jiǎng)?chuàng)建一個(gè)完美的GUI是沒有用的。本文由培訓(xùn)無(wú)憂網(wǎng)長(zhǎng)沙牛耳教育課程顧問(wèn)老師整理發(fā)布，希望能夠?qū)ο朐陂L(zhǎng)沙參加影視動(dòng)漫培訓(xùn)的學(xué)生有所幫助。更多課程信息可關(guān)注培訓(xùn)無(wú)憂網(wǎng)電腦IT培訓(xùn)頻道或添加老師微信：15033336050...