書(shū)馨卡幫你省薪 2024個(gè)人購(gòu)書(shū)報(bào)告 2024中圖網(wǎng)年度報(bào)告
歡迎光臨中圖網(wǎng) 請(qǐng) | 注冊(cè)
> >
軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本)

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本)

出版社：電子工業(yè)出版社出版時(shí)間：2022-11-01
開(kāi)本： 其他 頁(yè)數(shù)： 288
中 圖 價(jià):¥36.5(4.8折) 定價(jià)  ¥76.0 登錄后可看到會(huì)員價(jià)
加入購(gòu)物車(chē) 收藏
運(yùn)費(fèi)6元，滿39元免運(yùn)費(fèi)
?新疆、西藏除外
溫馨提示：5折以下圖書(shū)主要為出版社尾貨，大部分為全新（有塑封/無(wú)塑封），個(gè)別圖書(shū)品相8-9成新、切口
有劃線標(biāo)記、光盤(pán)等附件不全詳細(xì)品相說(shuō)明>>
本類五星書(shū)更多>

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 版權(quán)信息

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 本書(shū)特色

適讀人群 ：本書(shū)面向的讀者包括軟件工程師和管理者、軟件工程專業(yè)的學(xué)生、軟件工程領(lǐng)域的研發(fā)人員等。1.本版本為【簡(jiǎn)裝本】小冊(cè)，攜帶方便，地鐵、公交、圖書(shū)館、教室、辦公室，一本適合多場(chǎng)景閱讀。 2.一部英文原著亞馬遜4.5高分，暢銷(xiāo)全球26年的領(lǐng)域經(jīng)典——首次落地中國(guó)。 3.用【簡(jiǎn)單原則】講透軟件研發(fā)重要思想——從需求分析到產(chǎn)品演進(jìn)，覆蓋產(chǎn)品研發(fā)全流程。 3.首本實(shí)現(xiàn)【輕閱讀】的研發(fā)字典書(shū)——201個(gè)原則獨(dú)立成文，簡(jiǎn)練深刻，輕松閱讀。 4.百度技術(shù)學(xué)院【指定用書(shū)】——掌握科學(xué)的方法，效率提高不止100%。 5.原則1：質(zhì)量**。原則7：盡早把產(chǎn)品交給客戶。原則39：先確定問(wèn)題，再寫(xiě)需求。原則64：沒(méi)有文檔的設(shè)計(jì)不是設(shè)計(jì)。原則66：不要重復(fù)造輪子。

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 內(nèi)容簡(jiǎn)介

軟件工程是一門(mén)工程學(xué)科，是對(duì)經(jīng)過(guò)驗(yàn)證的原則、技術(shù)、語(yǔ)言和工具的智慧的運(yùn)用，用于有成本效益的創(chuàng)造和維護(hù)能夠滿足用戶需求的軟件。 本書(shū)匯總了軟件工程原則，對(duì)于軟件研發(fā)中的主要思想，以一系列分類原則的方式，給出了總結(jié)。原則是關(guān)于軟件工程的基本原理、規(guī)則或結(jié)論，不管所選的技術(shù)、工具或語(yǔ)言是什么，這些原則都有效。 全書(shū)共9章，第1章為引言，后面8章將201個(gè)軟件工程的原則劃分為8個(gè)大的類別：一般原則、需求工程原則、設(shè)計(jì)原則、編碼原則、測(cè)試原則、管理原則、產(chǎn)品保證原則和演變?cè)瓌t。

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 目錄

★第1章　引言★

★第2章　一般原則★

原則1　質(zhì)量**

原則2　質(zhì)量在每個(gè)人眼中都不同

原則3　開(kāi)發(fā)效率和質(zhì)量密不可分

原則4　高質(zhì)量軟件是可以實(shí)現(xiàn)的

原則5　不要試圖通過(guò)改進(jìn)軟件實(shí)現(xiàn)高質(zhì)量

原則6　低可靠性比低效率更糟糕

原則7　盡早把產(chǎn)品交給客戶

原則8　與客戶/用戶溝通

原則9　促使開(kāi)發(fā)者與客戶的目標(biāo)一致

原則10　做好拋棄的準(zhǔn)備

原則11　開(kāi)發(fā)正確的原型

原則12　構(gòu)建合適功能的原型

原則13　要快速地開(kāi)發(fā)一次性原型

原則14　漸進(jìn)地?cái)U(kuò)展系統(tǒng)

原則15　看到越多，需要越多

原則16　開(kāi)發(fā)過(guò)程中的變化是不可避免的

原則17　只要可能，購(gòu)買(mǎi)而非開(kāi)發(fā)

原則18　讓軟件只需簡(jiǎn)短的用戶手冊(cè)

原則19　每個(gè)復(fù)雜問(wèn)題都有一個(gè)解決方案

原則20　記錄你的假設(shè)

原則21　不同的階段，使用不同的語(yǔ)言

原則22　技術(shù)優(yōu)先于工具

原則23　使用工具，但要?jiǎng)?wù)實(shí)

原則24　把工具交給優(yōu)秀的工程師

原則25　CASE工具是昂貴的

原則26　“知道何時(shí)”和“知道如何”同樣重要

原則27　實(shí)現(xiàn)目標(biāo)就停止

原則28　了解形式化方法

原則29　和組織榮辱與共

原則30　跟風(fēng)要小心

原則31　不要忽視技術(shù)

原則32　使用文檔標(biāo)準(zhǔn)

原則33　文檔要有術(shù)語(yǔ)表

原則34　軟件文檔都要有索引

原則35　對(duì)相同的概念用相同的名字

原則36　研究再轉(zhuǎn)化，不可行

原則37　要承擔(dān)責(zé)任

★第3章　需求工程原則★

原則38　低質(zhì)量的需求分析，導(dǎo)致低質(zhì)量的成本估算

原則39　先確定問(wèn)題，再寫(xiě)需求

原則40　立即確定需求

原則41　立即修復(fù)需求規(guī)格說(shuō)明中的錯(cuò)誤

原則42　原型可降低選擇用戶界面的風(fēng)險(xiǎn)

原則43　記錄需求為什么被引入

原則44　確定子集

原則45　評(píng)審需求

原則46　避免在需求分析時(shí)進(jìn)行系統(tǒng)設(shè)計(jì)

原則47　使用正確的方法

原則48　使用多角度的需求視圖

原則49　合理地組織需求

原則50　給需求排列優(yōu)先級(jí)

原則51　書(shū)寫(xiě)要簡(jiǎn)潔

原則52　給每個(gè)需求單獨(dú)編號(hào)

原則53　減少需求中的歧義

原則54　對(duì)自然語(yǔ)言輔助增強(qiáng)，而非替換

原則55　在更形式化的模型前，先寫(xiě)自然語(yǔ)言

原則56　保持需求規(guī)格說(shuō)明的可讀性

原則57　明確規(guī)定可靠性

原則58　應(yīng)明確環(huán)境超出預(yù)期時(shí)的系統(tǒng)行為

原則59　自毀的待定項(xiàng)

原則60　將需求保存到數(shù)據(jù)庫(kù)

★第4章　設(shè)計(jì)原則★

原則61　從需求到設(shè)計(jì)的轉(zhuǎn)換并不容易

原則62　將設(shè)計(jì)追溯至需求

原則63　評(píng)估備選方案

原則64　沒(méi)有文檔的設(shè)計(jì)不是設(shè)計(jì)

原則65　封裝

原則66　不要重復(fù)造輪子

原則67　保持簡(jiǎn)單

原則68　避免大量的特殊案例

原則69　縮小智力距離

原則70　將設(shè)計(jì)置于知識(shí)控制之下

原則71　保持概念一致

原則72　概念性錯(cuò)誤比語(yǔ)法錯(cuò)誤更嚴(yán)重

原則73　使用耦合和內(nèi)聚

原則74　為變化而設(shè)計(jì)

原則75　為維護(hù)而設(shè)計(jì)

原則76　為防備出現(xiàn)錯(cuò)誤而設(shè)計(jì)

原則77　在軟件中植入通用性

原則78　在軟件中植入靈活性

原則79　使用高效的算法

原則80　模塊規(guī)格說(shuō)明只提供用戶需要的所有信息

原則81　設(shè)計(jì)是多維的

原則82　優(yōu)秀的設(shè)計(jì)出自優(yōu)秀的設(shè)計(jì)師

原則83　理解你的應(yīng)用場(chǎng)景

原則84　無(wú)須太多投資，即可實(shí)現(xiàn)復(fù)用

原則85　“錯(cuò)進(jìn)錯(cuò)出”是不正確的

原則86　軟件可靠性可以通過(guò)冗余來(lái)實(shí)現(xiàn)

★第5章　編碼原則★

原則87　避免使用特殊技巧

原則88　避免使用全局變量

原則89　編寫(xiě)可自上而下閱讀的程序

原則90　避免副作用

原則91　使用有意義的命名

原則92　程序首先是寫(xiě)給人看的

原則93　使用*優(yōu)的數(shù)據(jù)結(jié)構(gòu)

原則94　先確保正確，再提升性能

原則95　在寫(xiě)完代碼之前寫(xiě)注釋

原則96　先寫(xiě)文檔后寫(xiě)代碼

原則97　手動(dòng)運(yùn)行每個(gè)組件

原則98　代碼審查

原則99　你可以使用非結(jié)構(gòu)化的語(yǔ)言

原則100　結(jié)構(gòu)化的代碼未必是好的代碼

原則101　不要嵌套太深

原則102　使用合適的語(yǔ)言

原則103　編程語(yǔ)言不是借口

原則104　編程語(yǔ)言的知識(shí)沒(méi)那么重要

原則105　格式化你的代碼

原則106　不要太早編碼

★第6章　測(cè)試原則★

原則107　依據(jù)需求跟蹤測(cè)試

原則108　在測(cè)試之前早做測(cè)試計(jì)劃

原則109　不要測(cè)試自己開(kāi)發(fā)的軟件

原則110　不要為自己的軟件做測(cè)試計(jì)劃

原則111　測(cè)試只能揭示缺陷的存在

原則112　雖然大量的錯(cuò)誤可證明軟件毫無(wú)價(jià)值，但是零錯(cuò)誤并不能說(shuō)明軟件的價(jià)值

原則113　成功的測(cè)試應(yīng)發(fā)現(xiàn)錯(cuò)誤

原則114　半數(shù)的錯(cuò)誤出現(xiàn)在15%的模塊中

原則115　使用黑盒測(cè)試和白盒測(cè)試

原則116　測(cè)試用例應(yīng)包含期望的結(jié)果

原則117　測(cè)試不正確的輸入

原則118　壓力測(cè)試必不可少

原則119　大爆炸理論不適用

原則120　使用 McCabe 復(fù)雜度指標(biāo)

原則121　使用有效的測(cè)試完成度標(biāo)準(zhǔn)

原則122　達(dá)成有效的測(cè)試覆蓋

原則123　不要在單元測(cè)試之前集成

原則124　測(cè)量你的軟件

原則125　分析錯(cuò)誤的原因

原則126　對(duì)“錯(cuò)”不對(duì)人

★第7章　管理原則★

原則127　好的管理比好的技術(shù)更重要

原則128　使用恰當(dāng)?shù)姆椒?

原則129　不要相信你讀到的一切

原則130　理解客戶的優(yōu)先級(jí)

原則131　人是成功的關(guān)鍵

原則132　幾個(gè)好手要強(qiáng)過(guò)很多生手

原則133　傾聽(tīng)你的員工

原則134　信任你的員工

原則135　期望優(yōu)秀

原則136　溝通技巧是必要的

原則137　端茶送水

原則138　人們的動(dòng)機(jī)是不同的

原則139　讓辦公室保持安靜

原則140　人和時(shí)間是不可互換的

原則141　軟件工程師之間存在巨大的差異

原則142　你可以優(yōu)化任何你想要優(yōu)化的

原則143　隱蔽地收集數(shù)據(jù)

原則144　每行代碼的成本是沒(méi)用的

原則145　衡量開(kāi)發(fā)效率沒(méi)有完美的方法

原則146　剪裁成本估算方法

原則147　不要設(shè)定不切實(shí)際的截止時(shí)間

原則148　避免不可能

原則149　評(píng)估之前先要了解

原則150　收集生產(chǎn)力數(shù)據(jù)

原則151　不要忘記團(tuán)隊(duì)效率

原則152　LOC/PM與語(yǔ)言無(wú)關(guān)

原則153　相信排期

原則154　精確的成本估算并不是萬(wàn)無(wú)一失的

原則155　定期重新評(píng)估排期

原則156　輕微的低估不總是壞事

原則157　分配合適的資源

原則158　制訂詳細(xì)的項(xiàng)目計(jì)劃

原則159　及時(shí)更新你的計(jì)劃

原則160　避免駐波

原則161　知曉十大風(fēng)險(xiǎn)

原則162　預(yù)先了解風(fēng)險(xiǎn)

原則163　使用適當(dāng)?shù)牧鞒棠Ｐ?

原則164　方法無(wú)法挽救你

原則165　沒(méi)有奇跡般提升效率的秘密

原則166　了解進(jìn)度的含義

原則167　按差異管理

原則168　不要過(guò)度使用你的硬件

原則169　對(duì)硬件的演化要樂(lè)觀

原則170　對(duì)軟件的進(jìn)化要悲觀

原則171　認(rèn)為災(zāi)難是不可能的想法往往導(dǎo)致災(zāi)難

原則172　做項(xiàng)目總結(jié)

★第8章　產(chǎn)品保證原則★

原則173　產(chǎn)品保證并不是奢侈品

原則174　盡早建立軟件配置管理過(guò)程

原則175　使軟件配置管理適應(yīng)軟件過(guò)程

原則176　組織SCM獨(dú)立于項(xiàng)目管理

原則177　輪換人員到產(chǎn)品保證組織

原則178　給所有中間產(chǎn)品一個(gè)名稱和版本

原則179　控制基準(zhǔn)

原則180　保存所有內(nèi)容

原則181　跟蹤每一個(gè)變更

原則182　不要繞過(guò)變更控制

原則183　對(duì)變更請(qǐng)求進(jìn)行分級(jí)和排期

原則184　在大型開(kāi)發(fā)項(xiàng)目中使用確認(rèn)和驗(yàn)證

★第9章　演變?cè)瓌t★

原則185　軟件會(huì)持續(xù)變化

原則186　軟件的熵增加

原則187　如果沒(méi)有壞，就不要修理它

原則188　解決問(wèn)題，而不是癥狀

原則189　先變更需求

原則190　發(fā)布之前的錯(cuò)誤也會(huì)在發(fā)布之后出現(xiàn)

原則191　一個(gè)程序越老，維護(hù)起來(lái)越困難

原則192　語(yǔ)言影響可維護(hù)性

原則193　有時(shí)重新開(kāi)始會(huì)更好

原則194　首先翻新*差的

原則195　維護(hù)階段比開(kāi)發(fā)階段產(chǎn)生的錯(cuò)誤更多

原則196　每次變更后都要進(jìn)行回歸測(cè)試

原則197　“變更很容易”的想法，會(huì)使變更更容易出錯(cuò)

原則198　對(duì)非結(jié)構(gòu)化代碼進(jìn)行結(jié)構(gòu)化改造，并不一定會(huì)使它更好

原則199　在優(yōu)化前先進(jìn)行性能分析

原則200　保持熟悉

原則201　系統(tǒng)的存在促進(jìn)了演變


展開(kāi)全部

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 節(jié)選

★原則1　質(zhì)量**★ 無(wú)論如何定義質(zhì)量，客戶都不會(huì)容忍低質(zhì)量的產(chǎn)品。質(zhì)量必須被量化，并建立可落地實(shí)施的機(jī)制，以促進(jìn)和激勵(lì)質(zhì)量目標(biāo)的達(dá)成。即使質(zhì)量沒(méi)達(dá)到要求，也要按時(shí)交付產(chǎn)品，這似乎是政治正確的行為，但這是短視的。從中長(zhǎng)期來(lái)看，這樣做是自殺。質(zhì)量必須被放在首位，沒(méi)有可商量的余地。Edward Yourdon建議，當(dāng)你被要求加快測(cè)試、忽視剩余的少量bug、在設(shè)計(jì)或需求達(dá)成一致前就開(kāi)始編碼時(shí)，要直接說(shuō)“不”。 ★原則7　盡早把產(chǎn)品交給客戶★ 在需求階段，無(wú)論你多么努力地試圖去了解客戶的需求，都不如給他們一個(gè)產(chǎn)品，讓他們使用它，這是確定他們真實(shí)需求的*有效方法。如果遵循傳統(tǒng)的瀑布式開(kāi)發(fā)模型，那么在99% 的開(kāi)發(fā)資源已經(jīng)耗盡之后，才會(huì)**次向客戶交付產(chǎn)品。如此一來(lái)，大部分的客戶需求反饋將發(fā)生在資源耗盡之后。 和以上方法相反，可在開(kāi)發(fā)過(guò)程的早期構(gòu)建一個(gè)快速而粗糙的原型。將這個(gè)原型交付給客戶，收集反饋，然后編寫(xiě)需求規(guī)格說(shuō)明并進(jìn)行正規(guī)的開(kāi)發(fā)。使用這種方法，當(dāng)客戶體驗(yàn)到產(chǎn)品的**個(gè)版本時(shí)，只消耗了 5%～20% 的開(kāi)發(fā)資源。如果原型包含合適的功能，就可以更好地理解和把握*有風(fēng)險(xiǎn)的客戶需求，*終產(chǎn)品也就更有可能讓客戶滿意。這有助于確保將剩余的資源用于開(kāi)發(fā)正確的系統(tǒng)。 ★原則39　先確定問(wèn)題，再寫(xiě)需求★ 當(dāng)面對(duì)他們認(rèn)定的問(wèn)題時(shí)，大多數(shù)工程師都會(huì)匆忙提供解決方案。如果工程師對(duì)這個(gè)問(wèn)題的看法是正確的，那么解決方案可能奏效。然而，問(wèn)題往往是難以捉摸的。例如，唐納德·高斯（Donald Gause）和杰拉爾德·溫伯格（Gerald Weinberg）描述了高層辦公樓中的一個(gè)“問(wèn)題”，里面的住戶抱怨電梯等待時(shí)間太長(zhǎng)。這真的是一個(gè)問(wèn)題嗎？這是誰(shuí)的問(wèn)題？從居住者的角度來(lái)看，問(wèn)題可能是浪費(fèi)了他們太多時(shí)間。從房主的角度來(lái)看，問(wèn)題可能是入住率（及租金）可能會(huì)下降。 顯而易見(jiàn)的解決辦法是提高電梯的速度。但其他解決方法可能包括（1）增加新電梯，（2）錯(cuò)峰安排上班時(shí)間，（3）給快遞保留一些電梯，（4）提高租金（這樣業(yè)主可以接受降低后的入住率），（5）改進(jìn)電梯使用的“歸位算法”（homing algorithm），以便在閑置時(shí)移動(dòng)到高需求樓層。這些解決方案的成本、風(fēng)險(xiǎn)和時(shí)間延遲差別巨大。而任何一個(gè)方案生效，都取決于特定的場(chǎng)景。在試圖解決問(wèn)題前，針對(duì)面臨問(wèn)題的人及問(wèn)題的本質(zhì)，要確保深入分析了所有的可能選擇。在解決問(wèn)題時(shí)，不要被*初方案帶來(lái)的潛在興奮所蒙蔽。方案的變化總是比構(gòu)建系統(tǒng)的成本低。 ★原則64　沒(méi)有文檔的設(shè)計(jì)不是設(shè)計(jì)★ 我經(jīng)常聽(tīng)到軟件工程師說(shuō)，“我已經(jīng)完成了設(shè)計(jì)，剩下的工作就是寫(xiě)文檔了”。這種做法毫無(wú)道理。你能想象一個(gè)建筑設(shè)計(jì)師說(shuō), “我已經(jīng)完成了你新家的設(shè)計(jì)，剩下的工作就是把它畫(huà)出來(lái)”，或者一個(gè)小說(shuō)家說(shuō)，“我已經(jīng)完成了這部小說(shuō)，剩下的工作就是把它寫(xiě)下來(lái)”？ 設(shè)計(jì)，是在紙或其他媒介上，對(duì)恰當(dāng)?shù)捏w系結(jié)構(gòu)和算法的選擇、抽象和記錄。 ★原則66　不要重復(fù)造輪子★ 當(dāng)電子工程師設(shè)計(jì)新的印刷電路板時(shí)，他們會(huì)查閱可用集成電路的目錄，以選擇*合適的組件。當(dāng)電子工程師設(shè)計(jì)新的集成電路時(shí)，他們會(huì)查閱標(biāo)準(zhǔn)單元的目錄。當(dāng)建筑師設(shè)計(jì)新房屋時(shí)，他們會(huì)查閱預(yù)制門(mén)窗、飾條和其他組件的目錄。所有這些都被稱為“工程”。 軟件工程師經(jīng)常一次又一次地重新發(fā)明組件。他們很少修補(bǔ)已有的軟件組件。有趣的是，軟件業(yè)稱這種罕見(jiàn)的實(shí)踐為“復(fù)用”，而不是“工程”。 ★原則92　程序首先是寫(xiě)給人看的★ 在計(jì)算機(jī)時(shí)代早期，計(jì)算機(jī)處理速度相對(duì)較慢，任何能夠減少一些指令操作的事情都值得去做。在非常昂貴的計(jì)算機(jī)系統(tǒng)上，*有效地利用資源是主要目標(biāo)。如今形勢(shì)發(fā)生了變化，F(xiàn)在*有價(jià)值的資源是人力：開(kāi)發(fā)軟件的人力、維護(hù)軟件的人力和提高軟件能力的人力。除了非常少數(shù)的例外場(chǎng)景，程序員應(yīng)該首先考慮的是，后續(xù)需要嘗試?yán)斫夂瓦m配軟件的人員。任何能夠幫助他們的事情都應(yīng)該去做（原則 87 到 91 會(huì)提供一些幫助）。執(zhí)行效率也很重要（見(jiàn)原則63、79、94），但它們并不是互斥的。如果你需要執(zhí)行效率，這沒(méi)問(wèn)題，但要提升程序的可讀性，以免在這個(gè)過(guò)程中對(duì)相關(guān)人員造成負(fù)面影響。 ★原則104　編程語(yǔ)言的知識(shí)沒(méi)那么重要★ 不管使用哪種語(yǔ)言，優(yōu)秀的程序員都是優(yōu)秀的。不管使用哪種語(yǔ)言，糟糕的程序員仍然是糟糕的。不可能有一個(gè)人是“優(yōu)秀的C程序員”，同時(shí)是“糟糕的Ada程序員”。如果他確實(shí)在Ada語(yǔ)言上表現(xiàn)得很糟糕，那大概率在C語(yǔ)言上也不會(huì)表現(xiàn)得很好！除此之外，一個(gè)真正優(yōu)秀的程序員應(yīng)該可以很容易地學(xué)會(huì)一種新語(yǔ)言。這是因?yàn)橐粋(gè)真正優(yōu)秀的程序員很好地理解和贊賞高質(zhì)量編程的概念，而不只是了解某些編程語(yǔ)言的語(yǔ)法和語(yǔ)義特性。 所以，為一個(gè)項(xiàng)目選擇語(yǔ)言的首要驅(qū)動(dòng)力應(yīng)該是什么語(yǔ)言更合適（見(jiàn)原則102），而不是程序員都在抱怨“我們只知道C語(yǔ)言”。如果由于項(xiàng)目選擇了其他語(yǔ)言而導(dǎo)致一些人退出，那么這個(gè)項(xiàng)目很可能會(huì)更好！

軟件開(kāi)發(fā)的201個(gè)原則(必讀經(jīng)典簡(jiǎn)裝本) 作者簡(jiǎn)介

★作者介紹★ Alan M. Davis是一名計(jì)算機(jī)科學(xué)家，他的職業(yè)生涯大約有一半在工業(yè)界，一半在學(xué)術(shù)界。 他在工業(yè)界的經(jīng)歷包括： Offtoa公司的聯(lián)合創(chuàng)始人兼首席執(zhí)行官，這是一家?guī)椭髽I(yè)家制定商業(yè)戰(zhàn)略的互聯(lián)網(wǎng)公司（2012年至今）。 Omni-Vista公司的聯(lián)合創(chuàng)始人、董事長(zhǎng)兼首席執(zhí)行官，這是一家位于科羅拉多斯普林斯的軟件公司（1998—2002）。 他在學(xué)術(shù)界的經(jīng)歷包括： 位于丹佛的科羅拉多大學(xué)行政MBA創(chuàng)業(yè)教授，前任學(xué)術(shù)主席（2006—2018）。 科羅拉多大學(xué)斯普林斯分校的商業(yè)策略與企業(yè)家精神專業(yè)的教授，前El Pomar軟件工程教授（1991—2015）。 Davis博士在1994年至1998年擔(dān)任《IEEE 軟件》的主編；在全球28個(gè)國(guó)家或地區(qū)演講2000余次，并撰寫(xiě)了9本圖書(shū)；他自1994年起成為IEEE會(huì)士；曾多次訪問(wèn)中國(guó)，其中包括領(lǐng)導(dǎo)EMBA學(xué)生小組三度赴上海、北京出訪。 ★譯者介紹★ 本書(shū)譯者均為百度內(nèi)部培訓(xùn)項(xiàng)目“代碼的藝術(shù)訓(xùn)練營(yíng)”的學(xué)員。出于對(duì)本書(shū)的熱愛(ài)和推廣優(yōu)秀軟件工程理念的使命，大家自發(fā)組織起來(lái)，利用業(yè)務(wù)時(shí)間完成了本書(shū)的翻譯。翻譯小組的成員包括：葉王，馬學(xué)翔，吳斌，王冰清，楊光，曾浩浩，李殿斌，甘璐，李子昂，肖遠(yuǎn)昊，賈儒，王瑩，張苗，李雙婕，榮文升。 大家很高興能夠在百度完成這件非常有意義的工作。

暫無(wú)評(píng)論……
書(shū)友推薦
返回頂部
中圖網(wǎng)
在線客服