個人作業4——alpha階段個人總結
阿新 • • 發佈：2018-05-19
展現 過去 發的 活力 軟件項目 估算 面試問題 維護 開始
一、個人總結
| 類別 | 具體技能和面試問題 | 現在回答（大三） | 畢業找工作時 |
|---|---|---|---|
| 語言 | 最拿手的語言之一，代碼量多少？ | Java，之前做過PTA題目，代碼量就是作業的要求 | |
| 軟件實現 | 有沒有在別人代碼上改進，如何讀懂他人代碼，采取什麽方法不影響原來功能，如何解決bug？ | 只能改進簡陋不規範的代碼，讀懂他人代碼主要是要了解這個主體框架，先總後分，不影響原來功能需盡量做添加，不修改 | |
| 軟件測試 | 如何測試所寫的代碼？如何測試他人的代碼？掌握了多少種測試工具和方法？寫過測試工具嗎？如何測試軟件的人機界面？ | 用測試工具來測試代碼，只是了解一些測試工具和方法。只測試之前的結對編程代碼 | |
| 效能分析 | 寫過的最復雜代碼？如何測量和改進性能？ | 就是上學期完成的數據庫課設，沒有進行效能分析 | |
| 行業洞察力 | 最感興趣的領域？這個領域過去十年經歷的創新？ | 互聯網？支付寶、京東、騰訊應該能算是創新，這些企業都抓住了用戶巨大的需求並解決了問題 | |
| 團隊協作 | 如何說服同伴采用你提出的更好的方案或者如何聽取他人意見？如何說服同學加緊工作？ | 一個團隊重要就是分工明確，每個人都有自己的定位，對於個別能力比較弱的同學還是要給予幫助 | |
| 自我管理 | 全年級專業排名？是否有變化並作出解釋？ | 比較穩定，中等水平，偶爾發揮好還能拿到良好 |
1 當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候，不要想 “既然別人的代碼已經這樣了，我的代碼也可以隨便一點啦。”
一直主動這樣做
2 主動解決問題。當看到不靠譜的設計，糟糕的代碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了
一直主動這樣做
3 經常給自己充電，身體訓練是運動員生活的一部分，學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術博客等）來確保自己真正掌握了新技術。
有時分享
4 DRY （Don‘t Repeat Yourself）——別重復。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式
聽說過，但是認為意思不大
5 消除不相關模塊之間的影響，在設計模塊的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。
想做，但是不知道怎麽衡量效果
6 通過快速原型來學習，快速原型的目的是學習，它的價值不在於代碼，而在於你通過快速原型學到了什麽。
一直主動這樣做
7 設計要接近問題領域，在設計的時候，要接近你目標用戶的語言和環境。
一直主動這樣做
8 估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。
一直主動這樣做
9 圖形界面的工具有它的長處，但是不要忘了命令行工具也可以發揮很高的效率，特別是可以用腳本構建各種組合命令的時候。
正在學習命令行工具
10 有很多代碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定制，可以用腳本驅動，用起來得心應手。
沒有任何定制
11 理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麽，什麽時候用，什麽時候不用。
從來沒聽說過
12 代碼版本管理工具是你代碼的保障，重要的代碼一定要有代碼版本管理。
用QQ，u盤即可
13 在debug的時候，不要驚慌，想想導致問題的原因可能在哪裏。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的代碼裏面加 log.
只會printf
14 重要的接口要用形式化的“合同”來規定。用文檔和斷言、自動化測試等工具來保證代碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證代碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。
從來沒聽說過
15 只在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低代碼的效率和可維護性。記住不要用異常來傳遞正常的信息。
一直主動這樣做
16 善始善終。如果某個函數申請了空間或其他資源，這個函數負責釋放這些資源
有時這樣做
17 當你的軟件有多種技術結合在一起的時候，要采用松耦合的配置模式，而不是要把所有代碼都混到一起。
一直主動這樣做
18 把常用模塊的功能打造成獨立的服務，通過良好的界面 (API) 來調用不同的服務。
一直主動這樣做
19 在設計中考慮對並行的支持，這樣你的API 設計會比較容易擴展。
從來沒聽說過
20 在設計中把展現模塊 (View) 和實體模塊 (Model) 分開，這樣你的設計會更有靈活性。
沒搞清楚啥是V，啥是M
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 （帶領團隊）團隊中往往會有矛盾產生，作為領頭人，怎麽辦？
有明確和一致的處理矛盾的原則
二、回答問題
1.合格的軟件工程師是怎麽判斷的？還是說能寫代碼就可以成為了呢？我們現階段可以從哪方面開始培養自己的開發思維和能力，向工程師邁進？
一，良好的編程能力。編程能力直接決定了項目開發的效率。軟件工程師至少需要精通一門編程語言，熟悉它的基本語法、技術特點。 二，自覺的規範意識和團隊精神。隨著軟件項目規模越來越大，僅僅依靠個人力量已經無法完成工作，因此，團隊精神就尤為重要。
所以在大學時光裏我們就要有意識地培養這方面的能力。
2.重復的工作具有機械性，不停做同一件事，往往會忽視而難以發現新的東西。那麽作為一個軟件工程師，如何在團隊工作中保留自己的創新能力呢？
項目必要的討論可以碰撞出火花，每天和同學之間的交流我認為是創新的源泉。
3.一個小團隊，是否需要分工明確，還是大家一起合作完成所有任務？所以如果角色明確、各司其職的時候是否會使進度變慢？
必須分工明確，每個人都有參與這個團隊才能保持活力，角色明確、各司其職並不會使進度變慢，只是進度可能不一致，所需要做的工作就是協調進度。
三、再提問題
1、人們為了解決現實社會和生活中的各種問題，要求助於軟件。那麽軟件開發團隊如何才能準確而全面地找到這些需求呢？
2、對比敏捷（Agile）、計劃驅動（Plan-driven）、形式化的開發方法（Formal Method）。所提到的形式化的開發方法，其基本步驟是怎樣的呢？為什麽它能有極高的可靠性呢？
3、斷言是什麽？它的作用是什麽？
4、在任何一個項目中，PM（項目經理）都扮演了至關重要的角色，如何才算是一個合格的PM？PM和其他人員的關系如何處理？
5、如何理解技術產品的發展周期（萌芽->成長->成熟->衰退->結束）？
個人作業4——alpha階段個人總結