Alpha 事後諸葛亮

組長部落格連結：https://www.cnblogs.com/heihuifei/p/10055777.html

Alpha版本展示視訊連結：https://www.bilibili.com/video/av37332756/

團隊會議紀要連結：https://www.cnblogs.com/heihuifei/p/9824563.html

目錄

• 設想和目标
• 計劃
• 資源
• 變更管理
• 設計/實作
  • 測試/釋出
  • 團隊的角色，管理，合作
• 總結:
• 本小組和其他組的評分
• 分工和貢獻分
• 全組讨論的照片
• 問題
  • 第一組提問回答：爸爸餓了隊
  • 第二組提問回答：拖鞋旅遊隊
  • 第三組提問回答：很行隊
  • 第四組提問回答：火箭少男隊
  • 第五組提問回答：起床一起肝活隊
  • 第七組提問回答：第三視角隊
  • 第八組提問回答：小白吃隊
  • 第九組提問回答：我的頭發呢隊
• 個人PSP
• 個人學習進度條

1.我們的軟體要解決什麼問題？是否定義得很清楚？是否對典型使用者和典型場景有清晰的描述？

• 我們軟體解決的問題是：人們日常并行事項越來越多，而人的記憶是有限的，我們的記憶罐頭這款

  備忘錄可以有效的提醒和安排日常事務，并且提供衆多便捷、智能、實用的功能。

• 已經定義的十厘清楚。（詳情可參見需求分析報告）
• 典型使用者為：學生黨和工作黨。（在需求分析課堂展示中已有描述。）
• 典型場景：佩佩和小柯的故事。（在需求分析課堂展示中已有描述。）

2.我們達到目标了麼（原計劃的功能做到了幾個？ 按照原計劃傳遞時間傳遞了麼？)

• 已達到目标，原計劃功能已完成6個：備忘錄的基礎使用、天氣分析、智能提醒、App使用分析、語音輸入、智能識别短信。剩下1個需在Beta版本完成：形成語音輸入小浮标。
• 在Alpha版本規定時間完成傳遞。并進行Alpha版本課堂展示。

3.原計劃達到的使用者數量達到了麼?

• 原定計劃中未對使用者數量做出明确定義。使用者量還需要在Beta版本完成之後進行推廣擷取。

4.使用者量, 使用者對重要功能的接受程度和我們事先的預想一緻麼? 我們離目标更近了麼?

• 暫時還未進行推廣，是以還沒有使用者量。離目标更近一步。

5.有什麼經驗教訓? 如果曆史重來一遍,我們會做什麼改進?

• 應該在開始的時候目标定得更明确一些。如果重來一遍的話，我們會加上對後期使用者量的明确目标以及設想的更加細緻。

你原計劃的工作是否最後都做完了? 如果有沒做完的，為什麼?

• 在alpha版本的原計劃的資料庫初始化和接口的實作任務最後都完成了，剩下的是beta版本的使用者登入和雲端備份的實作；原計劃的前端功能都已經實作，現在缺少的是頁面的精修，在美觀上還需要改進。

有沒有發現你做了一些事後看來沒必要或沒多大價值的事?

• 在android stdio的下載下傳上花費了很長時間，至少有兩天，出現各種問題。以及在代碼整合的過程中，出現有些人代碼可以運作，但是有些不能運作的情況。在軟體的問題上出現很多錯，但是有很費時。項目初始計劃是做伺服器上的資料庫和接口，但是這樣會導緻手機在沒有網絡的情況之下，加載不出資料，整個軟體會處于不能使用的狀态，這和我們這樣一個備忘錄app的使用者使用場景出入很大。發現問題之後決定将資料庫部署在本地。還有就是接口設計的時候，其實有些功能前端可以直接實作的，不需要對應的接口，常常設計出前端不需要的接口；

是否每一項任務都有清楚定義和衡量的傳遞件?

• 在後端部分，資料庫和接口的設計我們是有在需求文檔中做了詳細的規劃，根據軟體的原型和需求，規範地設計資料庫和細緻地設計接口的，資料庫表結構和接口需求明确之後才進行的代碼實作，是以在于整個項目的開發中，任務和進度是很精确的，也提供測試樣例作為參考。

是否項目的整個過程都按照計劃進行，項目出了什麼意外？有什麼風險是當時沒有估計到的，為什麼沒有估計到?

• 後端部分，是先根據原型和需求，資料庫表結構和接口需求明确之後才進行的代碼實作的，按照文檔一步步實作的，期間由于對java和AndroidStudio開發的不熟悉，有時在資料庫初始化和sql語句上出現問題；風險的話因為做的功能是相對簡單和基礎的部分，可能在安全系數和資料庫版本更新的部分沒有做的詳盡；對于将來伺服器安全部分會考慮加強安全性的途徑；

在計劃中有沒有留下緩沖區，緩沖區有作用麼?

将來的計劃會做什麼修改？（例如：緩沖區的定義，加班）

• 計劃的實施都是在大家都有空的時候，一起進行的。各自在平時有空的時候自行學習和code，也會互相分享經驗，任務完成的也相對高效緊湊，沒怎麼需要加班；一起code的時候，一般都是任務完成到預期進度才各回各家；将來的計劃，我覺得這種狀态挺不錯的（畢竟大家有不同的課業需要兼顧），可能會多一項在固定時間互相交流學習内容和實作思路，這樣對接下來計劃的實作思路會更加明确；不過在每天的任務中難免存在難度無法做完的情況，我們會選擇熬夜完成項目。

我們學到了什麼? 如果曆史重來一遍, 我們會做什麼改進?

• 對于後端能實作來說，由于第一次做，對于任務量的不熟悉，在配置設定任務的之後，會導緻有的成員天天埋頭苦幹，有的則無所事事，還有就是不同成員在學習重複的知識，這樣使任務的完成度參差不齊，也降低效率；如果曆史重來一遍，會對任務進行詳盡的分析，明确技術難點和工作量，然後進行任務分派，在提高效率上應該會有所成效；同時，我們可能會選擇多增加代碼規範性的了解，在頁面的設計上也會稍加改進。

我們有足夠的資源來完成各項任務麼?

• 有足夠的資源來完成各項任務。團隊人才濟濟。

各項任務所需的時間和其他資源是如何估計的，精度如何?

• 各項任務所需時間及其他資源是詢問前輩的經驗以及在開發過程中不斷更新考量估計的，精度不太準确，出現逾時完成任務的情況。

測試的時間，人力和軟體/硬體資源是否足夠?對于那些不需要程式設計的資源 (美工設計/文案)是否低估難度?

• 并未低估文案和美工設計的難度，在最開始的時候便配置設定了專員負責這兩個子產品。測試時間安排不太合理，暫未配置設定測試時間。

你有沒有感到你做的事情可以讓别人來做（更有效率）?

• 我覺得我做的事情，讓一個心思缜密的組員都能做的不錯。

有什麼經驗教訓? 如果曆史重來一遍, 我們會做什麼改進?

• 配置設定任務的時候會對任務進行詳盡的分析，明确技術難點和工作量，然後進行任務分派，能夠讓大家都輕松高效的完成項目

每個相關的員工都及時知道了變更的消息?

• 如果有變更的消息的話，員工們都能從員工群裡面擷取實時的變更消息，此外在相關員工的小組群裡面也會有變更消息的提醒，這樣保證了每個相關的員工都能夠及時知道變更的消息。

我們采用了什麼辦法決定“推遲”和“必須實作”的功能?

• 在項目初期，員工們對于自己負責部分的功能有粗淺了解之後，員工們根據功能的實作難度判斷功能屬于“推遲”或“必須實作”的功能，然後在開會期間提出該議題（若無提出，預設“必須實作”），經過讨論（參照功能是否為必須實作的主要功能、關鍵功能）後，采取集體投票的方式最終決定該功能屬于“推遲”或“必須實作”的功能！

項目的出口條件（Exit Criteria – 什麼叫“做好了”）有清晰的定義麼?

• 對于我們的項目，我們首先規定了一些基本功能，在最後完工時，這些基本功能就是我們的項目的出口條件。

對于可能的變更是否能制定應急計劃?

• 是的！俗話說計劃趕不上變化，我要以不變應萬變，根據自己所學的和所看的書結合實際情況，做出判斷。接着進行羅列出可行的計劃，然後進行選擇，選出比較好的幾個應急計劃，再對各個計劃、各種方案的優缺點以及成本進行篩選。

員工是否能夠有效地處理意料之外的工作請求？

• 我們的員工在收到意料之外的工作請求時，會先确認其來源的需求，在确認無誤并沒有異議的情況下，能夠合理協調自己的安排以滿足目前的總體需求。

• 首先，每個員工在技術知識方面都或多或少有所收獲，或是前端頁面方面、或是後端接口編寫方面等，此外我們的每個員工都對一個app的開發流程有了一定的了解，而不是負責某一部分就隻了解該部分的内容；其次，我們積累了一些開發經驗，在某些問題的解決上有了解決方法；此外，我們還認識到了軟體開發團隊中員工之間的團結協作和交流溝通是十分重要的，如果一個團隊能夠團結協作并積極地交流溝通，那麼這個團隊的狀态是健康積極的，軟體的開發便能順利愉悅地進行，相反地，如果一個團隊有大大小小的各種沖突，那麼這個團隊的狀态是不健康的，甚至很可能影響到軟體開發的進度。如果曆史重來一遍，我們會請教有過項目開發經驗的學長或學姐更具體的開發流程細節，更好更快地完成我們項目的分工部分，為開發過程中的“bug”留下更充足的時間；其次，我們會更加注重開發的“規範化”，比如每兩天寫學習總結，将開發過程中遇到的問題的可行解決方法寫成技術文檔等；此外，我們會在團隊成員之間的團結協作和積極交流方面做得更好！

設計工作在什麼時候，由誰來完成的？是合适的時間，合适的人麼？

• 原型的設計工作是卉卉做的，之後疊代是丹丹完成的。原型的設計工作在團隊選題報告之後重新設計的，一方面讓新隊員卉卉熟悉了我們的項目，我們認為讓她來做是比較合适的。（卉：界面醜其實是我的鍋orz）
• 資料庫和接口的設計是由後端部分的家燦和卉卉在選題報告之後一起讨論完成的。

設計工作有沒有碰到模棱兩可的情況，團隊是如何解決的？

• 負責的原型設計的同學在群裡釋出了很多版本，其他組員也提了許多意見，最終确定了最終版本。
• 後端的設計工作在後面的代碼實施階段遇到了一些分歧，也是通過後端組内讨論解決的。

團隊是否運用單元測試（unit test），測試驅動的開發（TDD）、UML, 或者其他工具來幫助設計和實作？這些工具有效麼？

• 後端是在Androidstudio裡進行的單元測試，後端同學表示Androidstudio自帶的測試環境比較友善也挺好用的。

比較項目開始的 UML 文檔和現在的狀态有什麼差別？這些差別如何産生的？是否要更新 UML 文檔？

• 差距還是比較大的，差別是在開發過程中發現UML文檔的東西不适應項目的開發，需要改變。需要更新UML文檔以适應。

什麼功能産生的Bug最多，為什麼？在釋出之後發現了什麼重要的bug? 為什麼我們在設計/開發的時候沒有想到這些情況?

• 基礎功能中的備忘錄展示，因為對android開發不熟悉，自定義控件的使用不熟悉，導緻書寫的過程出現很多問題。釋出之後，語音插入之後完成時間是已過期，删除功能不完善。開發的時候因為alpha版本時間有點趕，未進行完整的測試。

代碼複審（Code Review）是如何進行的，是否嚴格執行了代碼規範？

• 無，并未嚴格執行代碼規範。

• 學到了如何開發一個項目的全部流程，以及如何有效的分工。同時，每個組員對前後端的交接有了完整的了解。如果曆史能重來，我們會在一開始就進行代碼規範，以及代碼複審，這才是軟工實踐的最大意義。以及合并時采用GitHub，讓合并更加高效。

團隊是否有一個測試計劃？為什麼沒有？

• 測試計劃分為四個方面：

1. 測試桌面是否可以自動生成

   可自助選擇桌面格式，字号大小，字号顔色，自動生成桌面桌面

2. 測試快遞，車票資訊是否可以自動生成

   接受車票，快遞資訊，生成備忘資訊

3. 測試是否可以建立備忘資訊
4. 測試語音轉文字功能
5. 測試删除選中功能
6. 測試回報功能

7. 測試桌面控件功能

   在測試過程中，及時消除bug和解決軟體閃退問題。

是否進行了正式的驗收測試？

• app在桌面可安全開啟，并完成測試計劃提到所有功能，有視訊展示。

團隊是否有測試工具來幫助測試？

• 測試計劃分為前端，後端兩個部分。

  前端測試利用Android studio進行build，build成功後按三角運作按鈕，電腦與安卓機利用資料線相連，授予USB通路權限，運作成功後，創作界面會在安卓機自動顯現。

  後端利用Android studio裡的junit進行測試，測試失敗會顯示錯誤。

團隊是如何測量并跟蹤軟體的效能的？從軟體實際運作的結果來看，這些測試工作有用麼？應該有哪些改進？

• 我們的後端已經寫了一份單元測試來進行測量并跟蹤軟體的效能。從實際運作結果來看，這些測試工作是非常有用的。我們應該适當地豐富測試檔案的内容。

在釋出的過程中發現了哪些意外問題？

• 由于我們在打包APK的過程中，想要将所有的部分調整到最好，導緻沒有将APK打包好。

• 我們對前端，後端的部分從一無所知或者隻知道大概，到對整個開發流程和APP有了很詳細的了解。并且明白了如何融入一個團隊中，将團隊變得更好。

  我們會對隊員分工進行更詳細得調整，将所有人都加入到開發工作的熱情中。

團隊的每個角色是如何确定的，是不是人盡其才？

• 角色是在先自由選擇之後再由pm進行分工。盡量按照大家熟悉的且有意向的角色進行配置設定。總體上做到了人盡其才。

團隊成員之間有互相幫助麼？

當出現項目管理、合作方面的問題時，團隊成員如何解決問題？

• 互相幫助是肯定存在的，經常面對面互相交流的時候就需要互相幫助，比如前端就是前端小組長

  和pm比較熟悉一些幫助另外兩位隊友。

每個成員明确公開地表示對成員幫助的感謝：

• 我感謝家燦對我的幫助， 因為突然得知要做本地很慌，感謝他查閱了很多資料跟我一起分享。

• 鴻傑

  大部分時候你要做的功能網絡上并沒有完整的代碼可以“搬運”，需要你看懂網上的代碼，然後根據你的功能需求自己修改代碼（這步驟可以借助相關的開發文檔）；

  如果曆史重來一遍，我們會在分工在做的更好，合理配置設定人力資源到各個部分。

• 家燦

• 一好

  如果能重來一遍，我會對不同廠家的語音轉文字API進行測試，選擇最優秀的API加入到我們的APP中。我還會在Alpha版本開發時，調整自己的時間安排，完成屬于自己的所有任務。

• 卉卉

  雲端本地要同時進行orz

• 政演

  提前考慮應用一些前沿的技術，增加亮點

• 青元

  對任務的配置設定需要更加詳細，學習的時間配置設定需要更多一點。如果重來，會增加更多的學習時間。

• 丹丹

  我在這門項目裡确實學到了很多東西，對視訊剪輯軟體有掌握，在後面也有接觸到前端學習。

  教訓就是一定要下一個下一個正規的剪輯軟體。前期因為電腦和安裝軟體不正規，導緻電腦真的變得很卡。

  重來一遍的話，我一定會更加認真的完成這份工作，更加珍惜現有的資源，好好學習前端。

• 家偉

  相比于一步步按源碼用到的知識片面學習Android知識，先系統的學習Android基礎知識會對在app中實作功能有很大的幫助。

  重來一遍的話，我将前期的任務設為系統地學習Android基礎。

• 宇恒

  如果曆史重來一遍, 我們會做什麼改進? 答：在時間安排上過于集中，如果再來一遍，會把任務配置設定到每天。

• 緒佩

  在開始做之前應該多問一下有開發經驗的前輩，詢問清楚不懂的地方，這樣開發的時候可以節省很多時間和多餘的工作。

• 恺琳

  在了解自己的任務同時也了解别人的任務，在交流中能更好地了解

你覺得團隊目前的狀态屬于 CMM/CMMI 中的哪個檔次?

• 可重複級(Repeatable)

  在一次次團隊項目中，我們團隊建立了較明确的管理制度和貢獻分配置設定規則。每次項目結束後都會進行反思和總結，且能夠據此做出改進并較為詳細地确定下一階段應實作目标。

你覺得團隊目前處于 萌芽/磨合/規範/創造 階段的哪一個階段?

• 處于規範階段

  經過alpha沖刺和團隊現場git後，團隊成員已經進行了足夠多的磨合，有了充足的協作程式設計經驗；目前我們所欠缺的是互相之間代碼等達到“規範”這一要求。

你覺得團隊在這個裡程碑相比前一個裡程碑有什麼改進?

• 目前（alpha階段）相比于上一個裡程碑（需求分析），團隊整體的技術水準有了很大程度的提升，團隊協作能力++。

你覺得目前最需要改進的一個方面是什麼?

• 編碼規範是我們目前最需要改進的方面。

對照靈活開發的原則, 你覺得你們小組做得最好的是哪幾個原則? 請列出具體的事例。

• 在團隊内部，最具有效果并且富有效率的傳遞資訊的方法，就是面對面的交談

  我相信，在alpha沖刺階段中，我們團隊的面對面交談/編碼時間能夠在所有團隊中排在前幾甚至是第一。

• 每隔一定時間，團隊會在如何才能更有效地工作方面進行檢討，然後相應地對自己的行為進行調整。

  即使除去alpha沖刺兩天一次的站立會議，我們團隊仍能夠保持平均每周1.5次以上的線下會議頻率，并在會議上對近期工作做出彙報、總結及相應調整。

成員	比例
	13%
	7%
	6.5%
	11%
	9%

Q1：團隊沒有使用GIT進行版本管理,是否考慮在之後使用git進行版本控制

答:感謝提問，謝謝你們的提醒，我們Alpha版塊還沒有進行Git整合，在Beta版本這方面會選擇進行Git版本整合的。

Q2：備忘桌面功能所選的桌面似乎會影響備忘内容的可讀性?

答:感謝提問!這個問題我們我們有考慮過，以前也有具體回答過，在桌面方面我們進行了多種設計來避免桌面内容遮擋備忘錄，排版合理，盡可能完全清晰的展現備忘錄。

Q3：語音部分的功能在嘈雜環境中的表現有相應測試嗎?

答:感謝提問!語音功能有進行初步檢測，但因為我們的主打功能不在此，并沒有具體的去增強語音識别功能，後續如果有時間精力的話，會考慮在這方面進行改善。

Q1：生活助手界面的優先級“無”是什麼意思？

你好，我們對所有備忘都設定了一個可選填的優先級選項，如果備忘存存在優先級會按高低進行排序，不存在優先級的話按到期時間進行排序。

Q2：打開檔案擷取圖檔資訊是用來編輯鎖屏界面的資訊嗎？

你好，不是用于編輯屏鎖界面的，隻是針對備忘儲存圖檔。

Q3：是否有使用者資訊界面來展示資訊以及對備忘錄記錄任務的完成度展示？

你好，我們首頁設定了三個清單來展示備忘任務的完成情況，分别是近期待完成、逾時未完成、已完成任務，并可對這三個清單的已有備忘進行修改跟删除。

Q1：設計主界面采用流動的消息條,是否考慮會造成視覺疲勞？

後期我們的美工和前端會對界面的美觀進行修繕。

Q2：說到算法,有想過提高一下算法嗎

我們會對一些算法進行改進。

Q3：界面的整體風格好像有點普通,可以考慮簡化一下界面,很好看？

前端在下一階段的任務就要包括對界面進行優化的任務。

Q1：本次語音識别子產品的示範未展現，是否會選擇下次用更好地方式來示範？

答：感謝提問！我們的語音轉備忘錄功能在視訊中有展示。

Q2：“生成桌面”中貌似在桌面上有存在兩個按鈕，是用過截屏功能進行實作的嗎？若考慮美觀問題？

答：感謝提問！确實是用截屏，然後再利用截屏生成的照片去生成鎖屏，由于alpha之中夾雜了兩科考試，故未優化。我們後期會進行優化，獲得更好看的生成鎖屏功能。

Q3：備忘錄中的字型貌似不會較美觀，是否考慮後續改進呢？

答：感謝提問！alpha我們盡量在美觀和功能齊備之間達到平衡，但在時間不能允許我們兼顧的情況下，我們先選擇了功能的齊全，然後後期會進行改進。

Q1：語言轉文字功能目前隻能對接百度的，如果某天百度的接口取消了，要怎麼辦呢？

感謝提問！百度語音識别的功能現在已經和百度輸入法，魅族輸入法等手機品牌的輸入法在合作中，并且手機百度，愛奇藝等平台的語音搜尋功能也是建立在百度語音識别這個項目上的。如果有一天百度關閉了這個api那想必是百度搜尋不想做下去了，放棄了這麼簡便的輸入方式。再者現在是人工智能飛速發展的時代，語音識别也處于這個範疇中，再加之百度近期将其api免費提供給開發者們使用，證明這個api還有很大的發展空間，是不會關閉的。

Q2：某些背景會影響閱讀，是否會考慮在使用者設定桌面時提醒使用者的功能？

感謝提問！這個功能是通過使用者可以選擇的開關來設定的，是以說這個功能的開關可以由使用者自己決定。我們後端和前端同學在設計這個功能時會考慮到包括影響使用者體驗在内的各種情況，盡努力使使用者體驗達到最佳。

Q1：你們的訂單資訊和快遞資訊之間有什麼差别？

感謝提問！訂單資訊指的是汽車票、動車票和飛機票等出行資訊，而快遞資訊便是字面上的快遞取貨資訊。我們在最後的對接過程中沒有注意到這一細節，在之後的代碼整合時我們會多加注意，避免這一失誤再次發生。

Q2：為什麼你們展示的時候，生成桌面那一塊，鎖屏的桌面展示還留着“生成桌面”按鈕和“取消”按鈕？還有，你們的生成桌面支援預覽嗎？

我們"生成桌面"這一功能目前僅做到初步實作，在後續的版本疊代過程中我們會進行持續優化改進；生成桌面支援預覽功能。

Q3：如果百度的接口哪一天不提供對外使用了那語音輸入是不是就廢了？

百度接口不予外用的話，考慮到自主實作效果不佳，我們比較傾向先尋找其它接口進行代替；在之後算法能力提升後會考慮自主實作。

Q1：對于算法方面是合理調用網上接口，後期會考慮自己來做語音識别嘛？

我們語音識别是直接調用的百度提供的識别接口，由于這個自主實作的效果和網絡上的接口出入很大，考慮到使用者體驗和識别的精确度，還是傾向于直接使用百度接口。

Q2：如何統一美化ui界面？

對于ui界面，确實做的不夠美觀，改進思路是：參考現在發行的各種備忘錄類的軟體，博采衆長，進行組内讨論和問卷調查等形式，确定ui界面的美化方向；

Q3：對于識别快遞資訊是直接通過單号來提取資訊的嘛？

快遞資訊的識别，是根據短信的内容，直接識别的，（正規表達式），我們沒有做物流資訊的同步，隻是對收到到取貨資訊的短信進行識别；

由于對方隊伍送出問題的時間太晚，故暫不做回答。

PSP2.1	header 2	預估耗時（分鐘）	實際耗時（分鐘）
Planning		50	30
· Estimate	·估計這個任務需要多少時間	20
Development	開發	150	120
· Analysis	需求分析（包括學習新技術）	60
· Design Spec	· 生成設計文檔
· Design Review	· 設計複審
· Coding Standard	· 代碼規範 (為目前的開發制定合适的規範)
· Design	· 具體設計	40
· Coding	· 具體編碼
· Code Review	· 代碼複審
· Test	·測試（自我測試，修改代碼，送出修改）
Reporting	報告	10
· Test Repor	· 測試報告
· Size Measurement	· 計算工作量
· Postmortem & Process Improvement Plan	· 事後總結, 并提出過程改進計劃

|合計||240|300
           

第N周	新增代碼（行）	累計代碼（行）	本周學習耗時（小時）	累計學習耗時（小時）	重要成長
1	666		15		複習c++，學習單元測試和代碼覆寫率，學習git
2	97	763	4	19	沒什麼成長，就是在優化代碼
3		29	閱讀《建構之法》第三章和第八章，學習使用Axure RP8，了解原型設計的方法
	197	960		49	進一步學習爬蟲（了解beautifulsoup使用、學會使用正則），學習使用git進行團隊協作，學習使用NodeXL，了解flask
...
9	410	1370	24	73	學習JavaWeb、Android、sqlite，對後端工作有了更深的認識
		1410	6	79	更深入學習Androidstudio的使用，學習接口
11	315	1725		94	簡單地做了一個網站，對javaweb資料傳遞展示處理了解加深
12	70	1790		100	學了一點web，部署伺服器