說明:經驗是個好東西,希望你也能擁有,如果這就是經驗,我想我也get到了一點點
其實開發乙個模組或者實現乙個功能.需求分析時間應該佔到30%左右.下面以乙個看似非常簡單模組為例.
這是原有的基礎,看似就是簡單加乙個小功能,判斷是否顯示超出範圍調整
一:仔細分析需求後應該會有一些疑問
1:超出調整範圍是否只是在我們頁面進行顯示?還是需要回傳資料?
1.1 hr不需要再傳遞額外的字段,我們只要根據目前欄位就可以實現功能
1.2 "是否越級晉公升"的判斷標準是什麼?以下三個哪個屬於越級晉公升?
p2---p3? p2---p5? p2--m2?
1.3 "上次調整時間"對應什麼字段?是頁面上"內部調轉時間"嗎?
如果是,那麼這個欄位會不會有空值?如果初始值=="入職時間"的話會輕鬆很多,不然以後做判斷的時候會稍微麻煩些
另外"發起時間"和"內部調轉時間"和"上次調整時間"以及"入職時間"的關係
1.4 "晉公升的級別在m2以上或者p7以下，距上次調整時間或入職時間小於6個月" 這麼長的字段,在web端,特別是手機端,對整體頁面布局都會產生影響的.
1.5 字段確認此處是"m2以上"還是"m2以下"?根據上下文分析,應該是"m2以下".
1.6 我們就假設原有的邏輯和資料都是正確,不會出現,明明薪資調整了,"薪資是否調整"欄位還出現"否"的情況;也不會出現"上次調整時間"
2:"手動選時間" 我們是否需要回傳過去?
"入職時間"也能隨意調整.比如說判斷的上次調整時間2017-10-1 由於晉公升級別小於6個月,所以顯示"超出調整範圍".如果手動改成"2005-10-1"號,那麼會有什麼影響?如果該員工是"2015-10-1"才入職的.那麼這個時間是改的入職時間還是上次調整時間?如果公司是2023年才成立呢?而且這個"上次調整時間"是指"上次晉公升的調整時間"?還是指"上次調薪的調整時間",或是不區分
從第一階段的分析來看,我們不僅要提出對需求的疑惑的地方,還要對設計指出不足,有時候還不能簡簡單單的把問題丟擲來,還要自己試著去尋找答案,例如1.3這個問題,我們可以從系統中原有資料,分析歸納
二 敲**前的草稿
我們需要大致打這樣乙個草稿,這個比較簡單.所以在摸清需求的情況下可以自行開發,如果比較複雜,需要跟開發經理商量,看看思路是否跑偏,使用技術是否合理,
三:要預判技術難點.以我個人的意見,可能這個習慣未必利於對技術的發展.系統中有的能抄就抄,自己設計第一比較慢,而且實現起來坑比較多,也不利於後期其他人的維護
3.1 手動選時間,需要引入控制項或者jquery外掛程式嗎?直接使用我們系統中的日期控制項會不會有問題?是否需要回傳資料?如何回傳資料?有類似的例子嗎?
3.2 js如何對兩個時間格式的字串做差?
四:為測試人員提供一些測試用例.因為這段**是我們寫的,哪些薄弱的地方用可能出問題自己比較清楚,我們有義務為測試提供"拋磚引玉"的測試用例,反過來如果這些地方真的出問題對我們也是乙個成長,避免下次跳入相同的坑
一些簡單的測試用例
因為"調薪幅度"是我們這次開發功能的"根資料",所以要務必確保其正確性
1:發起一筆薪資不調整的單子.目的:測試判斷如果"調薪幅度"不存在的時候會出現什麼情況
2:發起一筆降薪超過30%的單子.目的:測試降薪出現負數的情況
3:越級晉公升,但薪資不調動
步步為營 79 快取
快取cache,一種空間換取時間的技術,適用於經常訪問,不常修改的資料.1 寫入快取 1.1 方法一 cache message ab 1.2 方法二 cache.insert message ab 1.3 其他過載 insert string key,object value,cachedepen...
步步為營 50 事務
說明 比較常用 1 事務的四大特性 1.1 原子性atomicity 乙個事務中包含的多個sql語句,要麼同時成功,要麼同時失敗.1.2 一致性consistency 事務必須使資料庫從從乙個一致性狀態變成另外乙個一致性狀態.銀行轉賬 1.3 隔離性 isolation 各個事務執行互不干擾 鎖 1...
關於排錯 專注思考，細心觀察，步步為營
時常有朋友發郵件給我，說遇到了乙個什麼什麼奇怪的問題，不知道是怎麼回事，希望我幫忙看看。我基本上每天都會抽出或長或短的時間來回覆這些郵件，不過也經常發現，其實許許多多的問題都完全是有能力自行解決的。在很多時候，我發現許多朋友還缺乏最基本的解決問題，分析問題的方式。其實我在平時工作中也會遇到各種各樣的...