2012年10月7日 星期日
UML 教學分享
前陣子我開始在公司內嘗試導入 UML 做為內部所有設計文件的溝通標準。過去,敝公司的前任架構師有他習慣的系統架構表達方式,定義了許多幾何形狀與色碼標準。
雖然其細緻程度也能相當詳盡地表達系統的異動,但總不是個業界標準的方式。
一直以來,我的理念就是讓工程師(包括我自己)在一家公司所學到的技能與知識,是到了下一個環境也能夠再運用的,而不是學到的知識僅僅只能適用於當下的工作環境,一旦轉換了工作環境就全部變成廢物,這樣不但無法真正累積實力,而且真的非常浪費寶貴的生命。
終於有機會讓這局面有了轉機,我開始重新導入設計文件的標準,開始要求工作同仁放下過去學到的一切,全部重新改以業界標準 UML 來表達一切的設計。
訂閱:
文章 (Atom)
-
最近公司在為了即將上線的產品進行壓力測試,產品內有個結帳功能是同事 A 先生的得意代表作,結帳功能在 A 先生信誓旦旦拍胸脯保證三百萬筆資料秒殺的信心下,平行作業卻發生了 Deadlock。
-
上次『 大禹治水 』提到,對於採用 Windows+ASP.NET+MSSQL 技術的網站服務,找出網站系統變慢、效能不佳的原因其實有一簡易 SOP 可以起手,減少無頭蒼蠅盲目亂撞的時間成本浪費,這篇就簡單介紹一下這簡易的 SOP。 ...
-
只要在軟體開發圈子混一段時間,尤其已經有系統 run 在 production 環境上,十之八九會聽到這句廣為流傳的經驗談:「 東西沒壞就不要修。 」 這句話,常常被反對重構( refactoring )者掛在嘴上。