軟工網絡15個人作業4——alpha階段個人總結
一、個人總結
第一部分:硬的問題
類別 | 具體技能和面試問題 | 現在回答 | 畢業找工作時 |
---|---|---|---|
語言 | 最拿手的計算機語言之一,代碼量多少? | java,三千左右 | |
語言 | 最拿手的計算機語言之二,代碼量有多少 | C,一千五左右 | |
軟件實現 | (代碼閱讀能力,實現,單元測試)你有沒有在別的代碼的基礎上改進,你是怎麽讀懂別人的代碼,你采取什麽辦法保證你的新功能不會影響原來的功能?你在開發中碰到最復雜的bug是什麽,你是如何解決的?這個bug出現的原因是什麽,你將來應該怎麽樣去避免bug出現? | 有;直接看啊,不懂的就問原作者,不知道原作者就百度;修修補補;沒什麽最復雜的bug,要麽問同學要麽就百度解決;出現的原因是因為自己能力不夠;未來為加強自己的能力。 | |
軟件測試 | (測試方法,測試工具,測試實踐,代碼覆蓋率)你是如何測試你自己寫的代碼?你何如測試別人寫的代碼?你掌握了多少種測試工具和方法?你寫過測試工具嗎?你如何對一個網站進行壓力測試和技能測試?你如何測試一個軟件的人機界面(UX/UI)? | 先運行一遍試試,再用各類工具去測試;只會簡單使用eclipse和intellij idea;都是通過直接使用。 | |
效能分析 | (效能分析,效能改進)你寫過的最復雜的代碼是什麽?你是如何測試量和改進他的效能的,用了什麽工具,如何分析? | 最復雜的是大一的C語言課設、大二的Java課設和現在正在進行的軟件工程團隊項目;直接使用。 | |
需求分析 | (需求分析,典型用戶,場景,創新)你做過多少有實際用戶的項目,用戶量是多少?你的項目有什麽創新的地方? | 以前沒做過,只做了現在的團隊項目;創新就創新在沒人做過我們的產品,而我們的產品又非常有用,符合廣大師生的需求,且現在已經可以使用了。 | |
行業洞察力 | 你最感興趣的領域是什麽?這個領域過去十年有什麽創新?你分析過這個領域前十的產品嗎?請分析一下他們的優劣,你要進入這個領域,如何創新? | 最感興趣的是人工智能和大數據 | |
項目管理 | 你參加過項目管理嗎?如何決定各個任務的優先順序?如果項目不能及時完成,你要怎麽辦? | 沒參與過;哪個重要哪個先做;不能及時完成就加班加點補救 | |
軟件設計 | 你做過架構設計,模塊化設計,接口設計麽?請說明一下你為何是這樣設計,你比較過什麽不同的設計方式,你的設計取得了什麽結果? | 做過;這樣做可以減少代碼量,還可以增加代碼可讀性 | |
質量意識 | (代碼復審/代碼規範/代碼質量)你是怎麽做代碼復審的,你加入我們團隊後,能幫我們提高代碼質量麽,請具體說明怎麽提高? | 按代碼規範的框架來做 | |
工具/社區 | Software Tools(performance too l,version control,work item,TFS)你在各種開發平臺(web,linux,PC,mobile,macheine learning)都使用過什麽樣的工具,自己寫過什麽工具來改進工作效率?給社區貢獻過什麽工具和代碼?GitHub有分享代碼麽?你寫的技術博客堅持了多久,讀者最多的是哪一篇? | eclipse、intellij idea、codeblocks、devc++、vs等;沒寫過;沒貢獻過;沒寫技術博客,寫的都是博客作業 | |
團隊協作 | Work with others(協同工作,提供反饋,說服別人請描述你在項目中如何說服同伴采用你提出的更好的解決方案,或者你如何聽取別人的意見,改進了自己的方案?你如何說服懶惰的同伴加緊工作,實現團隊的目標? | 給同伴講解我的方案的所有優點,比原先的方案好在哪;無論怎樣,哪個好就采用哪個;當然是催啊一直催催催 | |
理論素養 | 你上過什麽數學,計算機或者其他理論課,請舉具體的例子,說明你學的理論知識如何幫助你解決實際問題。 | 高等數學、離散數學等各種數學類課程、C語言、計算機組成原理、Java、數據結構等;如何幫我解決問題?當然學會了很多知識,學會敲代碼,我現在才能做軟件工程這個團隊項目。 | |
自我管理 | 全年級你專業排名多少?你從剛入學(大學一年級)到現在排名有變化麽?如何解釋你的排名的變化? | 排名中下,因為只學自己有興趣的想學的。 |
第二部分:軟的問題
編號 | 問題 | 回答 |
---|---|---|
1 | 當你看到不靠譜的設計、糟糕的代碼、過時的文檔和測試用例的時候,不要想 “既然別人的代碼已經這樣了,我的代碼也可以隨便一點啦。” | 不但主動做,還會影響同事一起做好 |
2 | 主動解決問題。當看到不靠譜的設計,糟糕的代碼的時候,不要想“可能別人會來管這個事情” ,或者“我下個月發一個郵件讓大家討論一下”。要主動地把問題給解決了 | 不但主動做,還會影響同事一起做好 |
3 | 經常給自己充電,身體訓練是運動員生活的一部分,學習是軟件工程師職業的伴侶。每半年就要了解和學習一些新的相關技術。通過定期分享(面對面的分享,寫技術博客等)來確保自己真正掌握了新技術。 | 一直主動這樣做 |
4 | DRY (Don‘t Repeat Yourself)——別重復。在一個系統中,每一個知識點都應該有一個無異議的、正規的表現形式 | 這要講場合 |
5 | 消除不相關模塊之間的影響,在設計模塊的時候,要讓它們目標明確並單一,能獨立存在,沒有不明確的外部依賴。 | 想做,但是不知道怎麽衡量效果 |
6 | 通過快速原型來學習,快速原型的目的是學習,它的價值不在於代碼,而在於你通過快速原型學到了什麽。 | 不但主動做,還會影響同事一起做好 |
7 | 設計要接近問題領域,在設計的時候,要接近你目標用戶的語言和環境。 | 大概同意,但是怎麽接近用戶呢? |
8 | 估計任務所花費的時間,避免意外。在開始工作的時候,要做出時間和潛在影響的估計,並通告相關人士,避免最後關頭意外發生。工作中要告知可能的時間變化,事後要總結。 | 不但主動做,還會影響同事一起做好 |
9 | 圖形界面的工具有它的長處,但是不要忘了命令行工具也可以發揮很高的效率,特別是可以用腳本構建各種組合命令的時候。 | 正在學習命令行工具 |
10 | 有很多代碼編輯器,請把其中一個用得非常熟練。讓編輯器可以實現自己的定制,可以用腳本驅動,用起來得心應手。 | 沒有任何定制 |
11 | 理解常用的設計模式,並知道擇機而用。設計模式不錯,更重要的是知道它的目的是什麽,什麽時候用,什麽時候不用。 | 每寫100行程序,我就盡量用一個模式。 |
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 | (帶領團隊)團隊中往往會有矛盾產生,作為領頭人,怎麽辦? | 不但有明確和一致的處理原則,而且對於影響團隊士氣的任何事情追究到底 |
二、回答問題
問題一:
我看了這一段文字
軟件工程是把系統的、有序的、可量化的方法應用到軟件的開發、運營和維護上的過程。
那麽軟件工程到底有什麽用呢?
回答:
- 軟件工程的思想目的和其他學科的工程方法(比如土木工程等)並無太大差異,主要是降低軟件系統的復雜性、提高其可控性,以此在軟件開發、維護、測試等各個階段提高效率。
- 讓整個軟件系統“大而不亂”,井井有條。減少程序員工作的負荷並提高軟件需求、設計、開發、測試、維護的效率。
問題二:
我看了這一段文字
從學生到職業程序員,並不是更加沒完沒了地寫程序——花在寫代碼的時間反而少了許多。
職業程序員的能力比學生強多了,會做的東西就更多了,就會敲更多的代碼了。那為什麽職業程序員花在寫代碼的時間反而少了許多呢?
回答:
因為職業程序員任務的質量要求不一樣。職業程序員在“需求分析”和“測試”這兩方面明顯地要花更多的時間。但在具體編碼上,花費的時間會比學生少。從學生到職業程序員,並不是更加沒完沒了地寫程序——花在寫代碼上的時間反而少了許多。
問題三:
我看了這一段文字
在軟件工程的語境裏,“敏捷流程”是一系列價值觀和方法論的集合。
那麽敏捷流程到底是什麽東西呢?
回答:
敏捷開發以用戶的需求進化為核心,采用叠代、循序漸進的方法進行軟件開發。在敏捷開發中,軟件項目在構建初期被切分成多個子項目,各個子項目的成果都經過測試,具備可視、可集成和可運行使用的特征。換言之,就是把一個大項目分為多個相互聯系,但也可獨立運行的小項目,並分別完成,在此過程中軟件一直處於可使用狀態。總結如下:
- 不斷交付軟件以滿足客戶需要
- 歡迎需求的變化
- 可以工作的軟件是進度的主要衡量標準
- 對卓越技術與良好設計的不斷追求將有助於提高敏捷性
- 簡單——盡可能減少工作量的藝術至關重要
感覺敏捷是態度而不是流程,是氛圍而不是方法。
三、再提問題
第4章 兩人合作
我看了這一段文字
代碼復審就是看代碼是否在“代碼規範”的框架內正確地解決了問題。
Q1:
那如果開發人員在寫代碼的過程中就嚴格按照代碼規範來寫,做到完美,那此時代碼復審不就毫無意義了?復審者本就是在替開發者幹開發者本應幹的事情,那意味著開發者自己做好的話,復審就沒必要了?
第5章 團隊和流程
我看了這一段文字
軟件團隊有各種形式,適用於不同的人員和需求。基於直覺形成的團隊模式未必是最合適的。
Q2:
如果要開展一個全新的項目,到底該怎麽選擇“合適”的團隊模式呢?課本中僅僅是介紹了各種模式,但並未教我們到底該如何選擇。
第7章 MSF
我看了這一段文字
二柱:軟件工程講的凈是一些奇妙玄幻的概念,拗口的專業名詞加上紛繁復雜的流程,其實做軟件完全沒那麽難,主要靠的還是程序員自身的修養和完成工作的素質。
Q3:
我覺得這段話講得很有道理啊,請問你怎麽看呢?
第12章 用戶體驗
我看了這一段文字
用戶體驗設計的一個重要目的就是要降低用戶的認知阻力,即用戶對於軟件界面的認知和實際結果的差異。
Q4:
既然用戶體驗設計的目的就是為了用戶,那是不是可以理解為要根據大眾的想法來設計?但我們平時使用的一些軟件,比如知乎,這些公司對於用戶體驗設計應該都是很在行的,但為什麽在用戶體驗這一方面會越做越爛呢?
我的問題是,是什麽原因導致了這種情況的發生。每次出新版本,每次都會受到用戶的大量吐槽,為何會一直在錯的路上一直走下去呢。如果在內容和功能上,加入了可以獲利的東西尚可理解,畢竟一個公司都是需要收入的。那麽UI越做越醜,怎麽就不會改回去呢。
第16章 IT行業的創新
我看了這一段文字
不但大眾不喜歡創新,甚至連創新者自己都不例外,有些創新者甚至恨創新。
Q5:
我反對作者的這個觀點,而且反對作者關於這句結論的一個設想。
作者說:假設你發明了電報,創辦了電報公司,並花費畢生的精力建起了覆蓋全國的電報網。這時有個年輕的發明家上門推銷他的創新——電話。這個早期的電話看起來其貌不揚,後面還拖著一條尾巴。可是你敏銳地看到,這個創新將會顛覆目前的電報產業,它預示著你辛辛苦苦建立起來的電報公司將會失去市場,這是你會怎麽想?會不會恨這個發明?
依我的看法,作者的結論是錯的。這並不是說有些創新者不喜歡創新或者恨創新,這根本就是利益沖突的問題,是一個創新者的利益被另一個創新者所破壞,不是不喜歡創新或者恨創新。單就創新而言,若創新者不喜歡創新抑或恨創新,那他如何創新?他如何實現創新?他做不了,他根本就不會成為一個創新者。
軟工網絡15個人作業4——alpha階段個人總結