新聞中心
app開發資訊
小程序開發資訊
軟件開發資訊
業界動態
公司動態
聯系我們

了解更多詳細信息請致電

4000-670-790

或給我們留言

在線留言

您所在的位置: 首頁 > 新聞中心 > 軟件開發資訊 >

關于軟件的10個常識,你一定要知道!

作者:深圳軟件開發公司 點擊量: 2020-01-07 10:13
內容導讀: 馬克·安德列森(Marc Andreessen)寫過一篇文章,預言“軟件吞噬世界”,本文列出了管理者應該知道的10個常識:關于軟件,本文認為這是所有管理者都需要知道的10件最重要的事情: ...

  2011年,馬克·安德列森(Marc Andreessen)寫過一篇文章,預言“軟件吞噬世界”。觀點主要有兩個:第一,許多傳統業務正在被軟件公司所取代;第二,所有其他公司都發現,他們所提供的價值越來越多地來自軟件系統。

  在安德森撰寫這篇文章時,市值最大的10家公司中,沒有一家是從事軟件驅動業務的。如今,10家最大的公司中有6家主要由軟件驅動,而其他4家也已經準備好了轉型。

  Stack Overflow和LinkedIn列出非技術公司的軟件工程招聘廣告超過了科技行業本身。這是經濟發展中的一個重大轉變,表明公司正在加強他們的軟件工程實踐。

  會計和軟件,哪一個對公司更重要?本文沒有答案。但是現在許多不認為自己是軟件公司的公司也開始發現:軟件系統是他們運營的一個關鍵組成部分。

  如果CEO和各級管理人員不了解軟件,那么他們將是可有可無的。這要么會限制他們的職業發展,要么會對公司業績產生負面影響。不管怎樣,不了解軟件都注定要失敗。(據Gartner預測,到2020年,有50%的首席信息官(CIO)將被取代,因為他們沒有變革公司的能力。)

軟件常識

  本文列出了管理者應該知道的10個常識:

  關于軟件,本文認為這是所有管理者都需要知道的10件最重要的事情:

  1. 軟件不是魔術

  軟件不是魔術。雖然它看起來像魔術,或者是魔法,但它不是魔法。每一個元素都是由人設計的,都有其數學基礎,或者是可以用人類語言解釋的過程。

  與魔術不同,軟件不是憑空變出來的。它需要設計、構建和維護。就像房子有多種系統一起工作(地基、結構、管道、房間、家具等等)那樣,軟件系統也需要許多層和子系統來創建整個系統。它可以設計得很好,也可以設計得很差,而且快速的設計很少能持久。

  如果人們不能用語言來描述它會做什么(包括想要的結果和如何實現),那么計算機也無法做到。“how”被稱為算法,這并不神奇。

  機器學習和其他人工智能技術也并不神奇。機器學習是基于數據的預測,而不是顯式的規則或指令。它一般是用線性代數來做的。如果有100萬張已知的香蕉照片和100萬張沒有香蕉的照片,一個訓練有素的機器學習系統看一張新照片,會根據它從之前的照片中學到的知識告訴你它看起來像第一組還是第二組,這不是魔術。使用機器學習根據過去的招聘決定對簡歷進行排序,即使沒有任何故意的偏見,也可能會放大經驗主義的招聘歷史。

  2. 軟件永遠不會“完成”

  軟件永遠不會“完成”,軟件是一個迭代的過程,在其生命周期中包含許多修訂和更新。我們的工作是創造一個能認識到這一點的環境。

  同樣,我們從來沒有期望市場營銷和客戶獲取是“完成的”,它們也是迭代過程。在每個迭代中,隨著我們不斷地為業務交付價值,我們也不斷地學習和成長。即使已經做了一些成功的發布,我們從來沒有打算“停止”做這些事情。

  如果軟件可以在一個版本中完成就好了,但這不是現實。需求文檔充滿了模糊性,軟件的第一個版本充滿了“哦,那是我寫的,但不是我的意思”的場景。最好的軟件能激發新的想法和功能需求,看到新的銷售管理系統更加高效,就會激發出更高的效率。世界在變化,競爭對手提供了新的功能,人們就有了新的想法。另外,總是有一些bug需要修復:可能是在代碼中,也可能是在構建代碼的底層軟件框架和系統中。某些軟件可能是完美的,但可以確信的是,隨著時間的推移,人們會發現它所構建的平臺存在各種漏洞。

  我們的工作就是讓一個組織能夠認識到這一點。

  認識到這一點的方法是建立一個有信心定期發布新版本的組織。當完全自動化測試和其他工程規范就位時,我們就建立了信心。這種信心創造了一種能力,可以避免過長的發布周期,而是每季度、每月甚至每周發布高質量的軟件。特定的頻率并不重要,但是信心很重要,自信能夠帶來更快的創新。

  3.軟件開發是團隊作戰,沒有人能做所有事情

  軟件開發是團隊作戰,開發人員既不是產品經理,也不是UX(用戶體驗)設計師,也不是質量工程師、分析師、安全專家、技術作家或運營工程師。組織需要所有角色。

  沒有哪個管理者會建議每個銷售(sale)人員都做營銷(marketing)及PR,否則就解雇銷售團隊(因為營銷人員了解產品,也能做銷售)。營銷和銷售是相關的,但又是不同的。因此,兩者之間存在著分工。

  同樣,開發團隊需要獨立的人員來收集需求、質量保證和測試、代碼編寫等等。

  一個開發人員可以“做所有事情”的神話,稱為“全棧開發人員”或“10x工程師”,這一般只存在于小公司。是的,一個非常小的公司可能一個人同時做營銷和銷售,但你可能不會加入這樣的小公司。

  不要用自己的興趣去挑戰別人吃飯的專業。一個小孩“擅長Facebook”并不意味著他或她會成為下一個扎克伯格;一個小孩對工程學很感興趣并不意味著他或她可以能夠使用微積分;一個小孩能夠自己做了一個網站并不意味著這個網站每小時可以處理數十億的金融交易。

  4. 設計不是外觀,而是工作原理

  史蒂夫·喬布斯有句名言:”設計不只是外表和感覺。設計就是工作原理。“ UX設計師不會坐下來決定菜單的顏色,或者決定按鈕是圓形還是方形,他們決定工作流和交互是什么。

  用戶會看到一個有三個選項的屏幕,還是一個屏幕只顯示一個選項?這個設計決定需要心理學、對用戶的同理心,以及測試、測試、再測試。

  UX設計的最大挑戰之一是,一旦你熟悉了系統,就失去了預測新用戶的能力。設計該系統的人在預測新用戶的需求時將自動被取消資格。UX可能很漂亮、優雅,可以與一件藝術品相媲美,但是請UX設計師將背景更改為帆船的圖片是沒有幫助的。

  我們的工作是信任測試數據而不是主觀臆測,創建一個環境,在產品發布之前計劃進行多次修訂,并期望在產品發布之后進行進一步的改進。不要將UX設計人員與圖形設計人員混淆。讓UX計師設計公司節日賀卡和讓技術作家寫公司通訊是一樣的失禮行為,這些是不同的技能。

  5. 安全是每個人的責任

  不管知不知道,無論愿不愿意,我們都是從事安全行業的。所有軟件都有安全需求和潛在的安全漏洞。開發軟件所涉及的系統也有安全需求和漏洞。雖然防火墻和入侵檢測等安全的基礎設施組件是必要的,但它們還不夠:還必須使用內置的安全控制來設計、實現和維護軟件平臺。安全既是好的技術,也是好的流程。

  如果認為我們不是被攻擊的目標,那就錯了。所有的計算機系統都是被攻擊的目標,因為攻擊不僅是為了其中的信息,而僅僅是它是一臺計算機這樣的一個事實。例如,一個沒有價值信息的系統是網絡攻擊目標,因為它可以被用來轉發對其他計算機的攻擊,或挖掘比特幣,或存儲他人的盜版視頻。

  安全不是打開/關閉這樣按鈕,有許多灰色地帶。安全性最好從一開始考慮。事后的亡羊補牢是昂貴的,而且往往是無效的。我們不會先造一艘船,然后再“添加”一種讓它漂浮的功能。同樣,也無法先構建一個系統,然后按下“具有安全性”按鈕就安全了。

  安全是關于風險和對風險的容忍度。對兩個節點之間的通信進行加密并不能保證它的安全性,但它提高了安全性,只有超級算力才有可能破解密碼。在一個領域降低風險對其他領域沒有幫助。保護網絡并不能防止物理安全問題。一個人撐開一扇門,其他人就能偷走你的備份磁帶。

  正如吉恩·斯帕福德(Gene Spafford)的一句名言:”唯一真正安全的系統,是一個關了電、澆鑄在混凝土里、由全副武裝的警衛把守在絕緣房間里的系統——即便如此,我還是心存疑慮。“

  遵守NIST CSF(國家標準與技術網絡安全框架學會)、PCI DSS(支付卡行業數據安全標準)和SOC 2(服務組織控制報告)等安全標準可以量化風險,如果做得合適,還可以降低風險。這些標準并不能保證絕對安全,絕對安全是不存在的。更重要的是,它們為如何負責任地應對和報告不可避免的安全漏洞提供了指導。誠實、直率、公開是良好的建議。

  軟件,如果不管它,就像面包一樣變得陳舊。我們的工作是平衡安全妄想與現實,并適當預算時間和資源。

  6. feature大小并不能預測開發時間

  feature大小(用戶感知到的)與創建feature所需的時間完全無關。小feature可能需要幾天或幾年的時間,大feature(用戶感知到的)也可能需要幾天或幾年的時間。

  我們的工作是創建并支持一個軟件開發過程,該過程接受這個事實,并且不是拍腦袋評估工程量。工作量評估本身可能需要令人驚訝的很長時間。

  鼓勵通過溝通來解決工作量評估的問題。工程師可能會給出一個令人驚訝的很長時間的工作估算,但是也會提出對需求進行更改,從而大大縮短時間。記住工作量評估要包括測試、培訓、部署和意外的假期(例如病假)。

  在沒有與工程部門協商工作量的情況下,永遠不要承諾某個feature。這并不是我們在公司的權力標志,這需要的是一個專業流程,在這個流程中,開發人員的請求得到認真對待,評估工作量,并按時交付(或出于誠實的原因延期)。

  7. 偉大來自于成千上萬的小進步

  偉大來自于在很長一段時間內所做的成千上萬,也許是數百萬的小進步(變更)。如果變更的效果都被測量是負面的,那么變更將被回滾。

  谷歌也不是一天建成的。谷歌的搜索引擎是數百萬個人改進的結果。搜索質量小組每周開會一次,工程師們走上講臺,提出他們的修改建議。他們展示了在模擬的環境中會有多大的改進,委員會進行辯論并投票表決。幾周后,將對測量結果進行評審,并決定保留或回滾更改。

  谷歌搜索是迭代開發戰勝“數據大爆炸”思維的勝利。誰都不可能在一開始做出一個好的搜索引擎。只有在好萊塢電影中,一個聰明的極客才會想出一個驚人的新點子,并且第一次就能完美地實現它。在現實世界中,一夜成名需要數年的時間。

  無論試圖實現的目標是一個為客戶提供更好服務的系統,還是一個更高效、錯誤更少的系統,還是一個運行更順暢的系統,都是如此。

  我們的工作是要求系統的設計能夠容易擁抱新的變化,并定義相關的KPI(關鍵性能指標),這些KPI可以在更改之前和之后方便地進行度量。最重要的是,必須有一個流程來檢查結果,并決定保留或回滾變更?;貪L不應被視為失敗或受到懲罰。從每次回滾中學到的與在每次保留的更改中學到的一樣有價值。

  托馬斯·愛迪生聲稱在發明燈泡的過程中測試了1000根燈絲。當一位記者問他:”失敗1000次是什么感受?“他回答說:”我沒有失敗1000次。燈泡是一項有1000個步驟的發明。”

  8. 技術債很討厭,但不可避免

  技術債務是將來需要做的工作,因為我們現在選擇了一個更簡單的解決方案,而不是使用一個需要更長時間的更好解決方案。任何合理規模的軟件項目都有技術債務。技術債務讓所有的進步都變得更慢,越忽視它,它就越像滾雪球一樣越滾越大。

  有金融背景的管理者聽到“債務”時,會認為這是一種未來會有回報的投資。技術債務恰恰相反,它是有毒和痛苦的,并且是一個定時炸彈。

  1972年,Fram為它的濾油器做了一個電視廣告,在廣告中,一位汽車機械師解釋說,一位顧客為了節省4美元而不更換濾油器,后來,這位顧客不得不花200美元更換一個昂貴的主軸承。汽車機械師總結說:“你可以現在付給我錢,也可以以后付。”

  有一個軟件項目,其中有一個子系統與供應商通信。最初系統只與一個供應商通信,所以非常簡單。然后又接了一個,然后另一個。有些功能必須實現三次,每個供應商一次,這是不可持續的。當要求支持第四個供應商時,開發人員表示反對。是的,他們可以在大約一個月的時間里把它移植上去,但是軟件架構開始吱吱作響,就像颶風中的老房子一樣。這些權宜之計積累了大量的技術債務。

  開發人員的建議是花兩個月的時間重構供應商架構,使其成為一個插件系統。然后,新的供應商可以在一周內而不是一個月內支持接入。

  管理者們并不高興。為什么下一個供應商需要兩個多月的時間來支持,而之前的供應商是在一個月內支持的呢?花兩個月的時間來償還技術債務將使未來的支持更快,代碼更穩定,并使添加新feature更容易。很難衡量確切的好處。

  “你可以現在付給我,也可以以后再付給我"。

  我們的工作是分期償還技術債務。失控的技術債務降低了添加其他feature的能力,并導致軟件系統不穩定。償還技術債務應該與業務目標掛鉤,類似于非功能需求。

  9. 軟件不會自己運行(軟件需要運維)

  雖然供應商和開發人員可能會試圖告訴你不同的情況,但是軟件并不會自己運行。任何基于軟件的系統(特別是網站和web應用程序)都需要運維人員和運維流程。否則,軟件就像一本合上的書,必須有人打開它,管理它,以及照顧它的需求。

  運維比軟件開發本身更重要。代碼只寫一次,但運行可能會是數百萬次。因此,粗略地衡量一下,運維的重要性是否要高出幾百萬倍呢?

  我們的工作就是期望運維成為任何軟件系統的一部分。它必須像其他任何項目一樣被計劃、預算、管理和有效地運行。

  運維功能(通常稱為非功能需求)對用戶是不可見的,除非作為二級需求。數據備份是非功能需求中一個很好的例子。沒有用戶請求數據備份,但是,用戶確實要求恢復已刪除的數據。遺憾的是,沒有備份就沒有恢復?;謴褪枪δ苄枨?,備份是一種運維(非功能)需求。

  讓軟件服務易于維護或高效運行的功能需求從來不會被用戶提出來。然而,他們確實享受著一個低成本、高可靠的系統所帶來的好處??蛻魰x開那些不靠譜的網站,再也不會回來。

  持續改進的需求不僅包括新功能需求,還應該包括新的非功能性需求。因此,我們的工作不僅是為客戶提出的功能需求分配資源,還要為運維需求分配資源。在兩種相互競爭的需求之間取得平衡是困難的。

  但是,一個成功的產品是業務需求和運維需求的權衡結果。

  10. 復雜的系統需要DevOps才能良好運行

  復雜的系統最好通過DevOps進行改進。DevOps有很多定義,但是DevOps通??醋魇峭ㄟ^快速迭代加速交付價值(feature、bug修復、流程改進等等)。要做到這一點,每個相關人員都必須參與。也就是說,他們必須跨職能團隊進行協作。DevOps這個名字來自于移除開發人員和運維(IT)之間的隔閡,這對于實現快速的發布是絕對必要的。然而,優秀的DevOps環境將其擴展到跨所有職能團隊的端到端工作。

  DevOps被誤解為開發人員來做運維。這種“構建它,運行它”的策略是跨職能團隊工作(消除隔閡)的一種方法,但它不是唯一的方法。

  一個復雜的系統需要三件事:良好的流程、所有相關人員的良好溝通以及嘗試新事物的能力。

創新夢想:www.0522869.live】個性化軟件定制開發專家!提供專業的軟件開發、手機APP開發、微信開發、小程序定制服務!

本文關鍵字: 軟件開發領域知識
上一篇:介紹詳細軟件開發流程
下一篇:沒有了
業務咨詢
咨詢在線客服
合作咨詢
咨詢在線客服

我們的微信

我們的微博

點擊圖標進入幫助中心
v 快递公司是靠什么赚钱的