當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

软件开发需求文档案例_第2部分：开发软件需求，一个案例研究

發布時間：2023/12/10 编程问答 43 豆豆

生活随笔收集整理的這篇文章主要介紹了软件开发需求文档案例_第2部分：开发软件需求，一个案例研究小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

軟件開發需求文檔案例

這是4部分系列的第2部分。第1部分：為什么“現實世界中的軟件需求很難” 討論了開發需求的挑戰以及好的需求。這篇文章著眼于需求開發過程及其在實際項目中的輸出。

TL; DR

優先考慮運輸軟件以引出實際需求的敏捷方法與優先考慮先期需求工程的瀑布方法之間的熟悉的二分法過于簡單。在這些極點之間，存在一種用于開發需求的中間方法，該方法易于實施，并且可以更好地為用戶和利益相關者帶來價值。這種方法的功能和優點包括：

定義一個迭代的需求開發過程，生成標準并達成一致的輸出，并與更廣泛的敏捷交付方法集成
利用廉價的實驗（例如快速原型制作）以循證的方式快速進行，而無需交付功能全面的軟件
使用層次結構（通常與需求工程相關聯）在適當的抽象級別為用戶和涉眾提供有用的上下文
選擇性地填充層次結構（不一定是自上而下的），以便開發團隊和其他人員擁有他們需要的背景，以便進行調整并做出更好的決策。

視覺教練

Vision Coach是我將用作該主題的一種實際項目。這是我的團隊與拜耳醫療保健合作建立的一個平臺，用于患有糖尿病性黃斑水腫（DME / DMO）的眼病患者和醫生的治療。 DME影響全球約2100萬糖尿病患者，并且是工作年齡成人失明的主要原因。

拜耳醫療保健提供的一種療法是眼科醫生用來改善患有DME等視網膜疾病的人的視力的一種療法。盡管存在視力障礙的情況，但是患者對治療的依從性差，這意味著視力結果通常不是最佳的。解決該問題成為該項目的重點。

為簡便起見，我始終使用傳統術語，例如“需求，啟發，規范”。盡管并不完美（將假設稱為“要求”很奇怪嗎？），但它們具有熟悉的優勢。

需求方法

關于如何滿足需求的爭論通常集中在我稱之為分析癱瘓和迭代崇拜的兩種對立的方法上。分析癱瘓說，您必須在任何編碼開始之前就預先提出并指定需求，它們必須具有一組完美的屬性（一致性，缺乏歧義性，完整性等），如果這需要花費數周甚至數月的精力，就這樣吧。

迭代崇拜則相反-得出需求的最佳方法是構建某些東西并與用戶進行測試。用戶不知道他們想要什么，或者至少不能總是清楚地表達出自己的想法，直到向他們提供工作軟件后，他們的真正需求才出現。因此，預先規范是浪費時間。

從廣義上講，這描述了需求開發的瀑布式和敏捷方法。兩者是相反的，通常假設您是站在另一側。那你站在哪一邊？

好吧，顯然您并不處于Analysis癱瘓狀態。花費大量時間從利益相關者那里獲取需求，使它們在開始編碼之前是一致的，完整的，可測試的（以及其他所有需求），在面對不確定性和變化的情況下是徒勞的，而成功完成的一切只是增加失敗和學習的成本。

像大多數團隊一樣，如果您需要失敗并學習很多東西，那就不好了。哦，事實證明它行不通-Standish Group的Chaos調查是經常被證明的一種來源。

這意味著您處于迭代崇拜方面，對嗎？嗯，不，至少不是因為這里已被描述（或諷刺？）。這種方法也有問題。首先，如果沒有第一個交付給用戶的軟件就無法說出任何與需求有關的寶貴信息，這是完全不對的-使用線框圖工具進行快速原型制作是一種能夠在編碼開始之前為需求提供有用證據的技術。

其次，迭代實際上并不便宜-當然，它們比提供軟件瀑布式樣式便宜，但與快速原型制作等技術相比，它們仍然昂貴。

第三，如果您真的不花時間來定義需求，那么您構建的內容可能會離目標更遠，因此需要進行更多的迭代才能達到目標。

我們的方法介于兩者之間-預先結合了一些規范，并早日附帶了工作軟件，以在更高保真度的實驗中引起用戶的進一步要求。

流程和層次

在第1部分中，我確定了需求開發流程及其輸出的一些關鍵屬性-例如，它需要協作，迭代，并且需要針對不同的受眾量身定制其輸出。除此之外，定義流程和確定用于優化輸出的技術將很有幫助。

圖1顯示了我們遵循的過程。它包括四個活動：

啟發 -使用各種技術從用戶和利益相關者中提取需求
分析 -了解要解決的基本問題，完善用戶和利益相關者的要求，并將其與系統要求結合
規范 -使用層次結構和約定的模板制定需求，并記錄下來
驗證 -驗證要求的準確性與所提供證據的準確性一樣，一旦實施便可以驗證。

圖1 。需求開發流程（改編自Wiegers＆Beatty，軟件需求，第三版）。

該過程是反復進行的，涉及經常在同一會話中在不同活動之間來回移動，這意味著更快的反饋循環和更好的輸出。它還涉及客戶利益相關者的審核和批準決策點，這是開始任何編碼之前所必需的。除此之外，它還集成到了我們用于交付項目的更廣泛的Scrum流程中，包括2周的沖刺，每日站立，在沖刺結束時進行客戶展示和回顧，以及在下一個開始時進行計劃。

此外，我們定義了一個層次結構，該層次結構由圖2中所示的級別組成。

為什么要定義層次結構？不同的人需要在不同的抽象級別捕獲不同的信息。在Vision Coach上，客戶利益相關者花了一些時間檢查視覺，范圍，用戶故事和高級功能，但對技術設計或任務不感興趣。

交付團隊還需要決策的上下文，明智的層次結構可以提供決策的上下文。

圖2 。需求層次結構。

定義層次結構是容易的部分。填充它比較耗時，但是考慮到我們不在分析癱瘓游戲中，并且只有一個小團隊，因此填充的數量僅是我們前進所需的數量。最初，這涉及在愿景和范圍級別進行更多的工作，以使項目獲得綠色，然后在較低級別進行。

重要的是，我們并沒有始終從上至下填充層次結構，這是一個很好的例子，即范圍的更改，如果我們的用戶故事和任務符合現有功能和非功能性要求并且沒有足夠的爭議性或復雜，需要技術設計。

也就是說，我們將層次結構更多地用作指導而非可強制執行的架構-當我們需要在適當的抽象級別上生成需求時，它可以幫助我們構造需求。

啟發

醫療保健很復雜。有很多利益相關者，通常以復雜的方式聯系在一起。這些包括患者，醫生，診所，醫院，付款人，監管者……清單很廣。與所有人直接接觸是不切實際的，因此您要創建代表代理，這就是我們在這里采用的方法。

需求和約束（置于需求上的條件）來自大量利益相關者群體。這里是主要的（還有其他！）：

用戶數

患者。患者通常處于工作年齡（55歲或以上），已經患有糖尿病多年，并且隨著疾病的發展開始出現DME等并發癥。與該小組的直接互動受到嚴格法規的約束（稍后會詳細介紹），這使用戶測試比平時更加??困難。
醫生。這些醫生是眼科醫生（專科眼科醫生），他們與其他醫生，技術人員和管理人員在獨立診所或醫院內診所中的其他醫生，技術人員和管理人員團隊一起工作，既有公共場所也有私人場所。
診所和醫院 。醫生治療患者的組織。較大的組織具有完善的公司職能，例如IT，臨床治理和信息治理，所有這些都有需求。

客戶端功能

市場營銷 。全球眼科營銷團隊委托并管理了該項目。他們有與業務優先級和證據使用（定性和定量研究）有關的要求，以指導我們的工作。
IT 。政策和程序中記錄的業務規則規定了工作方式，有時還要求使用特定技術。要求涵蓋了諸如設計準則，Cookie，用戶同意，Web分析和證書管理之類的內容。
安全性 。系統存儲可識別的患者數據，這些數據需要嚴格的控制。安全要求被提煉為供應商安全評估。另外，我們收到了有關外部筆測試，使用指定供應商的分布式拒絕服務（DDoS）保護以及針對信息安全的ISO27001標準認證的要求。
合規性 。 Vision Coach必須經過法律，醫學和監管（LMR）符合性審查，然后才能被患者和醫生使用。這涉及針對這些不同領域的要求進行全球和本地審核。評論通常會引起新的要求。

客戶供應商

翻譯社 。該機構將全球英語副本翻譯成12種翻譯和本地化版本，對所使用的技術和流程有要求和約束。

我們

交付團隊 。我們是一個小團隊，擔當許多角色：開發人員，測試人員，DevOps，技術架構師，產品所有者（PO），項目經理，用戶體驗（UX），UI設計和臨床領域專家。 PO和UX潛在客戶提出了要求。

對于客戶，我們在全球范圍內創建了一個核心團隊，代表整個企業的關鍵客戶職能。我們從該小組中提出了要求，如果我們需要與其他利益相關者（例如，醫療器械法規或數據隱私等領域的專家）進行交流，則可以通過此團隊來促進。

對于患者和醫生而言，誘因變得更加復雜，因為制藥公司（及其供應商）受到嚴格的法規和與他們進行溝通的內部流程的約束，這意味著用戶測試并不容易，快速或便宜。

幸運的是，首先，我們可以在內部獲得臨床專業知識，并且能夠依靠廣泛的市場研究和對先前具有相似原型的患者進行用戶測試。在持續的基礎上，我們通過觀察，訪談，講習班，使用原型進行測試（針對不同的保真度構建）和臨時跟進來提出需求。

分析，規范和驗證

采購結果由PO和UX主管記錄，通常一開始通常是非結構化注釋，然后回放給客戶利益相關方進行審核和批準。然后，這些由PO整理，并轉換為用戶故事（在我們的層次結構中為2級），并使用商定的模板記錄在Jira票證中，其中包括：

敏捷的用戶故事，形式為“作為[用戶類型]，我想要[某些目標]，以便[某些原因]”
解釋要求為何如此重要的背景/理由
使用Gherkin的步驟語法接受標準，涵蓋主要目標和替代目標
鏈接到線框，UI設計和其他相關工件。

與內部交付團隊的討論始于積壓的改進會議，其目的是改進故事，確定接受標準，并通過功能，非功能性要求，技術設計和任務來增強它們（級別3-5）。

討論在計劃中結束了，我們在其中編制了一份沖刺積壓的需求清單，以滿足我們的“就緒定義”。通常由于復雜性而引起的對技術設計的分歧是進一步設計工作的線索，我們在sprint期間的設計會議上做了這些工作。

在所有這些會議中，PO在適當的領域專家的支持下，代表用戶和客戶利益相關者代表開發人員，幫助他們回答問題并指導他們的決策。

這是我們在層次結構中的3-5級上指定工件的方式：

在Jira史詩中高層捕獲了功能和非功能需求 （NFR；級別3），并附有簡要說明以及與線框，設計等的鏈接，并用于對相關的用戶故事進行分組。我們使用與技術設計相同的方法將NFR記錄為單獨的文檔（請參閱下一個項目符號），并在用戶案例中使用了接受標準來幫助他們盡早浮出水面。
技術設計 （第4級）由散文和圖表組成，并記錄在reStructuredText和PlantUML中，存儲在git repo中，并使用Sphinx和Read the Docs主題呈現為靜態html，并帶有在我們的文檔中創建的托管文檔的鏈接。吉拉項目。如今，我們已經大大改變了文檔堆棧，但是我們仍然非常喜歡文檔編碼方法。
任務（第5級）在Jira中被記錄為用戶故事父票證的子任務，通常采用范圍內和范圍外的工作清單的形式。這增加了故事的接受標準的粒度，使我們能夠驗證故事是否已完成（過程中驗證步驟的一部分）。

范例要求

讓我們看一下從為患者移動應用程序入職以來層次結構的垂直縱斷面，看看輸出結果如何。它包含了適用于全球平臺以及僅適用于患者應用程序入門的各種內容。

視野和范圍（1級）

我們用這個簡潔的模板（最初來自Geoffrey Moore的Crossing the Chasm），以簡潔地捕獲視覺和范圍：

對于糖尿病眼病患者（目標用戶）
誰通常不堅持治療（需要或機會的陳述）
遠景教練服務（產品名稱）
是移動應用（產品類別）
這提供了對關鍵健康數據的訪問，有助于理解數據以及采取措施改善依從性，視力結果和總體健康的工具（關鍵優勢）
與其他針對糖尿病患者的應用不同（主要競爭替代品）
除了潛在的糖尿病外， 我們的產品還解決了糖尿病眼病（原發性分化的陳述）

用戶案例（第2級）

入門史詩將所有用戶故事收集在一起進行入門，其中包括兩個獨立的流程-注冊和登錄。圖3顯示了兩個流程中的故事的屏幕快照-基于SMS的一次性密碼（OTP）驗證。它使用上述模板，并具有涵蓋主要目標和替代目標的接受標準。

圖3 。在注冊過程中用于帳戶驗證的示例用戶案例

功能和非功能要求（級別3）

特征

入門功能是在Jira史詩中捕獲的，作為單獨的注冊和登錄流程的列表。

注冊：

確認地區和語言
同意條款和條件
輸入電話號碼
驗證短信一次性密碼（OTP）
輸入用戶名
確認治療計劃

登錄：

輸入電話號碼
驗證短信OTP

圖4所示的準活動圖對此進行了補充，并鏈接到相關的用戶故事。

圖4 。耐心的移動應用程序入職流程。

非功能需求（NFR）

安全性非常重要，因為該系統存儲患者數據，這是GDPR定義的敏感個人數據類別。更廣泛地說，我們被要求遵守和認證ISO27001，這是信息安全的行業標準，其中一部分涵蓋了用戶身份驗證的控件。這需要大量的努力，并且影響了我們的技術設計和實施，以及我們的流程，人員和位置。共同商定的審核員正在進行的年度審核也意味著這不是一次。
國際化（i18n）和本地化（l10n）很重要，因為該應用程序最初設計用于具有12個本地副本集的10個國家/地區。還有一個項目要求，由認可的翻譯機構進行所有翻譯工作。與產品相比，最終影響過程更大。
鑒于源自法律，法規，標準和合同的有關患者數據的合規性要求，法律非常重要。在處理患者數據（出于真實和可感知的原因）時，數據主權（存儲數據的國家/地區）很重要。對于Vision Coach，患者數據需要生活在許多不同的全球區域中。入職時捕獲的可選分析數據共享同意書也需要至少每年存儲和更新一次（符合歐盟法律）。
考慮到某些用戶的視力障礙（從輕度到重度）， 可訪問性很重要。對此的一個限制是iOS和Android原生提供的豐富的可訪問性工具，以及一些證據（公認的是，在更廣泛的人群中），這些工具經常被視障用戶（例如屏幕閱讀器）使用，如圖2中的接受標準。 3）。
性能和可伸縮性很重要，因為系統需要在最短的時間內做出響應才能使用，因此，我們部署基礎架構的方式需要能夠支持用戶數量的最佳情況估算，尤其是在負載很重的情況下。

技術設計（第4級）

身份驗證 。圖5顯示了用于廣泛認證流程的UML序列圖，包括使用基于SMS的OTP進行電話號碼驗證。我們沒有為該應用程序生成許多時序圖，但是在這種情況下，身份驗證流程是我們要做的一個領域，因為在技術設計上存在分歧。如前所述，分歧和復雜性通常是觸發我們在技術設計會議上進行更多工作的誘因，而順序圖和其他圖則偶爾會作為這些結果的輸出，當被認為對分析需求和改善團隊協調性很有用時。

圖5 。 UML序列圖顯示了端到端認證流程

I18n和l10n 。由于翻譯工作是由外部機構完成的，因此翻譯內容的格式必須易于在此過程中來回移動。我們決定對構成Vision Coach的各種應用程序使用通用框架。所有內容都存儲在yaml文件中，這些文件已從任何單獨的應用程序中分解出來并在運行時加載。對于患者應用程序，在啟動時，該應用程序將從翻譯API加載內容。
用戶同意 。作為服務同意條款的一部分，要求用戶同意跟蹤應用程序的使用。我們需要記錄同意事件，并將其發送給客戶端的IT涉眾指定的第三方API。然后需要將同意信息提供給多個應用程序和設備，這對于患者應用程序是通過存儲在經過身份驗證的API中的數據來完成的。
短信服務 。我們選擇使用Amazon Web Service（AWS）的簡單通知服務（SNS）發送事務性SMS消息。鑒于該應用程序托管在AWS上，因此這是一個方便的決定。
區域部署 。由于需要將患者數據保留在某些區域內，因此我們需要將該平臺部署到多個AWS區域。這為改善全球客戶的延遲帶來了額外的優勢。僅需要一個版本的患者應用程序，并且我們使用了眾所周知的單個全局端點來允許其發現API和身份驗證服務等區域資源。圖6顯示了區域部署。它包括一個托管靜態服務的主要區域（EU），以及托管API服務（由AWS Relational Database Service（RDS）和基于HL7 FHIR標準的臨床數據存儲庫支持）的單獨區域和身份驗證服務。移動應用從主要EU環境中的配置服務獲取有關適當區域的位置（基于電話的區域設置ID）的配置數據，然后從適當的區域環境獲取其數據

圖6 。視覺教練區域部署

高可用性部署 。應用程序使用水平很難預先預測，這是我們部署在AWS的Elastic Container Service（ECS）上的部分原因，因為它使我們能夠在需要時輕松擴展應用程序，并且盡管成本高昂，但仍可控制成本區域設置。

任務（5級）

實施工作記錄在Jira父票證附帶的子任務中。通常，我們從最小的可行產品（MVP）開始采用增量方法實施，然后從那里分層功能。遵循電話號碼驗證的故事，前端和后端（FE＆BE）任務包括：

基本OTP輸入框（FE）
API調用以驗證OTP驗證完成（FE）
UI控件導航到上一屏幕（FE）
一旦提供了真正的API（FE），便可以進行其他集成工作
為前端開發人員實現模擬API終結點，以盡早開展工作（BE）
實現真實的API端點，以根據數據庫（BE）中存儲的值驗證OTP

超出MVP的增量包括以下任務（FE＆BE）：

在驗證碼中輸入最后一位數字時自動提交OTP
在OTP驗證時自動路由到入職的下一個屏幕
在交付失敗的情況下重新發送OTP

挑戰與解決方案

使用此處勾勒出的方法，我們在開發和管理需求方面遇到了許多挑戰。這些是主要解決方案，也是我們的一些解決方案：

潛在需求 。用戶和客戶利益相關者常常不知道他們想要什么，以為他們知道他們想要什么（但不是真的），想要他們假設別人會知道的事情……這是您的工作，找出這些要求然后建立東西滿足他們。最好的方法是在實際環境中將工作軟件交付給具有代表性的用戶樣本，但是由于擁有完整的跨職能團隊的迭代成本很高，因此我們可以使用快速原型技術來獲得有用的信息（盡管（當然較弱））以較低的成本盡早提供反饋。
合規和用戶輸入 。與患者和醫生的所有互動都必須通過合規性計劃（記錄，審查，批準）（法律，醫療和法規），因此既不快捷也不容易。每當我們需要用戶反饋時，我們都必須制作一個討論指南，其中包含所有屏幕的PDF，以供相關的本地合規團隊審閱。這使開發過程中的用戶交互比我們希望的要少，但并非不可能。我們通過創建可循環使用的模板作為討論指南來解決此問題，并將PDF生成內置到我們的自動化端對端測試套件中，從而使審核所需的資產的生產更加容易。這有助于加快將我們的軟件展示在用戶面前的時間表。
企業發展緩慢 。企業中的所有事情進展緩慢。這意味著迭代開發可能會很慢，并且需求通常處于不同的準備狀態。有幾件事情有所幫助：（i）制定了實施計劃，以便在需要更多時間的領域進行澄清和驗證；（ii）首先開發具有更好開發要求的功能；（iii）確保我們不會為我們無法控制的流程部分承擔任何風險。
企業不是敏捷的 。企業通常不敏捷，而醫療保健企業當然不是。但是，我們的項目負責人被吸引到了新的工作方式，因此我們在每次沖刺結束時將全球范圍內的客戶評論和反饋嵌入到展示柜中（更頻繁的交互/決策是不現實的）。這很好地在整個項目中引發了其他客戶需求。主要的挑戰是在發布之前要進行合規性審查，這是在（接近）最終資產上完成的本地流程，并且不能進行迭代工作，這意味著交互和必備需求在周期的后期出現。這個過程是不可更改的，因此，實際上我們唯一可用的解決方案是在交付計劃中建立應變性。事實證明，這種偶然性是不夠的，盡管我們能夠觸發合同延期，這至少可以使我們最小化財務方面的損失。
利益相關者很多 。對于資源有限的小型團隊而言，征集遍布全球的眾多利益相關者的要求是不切實際的。我們通過在全球范圍內創建核心團隊來解決此問題，該團隊的職責是代表整個企業中利益相關者的需求，并在必要時促進與他們的聯系。我們已經與我們的團隊和流程安排了接觸點。這在許多領域都做得很好，但是當然不是完美的，需要額外工作的主要領域是合規性，各地的情況大不相同。
用戶故事還是用例 ？用戶故事為我們提供了一種描述用戶需求的簡潔方法，并且利益相關者可以理解。他們也有缺點，其中有許多是由阿利斯泰爾科伯恩在突出很大一塊用戶故事與使用情況的限制，即缺乏對設計師（I）的背景下，（II）為完整開發團隊及（iii）粒度用于計劃/研究。用例雖然可以填補這些空白，但它們也更難編寫，也讓利益相關者難以理解。我們決定結合每個要素-以接受標準為核心的用戶故事，以及替代目標（例如擴展點）和UML圖（例如，使用PlantUML的人類可讀語法而不是XML）的接受標準，以提供技術設計的上下文和粒度以便及時評估。
范圍蠕變 。這在所有項目上都會發生。當然，我們為此內置了應急緩沖，這為預算范圍內的范圍增加提供了一些余地。在這個特定項目上，很多范圍的爬升都來自本地合規團隊，尤其是在要求更高的國家（例如英國和加拿大）。由于這些要求通常以解決方案的形式提交給我們-常常與為滿足患者或醫生而實施的解決方案相沖突-我們首先花時間確定基本要求，然后研究如何以一致的方式滿足這些要求與其他用戶要求。有時這是可能的，而其他時候則沒有，合規性才是關鍵。

加起來

盡管您在網上閱讀的有關需求開發的許多內容都表明，分析癱瘓和迭代崇拜之間存在兩極分化，而且大多數人都與后者相吻合，但是中間的方法可以Swift產生真正的收益。

就我的金錢而言，這種中間方法（此處所述方法）的最大實質好處是，由于更好的環境而改善了決策，從而提高了速度，現金消耗和團隊士氣。從個人經驗來看，由于花了一些時間思考和定義需求，我的團隊的速度提高了約40％。

此“客觀”度量帶有一些警告-它是通過??在確定更好的需求開發引入之前和之后，在定義的時間段內測量每個sprint完成的平均故事點之間的差異來粗略地計算得出的，并且它無法控制其他混雜變量（例如人事變動）。

但是在方向上這很有趣，而且它在主觀指標上也得到了極大的改善，即團隊士氣和對沖刺過程中取得的進展的滿意，這一事實提供了一些其他證據。

總而言之，時間和精力的初始投資所帶來的投資回報是可觀的，投資回收期可以短于單個沖刺，因此絕對值得這樣做。

下次我該怎么做？缺少想出一種使合規功能完全敏捷并與開發周期完全集成的神奇方法，我要做的主要事情是：

提出在開發周期中更早地讓本地合規團隊參與的可接受方法，例如，通過讓更多的人參與原型審查以及早淘汰相關要求
找出如何以更一致，更可衡量的方式捕獲非功能性需求，并通過諸如Planguage之類的形式主義來尋求靈感
使用不同的工具鏈來管理需求-使用Jira和靜態網站的組合來處理文檔存在很多問題，我將在下一篇文章中介紹。

下一步是什么

第3部分重點介紹用于管理需求的工具。它包括對我們過去使用的工具的分析和評估，其他現代軟件團隊在決定如何管理其需求時往往會了解和考慮。

參考書目

A. Cockburn，編寫有效的用例，Addison-Wesley Professional，2000年
A. Cockburn，為什么我仍然使用用例，2008年
D. Gause和G. Weinberg，《探索要求：設計之前的質量》，多塞特郡出版公司，1989年
D. Leffingwell，敏捷軟件需求，Addison Wesley，2010年
G.摩爾，《跨越鴻溝》，第三版，《哈珀商業》，2014年
K. Wiegers＆J. Beatty，軟件要求，第三版，Microsoft Press，2013年

特別感謝Karl Wiegers的有用評論！

翻譯自: https://hackernoon.com/foo-xv1x3278