軟工網絡15我的做業4——alpha階段我的總結

1、我的總結

在alpha 結束以後， 每位同窗寫一篇我的博客， 總結本身的alpha 過程；
請用自我評價表：http://www.cnblogs.com/xinz/p/3852177.html 有比較纔會有進步。

（1）

類型	具體技能和麪試問題	如今的回答
語言	拿手的語言	很沒有底氣的回答：JAVA。此外爲了程序的測試，學了一點點Python
軟件實現	有沒有在別人的代碼基礎上進行改進？ 你是怎麼讀懂別人的代碼？ 遇到的bug是什麼，怎麼解決？ bug出現的緣由，應該如何避免？	1.常常的事情。 2.通常寫的規範的代碼都是看的懂的，先根據註釋大致看一下實現的功能，而後再詳細閱讀。實現看不懂的就說一句：「兄弟解釋一下？」 3.bug會有不少緣由，有兩種緣由最讓我頭疼。第一點，糟糕的命名致使最後亂成一團。第二點，邏輯問題，這是很要命的本質問題。 4.至於避免，我以爲是由於缺少經驗致使的，須要多累計經驗
軟件測試	你是怎麼測試本身的代碼？怎麼測試別人的代碼？	1.進行JUnit單元測試，市面上有測試工具來進行性能測試、壓力測試等等。 2.測試別人的代碼，就是先讀懂別人的代碼，如同轉換成本身的東西，再進行一樣測試
效能分析	你是如何測量代碼效能的	進行多種測試，好比性能測試、壓力測試等
需求分析	你作過多少個有實際用戶的項目？ 你的項目有什麼創新的地方	1.有實際用戶的項目是咱們目前開發的微信記帳小程序 2.他的創新之處在於能夠作預算，計劃天天的能花費的錢，並根據實際花費（超支或者剩餘）對接下來天數的可用金錢進行調整
行業洞察力	你最感興趣的領域是什麼？你分析過這個領域前十的產品嗎？請分析一下他們的優劣，你要進入那個領域，如何創新	人工智能吧。最讓我印象深入的是去年末索尼公司只是面向日本市場推出的robodog系列機器狗，每隻售價1800美圓 。最突出的一點是，該款產品結合AI技術可以準確識別出主人並在互動過程當中感知主人的情緒。換言之AIBO機器狗經過傳感器可以具有強大的養成能力，感知到主人的喜愛並調整本身的性格及互動行爲，成爲每一個主人身邊獨一無二的AIBO。它的優點是在於再也不是冰冷的機器，而是可讓主人對它產生感情，而且進行情感互動。至於創新，應該就是基於人性化的設計尤其關鍵吧
項目管理	1.你參加過項目管理麼？請描述一下兩個當下流行的開發方法在你的項目中的具體應用狀況。 如何決定各個任務的優先順序，有什麼理論來支持你的作法？ 若是項目不能及時完成，做爲項目領導，有什麼辦法？	此次的軟件工程的項目開發最重要的任務之一就是項目管理，我想不少團隊包括咱們團隊，都是採用「主治醫師」的團隊模式(不排除一些團隊用的是"明星模式";在衝刺階段採用的是敏捷開發。你們各自其職。 2.PM老是在宏觀調控你們的任務與進度，優先順序天然是把最基本的、適合全部人的功能放在首位。 3.若是不能及時完成，那咱們就會選擇退而求其次，放棄附加功能，盡力完善基礎功能
團隊協做	描述你在項目中如何說服同伴採起你更好的方案，或是聽取別人的意見改進本身的方案，如何說服懶惰的同伴加緊工做，或者如何聽取了別人的意見，改進了本身的方案？	沒有出現誰說服誰的狀況，遇到問題你們都是一塊兒討論，找到一個好的解決方案，衝刺階段項目經理及時跟進，讓咱們順利趕出進度
理論素養	你上過什麼數學，計算機或是理論課，舉出具體的例子，如何幫你解決問題	高等數學，C語言，JAVA等，聽說算法課程頗有用，惋惜我沒有選，這些課都是很基礎的課，編程能力越高衝刺階段的敏捷開發就越輕鬆
自我管理	整年級你專業排名多少？你從剛入學（大學一年級）到如今的排名有變化麼？如何解釋你的排名變化？	1.二十幾名 2.大一是四十幾名，大二是三十幾名，整體來講是在進步的，給本身朵小花 3.用在學習的時間上多了，再也不抱着「及格就行」的心理

（2）自我評分很難，我以爲我纔剛走進這個"世界"有不少東西要學，無窮無盡

技能	課前評估（0——9）	課後評估（0——9）
對編程的總體理解	3	4
程序理解	3	4
架構設計、模塊化設計、接口設計	0	2
模塊實現、逐步細化	0	2
單元測試、代碼覆蓋率	2	6
效能分析和改進	0	4
代碼複審/代碼規範/代碼質量	2	6
JAVA	3	5
WEB	0	2
我的源代碼管理	5	6
我的軟件過程	5	8

（3）

技能	自我評估（0——9）
對編程的總體理解	4
程序理解	4
架構設計、模塊化設計、接口設計	2
模塊實現、逐步細化	2
單元測試、代碼覆蓋率	6
效能分析和改進	4
代碼複審/代碼規範/代碼質量	6
JAVA	5
WEB	2
我的源代碼管理	6
我的軟件過程	8
需求分析，典型用戶，典型場景，創新	7
測試方法、測試工具	5
數據庫	5
美術	5
自主學習能力	8
計劃任務	9
質量要求，定期完成任務	10
協同工做	10
報告項目狀態	10
在第一線寫代碼的時間	6
寫代碼的大體行數	5
所寫軟件用戶量	8
所發佈軟件的質量要求	7

（4）

編號	問題	個人回答
1	保持高標準，不要受制於破窗理論(broken windows theory)[i]。當你看到不靠譜的設計、糟糕的代碼、過期的文檔和測試用例的時候，不要想 「既然別人的代碼已經這樣了，個人代碼也能夠隨便一點啦。」	不但主動作， 還會影響同事一塊兒作好
2	主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想「可能別人會來管這個事情」 ，或者「我下個月發一個郵件讓你們討論一下」。要主動地把問題給解決了。	不但主動作， 還會影響同事一塊兒作好
3	常常給本身充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。經過按期分享（面對面的分享，寫技術博客等）來確保本身真正掌握了新技術。	不但主動作， 還會影響同事一塊兒作好
4	DRY （Don't Repeat Yourself）——別重複。在一個系統中，每個知識點都應該有一個無異議的、正規的表現形式。	不但主動作， 還會影響同事一塊兒作好
5	消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。	不但主動作， 還會影響同事一塊兒作好
6	經過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你經過快速原型學到了什麼。	不但主動作， 還會影響同事一塊兒作好
7	設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。	不但主動作， 還會影響同事一塊兒作好
8	估計任務所花費的時間，避免意外。在開始工做的時候，要作出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工做中要告知可能的時間變化，過後要總結。	不但主動作， 還會影響同事一塊兒作好
9	圖形界面的工具備它的長處，可是不要忘了命令行工具也能夠發揮很高的效率，特別是能夠用腳本構建各類組合命令的時候。	不但主動作， 還會影響同事一塊兒作好
10	有不少代碼編輯器，請把其中一個用得很是熟練。讓編輯器能夠實現本身的定製，能夠用腳本驅動，用起來駕輕就熟	還會學習和使用各類編輯器的擴展。
11	理解經常使用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，何時用，何時不用。	模式沒用
12	代碼版本管理工具是你代碼的保障，重要的代碼必定要有代碼版本管理。	不但主動作， 還會影響同事一塊兒作好
13	在debug的時候，不要驚慌，想一想致使問題的緣由可能在哪裏。一步一步地找到緣由。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在本身的代碼裏面加 log	不但主動作， 還會影響同事一塊兒作好
14	重要的接口要用形式化的「合同」來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來作事，很少也很多。使用斷言 (assertion) 或者其餘技術來驗證代碼中的假設，你認爲不可能發生的事情在現實世界中每每會發生。	不但主動作， 還會影響同事一塊兒作好
15	只在異常的狀況下才使用異常 (Exception), 不加判斷地過多使用異常，會下降代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。	不但主動作， 還會影響同事一塊兒作好
16	有始有終。若是某個函數申請了空間或其餘資源，這個函數負責釋放這些資源。	不但主動作， 還會影響同事一塊兒作好
17	當你的軟件有多種技術結合在一塊兒的時候，要採用鬆耦合的配置模式，而不是要把全部代碼都混到一塊兒。	不但主動作， 還會影響同事一塊兒作好
18	把經常使用模塊的功能打形成獨立的服務，經過良好的界面 (API) 來調用不一樣的服務。	不但主動作， 還會影響同事一塊兒作好
19	在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。	不但主動作， 還會影響同事一塊兒作好
20	在設計中把展示模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。	不但主動作， 還會影響同事一塊兒作好
21	重視算法的效率，在開始寫以前就要估計好算法的效率是哪個數量級上的（big-O）。	不但主動作， 還會影響同事一塊兒作好
22	在實際的運行場景中測試你的算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支持大小寫敏感的排序，數據是否支持多語言)會致使算法效率的巨大變化。	不但主動作， 還會影響同事一塊兒作好
23	常常重構代碼，同時注意要解決問題的根源。	不但主動作， 還會影響同事一塊兒作好
24	在開始設計的時候就要考慮如何測試 ，若是代碼出了問題，有log 來輔助debug 麼? 儘早測試，常常測試，爭取實現自動化測試，爭取每個構建的版本都能有某些自動測試。	不但主動作， 還會影響同事一塊兒作好
25	代碼生成工具能夠生成一堆一堆的代碼，在正式使用它們以前，要確保你能理解它們，而且必要的時候能debug 這些代碼。	不但主動作， 還會影響同事一塊兒作好
26	和一個實際的用戶一塊兒使用軟件，得到第一手反饋。	不但主動作， 還會影響同事一塊兒作好
27	在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。	不但主動作， 還會影響同事一塊兒作好
28	若是測試沒有作完，那麼開發也沒有作完。	不但主動作， 還會影響同事一塊兒作好
29	適當地追求代碼覆蓋率：每一行的代碼都覆蓋了，可是程序未必正確。要確保程序覆蓋了不一樣的程序狀態和各類組合條件。	不但主動作， 還會影響同事一塊兒作好
30	若是團隊成員碰到了一個有廣泛意義的bug, 應該創建一個測試用例抓住之後將會出現的相似的bug。	不但主動作， 還會影響同事一塊兒作好
31	測試：多走一步，多考慮一層。若是程序運行了一星期不退出，若是用戶的屏幕分辨率再提升一個檔次，這個程序會出什麼可能的錯誤?	不但主動作， 還會影響同事一塊兒作好
32	（帶領團隊）瞭解用戶的指望值，稍稍超出用戶的指望值，讓用戶有驚喜。	不但主動作， 還會影響同事一塊兒作好
33	（帶領團隊） 不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過期的假設、對用戶的誤解或其餘因素所遮擋。	不但主動作， 還會影響同事一塊兒作好
34	（帶領團隊）把全部的術語和項目相關的名詞、縮寫等都放在一個地方。	不但主動作， 還會影響同事一塊兒作好
35	（帶領團隊）不要依賴於某我的的手動操做，而是要把這些操做都作成有相關權限的人士都能運行的腳本。這樣就不會出現由於某人休假而項目被卡住的狀況。	不但主動作， 還會影響同事一塊兒作好
36	（帶領團隊）要讓重用變得更容易。一個軟件團隊要創造一種環境，讓你們有輕鬆的心態來嘗試各類想法 （例如，模塊的重用，效能的提高，等）。	不但主動作， 還會影響同事一塊兒作好
37	（帶領團隊）在每一次迭代以後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。	不但主動作， 還會影響同事一塊兒作好
38	（帶領團隊）團隊中每每會有矛盾產生，做爲領頭人，怎麼辦？	不但有明確和一致的處理原則，並且對於影響團隊士氣的任何事情追究到底

2、回答問題

• 問題一

  若一個新的創新的產生會帶來好處的同時它又會帶來很差的一面，那麼咱們應該怎麼權衡利弊，咱們不能說只享受好的一面，至於負面的就避而不談。書中的例子明顯看出了紡織機的好處，那麼失業的工人應該怎麼辦？
  以前我在網上看到這樣一個問題：「將來人類的工做會被百分之50的人工智能取代嗎？」無論是醫療教育仍是金融管理，此刻在各個領域中，正不斷有大量案例，來印證人工智能能夠在許多崗位上，以更低廉的成本作的比人類更好。就比如在我父母的那個年代，只要外語能力強就不怕找不到工做，但當智能翻譯系統從書面到語音，變的愈來愈進步以後，將來對翻譯人才的需求還會剩下多少？之前的教育重點在傳遞知識，但就這方面，線上智能或者百科每每能作的比老師更好。因此老師的任務也在不斷創新，所以教育這個行業在將來可能就從單純的傳遞知識轉型成學習服務，它的目的是協助同窗，幫助他們產生好奇、緩解焦慮、完善人格。而這些服務端時間內人工智能都沒有作的比人類更好。可是若是一個行業是純技術性的、是不須要與人互動的，那這一行就頗有可能會消失。那麼這件事究竟是好的仍是很差的？有又誰來爲這些技術性人員的事業而負責？

  最近蘋果的新廣告：「Apple不爲多數人，也不爲少數人」。視頻中，一位叫 Carlos 的盲人鼓手，用 iPhone 寫 Po 文，發動態，用的就是一個叫「旁白」的輔助功能。「旁白」是一種基於手勢的屏幕閱讀器，能夠幫 Carlos 在看不到屏幕的狀況下，讀出屏幕上的每項內容。再結合簡易的手勢及語音輸入，Carlos 就能和咱們同樣，自由地在網上發佈信息了。不只是「旁白」這個功能，你還能找到針對視力、聽力、學習與讀寫、肢體與活動能力而設計的各類輔助功能。Apple 所追求的創新，不只是強大的性能和出衆的外觀。因此我深信，真正的科技創新，應該讓每一個人都從中受益，固然也包括殘障人士。因此在設計產品時，將全部人都考慮在內，從而讓每一個人都能無障礙地工做、創做、溝通、健身和娛樂。不爲多數人，不爲少數人，他們產品設計是爲了每個人。我認爲這正是一個好的產品設計的精髓。

• 問題二

  我看過的任何一本書中有關創新內容都是在推崇創新，都在告訴咱們創新的必要性。雖然如今國內的教育在逐漸轉型，但在教育方面學生仍是以一種很依賴老師的學習方式來吸取知識，將來的工做方面絕大一部分人也會默守陳規，何談創新？該怎麼作才能改變本身，讓本身跳出本來的圈子，鍛鍊本身以另外一種方式看問題思考問題，不斷創新呢？

  創新一詞早被說爛，但真正要去定義它，一定不是「在不少人已經作得很好的基礎上去作得更好」，應該是「在你們都沒有想到的地方開拓荒地、作到極致」。這須要想象力、勇氣和執行力。去年末索尼公司只是面向日本市場推出的robodog系列機器狗，每隻售價1800美圓 。最突出的一點是，該款產品結合AI技術可以準確識別出主人並在互動過程當中感知主人的情緒。換言之AIBO機器狗經過傳感器可以具有強大的養成能力，感知到主人的喜愛並調整本身的性格及互動行爲，成爲每一個主人身邊獨一無二的AIBO。它的優點是在於再也不是冰冷的機器，而是可讓主人對它產生感情，而且進行情感互動。創新一詞咱們在擅長的領域每每會固步自封，被固有的思想所侷限，而對於陌生的領域則是懷揣的對未知事物好奇與探索，更加有可能有所創新。因此，咱們要接觸其餘領域，接觸另外一個圈子的人，學習吸取新領域的知識來豐富本身而且不怕失敗的嘗試。在此次程序來發中，有一個團隊是經過中文解釋與英文單詞配對的方式來學習單詞，即單詞連連看。我以爲他們的想法頗有創意、很新穎，給朵花花。

• 問題三

  書中沒有提到，當一個可能有風險新產品帶來的利潤會大於成熟產品的時候，公司該如何抉擇？

• 問題四

  在書中提到了公司是追求利益的，當一個創新並無達到預期的利益的、甚至是前期虧損的狀態時，創新還要繼續嗎？在一百年
  甚至幾百年前，新事物的產生每每是由我的發明的。因此就算失敗，影響的範圍和程度是很小的，可是現現在的創新都是由團隊甚至更大的團體發起的，可能這個創新是一個好點子，可是因爲沒法被人們立刻接受致使了沒有預期盈利甚至虧損，每每對一個公司的影響的不小的，那麼還要繼續堅持下去嗎？

  問題三和四放在一塊兒回答。其實這個問題我如今也沒有想明白。可能每一個企業都有本身的評估規。我的猜測是，對於大公司而言，若是一個新的項目風險過大，即便將來會帶來很大的利益，這個新項目也不會實行。但對於個體（即一我的），須要經歷太多不得已，最後纔能有所得——甚至，還有一無全部的風險。此次是人生。（忽然扯遠了……）

• 問題五

  有不少種團隊合做方式。個人問題是：咱們須要嘗試着其餘團隊合做模式嗎（儘管我以爲並不適合）

  能夠小小嚐試一下，首先沒有人會蠢到選擇一個徹底不可行的方式執行，幹嗎要折磨本身折磨你們呢？那麼就算換一種團隊合做方式也應該選擇一種看起來最可行的團隊合做方式。若是發現並不合適，立馬換掉。拒絕糾結！拒絕拖拉！！

• 問題六

  我很好奇學校是怎麼選擇咱們將要學習的編程語言的？是繼續學習這個基礎的、必定有用的東西，仍是會隨着改變用熱門的語言替代某些基礎語言，亦或者這些語言咱們都要學習？咱們以前學的數據結構的課程到底有什麼做用呢？

  通過Alpha階段以後，對這個問題有了答案。學習各種語言才能知道本身適合什麼。在不肯定本身的就業方向時應該普遍學習，在有了方向以後，則應該有所側重。在這次的微信小程序開發中，我發現不一樣小組用不一樣的編程語言進行前端後端的開發，好比Python、Java等等。因此說不管什麼語言，學精是很重要的。

3、再提問題

• 問題一

  第十二章——用戶體驗。在P159——P164，強調了用戶對產品第一印象的重要性，要從用戶的角度考慮問題，以及設計的時候不要讓用戶出現簡單的錯誤，且強調了記住用戶選擇的重要性。我以爲說的很對，就比如若是我在某個閱讀APP上屢次讀了天文學類的文章，那麼這個APP就會自動爲推送我天文學類的文章。這真的是很棒的功能。可是在本次項目開發出現了有關「用戶體驗」的問題。咱們開發的是微信記帳小程序，咱們記帳小程序與其餘的記帳小程序的不一樣之處在於，咱們的側重點在於規劃將來消費。咱們有添加計劃的功能。選擇將來多少天有多少預算，系統就會自動計算平均天天能夠花費的金額，若是今天花的錢超出了預算，系統從新計算後將來平均天天能夠花的錢就少，反之同理。我本人是很是喜好這個功能的，可是用戶體驗效果很差，由於他們不瞭解這個功能，致使操做的時候出現了不少問題。若是用戶一開始體驗就很差，三分鐘以內他們就會跟這個小程序say goodbye。個人問題是：那做爲開發人員要怎麼才能良好避免解決用戶體驗時可能會出現的情況？

• 問題二

  依舊是第十二章——用戶體驗。

  在P160提到了「要從用戶的角度考慮問題」。可是不一樣用戶終歸是有不一樣需求的。拿咱們的小程序舉例子，由於咱們的小程序側重點在於規劃將來消費，因此和其餘組的記帳記帳小程序相比，咱們的記帳功能比較簡單化。有些用戶很喜歡這樣的簡單設計，有一些用戶卻想要更豐富的功能。就在昨天我在微信小程序裏發現「鯊魚記帳」，它有着簡單的記帳基本功能，若是須要更多地功能，就須要下載他們的APP。

  個人問題是：如何知足不一樣用戶的多種不一樣需求？是要像「鯊魚記帳」那樣有給用戶提供多種選擇（選擇簡潔功能的微信小程序或者複雜功能的APP）嗎？這樣不是會浪費更多精力和資源嗎？

• 問題三

  書上P117講述了「敏捷流程和解法」。

  書中提到「問題未必能在短期內完成，然而時間不等人，那麼程序員會冒着風險先嚐試着在某些平臺上實現——也許之後要返工」。

  個人問題：書中提到的敏捷開發會出現的問題咱們也遇到了。預計的是兩週的時間，但其實咱們在兩週之前就開始行動了，雖然「勉強」將小程序上架了，卻仍是沒有達到理想的目標，甚至是還有一些基本功能沒有實現。問題就出在咱們沒想到中間過程當中會出現不少問題，然而修復完錯誤以後所剩的時間就寥寥無幾。（折磨人的敏捷開發！！！）在成果演示的時候，我發現本身組還算是比較優秀的，有不少組沒有上架亦或者上架後漏洞百出。所以高敏捷開發的認知是：「是對技術要求提升了，而不是下降了」。這種提升不是那種滿口天花亂墜的理論式的提升，而是寫最基本的代碼上的能力提升。那麼敏捷開發的意義是什麼？爲何不能心平氣和的作完一個優秀的項目？若是組成員能力都不高那麼敏捷開發會很吃力，那麼他們是否是不適合敏捷開發？若是規定時間內沒有作完理想的任務，是延長衝刺的時間，仍是盡力而爲就好？

• 問題四

  這個問題是我對某個組開發的APP產生的疑問。

  第八章《需求分析》，談到用戶需求性分析，也詳述了「NABCD」

  書中說道一個程序的開發，要考慮到用戶「最須要的東西」，要展示本身程序的獨特之處。在競爭分析需求中，咱們要看清楚我方的優點和劣勢。

  問題：某一組開發的是一個能查詢快遞的APP（能夠掃碼，語音輸入單號，或者鍵盤輸入），看起來沒什麼問題，可是仔細一想，如今不少購物平臺不都是在哪兒買就能在哪裏查到嗎。作爲用戶我爲何要爲了查快遞download一個APP？退一步講，就算我並不是在購物軟件上買的東西，我爲何不能直接在網站上查詢而要下載一個APP？相比之下，我以爲若是設計成微信小程序會更加便捷一些。最後一點，語音功能是什麼鬼？我能一口氣說那麼長的單號嗎……

  對這個組並無惡意，更沒有江湖恩怨哈哈，僅發表小小意見。

• 問題五

  第十三章《軟件測試》，P282-P283提出了多種測試。在本次程序開發中，我是「測試員」的身份。我認爲，功能測試時比較容易評估的，好比單元測試。相對來講功能測試會比較複雜，例如，壓力測試中，咱們的小程序可支持百人之內的用戶同時運行。可是不能再多，那麼問題來了，這算質量不過關嗎……不能吧，畢竟我以爲100人足以，怎樣才能定義這個軟件的質量……糾結。

• 問題六

  說一個和本書無關的小小的事。 最近咱們組PM很生氣，她一直在碎碎粘：「這不科學，咱們組全部內容都是本身作的，評分卻比不過別人在網上‘借鑑’的，他們這個代碼頗有問題……明明某某組程序一堆bug，他們居然沒有看出來，balabala……好氣」。 emmmmm，我以爲不少人在評分的時候，是隻關注的界面好很差看，並無細想功能實現問題……有些程序沒上架的咱們也測試不了，只能看看他們的截圖……另外若是不一樣類型的程序分開評是否是會更好？（遊戲、小程序）