PART1 博文閱讀感想

?

　　十幾篇博客一氣讀下來，有一個詞一直縈繞在我的腦海里——緊張！緊張！還是緊張！

　　首先這緊張來自于自己的學習方面。作為計算機系的科班出身，當然與生俱來就有一種優越感——我們是專業的，四年的專業訓練再怎么不濟也要比那些半路出家的野路子們好找工作吧。但讀了這么多博客給我了一種深深的緊張感，粗粗看下來，這些博主們絕少是科班出身，有學英語的，有學數學的，五花八門，但唯獨很少是計算機系出身。每個人在提起自己轉向程序開發領域的同時，都有一番非常痛苦的，甚至天昏地暗的學習階段。短短幾個月的時間，他們就學會了幾門語言，掌握了幾種我在學校里都沒聽過的技術。誠然，接受過專業基礎訓練的我們可能會對原理上了解的更加深入一些，但是IT行業這個市場早已有太多人擠著頭皮想要進入，這個行業的門檻并沒有那么深。除了谷歌微軟，還有很多默默無名的小公司需要信息技術人才。而往往很多開發工作并不需要你對計算機底層原理的了解，只需要你掌握一門技術，一門應用性很強的技術，在應用方面，在專業技術方面，計算機專業科班出身的學生如果僅僅滿足于學校中的那點知識，完全沒有任何競爭力。所以啊，什么時候都要學習，要靠自己學習，要結合實踐的學習，要永不滿足的學習。

　　另一個緊張來自于這個行業的憂慮。程序員？=青春飯，捫心自問，雖然對于這個專業擁有著極大的熱忱，但是如果說要讓我當一輩子程序員，甚至想要安穩的當一輩子程序員都很困難（被年輕人替代），我還是拒絕的。看了這么多博文，我越發的發現這個行業的門檻真的非常低，而工作強度卻異乎尋常的高，如果等自己步入中年，身體上是否能吃的消上是一個問題。就算能勉強堅持，也總比不過那些入行剛幾年已經全面掌握技術的年輕人。程序員是一個太容易被他人替代的行業，如何能在這個行業中站住腳，如何能夠在自己的職業道路上獲得發展。看似很難。晉升管理層？誰也說不定。變身技術中堅？程序員真的不是越老越值錢。自己創業？機遇難得。雖然剛入行的程序員能夠拿著令人羨慕的工資，但是對于身體的透支和發展的局限性是一個不得不考慮的問題。

　　真的很緊張。

?

PART2 代碼復審

　　這次由于奇數個同學選課的原因，我們結對小組有三位同學，所以我們采用了單循環的方式進行代碼復審。這次我復審的是韓青長同學的代碼。

　　

General

• Does the code work? Does it perform its intended function, the logic is correct etc.

　　YES

　　我將代碼使用我自己的測試集進行測試，結果基本完成了作業基本要求中的-b和-c兩個功能。對于機場線單行線，環線，錯誤輸入等的問題也處理得很好。

　　下面是我的測試集與測試目標

　　1.MetroSystem.exe -b 2號航站樓 3號航站樓

　　2.MetroSystem.exe -b 健德門 火器營

　　3.MetroSystem.exe -b 南邵 角門西

　　4.MetroSystem.exe -b 朱辛 馬泉營

　　5.MetroSystem.exe -b 西直門 國貿

　　6.MetroSystem.exe -c 3號航站樓 西局

　　7.MetroSystem.exe –c 北苑路北 安立路

　　8.MetroSystem.exe -c 廣渠門外 國貿

　　9.MetroSystem.exe -c 大屯路東5 大屯路東15

　　10.MetroSystem.exe -c 什剎海 什剎海

?

　　第一組測試用例測試單行線

　　第二組測試用例測試環線

　　第三組測試用例測試盡頭站到換乘站

　　第四組測試用例測試錯誤輸入不存在的車站

　　第五組測試用例測試換乘站到換乘站

　　第六組測試用例同樣測試單行線

　　第七組測試用例測試不能換乘的大屯路東站

　　第八組測試用例測試不能換乘的雙井站

　　第九組測試用例測試兩條線同名車站實際不能換乘的情況

　　第十組測試用例測試同名車站

?

　　但是我還是發現了兩個小問題

　　第一個問題是，在兩種模式下，如果起點站與終點站相同，程序將會報錯。在-b模式下，程序直接崩潰，而在-c模式下，程序輸出結果將會是10001.這個點雖然平時一般不會出現在正常輸入中，但是也算是一個較為普通的特殊輸入，應該被考慮。

　　第二個問題（可能只是理解上的差異），實際上大屯路東站和雙井站交叉的兩條線是不能換乘的，我設計時將這兩個站分開考慮，韓青長同學則認為可以換乘。兩種方案我認為都可以接受。

• Is all the code easily understood?

　　Yes

　　韓青長同學的代碼均使用C++語言編寫，雖然沒有學過，但是代碼風格上結構清晰，還是比較容易看懂的。

• Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.

　　Yes

　　代碼中變量名命名清晰，雖然有很多簡寫，但是能夠很容易的看出來它代表的意思。沒有讓人不知所云的變量。大括號使用單起一行的形式，與我的習慣相同，很舒服。同時行長控制較好，較長的行均分行寫出，代碼縮進風格統一，雖錯落但是給人一種容易閱讀的感覺。每一個模塊開頭時均有注釋，這是一個非常好的習慣，我這次的代碼沒有寫太多的注釋，這點我要向韓青長同學學習。

• Is there any redundant or duplicate code?

　　No

　　通篇瀏覽了代碼，整體來看沒有大段重復或者冗余的代碼。

• Is the code as modular as possible?

　　Yes

　　整個代碼中除了main()函數都沒有長于100行的函數，讀起來各模塊功能清晰，我認為已經盡力做到了模塊化。不過如果能將main()函數中的初始化地圖模塊獨立出去就更好了，這樣可以讓main()函數大大縮短，簡化邏輯結構。

• ?Can any global variables be replaced?

　　Yes

　　該圖是程序中全部的全局變量，鄰接矩陣和站點相關的存儲作為所有路徑計算的基礎，作為全局變量是必要的，但是簡易不要將數組大小定死，這樣有些不利于以后的擴展。比較好的方式是通過定義常量來初始化數組空間，這樣修改起來比較方便。下面有關遞歸的全局變量中，我想如果將遞歸函數外部套一層調用遞歸函數的路徑查找函數，這些全局變量就可以定義在路徑查找函數中了。不過要求似乎也沒說要盡可能少的使用全局變量，我自己也是寫了一堆全局變量==

• Is there any commented out code?

　　No

　　在代碼中并沒有發現過時的被注釋掉的代碼。

• Do loops have a set length and correct termination conditions?

　　Yes

　　在代碼的遞歸部分，最開始均有跳出遞歸的判斷語句。

• Can any of the code be replaced with library functions?

　　No

　　我因為也是初學，對于庫函數了解不多，但是整體看上去并沒有什么能夠直接被庫函數替代的代碼。

• Can any logging or debugging code be removed?

　　No

　　代碼很干凈，沒有調試用的代碼。不過讀取文件路徑直接設置為了一個絕對路徑，我覺得設置為相對路徑更好一些。

?

Security

?

• Are all data inputs checked (for the correct type, length, format, and range) and encoded?

　　Yes

　　代碼中循環讀入參數，對于不正確的參數或者站點名都能進行處理，輸出“輸入錯誤，請重試”

• Where third-party utilities are used, are returning errors being caught?

　　No

　　沒有使用到第三方工具

• Are output values checked and encoded?

　　Yes

　　輸出值與題目要求相同。不過有一點小瑕疵，就是前面提到的起點終點相同的情況，如果都在環線上，會輸出環線上所有站點，如果不在，距離則會輸出10001.

• Are invalid parameter values handled?

　　Yes

　　在輸入處理時，就過濾掉了無效參數。

?

Documentation

?

• Do comments exist and describe the intent of the code?

　　Yes

　　韓青長同學的代碼中存在著大量的注釋，對于理解程序有著很大的幫助

• Are all functions commented?

　　Yes

　　所有的函數都有注釋，甚至函數內部都有詳細的注釋

• Is any unusual behavior or edge-case handling described?

　　No

　　雖然對于邊界情況進行了處理，但是并沒有在注釋中進行說明

• Is the use and function of third-party libraries documented?

　　No

　　并沒有使用第三方庫

• Are data structures and units of measurement explained?

　　Yes

　　所有的全局變量都有解釋，且大部分的變量在聲明時都有解釋。

• Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?

　　No

　　沒有，全部代碼都完成了

?

Testing

?

• Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.

　　Yes

　　可以直接執行txt文件，并很方便的執行測試

• Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.

　　No

　　可能因為沒有要求，在代碼中并沒有測試代碼存在

• Do unit tests actually test that the code is performing the intended functionality?

　　No

　　沒有進行單元測試

• Are arrays checked for ‘out-of-bound’ errors?

　　No

　　代碼中并沒有對于數組越界進行處理，可能這是導致程序-b出錯的原因

• Could any test code be replaced with the use of an existing API?

　　No

　　程序中并沒有測試代碼

轉載于:https://www.cnblogs.com/shhr/p/5917193.html

總結

以上是生活随笔為你收集整理的软工_个人博客作业3的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。