摘要:
單元測試 我們在開發的過程中應該實時的對新產生的代碼進行測試,一是為了及時發現問題及時更改,避免日后代碼復雜龐大,debug工作難度會指數級上升,這樣及時測試,縮小了bug范圍,能快速找到問題關鍵,避免不必要的時間浪費;不斷的發現問題,可能是是自己編寫代碼前邏輯關系的錯誤,這種致命的錯誤越早發現,越
閱讀全文
摘要:
收獲:編碼之前必須的思考是逃不掉的,而且這一步是磨刀不誤砍柴工,而且會加速以后的步驟 分析: 首要重要的事情是:需要完成的功能,理清邏輯關系。我們要隨機產生一定要求的算式,并且計算出算式的值。 其次的事就是那個差點沒讀懂題的要求:重復題目的判斷,為了實現檢驗重復,最讓我心煩的就是那個奇奇怪怪的判定條
閱讀全文
摘要:
編碼: 語言:編程所用的語言不同,它的特點也不同。匯編語言更接近機器代碼,而高級語言或者領域特定語言則更接近人類對于現實世界問題的思維方式,以及解決方式。這樣更解放了人類的思維,不在意去關注電腦對于語句的實現具體過程。高級語言回避了很多實現細節,提高了抽象能力和表達能力。當然沒有好好封裝的語言工具使
閱讀全文
摘要:
github地址:https://github.com/ljw-wakeup/expression_project2 對于這種結對的工作,由于有過電子設計實踐的基礎,大概知道建一個工程需要做的事,有點經驗還是有幫助的。 小組成員:李鑫PB16061107 林靜雯PB16060913 一、問題要求:
閱讀全文
摘要:
這周開始結對作業,還有對接的問題于是乎就看了一些關于接口、類的東西 由于結對兩個人的空余時間的重合度不高,所以還是會有些時候是一個人寫,另一個人上課。這樣就存在一個代碼的理解問題,還好隊友和我都是沒有記憶力的金魚,沒有了注釋可能自己都不知道自己干了啥,于是乎在代碼里面的注釋很關鍵,宜多不宜少,要讓隊
閱讀全文
摘要:
我們制作一個產品的最大的障礙就是同行,俗話說同行即對手,雖然殘酷但是是事實。那么我們非常有必要去思考我們怎么做一個產品可以把別人家的用戶變成我們自己的。在這個快速的時代,人們都是非常煩忙的,如果這個APP與之前自己用的那款幾乎沒有多大的對自己使用價值的提升,沒有幾個人會愿意花額外的時間和精力去重新學
閱讀全文
摘要:
這次學習的最后一個關于敏捷與精益的時實踐例子是結合了敏捷和精益于一體的“看板方法” 這是一個在敏捷軟件開發的精益方法,所以兩者都有,但更側重于精益,同樣和精益的概念來自于豐田生產系統。它的定義是一種增量式的,演進的改變技術開發和組織運作的方法。看板通過限制WIP(Work-in-Progress)的
閱讀全文
摘要:
作業要求: 對源文件中出現的字符,單詞,函數,詞頻進行統計。并且利用性能測試工具分析找出瓶頸并改進。 基本要求的功能: 1·統計文件的字符數; 2·統計文件的單詞數; 3·統計文件的的總行數; 4·統計文件中各個單詞出現的次數; 5·統計文件中各個詞組出現的次數; 6·嘗試在Linux系統下進行性能
閱讀全文
摘要:
因為這次有了個人作業,讀書方面相對較少。不過,軟工這門課就應該這樣以實踐為主,理論都是架空的理想,實際的鍛煉才是最重要的。 有這番感想主要還是因為,做了個人作業之后再看書上寫的內容,簡直就是不謀而合,雖說個人任務相對于團隊任務或者一個項目的開發簡直就是小巫見大巫,但是這些道理都是相同的,畢竟這些都是
閱讀全文
摘要:
《軟件工程:方法與實踐》 讀書筆記 精益的思想本來就是源于汽車制造業,這本書就直接用日本豐田的實例很形象的告訴了我們什么是精益的思想。 精益思想的核心是“消除浪費”,但是這個“浪費”和普遍被認可的觀點有一些區別 比如:倉庫里還有原材料的剩余,普遍思想是全力生產產品以降低每個產品的平均的設備成本;然而
閱讀全文