作業基本信息
| 這個作業屬於哪個課程 | 課程鏈接 |
|---|---|
| 這個作業的要求在哪里 | 軟件工程實踐總結&個人技術博客 |
| 這個作業的目標 | 回顧與總結實踐歷程 |
| 其他參考文獻 | 《構建之法》 |
課程回顧與總結
回顧問題
之前提問的博客鏈接
問題分析
- 問題一
一個軟件如果僅僅用於一時演示而沒有投入全面應用。甚至在演示之后基本就不會再繼續使用了，那么這些程序在開發的過程中還有必要嚴格按照常規的開發流程嗎？
引用助教的解答：應該沒有必要，這樣的軟件目的就是快速開發出來驗證需求的，如果按照流程一步一步來，這樣其實很不划算。
助教的解釋十分清楚，軟件開發流程目的就是為了提高軟件開發、運營和維護的效率以及提升用戶滿意度、軟件可靠性和可維護性，而如果軟件作用僅是用於一時演示可以為了節省時間快速開發，盡早地驗證需求、避免周期長的流程影響開發進度。
- 問題二
結對編程時，若兩人的能力水平差距較大，應當如何協調磨合從而更加高效地進行編程呢？
結對編程，雙方寫的代碼不僅是給自己看的，也是給對方參考和復審的。水平差距大的兩人結對編程，在編碼前應當對一些約定達成共識，例如編碼規范、注釋規范，方便之后復審，減少后期磨合工作的負擔。編碼的過程中避免英雄主義，建立集體精神，互相督促。
水平差距較大的時候可以使用后座領航員模式結對編程，水平高的程序員接管更多策略上的工作。駕駛員在鍵盤前坐着，執行諸如寫代碼的工作，后座領航員下達的是更細致的指示，駕駛員就負責寫代碼，瀏覽文件，還有基礎實現方法。領航員則着眼更長遠的考慮並且檢查錯誤。結對的編程過程中，初學者在按照專家指示做事的過程中得到學習，學習的過程中雙方不斷磨合與影響。
- 問題三
初級軟件工程師的成長可以體現在對通用的軟件設計思想和軟件工程的思想理解，那么可以用什么方式來評估一名軟件工程師在這一方面的水平高低？
根據鄒欣博客中《軟件工程師能力自我評價表》的博文中，評估軟件工程師的能力可以通過以下方面：
- 基本數據結構和算法問題
- 硬的問題，對於編程語言等具體技術方面掌握程度
- 軟的問題，在成長路上學到了什么
- 團隊管理源代碼的水平
評價軟件工程師水平高低並不是通過單一指標，而是在多維度上綜合分析考量。
- 問題四
在之前設計用例時，我使用UML圖形來分析的次數比較多，而文字內容較少，故事有哪些圖形不具備的優勢嗎？
用簡單的故事描述用例，可以讓團隊成員對需求有統一的了解，並且故事使用文字描述，可以增加一些圖形不具備的細節，可以通過故事逐步構建整個系統的功能需求。故事包含背景、角色、目標，符合現實用戶與程序交互的場景。描述內容非常適合交互式的系統。
- 問題五
可是在軟件開發之初就可以確定自己潛在的忠實用戶嗎，實際市場中有什么策略可以有效地招募粉絲、培養忠實用戶並提高用戶忠誠度呢？
維護老客戶、開發新客戶是最關鍵的，所以只有不斷提高客戶對企業的信任、忠誠度，才能在市場上占的一地之席。
除了用戶需求，軟件質量很重要，任何實體或許虛擬的產品都首先需要有過硬的基本功。一個好的開場白一定會提升你的成功機率。也就是說，新用戶如果第一次使用你的軟件獲得好的體驗時，那么留下來的可能性就會非常大。
上手學習難度不能復雜。對於很多新開發的APP產品，多數用戶都是小白級別的，如何正確的使用操作也會影響用戶的感受。特別是游戲類和購物類的APP，新手教程設計的繁瑣冗雜必定會讓用戶失去耐心，甚至開始吐槽。
及時反饋用戶的意見。要想提高用戶的忠誠度，服務很關鍵，忠誠度並不是一次的交易就可以形成的，而是通過用戶一次次的使用，不管在那種情況下遇到問題，開發團隊都能及時站出來解決問題，讓用戶知道自己是和開發團隊站在一起的。
各階段收獲
需求
需求分析的重點在於以用戶的角度思考用戶到底想要什么，使用的場景有哪些。作為開發者團隊，很難基於自己的經歷和身份完全站在用戶方面，沒有遺漏地思考。還是需要收集用戶的喜好、做好用戶故事分析、信息收集明確自身產品定位，對於需求有明確的定義，不宜太過籠統，從而影響后續設計和編碼工作。
設計
根據需求分配模塊。做好數據庫、代碼規范以及接口的規范，完成各個模塊的設計，成員之間做好約定，避免后續成員接口不一致導致返工從而增加工作量。
實現
閱讀微信小程序接口文檔，學習到小程序的運行原理和程序結構。主要實現了小程序雲函數的編寫和部署，與前端成員交流定義好接口，獲取用戶的相關數據並且展示，順利實現對接，調式雲函數是通過本地調式，經過初步調試之后再部署到雲端，供小組內進行進一步的測試，鍛煉了和各個組員的溝通交流能力，更有效地溝通有助於團隊開發的高效進行。
發布
在項目進行時應當盡早了解產品發布的相關規章制度。小程序個人發布不允許用戶的社交功能實現，在alpha沖刺時並不知情這個政策，從而導致發布前夕匆忙地刪除了小程序內的相關模塊，在申請到企業認證時再次提交這些模塊，如果早點知道發布的相關政策就能避免這種事情的發生，也能避免一些其他意外情況。
理解與心得
個人項目
寒假作業的要求讓我重新審視了自身的學習經歷和編程經驗，思維導圖和學習路線也讓我在新的一個學期有一個明確的目標和學習方向。
在做編程作業，看到作業要求的時候，我覺得作業的要求比較簡單看起來容易完成。等到我開始做的時候我才發現，要考慮到的細節還是很多的，不僅在編程的時候要思考有沒有效率更高的方法，還要考慮編寫出的函數是否足夠可靠，能禁得起多次測試。做到后面又覺得其實只要把這個任務划分成多個小任務一塊塊完成的話，其實也沒有那么復雜，對軟件單元測試讓我了解到，測試一個程序的可靠性，需要花心思考慮各種包括異常在內的所有可能的情況。
個人編程作業讓我接觸GitHub的更多操作，使用GitHub委托自己的代碼感覺十分方便，做到哪一步覺得開始亂了可以回退到之前之前沒有問題的一個版本，GitHub給代碼管理帶來了便利。
結對編程
結對編程的作業有兩次，第一次主要在於網頁設計，對於編碼沒什么要求，雙方統一好風格和頁面大致布局以后各自負責各自模塊。雙方審視着對方的工作，有什么不同的意見可以相互交換進行取舍。遇到困難也能互相幫助，這讓我對團隊合作有一個初步認識也讓我明白結對合作的好處。
第二次結對編程是真正開始進行雙人編碼的工作，這次的結對項目我在重溫Python的Web框架同時，也學習到了如何使用Ubuntu系統的雲服務器部署Python的Web項目，同時還深刻認識到到在兩人同時進行一個項目時有效的溝通，比具體的埋頭編碼更有效率，團隊分工有時候可以做到1+1>2的效果。由於是進行同一個項目，以前遇到一個小問題可能就要折騰大半天，效率十分低而且也沒學到什么新東西，現在兩人進行同一個項目，可以直接向對方提問往往能更及時得到有效的反饋。這次結對編程的過程，對我也是共同學習小項目如何互相交流分工、兩個收到二人小團隊的驅使，互相學習新知識的過程，第一次實現在服務器部署項目也讓我有一種無法言喻的成就感。
團隊項目
團隊成員都很積極地參與進項目的設計和編碼的工作當中，讓我在進行功能實現的過程中有一種特殊的參與感、歸屬感。
盡管最后做出來的東西並不完美，還有缺陷之處，但我在團隊合作編程的過程中學習到了很多之前並不了解的知識，還是收獲滿滿的。
個人技術總結
技術概述
微信小程序調用雲函數，通過調用雲函數訪問數據庫得到需要的數據並返回結果。