台灣最大程式設計社群網站
線上人數
729
 
會員總數:245116
討論主題:189028
歡迎您免費加入會員
討論區列表 >> 心情甘苦談 >> 軟體組裝工廠-就從基層作業員做起吧
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
軟體組裝工廠-就從基層作業員做起吧
價值 : 500 QP  點閱數:6566 回應數:21

樓主

大頭源 版主
中級顧問
31892 227
19015 5947
發送站內信

捐贈 VP 給 阿源哥哥
各位程式寫作的愛好者:

今年由於某些因緣際會而興起了寫書的念頭。
(實際上是年紀也大了,實在沒力氣一直寫程式了,孩子還小總該再找些出路)
本來是興衝衝地一頭寫下去,但是前幾天跟某網友談起,應該是先找出版商談,
看看他們是否有興趣出才開始寫。

想說也對,但是個人還是想說那乾脆連潛在的讀者也問一下,看看他們
是否對這個內容有興趣。(也就是小舖的眾網友)

書本的架構不會想去追求新技術。(但是會以VS.NET 2008為主,可能會加入一些WorkFlow的話題)
而寫這個題目的動機是覺得一般程式開發的方式。
(我非本科系出身,沒補過習,也沒與資訊單位的同仁共事過,所以我認為的一般開發方式是指書上看到的)
如果是一個資淺的人員,如果他無法完全獨立作業的話,往往無法在團隊中與人合作,他的前輩再忙,他也插不上手。
而因為個人曾經在一些電子廠、機械廠、模具廠當過設計及管理的工作。所以個人認為程式設計應該也可以
類似電子工廠的組裝生產線一樣分工合作。讓一些程式邏輯不好的人,或是下資料庫指令不熟的人還是有發揮長
才的餘地。

所以我歸納出數條【生產線】:資料庫、商業物件、元件組裝、報表設計、成品組裝等五條生產線
上頭再由一個Poject Manager帶領,而這五條生產線可各自作業,各自作品檢,最後再整合成一
個產品。雖說是分成五條生產線還是可以由一人獨立完成,只要他能了解各個工作流程的工作方法。

底下的文章及範例是「元件組裝」的部分,可以讓一個對程式不是太熟練的人也可為團隊貢獻
心力。(或許他有美感及使用者操作介面順暢設計上的長才)


文章內容
http://www.keigen.net/share/documents/partsassemblyline.pdf

範例程式下載
http://www.keigen.net/share/SampleCodes/partsassemblyline.zip

不知道這樣的主題是否會引起讀者的興趣。請各位參考一下,如果有興趣也請提一下另外也想了解
那些東西,如果可以(個人還會的話)我會寫進書中的。

將來如果真的出書成功的話,應該是會有個贈書活動,只是到時應該不會是用抽的。在小舖曾經幫助過
我的,一定會免費送一本。


但是也或許是孤陋寡聞(因為真的沒在資訊單位與人共事過),會有人提出,人家早就是這樣做了
沒有出書的價值,那‥‥‥只好就此打住了。


本篇文章發表於2007-09-08 00:50
== 簽名檔 ==
我的 ASP.NET MVC 學習心路歷程

ASP.NET MVC 自學日誌:http://mvc.keigen.net

我的畢生經驗分享-老實書局:http://www.keigen.net/Books
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
1樓
最有價值解答

maduka
捐贈 VP 給 maduka 檢舉此回應
剛剛已經把pdf看過一次了
在下覺得這樣的寫法其實是蠻新穎的方法
或許是可以吸引讀者的一種方式
不過不見得所有的人都曾經在工廠工作過,所以對於一些說明的內容上
就是以工廠的流程或是觀念來描述的部份,可能會有讀者看不太瞭解的情況

對於出版社來說,出版社會考量的是這本書推出後會不會有市場
銷售量會不會好
所以還是建議您先與出版社聯絡
或是找小耿也可以,他那邊有合作的出版社喔
本篇文章回覆於2007-09-08 09:21
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
2樓
不錯的參考

淳淳的小羊
捐贈 VP 給 缺氧的羊:窒息 檢舉此回應
版大的構想, 說實在的, 是蠻不錯的

只是!!!!, 可能需要有更清楚的一個[定義], [定位]
=============================

我有大致view了一下pdf檔


說真的, 如果這本書, 真的要定位在[基層]人員的話,
裡面的內容可能還太深了...........

(相信我.......我一開始在寫ASP.NET時,
並不曉得event要怎麼弄出來, 只能點2下 產生click的事件
根本不曉得其他事件的呼叫方式...

甚至於, 把書本的 事件程式碼照抄...還打錯字...>_<
後來才知道VB.NET跟C#要在哪裡自動產生event)
=============================
我之前在工廠工作時,天天都想[打破砂鍋]...
搞到最後主管直接說:你不要再問了, 你就照做.........(然後我的疑問還是沒解開)

對於[基層]的人來說: 為什麼, 怎麼出現的...其實蠻重要的...

或許現在的人講求速成, 只看結果, 但...如果書本沒有一個詳細的步驟的話,
讀者很容易 lose掉某些步驟...然後就會發生: 書本的畫面跟實際操作時的畫面不一樣....
或者:書本突然出現某個畫面, 但是...根本沒有寫怎麼出現的..........

我家真的有這樣的 C#.NET ... ... 看了就搖頭.......
(這讓我聯想到小時候 我們老師總是說: 課本會犯錯, 所以我們要用人腦來訂正課本...)
我真的在找到答案後, 把書本沒寫的步驟補上去...........
=============================

另外一點就是:畫面...
我從以前到現在, 所設計的一切文件...畫面都跟您的差不多...
但是呢...每次我在看別的文件時, 總是會覺得...畫面少了很多...
(一陣子之後再回頭來看自己當初抓的圖, 還會不曉得自己寫了什麼... )

[鼎新]前一陣子來我們公司推[美容系統]時, 有給我們一本操作手冊...
說真的, 那本手冊真的不錯(很厚就是了), 所有的操作畫面幾乎都是全螢幕...
而且是完完全全沒有lose掉畫面...(做那本一定很辛苦, 也許訂正很多次了)
=============================


以上是我的感覺
本篇文章回覆於2007-09-08 10:03
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
3樓
不錯的參考

淳淳的小羊
捐贈 VP 給 缺氧的羊:窒息 檢舉此回應
我之前在學Java時, 有買一本 thinking in java (中文書),
還去官網下載了原文的PDF(國外的人真的很喜歡免費提供...)

裡面的簡介有提到, 作者一開始撰寫完的時候, 原本要直接送印了,
後來在一個機緣巧合之下, 決定把整個原稿PO在網路上讓大家看(OPEN SOURCE)
結果, 一開放, 馬上出現上千封的回應, 而且抓出了作者完完全全沒注意到的問題,
作者也因此得以在出書之前順利將有問題的部份, 不人性的部份全部修正,

最後出書...依然大賣...而且似乎也順利成了Java的主流書籍

(這種方式, 說真的 在台灣行不通, 有電子書可以下載, 就沒什麼人要買書了)
但是, 這種方式能夠真正的解決個人在撰寫時,所忽略掉的問題,
如同maduka 所說:可能會有讀者看不太瞭解的情況, 出版社會考量的是這本書推出後會不會有市場)

本篇文章回覆於2007-09-08 10:11
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
4樓
作者回應

大頭源
捐贈 VP 給 阿源哥哥 檢舉此回應
謝謝兩位先進提供寶貴的意見。

關於出版商,是已經請一位目前贈書活動正打得火熱的作者幫我牽線了
只是目前尚未有回音,而個人一向是比較不看重金錢,倒是比較喜歡把
事情作好,因此才興起問問一些將來可能的讀者的意見,希望能在第一次
出書就能做好一點(Do it well, if you do it at all.)。

書本當然不是真的要定位給[基層]人員看的。所以一些該如何從工具箱拉出
一個控制項,如何去設定屬性,如何去寫個Function、如何寫Class、如何定義變數‥‥
等等,一些市面上已經有許多書在寫的東西都會只是提一下並帶過。
如果全部都寫那可能是一本非常大本的書了,且也不太可能在VS.NET 2008上市前寫完。

而會在最前面就寫一個只要拉一拉就有功能的東西,實在是想說服讀者在接下
來的程式會寫「非常多」的程式碼,會有許多的Design Patern,會對程式碼
作很多的切割,而這這「麻煩」的處理是有意義的,因為怕把這些寫在前頭,
可能會有讀者嫌太麻煩,而馬上放棄。有時前段作業的麻煩是為了省下往後的時間。

而個人在初學程式時買了許多書,而書本大多是講些某些(控制項之類的)功能,
該如何用,但是如何把全部所學的湊成一個系統就講得很少了。

比如說個人剛開始對VS.NET 2005的一些Typed DataSet及一些DataBinding非常
感興趣,買了很多書來看,也真的是能很方便就能有資料庫新增/修改/刪除等功能。
但是如果有在開發系統的人一定了解,只會把資料填寫入資料庫,這並沒有完全學會。
重點是如可控制「正當」的人填入「正確」的資料進入資料庫,而這些一般的書
本並沒有說。

一般的書本也只是講,某個控制項如何用,而個人認為重點應該是如何在正當的時
機選用適用的控制項。這也是我多年來想提倡的「逆引導式」學習法。


至於圖,確實是應該全螢幕,且在一開頭就該建議讀者把環境都設成與書本一樣,
比如「資料來源」要放左邊,「工具箱」要放右邊,某個選單不能隱藏‥‥。
因為我小舅子失業有一段時間了,我跟老闆爭取了工作機會,初期也是請他幫我
拉控制項,但是說明書如果沒全螢幕,只是跟操作有關的角落,他還真的找不到,
所以圖到時應該會重貼一遍。





本篇文章回覆於2007-09-08 11:04
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
5樓
不錯的參考

伊恩
捐贈 VP 給 No.18 檢舉此回應
的確是很特別的表現手法,不過在內容上若是定位在基礎人員的話,應該是稍微深了點,畢竟現在真的很多人只知如何照本宣科的做,而不了解其中真的正的內容,另外在圖的呈現上,看起來比較像操作手冊,如果是出書的話,可能需要再安排一下位子囉,純屬個人感覺的小小意見,祝大大順利出書
本篇文章回覆於2007-09-10 00:36
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
6樓
作者回應

大頭源
捐贈 VP 給 阿源哥哥 檢舉此回應
前幾天跟某網友討論後覺得目前要出書確實是有點處於尷尬的時期。
因為當書寫完後,VS.NET 2008也上市了,正好是微軟強力打
VS.NET 2008廣告最盛的期間。如果以VS.NET 2005來寫書,不管
內容寫得再好,到時大概是沒有人要看的。
(雖說WinForm到VS.NET 2008完全沒變)

而我書中想寫的主要是「商業物件」的部分,而前述的文章及例題只是想告訴
讀者只要「商業物件」寫好,後續只要跟UI拉在一起就是一個Application了。
與WinForm拉在一起,還是與ASP.NET拉在一起都可以用同一個「商業物件」。

因此,再三考慮不如將UI拉成與WPF在一起。(好在在SilverLight發表會上有A到
一本WPF的書)

所以趕緊下載了VS.NET 2008 Beta2來測試。(奇怪,怎麼有日文版、韓文版,就是沒有
中文版,真該連合灣人給微軟一點壓力)

測試後,果然也是只要Binding過去,也是個WPF的Application了,所以信心大增,
決定就寫For WPF的。(雖然可能還要加上一點學習曲線,但是還可把寫書的時間拉長到
VS.NET 2008上市後一兩個月)

==
本來以為WPF只是在WinForm加上新的功能,但是測試後發現,這簡直就是
「破壞性創新」就像是液晶顯示器與映像管顯示器一樣。

在發表會上鄭老師所說的「微軟已經不會再發展WinForm的東西了」
當時只是認為她是為了讓她的書好賣故意這樣講的,
但是測試後發現果然不假,雖然WPF目前在工具箱中是比
傳統的WinForm少很多控制項,但是有的都是與WinForm有對應關係,因此猜想
微軟隨後會慢慢地將缺少的補齊並追過WinForm。

而在試著寫WPF AP時,驚然發現好像在寫ASP.NET一樣。
(已經很久沒寫ASP.NET了,目前是寫WinForm比較多)
同樣的是一個XML Like(XAML)的文件負責UI的部分,然後再一個Code Behind
來負責程式,熟練ASP.NET的人應該可以很快地接受這觀念,很快就可以上手。
(我說應該,沒有說一定),看來微軟是想整合所有AP的開發模式,就好像是
熟Office其中一項產品,那另外的產品操作起來就覺得似曾相識。


而之前寫的For WinForm的就全部公開好了,會找空檔慢慢貼出來共享同好。
因為是第一次寫書(論文不算),可能一些表達能力不是很好,還請各位多多指教。





本篇文章回覆於2007-09-10 08:20
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
7樓
不錯的參考

ASP.NET新手
捐贈 VP 給 ASP.NET新手 檢舉此回應
第三頁第二行,什麼是「組裝手順書」啊?這個名詞小弟看不懂......

其實不是看不懂,只是一開始直接看到這個名詞的話,相信一般程式設計師也看不懂
畢竟有很多時候在設計一個專案時,不見得會了解某一個領域的術語或專有名詞
如果是針對一般讀者的話,或許可以換個更口語化的說法

其餘二十多頁,小弟只有大略翻了一下∼

但這本書的定位在哪裡?或許大頭源兄需要思考一下∼
初階、進階、還是高階使用者?以及應用範圍在哪裡?

因為小弟大略看了一下,會產生一種錯覺
這是一本提供給專門幫電子廠、機械廠、模具廠設計程式的程式設計師看的書籍嗎?

在詞彙上可能需要再修改一下,才比較能夠帶領使用者進入狀況
而用字遣詞可能需要再多用心一些,像是第23頁「半成品入庫」上面那張圖片中的文字註解「沒有權限不給修改」
可替代成「沒有權限,不允許修改」,「欄位不許空白」可替代成「必填欄位不允許空白」
文字的語氣及用法需要客氣一些......

這一點在#1 maduka有提過,在此小弟只是稍微補充一下

而在#5 伊恩有提到,圖片的呈現上比較像是操作手冊∼
但說它是操作手冊嘛,小弟總覺得好像少了點什麼......

小弟覺得在圖片的編排上,還可以稍作調整∼
例如:ErrorProvider控制項要怎麼拉?它會出現在畫面中的哪個位置?
其它類似的控制項也是一樣的拉法嗎?
如何加入控制項、元件、類別的參考?
我想這個只需要在書本一開始的第一個章節講解一下就好了∼
讓基礎的使用者了解如何去使用VS.NET 2008的操作介面,
這樣子在其它的章節中,就可以省略掉許多圖片,而可以用更詳細的文字去說明
(其實對於VS.NET 2003、VS.NET 2005的USER來說,這些可以都省略不要......)

另外還有一個比較奇怪的地方,圖片上雖然有標明1. 2. 3. 這樣的步驟
但是在文字敘述的地方並沒有,這個比較容易讓讀者眼花 =.=|||
大多數書籍都會將圖片標上編號(圖一、圖二、圖1-1-2),以在文字敘述中引導讀者去看圖片

以上幾點是小弟個人的一些淺見 ^^"
本篇文章回覆於2007-09-10 10:10
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
8樓
不錯的參考

topcat
捐贈 VP 給 topcat 檢舉此回應
大頭源 大大要出書囉
^_^

內容編排上小喵並不專業,所以就不敢發表意見
不過書籍上的定位確實要思考一下

這本書要定位在哪個層級的讀者閱讀(初階、進階、高階)
當然這個定為可以橫跨(例如初階+進階)
這樣要推這樣的書的時候,以及讀者要考量閱讀的時候,會比較容易有個方向
--

出版商的部分
如同maduka大大所說
如果有問題可以請小耿大大幫忙
--

小喵本來也有想過是否要把目前的開發方式也寫一寫(COM+)
不過就如同大頭源大大所考量的
.NET 3.0都已經出來一陣子了,WCF未來也很可能取代這樣的方式
所以後來小喵打消了這樣的念頭
(也許未來運用WCF熟了後可以再來考量)
--

從試讀的那個內容看了一下,應該是以WinForm的方式來處理的
不知道大頭源 大有沒有寫WebForm的部份呢??
--

最後還是預祝...書籍暢銷大賣唷
^_^
本篇文章回覆於2007-09-10 11:11
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
9樓
作者回應

大頭源
捐贈 VP 給 阿源哥哥 檢舉此回應
謝謝各位。

其實書本的重點是要講「商業物件」
而這個商業物件將來也可以移作WebService,COM+
當然這樣的寫法不是我發明的,是參考到國外的書藉而想引進國內。
(有上網查一下,大陸那邊已經有人在推廣了,而「本國」應該還沒有【查到】)

而那個例題是用在WinForm上,但是商業物件是跟UI無關的,
要用在WinForm、WebForm或WPF都可以的,且我這堣]都有可Run的Sample Code了
只是用在實作的例子上(也就是我接的案子上)就只有WinForm的而已,所以才想先出
WinForm,等看看市場反應再出WebForm或WPF。(只是拉UI而已)

剛剛跟某位高手通過MSN,有可能會以WinForm為主,然後再夾一點WebForm(或是WPF)
來証明商業物件是跟UI完全切開的。是可重複使用的。

而書本的定位是定在比較高階的。(有想往高階進步的人)當然不是說我算是高階的人
只是我比較會讀書,比較會把所讀到的東西整理出來而已。而作法上有用到許多的OO
觀念及Design Pattern,但是不是要講OO,而是要講OO可以這麼用。(只要會用就好了)

或許,有許多表達技巧要多磨練,這還要各位先進多多指教。

而會想出書,是因為最近工作的重點會慢慢地移向只是出嘴吧叫人工作,所以比較有多
餘的時間研究新技術。

而該軟體開發模式也正是我目前在組的工作團隊所在推廣使用的。而書面資料其實就是
教學手冊啦。(所以很像使用手冊)


本篇文章回覆於2007-09-10 11:41
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
10樓
不錯的參考

天使
捐贈 VP 給 天使 檢舉此回應
您的軟體組裝工廠我有下載看過
我個人是很贊成這樣的軟體工廠模式(軟體工程講的無非就是要把軟體模組化, 標準化)
但是在台灣大概實行不起來吧
因為在台灣談到寫程式
大家幾乎只注重coding的技巧(所以coding的書最好賣)
很少有人談到要把程式模組化
從小鋪軟體工程版的冷清、書局中軟體工程的書幾乎都賣不出去,這兩點都可以看得出來吧
所以出書大概也不好賣吧(這是純粹個人的看法, 版大別介意)

曾經我為了找一本ASP.NET元件設設的書(之前在學校圖書館借過, 寫得不錯)
翻遍了整個網路書局
才找到一家書局有「庫存」(出版商已經停止出版了)
由此可以顯見 元件設計或軟體工程的書多不好賣了吧

以我之前在學校的經驗
只要談到OO, UML, Design Patterns
幾乎是所有的學生都陣亡
更不要談要把UML或Design Patterns轉化成程式碼
我也是花了好一段時間才真正了解UML及Design Patterns的真正精神

至於您說的商業物件轉化成Web Service
那正是我的碩士論文(我是整合在Web Form上, COM+還在努力學習中)
我的老闆(論文指導老師)跟我說
這個東西大概要十年後台灣才會漸漸推廣起來

目前我手上的專案做法
其實也跟您的觀念一樣
先做系統分析(用UML畫圖)
再來將系統分析的結果用VS2005中的塑模工具將Class程式碼產生+加工
根據這些Class寫成商業物件的Class
再將利用這些商業物件寫成我要的UserControl
再將這些UserControl拉至我要的版面組裝+排版
等於是一個人包辦了SA SD PGM的工作

小弟經驗算粗淺
如果您不嫌棄的話
有機會小弟也想向您請教一下相關的開發經驗

P.S 小弟也是住在高雄
本篇文章回覆於2007-09-16 02:16
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
11樓
不錯的參考

Mark Hsu
捐贈 VP 給 Mark Shu 檢舉此回應
軟體組裝工廠 這樣的概念是正確的 也是好的 只是深感在現在的中小型資訊公司 推行上有難處
只是以個人接觸到的部份來說 但未必代表是所有的公司或所有的工程師
以許多資訊公司來說 老闆希望公司賺錢 就拼命接案子 然後希望所有的案子趕快完成
一個案子下來 公司去接案子的人 連流程都還沒搞清楚 畫面都沒出來 也還沒和客戶確認
就接回了案子 說個大概的範圍 然後就要身兼SA SD PG 去把案子完成
因為公司覺得案子回來 弄一弄就出來了 所以明明要三個星期以上的案子 他就只給你兩星期
而且和客戶接洽的人 連畫面都沒給出 誰知道客戶到作成什麼樣子 到底要哪些功能
客戶也不知道 那些東西是要確認先給出的 以致做出來的東西 很多部份一定要再改
接案子的人 也不知道哪些東西要確認 才可以開發 也不急..以致開發的時間一再的被壓縮..
所以為爭取僅有的兩星期時間 就以所知道的部份 開始建資料庫 開始寫程式
等到接案子的人和客戶確認一切時 只剩下一個星期的時間了..
所以就一邊修改畫面 一邊修改程式 一邊修改資料庫...在這樣的情況下
會有品質? 東西能說出來就不錯了 誰管他裡面到底寫的如何 也懶的去管...
三個星期要開發的東西 寫程式的時間最後被壓縮成一星期 誰有空去理公司程式碼寫的多標準
因為公司希望趕快把案子敢好 以便可以接下一個案子 果然在好不容易趕好之前
下一個案子又來了....如此的情況下 只能把功能做給客戶 至於裡面寫的如何 就不管它了

也很想去做軟體組裝工廠.. 但公司只把工程師只被當成賺錢的工具 生產線的作業員 反正就是快速的大量的生產 案子越多 公司錢賺的越多 工程師已被壓搾的精疲力盡 連學新的東西都只能利用下班回家或假日去學 公司也不願意讓你上班時 去研討新的東西...因為那樣公司看不到工程師'有在幫公司賺錢'...所以變成 不管用什麼方法 能夠快速把功能寫出來 快速交差 程式寫的快...是所有工程師的目標...以致工程師永遠都只在敢程式..沒有新的概念 新的技術 彼此間也不會去研討 永遠也不會進步....新技術新架構接受的程度也低....若想慢工出細活 絕對等著被公司剥一層皮...所以寫到乏味 不爽 就走人..下一個接的工程師 就要維護前人的很多案子 還要開發新的案子...以致不爽 就走人...公司也不會想辦法留人 只想著反正東西會有人接 以致原本可以掌握自己工作的人 莫名奇妙的又要接一些別人寫的案子維護或是接手開發...也許 不爽 又走人...因為公司只想到賺錢 所以永遠也留不住人..
本篇文章回覆於2007-09-16 16:47
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
12樓
不錯的參考

天使
捐贈 VP 給 天使 檢舉此回應
To # 11
看完你的留言
我突然有一個感覺:我們是不是同公司的啊?(理論上應該不會是,實際上也不會是)
把我們公司上頭的型態描述得淋漓盡至

改天出來拜把一下吧!!
本篇文章回覆於2007-09-17 10:10
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
13樓
不錯的參考

達子
捐贈 VP 給 達子 檢舉此回應
to #11 #12
拜把+1
我前公司也是這樣壓榨工程師的
非得搞到天怒人怨還不肯罷休
扯的是
還會故意挑撥員工之間的感情(這些都是求證過的...)
這樣的公司
你說能賺錢ㄇ?
難ㄚ.....
本篇文章回覆於2007-09-17 17:54
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
14樓
不錯的參考

飛天南門
檢舉此回應
to #11.#12.#13
其實大部份的公司都是這樣
邊談邊改程式,這是軟體公司的通病
除非把舊有的程式或觀念,全部打掉重寫才有可能
(有些是資深工程師的觀念,幹嘛把軟體開發搞得那麼複雜)
變成軟體組裝廠的模式開發軟體
可是有那一位老闆願意花大把的鈔票呢?
換做是我我也不會,
寧願請更厲害的工程師(我覺得像做土水的)補土,抓漏
我曾經也試過有一個小的專案要用軟體組裝廠的模式開發
可是後來宣告失敗了,因為沒有人幫我分析
而我自已對OO的觀念也不是很清楚
就算有觀念、會寫OO,真的要寫出來還真的不容易
再來中文的相關書籍也很少(針對用.NET開發),所以就打掉重寫
想到什麼就寫什麼,最後也是交差了事!!
結論是只要客戶能用就好,公司收得到錢就OK了!!
不過用軟體組裝廠的模式開發軟體,這是寫軟體未來的趨勢
只是建議大頭源以後可以像『祭司』一樣,每隔一段時間
就把部份的內容貼出來,這樣才會有『引人入勝』的感覺
一步一腳印踏進大頭源的組裝工廠。








本篇文章回覆於2007-09-17 22:16
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
15樓
不錯的參考

天使
捐贈 VP 給 天使 檢舉此回應
TO #13 #14
其實公司會不會賺錢
真的是和開發的流程有關係(以工業術語來說就叫做製程)

如果接到的案子 若是跟客戶只做那麼一次生意
那麼要不要用軟體組裝工廠來開發都OK
反正只要客戶那裡程式可以跑就好了

但若是要一直幫客戶擴充功能
甚至是要開發超級大型系統(如大型ERP系統)
如果一開始沒有規劃好
那麼未來程式就會一直亂改
資料表一直亂擴充(若沒有用E-R Model事先正規化過會更糟)
只要前面的人留一手
後面接手的人的就會改到趕羚羊
搞到最後都不知道該怎麼做時
最後如同 #11 所說的 做到不爽走人
等著下一批敢死隊來接手

其實OO的觀念在很早以前就有了
只是當時沒有被推崇
是因為硬體效能不好 成本又高(能想像一台386的電腦要50000元嗎??)
所以 能夠節省系統資源及記憶體的使用量 才是寫程式的王道
因此西元1999年至2000年才會有千禧蟲的危機

我的老師還跟我說 以前他們寫程式是在比誰寫出來的程式碼比較短(當時差個幾KB效能就可以改善很多了)

現在硬體的效能是非常的好
價錢又非常便宜
所以寫程式的觀念才改變成OO的
OO的精神是不管什麼系統資源的事情
只管程式有沒有結構化

所以台灣接案為生的軟體公司
一直賺不到大錢
甚至有些案子一直「結不了案」
是因為軟體的生產沒有「標準化」及「結構化」
更別談如何「大量」生產

面對現在企業都在cost down的情況之下
若沒有辦法以質 + 量取勝
真的沒有辦法賺到錢

所謂的大量生產
不是同一套賣給很多客戶(對軟體來說這樣叫一套)
就像源大在文章中所提到
同樣的東西 畫面不同 顏色不同 對客戶來說就是不同的軟體

舉個簡單的例子
台灣的機車兩大廠
如果有仔細觀察 其很容多系列的車子嚴格來說根本就是同一台
只是外殼不同 後照鏡不同款式 名子取得不一樣(其實引擎都是同一顆)
對外行人人來說 這個叫兩款不同的機車
但對內行人來說 根本就是同一款機車

再來一個例子
洗衣機的款式那麼多
基本功能有改變過嗎(電源驅動馬達來轉動洗衣槽)??
只要掛上不同廠牌 不同型號 加上一些小功能(如P牌的好找夜視燈, 水先淨功能)
就是一台不同的洗衣機

如果當初沒有先進行設計過
如何將車子的外殼換成別款??
洗衣機的一些小功能要如何加上去??

所以如果只要能夠寫出幾個模組
然後用排列組合的方式來計算
「理論上」就會有n!不同版的「XX系統」

而現在產品的生命週期平均只有18個月
若不先把一些模組設計出來
那麼將來要如何變出一些新的產品出來??
甚至應付客戶「多變」的需求(在客戶的認知裡 改這些東西都是很「簡單」的動作)??
新的產品 也只不過是舊的產品 + 一些新的小功能 + 全新設計的外觀 + 砸錢下去行銷

所以我很期待源大的軟體組裝工廠問世(不管用什麼方法都好)
也想一窺裡面是否有我沒有學到的技術(期待源大屆時會透露一些小撇步)
本篇文章回覆於2007-09-18 08:58
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
   

回覆
如要回應,請先登入.