心有猛虎，細嗅薔薇——楊榮模傑和他的佶祥虎

時間 2020-05-09

標籤心有猛虎薔薇简体版

原文原文鏈接

@css

這個做業屬於哪一個課程	課程連接
這個做業要求在哪裏	做業要求的連接
團隊名稱	楊榮模傑和他的佶祥虎
這個做業的目標	團隊的我的學習總結、整理資料

1、項目發佈地址、登注/下載地址

項目github地址	網頁端登注/APK下載
網頁github項目地址	網頁版登注地址
安卓github項目地址	安卓apk下載地址
人臉識別項目github地址	無實體

2、網頁端 / 安卓端簡要說明

1. 網頁版操做簡明：

爲不出現兼容問題，但願使用Chrome瀏覽器訪問，可能被提示警告信息，請選擇高級->繼續訪問html

第一次使用請選擇「註冊帳戶」
（建議使用試用帳號，不然請聯繫我贊成您的帳號申請；註冊上傳照片時請注意照片要有人像，不然會失敗）
前端
進入主界面後，右方選擇「啓動攝像頭」，開始攝像後點擊「開始打卡」便可開始識別（必須是是自行註冊的帳戶，已上傳照片纔可進行識別）
node
- 點擊打開攝像頭，而後點擊開始打卡，在後端確認前顯示正在認證
  python
- 人臉識別非本人，打卡失敗
  react
- 人臉識別成功後，提示進入ip驗證
  webpack
- ip驗證失敗後提示必須鏈接指定wifi
  git
- 不開攝像頭直接點擊開始打卡，提示服務器錯誤
  程序員
開始、結束打卡es6
- 打卡成功頁，狀態由未打卡變爲已打卡
  當斷開指定wifi 「LC」後，將自動斷定爲離線
左側欄選擇「數據統計」，能夠看到目前作出的一項數據可視化功能
基本設置（文本信息）
更換頭像
【帳戶】->【用戶設置】->【基本設置】->
copyright
自定義UI風格
用戶管理
更多請自行體驗

2. 安卓端安裝及操做簡明：

安卓apk下載地址，下載以後，直接容許安裝便可（EMUI可能會讓容許QQ安裝應用，都點擊容許便可）
若不在樂程團隊wifi範圍內，建議使用83端口版本（該版本能夠非指定wifi環境打卡），首次使用請先註冊（若已在網頁端註冊則能夠直接登陸）
進入主界面是打卡排名，能夠選擇「同級」看到與你同年級的打卡排名狀況，選擇「所有」則不分年級
選擇我的欄能夠看到有打卡、中止打卡等功能
更多功能請體驗

3、隊員我的信息及總結博客連接

學號	姓名
201731103226	翟仕佶	翟仕佶我的博客
201731062517	曾中傑	曾中傑我的總結博客
201731062424	楊模	楊模我的總結博客
201731062632	鄧高虎	鄧高虎我的總結博客
201731062624	張祥	張祥我的總結博客
201731062224	陳遠楊	陳遠楊我的總結博客
201731062420	胡思榮	胡思榮我的總結博客

1. 曾中傑我的總結

後之視今，亦猶今之視昔。 -王羲之

回望開學到現在的結束博客，就像王羲之的話，沒有什麼值得感嘆的，後來的人看待今天，就跟今天的人看待之前同樣。有的人爲了分數高，洋洋灑灑寫着本身的博客做業，有的人不在意結果，安然於得過且過，還有的人只專一於本身的提高...

按照博客要求，回望第一次的我的做業：連接->第一次博客做業，作了一個對稱模式編寫本次博客：

1.1 於我而言是否有一些收穫呢？

答：那時本身書寫下的目標是：但願能略懂《構建之法》，運用其精美的內涵豐富本身的程序人生，尤爲寫到「本次做業從開始使用博客，讓我認識到寫博客對程序員的學習相當重要，以及應用書中的構建美妙，尤爲是後面的「敏捷流程」的內涵，使得我受益不淺。」

事實也確實如此，敏捷流程甚至被咱們小組運用在了項目的實際開發中，它的敏捷之美相信每個組員都有所感覺到。固然，實話實說，你們都說咱們小組編碼起來很輕鬆，但其實不能說你們都很厲害，而是由於咱們每一個人都是負責任的人，遇到了問題本身立刻去解決，很在意與其餘人的配合，才使得整個小組看起來很「輕鬆」。這是其餘人難以瞭解的。

綜上所述,個人收穫就是敏捷開發運用於實際，體會到了敏捷開發的編程之美，這也算略懂《構建之法》？

1.2 第一篇博客的自我介紹？

答：那時並不想多麼介紹本身，簡簡單單描述了本身社會角色，由於在我看來了解一我的是須要主觀接觸的，無論一我的怎麼去自我介紹，別人只會以他的方式度量你。寫了這麼多的博客，已經跟助教，老師們也有了必定的交流，相信他們可以比自我介紹階段更瞭解我一些。

1.3 第一篇博客的閱讀與思考？

答：這一部分都是本身的肺腑之言，從如何選擇這個專業到離成爲一個合格的本科畢業生，在專業知識、技能、能力上還差距哪些？這些問題變化都不大，可是也許別人在通過這一個學期的對個人瞭解後，可以更加理解當時本身寫下那些回答的緣由。固然有的問題的答案仍是有些改變的，好比本身學會的技能如今又多了一些：《構建之法》、《安卓開發》、《Linux基礎》...這都是這學期的收穫。

1.4 第一篇博客的提有質量的問題？

構建之法12.1.2中提到理解別人的處境，心境，動機的能力是同理心，軟件團隊的設計師和軟件工程師也須要同理心。我就在想站在別人的角度去考慮問題這點是很好的，可是做爲軟件工程師的話若是都從別人的角度去考慮本身軟件設計的因素的話須要考慮的角度就會特別多，例如設計者，用戶，上層等等，並且每一個角度看到的東西又都是大相徑庭的，這時候咱們要怎麼作才能更好的兼顧全局？

答：這一部分其實就是項目經理和軟件開發者之間的矛盾，在我最近看到的一本書《騰訊傳》就講到了，最厲害的項目經理馬化騰和他的軟件開發者之間產生矛盾的時候，最後由誰提出誰負責的原則，只要你們不是特別反對，那麼你就去負責你提出的設計，最後結果產生再來看效果也是蠻不錯。

同時，這樣的話會浪費更多的時間去調試，咱們又該怎樣在規定的工期時間內完成用戶的種種需求，這顯然是很是很是麻煩的，要作好一個知足所有要求的軟件顯然是不現實的，咱們又該怎麼取捨?

答：這個問題其實和上面的問題不謀而合，若是時間不夠能夠經過線上測試，內測版本間接測試去解決。要作好一個知足所有要求的軟件確實是不現實的，任何好的功能都須要用戶的反饋才能進一步發展。

12.5中向咱們提了一個問題：什麼是用戶體驗何時開始考慮用戶體驗？從不一樣時間段去考慮用戶體驗顯然會帶來不一樣的問題，那存不存在一個最好的時間點呢？

答：最好的時間點就是可以讓用戶體驗的時候，就讓用戶體驗，越早問題發現的越早，越容易解決，其實就跟單元測試原理相似，一個一個地保證方法函數的正確性，組合起來的正確性也相對提升。

14.1.1中提到軟件質量=程序質量+軟件工程質量軟件工程的質量又有三個特性：好，快，便宜。那麼假如一我的或者一個團隊開發軟件的過程當中過無法作到這三點，我認爲最重要的是好，但想了想，在規定的工期內既然無法作到快，那也很難作到好了，那麼對於一個軟件開發過程，這三點那一項是相較於其餘兩項要更佔主導位置的呢？

答：在我看來，沒有誰佔主導位置，都是相輔相成的結果，惟有各方面都有運行體現，總體軟件的發展更爲穩健。

書16章在介紹產品了，其中舉了個魔方創新的例子，魔方產業中出現了種種的競爭者，笑到最後的確是那名技術不夠硬，產品不夠好，出現時間不夠長的一位，只由於他作到了客戶的需求。那麼我就在想，在現實社會中一個產品的營銷中也會產生不少不少的競爭者，咱們可以支抓住目標用戶的需求就能夠脫穎而出嗎，在這以前不須要磨練出過硬的技術生產出過硬的產品嗎？

答：只能抓住目標用戶的需求但沒有過硬的技術，是一件悲哀的技術，不是說不能找別人作，可是本身沒有本錢，周圍也不多有厲害的人。就想馬化騰的創業路途同樣，他在工做階段弄傳呼機的時候就已經有過硬的技術而且弄過過硬的產品，發現了一個好的用戶需求，就去找了有過硬的技術的同伴一塊兒開發出了QQ。過硬的技術是軟件開發者的本錢。

2. 陳遠楊我的總結

第一次做業地址

2.1 回顧課程

我以爲軟件工程不是簡單一門課就能真正瞭解的，這門課只是帶我走進了軟件工程的大門。

對於之前的問題，我有了部分答案。我如今認爲軟件需求最須要的是解決最須要的功能，其餘的都是以後決定的了。知足核心功能纔是最重要的。在項目開發以後，看見你們作的項目後，本身有了新的疑問。咱們作的項目或許作了需求分析，知足用戶的需求。可是用戶真的有必要去知足這些需求嗎？用戶真的有必要去解決這些需求嗎？在知乎上有個相似的問題就是："當代大學生應用軟件過多你怎麼看？"好比易班，盜夢空間等APP這些軟件的的確確能解決當代大學生的需求。可是有幾個大學生真的想用呢？若是咱們班作的項目真的可以推廣出去，而且獲得更好的優化。是否真的能有用戶滿意？咱們是否過分知足用戶需求？或許這就是微信能搶佔QQ的用戶的緣由之一吧。進一步說就是咱們真的有必要開發這種知足用戶需求的項目嗎？

2.2 課程總結

通過一學期學習，除了對軟件工程理論上的進步外，我我的以爲並無什麼其餘大的進步。其實咱們組的項目在分組一個星期就已經完成了大部分開發了，以後的時間花了一小部分去對接，其餘時間都是在各自優化。我感受就是一次，普普統統的項目合做經驗。可是這學期的硬性要求寫的博客（我我的是特別煩的~~）對此次的項目開發過程當中有了很大幫助。讓咱們在項目進行過程當中，明白接下來要作什麼，哪怕是一件很微小的事情。可是咱們至少知道要作什麼，有了每一步的規劃。這是我之前作項目所沒有的。體會到「寫博客」對項目開發帶來的巨大便利，這算是這門課程給我帶來的最大的收穫吧。

3. 鄧高虎我的總結

第一次的博客做業連接

3.1 對於曾經提的問題的回答

第一章1.1 軟件 = 程序 + 軟件工程,這裏如何去衡量二者之間的平衡關係,或者是說哪一部分在實際的項目開發當中佔主要成分,在有限的時間以內,如何作到二者兼得?

首先是軟件工程的定義:就係統化的,嚴格約束的,可量化的方法應用於軟件開發,運行和維護,即將工程化運用於軟件.一個優秀的軟件是和軟件工程完美結合的.不存在誰更重要的問題.

第二章2.1 單元測試必定要做者本身寫嗎？若是是由其餘人進行測試,開發人員須要寫一份完整的開發文檔麼?

元測試是一種提升軟件質量很是有效的方法，但很重要的是咱們要去實踐和體會。在現代的敏捷軟件開發方法論只，都很是強調單元測試的重要性。相對專門的測試人員而言,軟件的開發者者更熟悉本身的程序,開發者須要完成基本功能的驗證,以提早發現bug並及時解決.

第二章2.12中提到了代碼覆蓋率，那麼什麼是代碼覆蓋率？

簡單的說，覆蓋率是指咱們代碼在測試中可以被覆蓋的程度。因此，覆蓋率理論上來講越高越好，代碼覆蓋率高說明咱們的每一段代碼都通過了測試，獲得了預期的答案。但咱們也不該該太糾結於代碼覆蓋率的高低，客觀地說：
並非越高的代碼覆蓋率表示代碼質量越好BUG越少
代碼覆蓋率高只能表示代碼都被測試過，可是否可靠並不肯定
雖然高的覆蓋率並不必定是好代碼，但覆蓋率低很大程度上代碼質量會有問題
沒有覆蓋的代碼應該引發咱們的重視，有存在問題的風險

第三章3.3 職業發展的方式不止一種,如何選擇適合本身的一條路,或者是在多種方式之間如何平衡?

將來展望。長遠來看，實現職業生涯的跨越須要鍥而不捨的激情。
1.考慮是否適合本身
2.付出與收穫是否成正比
3.堅持不懈地學習

第九章 9.5中,有這麼一句話."沒有風險，就是最大的風險".這句話該怎麼去理解,在本段以前剛剛對於風險管理水平進行了分層，那這句話是不是能夠理解爲：風險會從多方向來襲，企圖縮短軟件的生命週期，而所謂「沒有風險」只是沒有預見風險，而且沒有對其將來的風險狀況進行評估呢？

只要是投資行爲,總會伴隨着各類各樣的風險,甚至還有些不像是風險的風險.風險會從多方向來襲，企圖縮短軟件的生命週期，而所謂「沒有風險」只是沒有預見風險，而且沒有對其將來的風險狀況。

3.2 新的問題
有人認爲軟件開發時，一個錯誤發現得越晚，爲改正它所付出的代價越大。做爲項目經理，該如何管理本身的軟件項目？
通過這學期的學習，你掌握到了哪些之前沒有的技能，你是如何掌握的。
體會比較深的就是在於團隊開發和測試，之前都是小組內分模塊進行劃分工做，多我的同時開發一個效率可能會更低，如何作到結對編程的高效率其中有不少的學問．
其次就是軟件測試，之前作項目的時候，對於軟件的測試可能呢並非很到位，經過構建執法這門課讓我對於軟件測試有了一個新的瞭解．

3.3課後感覺

經過這門課程在必定程度上了解了什麼是軟件工程，如何去完成一個優秀的軟件以及如何去作到軟件的工程化管理和如何提升軟件的開發效率。軟件並不僅是簡簡單單地開發就完事了，在軟件開發以前必定要講需求分析作到位，明白用戶到底遇到的是什麼樣的軟件。
軟件工程包括幾個領域：軟件需求分析、軟件設計、軟件構建、軟件測試和軟件維護。所以這門課程的學習，就是把相關的技術和過程統一到一個體系中。而對這個體系的學習就是軟件工程這門課程的核心——如何提升軟件開發、營運、維護的效率，並提升軟件的質量、用戶的滿意度、可靠性和軟件的可維護性。

4. 張祥我的總結

4.1 問題

對於問題一
軟件開發人員忙於寫代碼，大可能是懶得測試的
對於問題二
如今企業須要的更可能是‘’T‘’型人才，而不是「 | 」型，好比前端工程師必須懂點後端，後端工程師必須懂點前端，這樣先後端才能高質量地協同開發
對於問題三
開發前作好基本需求分析，系統分析設計
對於問題四
pull request
對於問題五
其實不作優化也挺好的，代碼敲的特別爽
第一次博客地址
http://www.javashuo.com/article/p-otvswfzq-du.html

4.2 學會技能

寫做能力，學會用Markdown寫博客
前端開發能力，獨立構建前端應用
結對編程，協同開發
scrum開發，極限編程
單元測試

4.3 總結

不得不說，這個課程真是太牛逼了，本來我是一個連html，css都不會的小白，經過這個課程我掌握了html，css，js等開發技術，以及使用react，webpack，nodejs，and-design，es6,等技術利用模塊化組件化工程化的編程思想獨立開發一個先後端分離的項目，讓我熟練了git控制版本技術，體驗了團隊開發項目的魅力，我特別感謝開設這個課程的人，讓我學會了這麼多，也特別感謝助教們，真的特別負責，也感謝咱們的授課老師，他講課講得特別好，歷來沒遇到過講課講得這麼好的老師，最後再次感謝全部爲開設這個課程付出努力的人

5. 楊模我的總結：

第一次博客

5.1 對於第一次問題的解答

問題一：我在第三章55頁看了職業發展—考級之路這一段，有個問題「這些證書真的有企業承認麼？行業承認度怎麼樣？」，我查了一些招聘要求，發現行業對這些證書不太承認的樣子，個人困惑是「如今去考這些證真的有必要麼？他們的承認度不過高的樣子。」

答：其實還好，這半學期我也去了解過一些招聘的文章，也發現了不少HR仍是會對證書感興趣的，可是也不是很高，有證的必要性也不是那麼的高，可是也能夠做爲一個亮點，其次的話，有證也至關於對本身職業的一種承認吧！

問題二：個人困惑是「是否是咱們之後工做時寫代碼時只須要寫上徹底的註釋，而不用向上兼容代碼的使用者呢？」

答：經過這學期的團隊項目，我發現，關鍵的註釋是必要的，這樣會節省你和下一個來接手你代碼的人的大量時間，而對於使用者的話，你只須要保證本身的代碼不出錯，且告訴使用者如何合理的去使用這些東西便可。

問題三：「既然敏捷開發在國內受到文化差別的影響，甚至已經丟棄了敏捷開發所帶來的優勢，爲何這麼多互聯網公司仍是在樂此不疲的採用敏捷開發呢？」

答：在團隊項目的開發中，其實咱們也碰見了一樣的問題，隊員之間因爲陌生，以致於在每日站立會議的時候沒法給出合理的建議，也沒法合理的說出缺點，都過於委婉了，可是咱們也在其中收到了不少好處，敏捷開發的確能幫咱們開發出咱們想要的產品。這可能就是國內互聯網公司採用這種開發的緣由吧，畢竟花取少許時間就能獲取足夠的成果，這種開發模式又有哪一個老闆不喜歡呢？

問題四：身爲程序員如何明白的表達這個需求作不了之類的觀點？項目經理又如何讓一堆技術人員明白他的要求呢？又何以服衆呢？

答：這個仍是得說說，咱們組得項目組長其實也不太能理解其餘人的代碼，可是組長很是樂於聽取他人意見，並給出合理的對策，使得咱們在需求分析和需求確認階段的每一個需求都有專門的人去負責，故我認爲i，只要組長足夠服衆，就算他不是技術人員，也不礙事的。

問題五： 對於一個大型的，擁有足夠多用戶的軟件產品來講，這個軟件可能遇到的狀況，也是」荒誕「的。由於一個軟件開發者（團隊），永遠沒法在測試中窮盡他們設計的軟件會被怎樣的使用，和遇到什麼樣的情況。，可是，我仍是想問，是否存在一種標準去量化這些測試的有效度呢？

答：通過此次團隊項目，我認爲這種東西是沒法去度量的，由於咱們沒法知道咱們得系統到底有多少bug，因此沒法用數學去度量它，在咱們項目開發的過程當中，咱們每次都認爲此次的BUG徹底修復，可是老是有其餘新奇的BUG被其餘組測試出來。

5.2 是否產生了新的問題？

軟件工程的人如何快速的掌握寫文檔的技巧？
繁多複雜的文檔會不會佔用太多的編碼時間？

5.3 回顧

其實，經過這門課的學習，讓我掌握了不少軟件工程得過程方法這些，也明白了軟件工程爲何要叫軟件工程。瞭解到原來程序員也不僅僅的只是去負責編碼，在項目開始階段有着比編碼更重要的東西，明白了團隊間協做的重要性，掌握了墨刀等原型工具，知道在編碼以前如何向客戶展現他們所需求的東西。理解用戶需求，遠遠要比編碼重要得多。這些東西，都在課程中源源不斷的反覆練習着。

5.4 體會

學了兩年的軟件工程，直到這學期才知道咱們學的是什麼，爲何要去學，在學習的過程當中，的確由於做業出奇的多而各類抱怨老師，卻不知只有讓咱們本身去經歷一下才能讓咱們對軟件工程有更深入更全面的理解。其次呢，這門課讓我認識了不少人，不少志同道合的人，本身也掌握了不少和原來不同的技術，惟一一點的遺憾就是，此次的課程彷佛也沒有提升本身的編碼能力，不過編碼自己就不是這門課的重點，沒有鍛鍊到也在氣力之中。

6. 胡思榮我的總結

離別贈言

之前博客

對於如今來講，這兩次博客之間發生事情挺多的，個人方向也越加明確。我仍是很滿意當初對咱們專業的選擇，也在裏面學到了許多知識。通過長時間的學習，我深入意識到狹義的編碼能力並非最重要的，反而會掣肘咱們的步伐，軟件工程讓我體會到，工程對於軟件行業的重要。

這學期我拓寬了個人朋友圈，也認識了更多的人，他們方向各不相同，但都有特色，有一個就是他們方向明確。咱們大三了，立刻面臨着考研，找工做的煩惱，這是不一樣於其餘時間的，而我選擇出國留學，爲了更深刻的學習，但願可以獲取更多的知識，也但願晚一點離開。

在我心中，編碼能力是次要的，因此我更傾向於更多的學習，固然，代碼量不能少，我也喜歡編碼。

對於我來講最大的問題是不能平衡學校的學習，和本身學習之間的矛盾，結課以後會輕鬆一點，我也想

投入更多的時間在英語學習上

回顧以前

1.人工智能實際是多領域的結合，確實是軟件工程的產物，軟件工程同其餘工程的區別在於，對軟件工程更傾向與人，爲了更好的做用於人

2.任何的發現都不是偶然的，各個領域之間的聯繫也會有不一樣的，相互推進，相互發展，微積分也推進了計算機產業的發展

3.擁有並不表明成功，咱們要掌握管理與發展的平衡，不能顧此失彼，當達到平衡以後會呈現出更蓬勃的生命力

原本人爲因素也不是公司所能表達的，宏觀的調控能夠確保總方向的肯定和人爲影響的不肯定性

道德在某方面也會根據法律而定，並非一昧的惟心，在法內道德，法外守德才是最好的作法

7. 翟仕佶我的總結：

連接：第一次我的做業

7.1 對本身提出問題的解答

問題1：第四章兩人合做。書上68頁

提到註釋使用的字符應該只用ASCII字符，不然會影響程序的可移植性，這裏我不是很懂，一是移植性，二是爲什麼使用ASCII字符。想起以前在使用GBK編碼後去其餘平臺會出現亂碼，提倡只使用utf-8字符集，這二者有什麼關係或者衝突麼？

回答： 移植性是指使用高階語言寫成的軟件，在不一樣環境下，是否具有能夠被重複使用的性質。打比方說在個人PC上能運行的程序，在美國的一個不一樣計算機上可否正常執行。ASCII畢竟是計算機最基礎的字符集，因此用ASCII註釋的移植性沒有什麼問題；而utf-八、utf-16等編碼都是基於Unicode字符集的不一樣映射結果，若是有的電腦底層沒有的Unicode字符集，移植後就白瞎...你就慢慢整吧。

問題2：第四章兩人合做。書上69頁

4.3.2小標題，認爲函數最好有單一的出口，爲了達到這一目的，能夠使用goto語句，但是以前咱們接收到的思想是goto語句破壞了程序結構，使程序可讀性變差，儘可能不要有goto語句。如何權衡？

回答： 這一點在我和朋友作結對編程的時候深有感觸。咱們爲了追求性能，不只使用了C++，尚未用正則表達式，致使算法比較複雜。不過即便未優化時代碼有些冗餘，咱們也堅持不搞多個程序出口，保持了程序出入口只有一個這個好習慣。因此我認爲在時間不是特別緊張，代碼邏輯不會因不寫goto語句就很是複雜的話，能不寫就不寫。

問題3：八章需求分析。書上155~156頁

在談到作用戶調研時使用的焦點小組方法，提到討論者對於他們不熟悉的事物（如全新市場，顛覆式的創新）不能表達有價值的想法，那麼該如何作需求調研呢？用相似事物誘導討論者麼，那這又是另外一個弱點——討論者容易受到主持人有意或無心的影響。因此，該如何作呢？

回答： 這個問題彷佛當時問的有點太刁鑽了哈哈（沒想到本身要回答了）。從本次咱們團隊項目，我的角度看與其說解釋很長時間，不如先作個有核心功能的成品原型出來，拿給用戶先試用一下。

問題4：第六章敏捷流程。書上117頁

提到Scrum Master不是一個官，而是一個沒有行政權力的溝通者，還要在團隊中作具體的工做，那麼這個Scrum Master究竟是一個什麼樣的角色，技術力壓衆人的大牛麼？在團隊中是否還須要負什麼重要責任呢？

回答： 技術並須要力壓大牛，好比咱們這個七人團隊六我的都很能打，而我這樣的技術菜雞，在項目中的編碼工做相較輕鬆（要麼就是較簡單的任務，要麼就是複雜任務作很差還能夠請教他人）。做爲Scrum Master / PM，我最主要的任務是：安排例會、瞭解進度、督促和協調任務和撰寫各類報告等，不能由於某我的的工做僵住了影響到總體的進度。

問題5：第十一章軟件設計與實現。書上226頁

ERD的小標題彷佛有點小問題，ERD應該翻譯爲「實體聯繫圖」而不是「實體關係圖」

回答： 這個已經獲得數據庫老師的回覆確認了，不過這是小事，無傷大雅。

7.2掌握到了之前沒有的技能，是如何掌握的？

最大的收穫就是使用git和github了。

真不是一次性掌握的！每次用完都忘，也遇到了各類push出錯問題——文件太大、網絡很差、沒有權限等等。
這裏感謝(da lao)楊模同窗，一遍遍的教我。

對C++及其編譯器VS的使用更上一層樓。

結對編程中，我主要負責面向過程，陶一同窗更面向對象。
無論是命令行仍是MFC，都是他編碼，我觀賞的，因此跟着他學了很多東西。
VS作C++效能分析也是獲得了鍛鍊，由於網上C#效能分析多，C++不多，咱們花了很長時間才搞定一個VS編譯器的莫名其妙bug。

學會了python web框架一些基礎知識

起碼我知道怎麼把機器學習成果展現在網頁上了。
再次感謝(ju lao)楊模同窗，一遍遍的教我。

知道了一些博客園美化方法、畫燃盡圖等等

固然了，做爲每次都要寫博客的PM，這些如今都是小事了。

7.3 新的提問

這門課讓你們很累，爲何？

首先我是以爲這門課一方面頗有意思，它不交給咱們技術，可是用一種新的開發模式（咱們團隊使用的就是Scrum）去讓咱們在大的實踐中去本身解決細節問題，可是一開始你們可能都不適應，不是合做的不適應，而是對團隊合做方式的不適應。
另外一方面我也相信，時間跨度、任務要求的冗長，技術應用上的不斷翻山越嶺，讓我身邊的同窗彷彿在跑一次馬拉松。也有一些很優秀、起點很高、領先好久的同窗忽然就說「算了算了」，固然，我發現他只是調侃，並無放棄。
固然究其疲憊的根本緣由，仍是同窗們太多太想作好。

7.4 深入體會與總結

寫代碼的角色
我終於將本身的所學知識轉化爲了對項目的貢獻。
做爲一個Python/C++愛好者，基本沒啥機會作一些我稍微擅長的點的事，身邊的大佬幾乎都是精通Java web，以往作的小組項目或是參加比賽都是這方面，我只能抱緊大腿划水。可是此次不一樣了，當團隊有打卡需求，而人臉識別又是網上隨處可見的關鍵詞時，咱們的項目就是一個很天然的一個鏈接整合，實用且不失新穎，隊友也很給力，這個過程使我體會到從未有過的存在感。
作PM的角色——感謝隊友
很是高興能與個人隊員在一塊兒作項目，這也是我作的最舒心的一次團隊合做。每次立會都能有新穎的想法，每次安排任務時能夠提出給本身安排挑戰的任務，最後也可以將本身的任務作的優秀。不只僅是由於個人隊友都是各自技術方向上的佼佼者，使咱們的項目進度飛快。
合理的團隊溝通和有安排的任務分工比實際能力更重要，我很高興咱們選擇了正確的方式，一個團隊分紅三個組先各自完成最初的模塊。在這個過程當中，web組有很好的交流與溝通，工做也不會被後勤組所打斷；在web組完成網站框架後，安卓組獲取了接口，後勤組暴露了接口，各類的功能天然而然交叉上線。做爲PM，我也感覺到了團隊的凝聚力和執行力。

8、項目資料——上傳至github

web前端

github：web前端點擊跳轉

使用方法

ctrl+c複製上面的網址
安裝git（這裏就不介紹了）
打開git-bush界面（怎麼打開就不介紹了）
隨便找個目錄cd進入
輸入 git clone 而後按下ctrl+v(粘貼),而後按回車，（必定記得按回車否則命令運行不了）
克隆完成後，安裝nodejs（不介紹，自行百度）
進入剛纔克隆項目的根目錄，按ctrl上面那個shift的鍵+鼠標右鍵，選擇在此處打開命令行窗口
輸入npm start命令，過一下子你就能看到瀏覽器跳出來的頁面了
部署輸入npm run build 過一下子就生成一個打包的dist文件夾（怎麼用自行百度）

web後端

github：web後端點擊跳轉

安卓端

github：倉庫地址點擊跳轉

安卓端只須要安裝APP便可，已經適配了市場上絕大部分安卓10的系統。
項目APP分爲兩個版本
下載地址爲
https://github.com/chenval/ThePunchSystemAndroid/tree/master/app/release
版本1 83：能夠不須要在特定網絡壞境下打卡，便於測試。
版本2 80：最終版本，須要在特定環境下
全部資源絕來自於服務器端，只要安裝APP 鏈接網絡便可。