iT邦幫忙

softwareengineering相關文章
共有 81 則文章
鐵人賽 自我挑戰組 DAY 18

技術 Day 18:如何當個 Code Reviewer

先來提個 PR 來紀錄目前的進度,當成一個里程碑,可以去 github 上看看 最近工作上在整理 PR 互相的 feedback,趁這個機會跟大家分享在看程式...

技術 Scrum: 什麼是Sprint目標?

Sprint目標是Sprint的一個目標,可以通過產品Backlog的實施來滿足。Sprint目標是產品負責人和開發團隊之間協商的結果。Sprint目標應具體且...

技術 一文總覽敏捷軟體開發術語

1. 什麼是Agile? Agile是一種軟件開發的理念,是對Software Development的價值觀。不是所有Project都應該使用Agile。Ag...

技術 所有您需要了解用例建模的基礎知識

用例描述了用戶如何使用系統來實現特定目標。用例圖由系統,相關用例和參與者組成,並將它們相互關聯以形象化:所描述的內容是什麼?(系統),誰在使用該系統?(參與者)...

徵才 GHR就博會-日本3月ONE DAY IT工程師面試會資訊

大家好:GHR是幫台灣人介紹日本工作的人才介紹公司FB https://www.facebook.com/GHRtaiwan/ ーーーーーーーーーーーーーー...

技術 《2017年Scrum指南》有哪些新內容?

今天(2017年11月7日)Ken Schwaber和Jeff Sutherland發布了Scrum指南的更新。Scrum指南是Scrum的權威定義,由Scru...

鐵人賽 自我挑戰組 DAY 23
再戰軟體工程 系列 第 22

技術 『雞尾酒式的scrum』 -- 談台灣最常見的 WaterScrum

曾經參加過大師91 Chen的講座,他提到:『現在在外面做scrum教練已經很難了,原因有二,一是有很多人認為Scrum不適合我們,二則是其他還有更多人認為我們...

鐵人賽 自我挑戰組 DAY 22
再戰軟體工程 系列 第 21

技術 『How Old Are You:怎麼老是你』 -- 從Singleton談設計模式

前面講了幾篇設計模式的好處,事實上,大自系統架構,小至單一個物件的創見,都可以看見設計模式的影子。今天我們從最簡單不過的『創建單例物件』(Singleton)來...

鐵人賽 自我挑戰組 DAY 20
再戰軟體工程 系列 第 19

技術 『程式都解耦合了,那測試呢?』 -- 談測試解耦合神器:Mock技術

在上一篇文章裡,我們介紹了透過『單一職責原則』來化解Feature Envy這個程式壞味道的方法。現在看起來PhoneBook與Contact都各司其職,並且功...

鐵人賽 自我挑戰組 DAY 19
再戰軟體工程 系列 第 18

技術 『你儂我儂的程式碼』 -- 談Code Smell 之 Feature Envy

我們在前面的兩篇文章中,各自提到了程式的『波動拳』與『大量參數』兩種降低可讀性的程式寫法。然而,大部分時候,『可讀性』並不是最嚴重的問題,他只是不高明而已,『耦...

鐵人賽 自我挑戰組 DAY 14
再戰軟體工程 系列 第 13

技術 『有點像又不會太一樣』 -- 慎選設計模式 之 模板模式

在前文中,我們看了依賴注入怎幫助解耦合與提高擴展性。在文末,我們有講到,當你有很多長得很像的類別,大家做的事都差不多,但是彼此之間都差了一點點,這時候該怎麼辦?...

鐵人賽 自我挑戰組 DAY 13
再戰軟體工程 系列 第 12

技術 『依賴注入(DI)』 -- DI做啥小?你才DI,你全家都DI!

今天要講的是一個老到不能再老的老題目:『依賴注入』。依賴注入,Dependence Injection,也很常被簡寫成DI。很多時候,我們都是在學Spring架...

鐵人賽 自我挑戰組 DAY 11
再戰軟體工程 系列 第 10

技術 『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (下)

不可能不欠技術債 在前文中我們其實已經提到了,技術債與金錢上的債務,有很多的共同點。在產品開發過程中,有時候為了搶奪商機,你不得不在深思熟慮後,決定用比較快速的...

鐵人賽 自我挑戰組 DAY 10
再戰軟體工程 系列 第 9

技術 『出來混,遲早要還的』 -- 工程師心中最軟的一塊:技術債 (上)

琛哥說了,出來混,遲早要還的。工程師出來職場上打滾,不論專業度高或低,責任心好或壞,都或多或少會累積出一些技術債。技術債這種東西,有很多點都跟真實生活中的借貸...

鐵人賽 自我挑戰組 DAY 8
再戰軟體工程 系列 第 7

技術 『根本就沒有QA』 -- 淺談測試與品保

『我進QA啦。』『這個案子現在已經在QA了。』『目前很順利,估計明天就可以進QA。』 多麽熟悉的工程師對白,不是?我對於各家公司的工作流程沒有意見,畢竟,能賺錢...

鐵人賽 自我挑戰組 DAY 7
再戰軟體工程 系列 第 6

技術 『為了估算而估算』 -- 談Negotiable的重要意義

打開Scrum教科書,翻到Planning Meeting,然後我們開始照本宣科的開了Planning Meeting,並且很乖的估算了故事點與工時。 然後呢...

鐵人賽 自我挑戰組 DAY 6
再戰軟體工程 系列 第 5

技術 『為了做事而做事』 -- 談價值的重要性

Planning Meeting估算完story,決定好這個sprint要做的story,sprint就開始了。 在一個自組織團隊裡,大家各有長才,各自領了自己...

鐵人賽 自我挑戰組 DAY 5
再戰軟體工程 系列 第 4

技術 『等價類劃分法』 -- 談測試的基本:快速建立所有可能案例

撰寫本篇文章是因為在一個讀書會當中,聽到了成員分享邰曉梅老師在著作中提到的觀念,雖然他不是該章節的重點,但是可以快速幫你已安全的方法,列出所有可能的測試案例。這...

鐵人賽 自我挑戰組 DAY 2
再戰軟體工程 系列 第 2

技術 『DoD』 -- 論定義完成的重要性

終於,我們開始跑scrum了。 在跑scrum的過程中,免不了要把需求寫成user story,再在每個story中定義什麼叫做『完成』。PO每個sprint都...

鐵人賽 自我挑戰組 DAY 1
再戰軟體工程 系列 第 1

技術 『量化工程師的忙碌度』-- 你是哪一個

『好忙啊,好忙啊!』身為工程師,時不時地就有這種心情吧?在產品發展的過程中,隨著功能越來越多,客戶需求變更,或是緊急修正線上bug,每天每天的工作忙碌度都不太一...

鐵人賽 自我挑戰組 DAY 4
軟體工程漫談 系列 第 6

技術 『用註解補足程式碼易讀性?』 -- 論註解的是與非

這是一篇臨時追加的主題,因為在前文中,有邦友指教,聊到註解的實用性,深有感觸。同時,想到大師Robert C. Martin也在作品中不只一次強調註解的利與弊,...