1 這個專案要做三個工具，做包工具、打包加密工具、公升級工具，由於時間和能力，基本完成前兩個工具，公升級工具只做了介面邏輯。
2 用到的技術，用c++寫功能邏輯dll，c#編寫介面邏輯，c#介面呼叫dll來實現功能。這樣的好處是介面邏輯實現簡單（起碼比mfc好），功能邏輯用c++寫，方便功能移植。缺點是c#和dll直接的引數傳遞，如果不是原生資料型別，無法直接傳遞，所以呼叫就不那麼靈活。
3 這次使用了crypto++開源加密演算法庫（c++的lib形態），呼叫時都花了好多時間去配置專案屬性（之前老報 ***未識別的符號），步驟大概是
<1包含標頭檔案#include "***"，
<2 導入庫#pragma comment(lib, "***.lib")
< 3 配置專案屬性，c++->一般配置，導入庫的標頭檔案位置
<4 配置專案屬性，link->一般配置，導入庫的lib檔案位置
<5 配置專案屬性，c++->**生成 執行方式設定為 mtd(relase模式對應mt)
<6 在**中呼叫庫函式，並執行
4 由於專案規模變大，單元測試和整合測試複雜度變高，做包和打包工具主要步驟都是讀入乙個檔案，生成檔案頭，和其他的檔案一起，再組合成乙個檔案組合體。那麼就要寫拆分檔案組合體的**來進行單元測試，驗證從輸出是否能逆處理出輸入。當前未寫出逆處理。
5 犯了個錯，原來加密演算法庫是由產品部門提供的，我以為他們有義務協助加密演算法庫的配置，但反應上不是這樣的，我應該問有沒有加密演算法庫的使用說明，或者問問我們部門內有誰使用過這個庫，讓他來幫配置。另外對他們能解決這個問題有了依賴性，忘記了思考。到後來，自己也沒有配置好這個庫，在問問產品部門，是否必須使用他們提供的庫，回答是不必須。哎，在這裡瞎折騰，於是就搜尋了個開源加密演算法庫來用用。（警示：專案中有哪些條件是你自以為被限定）
6 時間分配上犯了錯，解決加密演算法庫配置問題花了接近兩天，應限定解決問題的試探時間上限，如果解決不了就先放下。（試探上限設定為半天吧）
7 另外需增加搜尋的面，如中文、英文搜尋引擎，使用者說明文件、官網、msdn。
8 溝通的問題，提問的方式，是否把問題點表示清楚。
9 由於剛用dll來編寫程式，還未完全適應，除錯也增加了很多難度，進度也變慢了。
第三個Sprint總結
成員 羅凱旋 羅林傑 吳偉鋒 黎文衷 第三階段四則運算專案預期的所有功能功能已經實現，包括自動生成各種難度的算式以及計時功能和小遊戲比賽 看誰一分鐘內算的題目最多等等 團隊github 燃盡圖 結果圖 1.每個成員第二個sprint階段有何需要改進?成員介紹 需要改進 羅凱旋首頁的ui設計有待改進，...
為第三個專案寫點開頭
前乙個專案差不多收尾了近乙個月，終於可以開始第三個專案了。本來的計畫是過到這個專案，好好地設計功能，然後編寫高質量的 不料與核心組同僚交流還有aboard組兄弟討論後發現有些觀點，有些想法是我以前常犯的，而且我也不確定待久後，這些想法會不會又死灰復燃。所以還是寫下記錄，記下一些我認為至少是現在，對自...
基於OOSE方法的第三個專案實踐
1 2014年2月11日完成相關需求說明書的確認工作。最近完成了基於oose方法的第三個專案實踐，對用例建模又有了更加深入的體會.1 基於物件建模的方法來進行用例建模 通常在用例建模的時候，要保持合適的尺度，不能太多，也不要太小，如何保持這種尺度，通常沒有乙個固定的方法，這也是大家普遍不願意應用這種...