學習總結：WorkShop（一)

基于RestfulAPI的Service服務-Micro-Service to ingestion auto seller data

• What is a /Workshop/?(2 min)
• Rest API introduction (5 min)
• Workshop demo Q & A.(10~15 min)
• New requirement introduction and analysis (5 min)
• Task separation (20 min)
• Work out solution (20 min)
• AML (20 min)
• Pair programming (TDD?) (1 hour)
• Docker & Deployment (30 min)
• Free talk (30 min ~ 1 hour)</br>
  
  初入IT行業，承蒙老師（阿爾法二狗）指引，于17年6月10日在thoughtwork開始生涯中第一次Workshop，
  記錄下學習心得，以備日后查看。新手上路，大佬們多多指教。

一、Workshop

Workshop最早的定義為，由幾個人進行密集討論的集會，通常需要當場練習，后續在IT行業廣為
推廣，為求“跳脫喧囂、遠離噪音、沉下心一起做一次深潛”為愿景。

二、Restful架構

1、概述

"互聯網軟件"采用客戶端/服務器模式，建立在分布式體系上，通過互聯網通信，具有高延時、
高并發等特點。網站開發，完全可以采用軟件開發的模式。但是傳統上，軟件和網絡是兩個不同的領
域，很少有交集；軟件開發主要針對單機環境，網絡則主要研究系統之間的通信。互聯網的興起，使
得這兩個領域開始融合，現在我們必須考慮，如何開發在互聯網環境中使用的軟件。

    RESTful架構，就是目前最流行的一種互聯網軟件架構。它結構清晰、符合標準、易于理解、

 擴展方便，所以正得到越來越多網站的采用。（引用自：阮一峰博客“理解restful構架”）

REST（Representational State Transfer）如果一個架構符合REST原則，就稱它為
RESTful架構。

      ps：Representational State Transfer 中，這里省略了主語Resource，State為資
 源的狀態，Reset可以理解為用戶在使用互聯網軟件的過程中，資源的狀態的轉化。（個人理解）

2、分類說明

1）資源（resource）

資源，即為網絡上的具體信息。文字、圖片、音頻等等都可以視為資源。每一種資源都有與之對應的
特定的URI，想要獲取特定的資源，就要訪問與之相對應的URI。
eg：Uri resource（/companies/{id}/employees/{id}）

2）表述性（representational）

資源是一種信息，信息有各種各樣不同的表述方式，具體的表述方式就是資源的表述性。

    eg：文本資源的表述性可以為：TXT,HTML,XML,JSON等。

3）狀態轉換（state transfer）

 互聯網通信協議HTTP協議，是一個無狀態協議。這意味著，所有的狀態都保存在服務器端。因此，

 如果客戶端想要操作服務器，必須通過某種手段，讓服務器端發生"狀態轉化"（State Transfer）。
 而這種轉化是建立在表現層之上的，所以就是"表現層狀態轉化"。
 (引用自：阮一峰博客“理解restful構架”）

具體來講就是HTTP協議下常用的四種方法：GET（查找）、POST（新增）、PUT（更新）、DELETE（刪除）

三、Service Demo Q&A

• Q：閱讀完全未接觸過的代碼時，使用什么方式可以快速的了解代碼的架構。</br>
  A：對于Rest API架構的代碼來說，可以通過Controller快速了解RestAPI構成，閱讀modules可以快速
  的了解項目數據結構。

• Q：Rest API架構的項目開發過程中，有哪些實用的工具。</br>
  A:

  1. Curl:curl是利用URL語法在命令行方式下工作的開源文件傳輸工具</br>
  2. postman:自帶UI的Web開發工具，更加方便實用和測試</br>
  3. Raml:RAML的全稱是RESTful API建模語言，這是一種基于YAML格式的新規范，人機都能很好的理解。

• Q：測試代碼的原理。</br>
  A: 設定好被測模塊的運行目標，當測試代碼得到該結果時，證明被測模塊功能正常。

四、完整的項目開發模塊和需求分析方法

1、項目開發模塊

 Project{
    Coding{
        Dao
        Controller
        Service
        Model
        ...
    }
    Doc{}
    Test{
      UI AutoTest
      UnitTest{
          Junti
         ...
      }
    }
    Deploy{}
 }

2、需求分析方法

在收到客戶需求后，一定不能直接根據大致的理解就進行項目的開發，這個時候的Coding大部分都是廢品，
在理清需求之后大部分，甚至全部代碼都需要返工，所有盲目的編寫代碼是項目開發中最大的忌諱，而與之
相對的，分析客戶需求成了重中之重。</br></br>
首先，對需求進行分級，用戶提出的需求作為最高等級。從最高等級的需求開始拆分，將需求盡量的細化成
一個一個有邏輯關聯的單功能模塊，便于分單元開發與測試。</br></br>
一般需求都會拆分兩至三次，最低級的需求要求實現單一功能，設計好模塊的輸入和要求的輸出。完成好最
低級需求的分析后才可開始按模塊的進行開發。</br></br>
建議：開發與測試同步進行。