推 FUDIRTY:我怎麼覺得回文比原PO講得好@@" 07/23 09:08
推 jackylu63:感謝damody大大分享 07/23 09:32
推 lairrol:上一篇是理論 這一篇是實務....我比較想看的是實務... 07/23 09:44
推 imasa:推這篇，現實工作上給你重構的時間幾乎等於零，除非很熱血 07/23 16:04
※ 引述《jackylu63 (J)》之銘言：
: ※ [本文轉錄自 Tech_Job 看板 #1HxMoN9q ]
: 作者: jackylu63 (J) 看板: Tech_Job
: 標題: [討論] 軟體工程
: 時間: Tue Jul 23 01:32:05 2013
: 第一次PO自己的心得, 煩請不吝指教
: 兩年多前，小弟開始接觸《人月神話》、《PeopleWare》之類的書後，才知道有《軟
: 體工程》這個名詞。後來我就對這個題目感到興趣，並且開始閱讀一些相關的資料。
: 對於《軟體工程》我自己有些心得 (獻醜了...)
: 我認為《架構》與《重構》是軟體工程裏最重要的部份
: 《架構才是王道》
: 「架構的存在目的是為了簡化管理，因為架構的本質就是在建立《分工》及《合作》 的
: 模式。」
: 架構將一個軟體系統拆開數個模組，模組與模組之間的交結處稱之為介面。
: 架構及介面的設計如果越能簡單明瞭，開發人員也就越容易明白自己及別人在做些什麼事
: 情。溝通的開發大型軟體最重要的一件事情，簡化溝通也就能簡化開發。所以軟體架構是
: 軟體工程最重要的一件事情，先談《架構》再來談《工程》這件事情。
: 《抽象是必備的技能》
: 抽象是以人類的思考方式來描述軟體行為。好的介面的設計必須要有好的抽象性，這樣才
: 能讓人快速的了解模組使用方式。老闆及員工都要有軟體抽象概念，這樣子溝通上才不會
: 有障礙。
: 《重構是必然的事》
: 軟體開發的首要之務在於了解《到底軟體要解決什麼問題》，接著才是《要如何解決》。
: 然而，軟體開發有個很有趣的現象：
: 「針對一個已經開發好的軟體，不會需要開發第二次，因為只要copy就會第二個產品出來
: 」
: 即使經驗再多的老鳥，對於一個新成立的軟體專案一定會有一些問題是自己事先沒有想到
: 的。而且這些先前沒遇過的問題，一定都是發生在專案開發開到一半時才發現。所以重構
: 是必然的事，說白話一點就是要改code。
: 一個好的架構在重構時所付出的心血相對會比較少。因為架構明瞭，所以對於架構設計的
: 不足之處也會很明確，這對重構會有很大幫助。
: 《品質第一，schedule放一邊》
: 即然要改code是必然的，我們來想想一個情形：
: 「不管三七二十一，改就對了，破壞架構也沒關係」
: 許多老闆的立場都是以產品是否能如期產出為主，他們會對程式員施加壓力，當程式員有
: 這樣子的時程壓力後，就會出現上面這樣子的反應。程式員為了交差，會想辦法在架構裏
: 挖洞，以達到目的。而且通常不會跟老闆說自己挖了什麼洞，因為這樣子會自找麻煩。
: 破壞架構就等於破壞模組間的分工合作模式，這樣子會造成潛在性的問題。像這樣子的潛
: 在性問題爆發的時間點越晚（專案後期），則後果就會越嚴重。因為專案的後期的程式碼
: 已經大到不可想像了，光是要找出問題點就會花許多時間，而為了要修正問題所更動的程
: 式碼就越多，動用的人力越多，時程也就越會拖越久。
: 在軟體開發的過程中，軟體品質一個不可妥協的原則。測試及CodeReview都是確保品質的
: 方法，但是更重要是老闆對品質的堅持。
: 《在架構之前》
: 不是說架構就能架構的，台灣學術界與產業界脫節嚴重，幾乎沒有人學校一畢業就能懂架
: 構。通常還是要在產業界實作經驗之後才會有能力。所以各個公司行號只好自己培養自己
: 的架構人才。
: 《物件導向程式設計》是架構人才最重要的一個訓練題材。不過，物件導向程式並不是C++
: C#, JAVA …，用C也是可以寫出OO的程式。OO是觀念，不是程式語言。
: 《IC設計產業現況》
: 我與一些朋友討論這個議題時，最後發現在科技業裏《時程》才是最重要的事情，會這樣子
: 主要與《競爭型的市場》有關，如果沒辦法在有限時間內交出產品，案子很可能就不見了。
: +----------------------------------------------------------+
: | |
: | 而且越賺錢的公司就越注重schedule，接著軟體品質就不保了… |
: | |
: +----------------------------------------------------------+
: 因此, 所以我上面所說的《架構》《重構》《抽象》《品質》《人才培養》 都是屁話
: 唉~~ 應該都不適用於IC設計產業
: 我自己曾經有過幾次在好的架構下開發程式的經驗，個人的經驗覺得，好的架構真的能對
: 整個案子開發有很大的幫助。能在一個好的架構下寫code是一件很幸福的事情。但是我與
: 我朋友討論這個問題時，大部份的人都認為《時程第一》。
: 因為《時程第一》，以致於老闆不會認為花時間訓練架構人才是重要的事情，工程師也沒
: 有時間好好想架構。
: IC設計產業現行的做法與我的理想差異很大，對此我反而開始懷疑自己的觀念是否有錯？
: 請教各位大大, 您的想法為何?
: B.R.
: J
你說的都沒錯，不過在"小"軟體的規模下，
老闆，就是付你錢的那個人會覺得這些是不重要的，
大部份公司寫的軟體都太小，
老闆寧願出事了，再找救火隊，
也不願平常就顧一兩個六位數的工程師在 hold住大局，
他們也知道啊！
不過他們會覺得這是可有可無的，
因為短期成本比請救火隊高很多，
那種感覺就是硬要用便宜的電源供應器，
而不使用貴又穩定的電源供應器，
所以難免會燒壞樣品的感覺一樣，
一分錢一分貨，尤其是突然的大電流常常會把ic推壞。
您的問題，
有點就像是去保險公司買保險，
平常沒問題時就是多付出，
出事了再找消防隊，就好，
雖然案子已經過deadline了，
不過你老闆評估後，
沒有比較虧，
ok的，
我們是工程師想法，
東西要品質，
要QA去Q，
開發的開始打好架構，
光是吃飯是沒用的= =
老闆要賺錢，
QA請22K工讀生去Q就好，
請專業的幹麻？
真的不行再電電工程師就好，
總之你老闆以短期來看都是賺的，
所以不難發現，
有很多SPEC有BUG的IC或chip讓人覺得很幹，
不過就是這些SPEC有BUG，
整合系統開發的人才有工作做啊哈哈！
然後不會解決問題的工程師發現跟spec做的不一樣，
就不會動了，
會解決問題的，就把spec改的跟ic一樣，
通常spec有錯，原來的公司也不會改ic，
將錯就錯，超機車的。
回到主題，
你們公司的軟硬體太"小"，
再大一點以後，
維護與開發成本提高之後，
你老闆自然會考慮這些問題，
因為這些節省成本會在專案後期會呈 exp 成長並反應出來，
出來混總是要還的，
多來個幾次讓你老闆開始賠錢之後，
他才會開始思考以前那套的問題，
當然，如果你們的工程師太強了，
讓問題一直沒爆發出來，
那老闆當然不會想提高成本來進步，
總之一點經驗分享。
--
標題 [趣事] 說服老媽進電影院看少年PI
→ milkfox:我的老虎哪有這麼可愛 老虎也要談戀愛 人X虎 11/28 10:18
→ milkfox:鄰座的怪老虎 元氣少年漂流虎 漂流床的寵物老虎 11/28 10:19
→ milkfox:少年與老虎漂流 絕園的人與虎 PSYCHO_TIGER TIGER_NOTES 11/28 10:22
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.209.157.39
※ 編輯: damody 來自: 210.209.157.39 (07/23 09:06)