final个人阅读作业
一、軟件工程M1/M2總結
?
1、M1階段總結：
我們團隊的軟件工程開發是按照前后端來分別開發的，我是負責后端的。我們的項目是做一個北航的社團平臺，是一個網站。在后端我們使用的是ruby on rails。一開始對于ruby是沒有什么經驗的，因為之前沒有過什么接觸，之前只是接觸過Python。剛開始的時候，我有去圖書館借書，不過后來發現書中的內容已經有些舊了，稍微有點過時了。后來在網上找了一些教程，以及一個叫做《Web開發敏捷之道_應用Rails進行敏捷Web開發》的PDF，然后才慢慢開始熟悉。我比較喜歡從整體去了解，然后再開始關注細節，所以在M1階段我的開發進度是比較慢的，之前一直在學習整個工程構建，然后各個層次之間的關系等。之后就對于rails的體系有了一定的理解，然后才效率高了起來。在M1我們的進度總體上是很順利的，沒有遇到什么大的問題，整體項目的進程和我們的預想和安排基本一致。在第一輪，我們的整體項目是按照API文檔來實現的，項目PM先拿出了一份簡版的API文檔設計，然后后端和前端分別按照API文檔的設計開始實現。然后在我們都熟悉了這樣的開發模式以后，設計API文檔的工作就交給了后端補充，在一輪，我記得我大概是實現了設計到用戶狀態信息驗證的部分API，以及活動名單等API的實現。總體而言，在一輪的收獲，我覺得主要是這些吧：首先，單單從技術上來說，我學習并了解了ruby語言和rails，了解了什么是BS架構程序，什么是web開發。另外，我覺得我對于軟件工程的敏捷開發有了一點點的理解吧，因為rails很方便地提供了一種敏捷開發的方式。不過我們的開發實際上不能完全算是敏捷開發，就是不能說我們是完全做到隨時跟隨需求改變程序然后就很快拿出來demo那種，我們的開發和敏捷開發是有一定區別的。不過對于rails的理解，對于我對敏捷開發的理解有許多幫助。
?
2、M2階段總結：
?????? 在M2階段，可能所有人都會提到就是任務量時間的安排吧。我當然也不例外...因為在M2階段，說實話真的和M1比起來，學習到的知識上的東西并不是很多，主要的都是在學習如何應對各種各樣的壓力，各種各樣的事情接踵而來，如何在這些事情權衡。對于軟工來說，我覺得就是學習了如何在各種事情打斷，對于你的節奏不連貫的情況下，調整自己的節奏來面對這種隨時會被打斷的情況。在M2的開始時候，我實際上是有轉過去前端來幫忙，我自己也是希望能夠學習了解更多的知識。在第一輪的時候我們就發現實際上前端壓力遠比后端大，所以第二輪的時候我們是認為應該對于前端更重視的，所以當時我們的設想就是從后端拿一個人去前端。然后剛好我有想學習前端的想法，我就轉去前端了。在M2開發階段，我們的第一周是用來學習第二輪用到的各種新的東西的。在我們最開始的設計中，M2開發中，前端會學習使用Vue.js和React的，后端是需要學習一下learncloud，還有對于rails服務器的模式的調整。然后我在這一周的時間是需要去了解前端開發的基本知識的，當時我一直在看html5，css等，當時的感覺就是，實在是太雜了。感覺看了那么多收獲也不是很大，然后那兩個框架我也看的不是很明白。那一周對我來說，收獲是比較小的，也沒有取得什么成果。然后這周過去我們正式開始準備開發以后，當時我們經過討論，發現我們所面臨的問題和我們之前的設想差的很遠。因為在十二月，我們開發軟工的這兩周，需要面對數據庫大作業，數據庫答辯，數學建模大作業，編譯實驗等。這些東西全都擠在十二月，直接和我們的軟工開發是湊在一起的。然后我們當時匯報之前一周的學習狀況的時候，大家狀況都不是很好，所以我們經過討論還是沿用了第一輪的開發方式，就是還是按照原來的方式實現。然后我也就轉回了后端，還是繼續實現后端的功能。然后就正式開始開發，前兩天我主要負責后端數據庫的設計和API文檔的設計。哦對了在第二輪我們相比于第一輪，還引入了github的成分。在M2階段，我們的文檔是以markdown然后發送到github項目的wiki中的。當然代碼同步等等。然后當時那一周的開發還算比較連續，然后就開始斷斷續續了，尤其是編譯的第一次測試，然后還有就是數據庫大作業到了不能再拖的時候...軟工當時的進度真的是斷續的特別厲害，前端負責開發的一些同學實在是沒辦法繼續下去，就是我們的PM還在繼續開發前端的用戶界面。當時那段時間過的比較艱苦，好吧其實一直到今天答辯之前，這一整段的時間我們過的都十分艱苦......軟工的開發都是摻雜在這些考試和大作業deadline中的。中間也不知道刷過多少夜了。總的說起來，在M2輪的話，技術上的收獲，可能就是對于github的使用了吧。對于git的clone，commit，branch操作，還有就是當時使用的時候造成了很大困擾的merge，這些都有了一定的了解。不過我還是覺得，這輪開發，最大的收獲，還是在面對壓力上的。就是這種苦熬的感覺，在面對各種事情接踵而來，感覺沒有一個時候是頭的感覺，但是還是得繼續堅持的感覺，我覺得這種堅持對我來說是一個很有意義的經歷。
?
二、《構建之法》閱讀作業以及相關問題分析：
?
1、《構建之法》閱讀作業鏈接：
http://www.cnblogs.com/wk1216123/p/4831004.html
?
2、理解的問題
關于代碼維護的重要性：
?????? 當時的那個，說代碼維護不重要，然后還不如推翻了重寫的，是來自我們上個學期的一門課叫做oo，然后當時我們就是因為被各種注釋和規范折磨的特別厲害，然后在一個論壇還是什么地方看到的，然后當時在對于代碼注釋和規范十分厭倦的時候，對于那個觀點是比較支持的。不過經過這么多的開發，顯然這個問題也沒有什么好回答的，顯然代碼維護是十分重要的，代碼的注釋和規范對于一個項目的開發效率，尤其是多人合作的項目，影響當然是很大的。
?
關于團隊中想法不統一造成效率低的問題：
?????? 其實說實話，現在再回頭看當時的那些問題，很多都不是什么問題。好多都感覺可能是當時為了想出問題而想出的問題吧...就拿這個來說，團隊中想法不統一是肯定存在的，不過我個人覺得這種情況是積極的。因為想法不統一，就說明大家對于問題都有自己的思考，這是一方面；另一方面，將這些想法都考慮清楚，然后再統一想法然后開始，對于整個項目的理解會有很大的幫助，然后也會利于少犯錯誤等等。當然，在一個團隊中，每個成員都是要學會理解互相的，不能說性格很強，然后就持著自己的想法死不放手這樣，還是要學會權衡和接受吧。
?
怎么樣的軟件是一個好的軟件：
?????? 在現在看來，經過這段時間的開發，我覺得一個好的軟件是會有這樣的一些特點：功能強大，效率高，代價小。這三個我覺得都是很重要的，一個真正好的軟件是肯定需要權衡各種因素，使得這三個都在一個很良好的位置上。然后如果再區分的話，個人會覺得功能會更重要一點。
?
3、仍然不理解的問題
關于如何衡量開發成本和收益的問題：
?????? 這個問題我覺得，我覺得主要問題在于，現在所學習的知識還是不夠吧。個人覺得在有了一定開發經驗的情況下，應該以比較妥當地判斷出來開發成本吧。不過對于收益而言，就完全不是很明白了。我覺得還是得接觸更多的知識才能解決這個問題吧。
?
關于客戶要求如果是錯誤的，是否還是第一位的：
?????? 這個問題我不是很明白。我個人覺得，可能比較合適的做法是，盡量去和用戶解釋，然后說明情況，然后如果實在不行，還是得按照客戶的要求來吧。不過我并不是很了解，因為我沒有足夠知識來理解客戶要求的重要性到底到了什么地步。
?
三、8篇論文博客閱讀作業及相關體會：
?
鏈接：http://www.cnblogs.com/wk1216123/p/4962653.html
對于銀彈問題，我的理解和之前還是差不多吧，不過可能稍微有一點點的變動。我之前一直單方面地認為附加性問題的影響是要大于本質性問題的，不過后來我覺得本質問題和附加性問題，這兩個之間是需要在一定程度上考量的。對于大量程序而言，就是不處于科研前沿的程序，就是只是平時的應用或者是平時這些普通應用而言，我覺得附加性問題的影響是要大于本質性問題的。但是對于科研前沿的問題，比如人工智能等等，在這些領域中，本質性問題當然是最難以解決的方面。所以，這兩個概念，是要結合起來看的。我覺得在論文里面，作者所指出的情況，應當是指的是科研前沿而言的吧，所以站在作者角度，是會有這么個東西影響很大的，那就是本質性問題。
大泥球問題，在經過了軟工兩輪的開發，對于這個問題的理解和體會還是比較深的。在我們的項目中，大泥球問題是存在的，尤其在第一輪的代碼中，一些大泥球問題延續了下來。一個最簡單的例子，當時我們對于rails的render理解的不是很清楚，當時我們的理解是render和普通函數的return是一個意思，但是實際上這兩個東西是完全不同的。render是一個方法，是去渲染一個返回的表單或者是其他成分，可以是頁面等，然后實際上不是return。對于一個API是不可以渲染多次的，然后我們當時就將render理解成了return，然后就會可能導致多次渲染的問題。然后這個問題在第二輪的時候才被發現，當時我們在測試的時候發現一些API出現了兩次渲染的問題，然后經過研究才發現了這個問題。但是這個錯誤已經隨著一輪代碼的四處拷貝復制等，已經到處都是了。然后改的很費勁。這只是一個簡單的例子。我覺得對于大泥球問題，一方面我們需要提升自己的知識水平，對于很多錯誤需要能夠識別，然后我們需要改變很多不良的代碼習慣，就是要多考慮代碼重用的問題。我在二輪的時候有注意這個，然后將很多我覺得會重復的方法都寫成了代碼塊在一個主類中，然后在分類中就可以直接調用代碼塊達到目的。
關于大教堂問題，我覺得這個的話，我們還是會選擇大教堂模式的。就拿我們現在的項目來說，我們中間有做實名認證功能，然后這個功能是在教務的支持下完成的。我們是通過token來控制調用另外的API實現的。如果這個token泄露了，那么教務的數據就會泄露了。而這個token是作為代碼的一部分的，是不可以公開的 。所以實際上，我們是不可能使用市集模式的。不過當然，市集模式和大教堂模式的區別本質當然不是指保密性，不過我覺得保密性實際上是我們應該考慮的部分。
關于開源，在我們的項目中是沒有使用任何的開源項目或者別的開發框架的（就是指比如開發論壇，關注這樣系統的框架等）我們當時的考慮就是，一方面我們希望能夠自己手動來寫，這樣可以提升我們的能力。另一方面，如果使用了框架，項目就會受到框架的制約，對于項目的兼容，響應效率等，然后對于一個項目的上限，和今后開發都會有影響的。
關于簡潔最好的話，沒有太多特別的體會......
關于瀑布模型，我覺得其實在我們這個開發中并不是很合適的。因為很多情況下我們需要隨時修改我們的設計，所以如果是瀑布模型的話，之前錯了我們還要倒退回去，我覺得就不是很合適了
關于敏捷開發，比如我們的API文檔是隨時隨著需求的變化而變化的，然后我們后端的實現就需要隨著API文檔的變化而變化。
軟件工程的方法，我覺得是需要我們去體會的。對于軟件工程的方法有了足夠的了解，自然會起到一個引導的作用。
?
四、項目的 需求/設計/實現/測試/發布/維護?等6個階段中的學習體會：
?
需求：
在需求階段，主要學習了一些了解用戶需求的方法，比如調查問卷，面談啊等等。對于需求的詳細描述，主要就學到了NABC方法。
設計：
在設計階段，我們應用過ER圖的方法，另外還有做過數據流圖。
實現：
在實現階段，主要學習了代碼規范和注釋等，另外就是一些實現的方法，比如結對編程等。
測試：
在測試階段，主要學習使用了單元測試，黑盒測試，兼容性測試，壓力測試的方法。
發布：
在發布階段，主要就是有一個事后分析。
維護：
我們并沒有經歷維護階段，不過個人覺得，維護階段可能需要學會如何合理的解決bug的能力。
轉載于:https://www.cnblogs.com/wk1216123/p/5118910.html
創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎總結
以上是生活随笔為你收集整理的final个人阅读作业的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 自己为 GridView 写分页 如:
- 下一篇： 水系图一般在哪里找得到_进展 | 水系钾