Contenu connexe
Similaire à 軟體開發之路甘苦談(Gelis) (20)
軟體開發之路甘苦談(Gelis)
- 2. • 熱衷於 OOA/OOD/OOP 與 UML 塑模化應用程式設
計、軟體工程相關應用
• 喜歡程式設計、擅長 ASP.NET Web Form, MVC,
WCF, Windows Form/WPF/WCF 開發、也實作過一
些專案
• 善於 Trouble-shooting 程式設計的各種疑難問題
吳俊毅 Gelis
集英信誠 - 資深.NET開發顧問
關於我
- 9. 軟體開發最痛苦的事情是什麼?
• 需求不固定,時程無法預估
• 政治問題…
• 時程壓縮 - 加班 (老闆暗示星期六你要來... 測試你對公司的向心力..?) 長官消磨
你的熱情...
• 無法與客戶溝通、無法與 PM 溝通、無法與主管溝通、同事不跟你溝通(很難溝
通?)
• 客戶像流氓、客戶說的不是地球話、Member 難相處…
• 背前人的黑鍋 => 我不入地獄誰入地獄? => 當作磨練... 只是工作而已! 熱情呢?
可能剩下 5%
• 接手系統沒文件、Source Code 不完整
– 前人沒用 Source Control...!!!
– Production 目前 Run 的不知道是哪一版 (跟交接來的 Source Code 不一樣...)
– 在 Production 找到一顆DLL在 Source Code 裡面是沒有的!... (讓我我了解了反組譯工具
是幹什麼用的!)
- 10. • 不懂技術的 SA/PM 談下天馬行空的需求 還跟你說.. 這很難嗎?
(我心裡想,你帶腦袋出門很難嗎,你怎麼不來寫?) 因此,那
一陣子工程師最流行的就是 "做不到"、"不然你來寫"
• 傳聲筒 PM...
• 懂皮毛的 PM 跟你說,他覺得這個功能半小時可以做完! => 你
是你說你可以寫完,還是我半小時可以寫完?
• 團隊沒有規範 - 各做各的...
• 每個專案都從頭來 (沒有既定框架)….
• 公司團隊開發沒 (流程/SOP)
– 老闆完全不懂技術…
• 將人當作資源,許多案子失敗的關鍵,工程師的產值多事是看的見的有形物體
• 別信 KPI?.... 程式碼不是用行數來衡量工程師的產出....
- 12. 軟體開發最快樂的事是什麼?
• 不要做專案 (誤)
• 賺很多錢?.....
• 做自己想做的事/寫自己想要寫的程式
• 程式寫完很有成就感
– 做出來不是客戶要的 (成就感瞬間消失)
– [還是有成就感 (自爽)] 因為學會某項技術?
• 可以玩新技術?
• 不要交接別人的程式?...
• 最好不要維護舊系統
– 不要維護別人寫的程式?…
- 24. Martin Fowler 在深圳的演講
• http://www.jianshu.com/p/e042ed1d79b0
• 一般工程學套用在軟體開發不可行(工程方法/計畫驅動):
– 開發人員視為可替換的資源根本是個錯誤的假設
– 每一個開發動作都同時包含了設計和實施的成分在
– 每一個軟體專案幾乎肯定具有獨特性
• 如果都是完全一樣的程式碼,那你根本不用重寫,只需要copy一分(或買
套裝軟體)就好
• 幾乎永遠不可能有確定的需求
– 那從不確定的需求,要準確的預估時程幾乎是不可能實現的
- 25. • 所以?
– 敏捷開發法的設計者認為,你不能把程式設計師看做資源
– 應該把軟體開發團隊看做是一組球隊
• 團隊中的成員每一個都有自己獨特的角色和任務,人人不可或缺,無法
輕易替代
• 所以,每一個球員的產值大不相同,高低之間可能相差數十倍,是無法
相提並論或替換的!
– 敏捷開發中的迭代(iteration)行為會是當今軟體開發最可行的方式
- 28. 軟體開發之路該怎麼走?技術怎麼選擇?
• 給社會新鮮人:
– 不要只挑熱門的學 熱門的很快就會冷卻
• 但也不要排斥學習新的技術 有用的技術
• 給軟體開發人員:
– 維持對軟體的熱情
– 對市場需求、解決那些問題 (自己有那些問題) 有足夠的洞察力
• 不盲目追求新技術
– 對於技術、工具有(評估/選擇)的能力
– 培養解決問題的能力
– 接受改變、擁抱改變、切忌一成不變、事情永遠有更好的方法
- 32. 聯絡我
• 部落格 (Gelis 技術隨筆)
• https://www.dotblogs.com.tw/gelis/
• FB 粉絲團(Gelis 的程式設計訓練營)
• https://www.facebook.com/gelis.dev.learning/?ref=bookmarks
• FB 社團 (軟體開發之路)
•
https://www.facebook.com/groups/361804473860062/?ref=ts&fref=ts
Notes de l'éditeur
- 適當的限制 => 是為了讓軟使用的技術不會整個發散
是為了讓軟體更容易維護、交接
適當開發框架,可針對某些特殊領域加速開發
容易控管團隊的開發時程
- 一直以來也都是取用對我的團隊有幫助的部分,而不是全盤使用。在這樣的情況下,對我的團隊或是客戶而言,我們是能夠做到取用適當的新工具來改善現有開發方式甚至是加速的目的。
- 這是一個認知上的巨大差異,一旦當你把軟體開發團隊,從傳統工程(例如營造)的施工團隊,轉變成球場上的團隊,你會發現你的思維將會瞬間轉換。你將不再相信傳統的專案管理方法,你帶領團隊的方式也會大不相同。
- 新技術 不代表就適合你現在的團隊,不代表就適合投入到專案中開發
技術、工具有(評估/選擇)的能力:包含對於技術有一定的了解能力 (時間越短越好) ,也就是對於該技術所帶來的效益、它解決什麼問題?以及它的長遠性 等等