軟體工程自我評價

1.保持高標準，不要受制於破窗理論(broken windows theory)[i]。
當你看到不靠譜的設計、糟糕的程式碼、過時的文件和測試用例的時候，不要想 “既然別人的程式碼已經這樣了，我的程式碼也可以隨便一點啦。” E

a) 從來沒聽說過；   b) 我就是這樣隨便過來的；  c) 如果有明確要求，我可以做好。  d) 一直主動這樣做     e) 不但主動做， 還會影響同事一起做好

主動解決問題。當看到不靠譜的設計，糟糕的程式碼的時候，不要想“可能別人會來管這個事情” ，或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了[ii]。E

a) 不懂啥是靠譜的設計； b) 隨便應付一下即可； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
經常給自己充電，身體訓練是運動員生活的一部分，學習是軟體工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享（面對面的分享，寫技術部落格等）來確保自己真正掌握了新技術。E

a) 從來不看書； b) 看了就忘； c) 有時分享。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
DRY （Don't Repeat Yourself）——別重複。在一個系統中，每一個知識點都應該有一個無異議的、正規的表現形式。E

a) 從來沒聽說過； b) 聽說過，但是認為意思不大； c) 這要講場合。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
消除不相關模組之間的影響，在設計模組的時候，要讓它們目標明確並單一，能獨立存在，沒有不明確的外部依賴。E

a) 從來沒聽說過； b) 出了問題再說吧； c) 想做，但是不知道怎麼衡量效果。 d) 能夠在多種語言和架構中做到 e) 不但主動做，還會影響同事一起做好
通過快速原型來學習，快速原型的目的是學習，它的價值不在於程式碼，而在於你通過快速原型學到了什麼。E

a) 從來沒聽說過； b) 把原型直接用於產品，不然就浪費了； c) 不用原型，一直在產品中直接改。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
設計要接近問題領域，在設計的時候，要接近你目標使用者的語言和環境。E

a) 從來沒聽說過； b) 按我的想法設計，使用者以後會適應的； c) 大概同意，但是怎麼接近使用者呢？ d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
估計任務所花費的時間，避免意外。在開始工作的時候，要做出時間和潛在影響的估計，並通告相關人士，避免最後關頭意外發生。工作中要告知可能的時間變化，事後要總結。C

a) 做完了，就知道花費了，不用事先估計； b) 大概估一下，不必在意時間 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
圖形介面的工具有它的長處，但是不要忘了命令列工具也可以發揮很高的效率，特別是可以用指令碼構建各種組合命令的時候。C

a) 一直用滑鼠和GUI； b) 到時候問牛人； c) 正在學習命令列工具。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
有很多程式碼編輯器，請把其中一個用得非常熟練。讓編輯器可以實現自己的定製，可以用指令碼驅動，用起來得心應手。C

a) 只用老師教的一個； b) 隨意； c) 沒有任何定製。 d) 會定製，並且分享給其他人 e) 還會學習和使用各種編輯器的擴充套件。

理解常用的設計模式，並知道擇機而用。設計模式不錯，更重要的是知道它的目的是什麼，什麼時候用，什麼時候不用。C

a) 從來沒聽說過； b) 模式沒用； c) 每寫100行程式，我就儘量用一個模式。 d)有實際使用的經驗 e) 能用具體程式碼說明模式的利弊

程式碼版本管理工具是你程式碼的保障，重要的程式碼一定要有程式碼版本管理。C

a) 從來沒聽說過； b) 用QQ，u盤即可； c) 領導要求才用。 d) 經常用 e) 不但主動做，還會影響同事一起做好

在debug的時候，不要驚慌，想想導致問題的原因可能在哪裡。一步一步地找到原因。要在實踐中運用工具，善於分析日誌（log），從中找到bug。同時，在自己的程式碼裡面加 log.C

a) 從來沒聽說過； b) 只會printf； c) 加log 太麻煩，我的程式碼不會有bug 的。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

重要的介面要用形式化的“合同”來規定。用文件和斷言、自動化測試等工具來保證程式碼的確按照合同來做事，不多也不少。使用斷言 (assertion) 或者其他技術來驗證程式碼中的假設，你認為不可能發生的事情在現實世界中往往會發生。C

a) 從來沒聽說過； b) 太麻煩，不用； c) 想用，但沒有時間。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

只在異常的情況下才使用異常 (Exception), 不加判斷地過多使用異常，會降低程式碼的效率和可維護性。記住不要用異常來傳遞正常的資訊。C

a) 從來沒聽說過； b) 抓住所有異常 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

善始善終。如果某個函式申請了空間或其他資源，這個函式負責釋放這些資源。D

a) 從來沒聽說過； b) 隨緣； c) 有時這樣做。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

當你的軟體有多種技術結合在一起的時候，要採用鬆耦合的配置模式，而不是要把所有程式碼都混到一起。E

a) 從來沒聽說過； b) 沒有實踐的機會； c) 程式碼都在一起比較好管理。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

把常用模組的功能打造成獨立的服務，通過良好的介面 (API) 來呼叫不同的服務。C

a) 從來沒聽說過； b) 拷貝程式碼過來用也可以 c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

在設計中考慮對並行的支援，這樣你的API 設計會比較容易擴充套件。C

a) 從來沒聽說過； b) 並行不會出錯的； c) 任何程式碼都應支援並行。 d) 考慮在適當的層次支援並行 e) 不但主動做，還會影響同事一起做好

在設計中把展現模組 (View) 和實體模組 (Model) 分開，這樣你的設計會更有靈活性。C

a) 程式碼都在一起比較好改； b) 隨緣啦； c) 沒搞清楚啥是V，啥是M。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

重視演算法的效率，在開始寫之前就要估計好演算法的效率是哪一個數量級上的（big-O）。C

a) 從來沒聽說過； b) 我的資料量不大，無所謂； c) 不會有效率問題的，現在CPU 都快了。 d) 主動測試程式效率，以驗證估算 e) 不但主動做，還會影響同事一起做好

在實際的執行場景中測試你的演算法，不要停留在數學分析層面。有時候一個小小的實際因素 (是否支援大小寫敏感的排序，資料是否支援多語言)會導致演算法效率的巨大變化。C

a) 從來沒聽說過； b) 想用，但不知道工具 c) 主要靠肉眼觀察演算法效率。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

經常重構程式碼，同時注意要解決問題的根源。C

a) 從來沒聽說過； b) 任何修改都可以叫重構； c) 每天應該重構兩次。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

在開始設計的時候就要考慮如何測試，如果程式碼出了問題，有log 來輔助debug 麼? 儘早測試，經常測試，爭取實現自動化測試，爭取每一個構建的版本都能有某些自動測試。C

a) 從來沒聽說過； b) 我的程式碼不會出問題的； c) 專案沒有安排時間，我也沒有提這事。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

程式碼生成工具可以生成一堆一堆的程式碼，在正式使用它們之前，要確保你能理解它們，並且必要的時候能debug 這些程式碼。C

a) 從來沒聽說過； b) 從來不看那些程式碼； c) 那些程式碼沒有bug。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

和一個實際的使用者一起使用軟體，獲得第一手反饋。 C

a) 從來沒聽說過； b) 使用者太蠢，不值得聽反饋； c) 想做但是沒有機會。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

在自動測試的時候，要有意引地入bug，來保證自動測試的確能捕獲這些錯誤。C

a) 沒聽說過； b) 不必這麼麻煩； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

如果測試沒有做完，那麼開發也沒有做完。C

a) 從來沒聽說過； b) 簽入程式碼，就是做完了； c) 。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

適當地追求程式碼覆蓋率：每一行的程式碼都覆蓋了，但是程式未必正確。要確保程式覆蓋了不同的程式狀態和各種組合條件。C

a) 從來沒聽說過； b) 覆蓋20% 就好了； c) 要覆蓋至少60%。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

如果團隊成員碰到了一個有普遍意義的bug, 應該建立一個測試用例抓住以後將會出現的類似的bug。C

a) 從來沒聽說過； b) 每個bug都是特殊的； c) 測試用例不值得加 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

測試：多走一步，多考慮一層。如果程式運行了一星期不退出，如果使用者的螢幕解析度再提高一個檔次，這個程式會出什麼可能的錯誤?C

a) 從來沒聽說過； b) 如果有問題，使用者會報告的，我們不用測這些； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

（帶領團隊）瞭解使用者的期望值，稍稍超出使用者的期望值，讓使用者有驚喜。C

a) 從來沒聽說過； b) 我們決定使用者的期望； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好
（帶領團隊）不要停留在被動地收集需求，要挖掘需求。真正的需求可能被過時的假設、對使用者的誤解或其他因素所遮擋。E

a) 從來沒聽說過； b) 使用者不說的，我們不做； c) 如果有明確要求，我可以做好。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

（帶領團隊）把所有的術語和專案相關的名詞、縮寫等都放在一個地方。E

a) 從來沒聽說過； b) 都記在我腦子裡； c) 大家看程式碼就好 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

（帶領團隊）不要依賴於某個人的手動操作，而是要把這些操作都做成有相關許可權的人士都能執行的指令碼。這樣就不會出現因為某人休假而專案被卡住的情況。E

a) 從來沒聽說過； b) 我們沒有休假的，沒關係； c) 出了問題再說 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

（帶領團隊）要讓重用變得更容易。一個軟體團隊要創造一種環境，讓大家有輕鬆的心態來嘗試各種想法（例如，模組的重用，效能的提升，等）。E

a) 都聽領導的； b) 團隊嚴肅緊張最好； c) 不必嘗試，失敗的可能性太大。 d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

（帶領團隊）在每一次迭代之後，都要總結經驗，讓下一次迭代的進度安排更可靠，質量更高。E

a) 沒有時間總結，直接做下一版； b) 總結用處不大； c) 如果上級有要求，就做一下； d) 一直主動這樣做 e) 不但主動做，還會影響同事一起做好

q=%e5%ae%9c%e8%89%af%e4%bb%a3%e5%bc%80%e4%bc%91%e5%ad%a6%e8%af%81%e6%98%8e%e3%80%90ww155577%e5%be%ae%e4%bf%a1%e3%80%91
https://www.microsoft.com/zh-cn/learning/search-results.aspx?q=宜良代開出院證明【ww155577微信】
https://www.microsoft.com/zh-cn/learning/search-results.aspx?q=宜良代開�%9

軟體工程自我評價

軟體工程自我評價

軟體工程自我總結

GB/T 25000.51-2016 系統與軟體工程、系統與軟體質量要求和評價第51部分

個人作業——軟體工程實踐總結&個人技術部落格

軟體工程5

軟體工程

[全集]軟體工程與計算2_知識點總結

軟體工程系列==9、apache在windows下的安裝配置

基於CMMI的軟體工程及實訓指導相關課程第一章學習

自動生成小學四則運算題目——軟體工程

軟體工程小學生數學題的四則運算

軟體工程————python自動生成小學四則運算題目

軟體工程個人專案：能自動生成小學四則運算題目的程式

軟體工程的四則運算

資料模型最佳實踐_資料科學家應瞭解軟體工程最佳實踐

軟體工程方法論對於我們有什麼用處

【軟體工程|思考題】GIS專案如何估算成本和效益

軟體工程課程設計：黃金點遊戲

軟體工程作業7.8.9

醬油的軟體工程課程（6）

軟體工程自我評價

相關推薦