應用程式設計師 : 你不是元件程式設計師只可不會應用元件不可自創元件

Albert 2010-09-17 07:39:48 ‧ 5172 瀏覽

分享至

程式設計者 : 元件程式設計 ?
程式設計者 : 框架程式設計 ?
程式設計者 : 引擎程式設計 ?
程式設計者 : 應用程式設計 ?
應用還分應用領域 ?

一人全包 ? 那有什麼好討論的 ?

當程式設計者面臨程式碼可能會來不及在期限內寫完，
但期限看起來又是牢不可動時，
可能會採取降低品質的方法來應對。

好的程式設計者給他足夠的時間，
他會試著寫出沒有壞味道（bad smell）的程式碼，
同時也會考慮到將來重複運用的可能性，
並且兼顧日後的擴充性及彈性。
此外，像各種異常情境的處理，
也都會盡可能地撰寫完備。

真可憐::

一旦時間不夠充份，又受迫於時程的壓力，
程式設計者就很有可能放棄這些活動，
試圖寫出只要能夠過關的程式碼就好了。

創造底層元件嗎 ?? 自創 Method 嗎??

甚至有些程式設計者在時間十分缺乏的情況下，
還會寫出那種似是而非的程式碼，
也就是說是，
看起來好像真的是那麼一回事，
但一些細節可能都不大對勁的程式碼。

即使沒有到這麼誇張的地步，
也有可能產出的程式碼，
只包含了主要情境會通過的執行路徑上的功能，
至於那些非主要情境才會通過的執行路徑，
也許就留白，
或者是加上一行註解，
寫著：”TODO”。

看更多先前的討論...收起先前的討論...

海綿寶寶 iT邦大神 1 級 ‧ 2010-09-17 08:45:06 檢舉

如果您看不懂的話
可以先看看王建興先生寫的這一篇如何面對開發時程趕不上的狀況
就可以明白
albertachen大大在comment的內容了

fillano iT邦超人 1 級 ‧ 2010-09-17 09:10:32 檢舉

PHP很容易趕工寫成一堆會動的地雷...

海綿寶寶 iT邦大神 1 級 ‧ 2010-09-17 09:14:49 檢舉

套句葉師傅的名言句型：
「不是PHP的問題，是人的問題」

fillano iT邦超人 1 級 ‧ 2010-09-17 12:13:07 檢舉

是阿，寫的人通常連「壞味道」都沒聽過的。

fillano iT邦超人 1 級 ‧ 2010-09-17 13:08:11 檢舉

今天看到一句話很有趣：「為什麼我喜歡 PHP 和 jQuery ？是因為我常常可以在程式碼裡看到 $ 」

海綿寶寶 iT邦大神 1 級 ‧ 2010-09-17 22:08:18 檢舉

fillano提到：
我常常可以在程式碼裡看到 $

本日最中肯

逮丸逮丸 iT邦大師 1 級 ‧ 2010-09-18 08:22:15 檢舉

在程式碼裡看到 $

真是一語雙關

外獅佬 iT邦大師 1 級 ‧ 2010-09-18 21:55:54 檢舉

antijava提到：
王建興先生

....我還以為王建民復健太無聊...改行寫程式了...

外獅佬 iT邦大師 1 級 ‧ 2010-09-18 21:57:20 檢舉

albertachen提到：
只可不會應用元件不可自創元件

....只能不會應用...卻又不能自創？？
那應該會被老闆罵到臭頭....

Albert iT邦高手 1 級 ‧ 2010-09-19 08:44:33 檢舉

程式設計者不可以創造元件
元件應用是定型化的東西
應用程式員
不會用可以發問
不可自創元件

例如::
MOrder 訂單物件::
SOLine[] getLines
MfgOrder[] getMfgOrderByLines
::取得工單物件[]

程序員依據規格需求要判斷(取得)
::該訂單之工單"已經領料"
MProductionMILine[] getMaterialIssueByLine
程序員是不可以自營創造::

Albert iT邦高手 1 級 ‧ 2010-09-19 08:46:18 檢舉

請開立需求單由共用物件開發中心提供::

Albert iT邦高手 1 級 ‧ 2010-09-19 08:47:44 檢舉

wiselou提到：
老闆罵

客戶會罵老闆

兩支程式一樣的判斷點取得的方法不同

suda iT邦新手 3 級 ‧ 2010-09-19 16:07:01 檢舉

元件設計師不了解domain的範圍,設計師可以寫domain的框架來組合元件嗎?再交由元件設計師來元件化嗎?

Albert iT邦高手 1 級 ‧ 2010-09-19 16:29:08 檢舉

感謝你的繞口令::

商業元件來自有豐富商業經驗的元件需求設計師來設計元件需求規格::

你知道"客戶受訂"之後被取消客戶訂單要有哪些稽查動作嗎??

哪個元件可以知道此"客戶訂單"衍生了哪些事項嗎 ?

suda iT邦新手 3 級 ‧ 2010-09-19 17:09:49 檢舉

商業元件有可能滿足全部變化及需求嗎?那全世界都用sap的流程及元件就ok啦.

我指的是在不更改商業元件下,設計師按現行domain需求來重組商業元件功能,提供元件設計師可能在下一版將其考慮進來,並沒有違反統一元件的規則.

不同產業及客戶的特性,有時是遇到才會了解,先做個prototype,來溝通一下,
如果卡住就等元件設計師花費他寶貴的工時來Do some thing,
如果他說下一版才會加入,那客戶就笑了.

suda iT邦新手 3 級 ‧ 2010-09-19 17:14:52 檢舉

[壞味道]的由來,因為程式碼寫差了被老闆罵,緊張到想上大號,
因而有點 XXX leak ,味道當然不好啦,故[壞味道]的由來為此(逃....)

Albert iT邦高手 1 級 ‧ 2010-09-20 12:06:14 檢舉

suda提到：
商業元件有可能滿足全部變化及需求嗎?那全世界都用 OpenSource Adempiere ERP的流程及元件就ok啦.

感謝你的肯定!!
成就商業元件滿足全部變化
來自我們天天都用心在加強元件功能

Albert iT邦高手 1 級 ‧ 2010-09-20 12:10:07 檢舉

suda提到：
我指的是在不更改商業元件下,設計師按現行domain需求來重組商業元件功能,提供元件設計師可能在下一版將其考慮進來,並沒有違反統一元件的規則.

元件設計師 Release 元件是天天要作的事
每天都有下一個版本就是 Night-build

如果卡住就不需等元件設計師花費他寶貴的工時來Do some thing,
如果他說下一版才會加入,那客戶就笑了.
24小時後新版 Release 客戶當然滿意微笑!!

Albert iT邦高手 1 級 ‧ 2010-09-20 12:13:35 檢舉

蘇塔大師::
請來來個元件需求實例::
MSalesOrder 要 Void 要 Reverse 要 Correct 要 Close 需要很多信息::
我們可以例出一個一個來完成

Albert iT邦高手 1 級 ‧ 2010-09-20 12:19:24 檢舉

MMfgOrder[] mfgOrders = sOrder.getMfgOrders ()
MProductionMI[] productionMIs = sOrder.getProductionMIs ()
MProductionFG[] productionFGs = sOrder.getProductionFGs ()
MInOutLine[] shipmentLines = sOrder.getShipmentLines ()
MPurchaseOrder[] purchaseOrderLines = sOrder.getPurchaseOrderLines ()

Albert iT邦高手 1 級 ‧ 2010-09-20 12:21:50 檢舉

大家都是技冠寰宇
有賴大家解放原碼
才有實體討論空間
ERP 解放原碼領導者 Skype: ADempiere/Compiere
技術轉移顧問

登入發表討論

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

3 個回答

pantc328

iT邦高手 1 級 ‧ 2010-09-17 08:52:49

這個有什麼好研究的?
在台灣你就全包了.
客戶要什麼,你就生什麼.

自己寫底層跟買元件對我而言是一樣的.
寫底層要花很多時間做,但客戶要什麼都能做出來.
買元件做的時間少,但客戶需求變更或跟元件有點不同時.
你還是要花很多時間去熟悉元件模型,然後去破解,修正...
到最後可能成本相近.

所以據經驗的設計師或系分師要能很快速的分析局決定用哪一種解決方案.

回應 1
分享
檢舉

Albert iT邦高手 1 級 ‧ 2010-09-17 10:12:29 檢舉

pantc328提到：

這個有什麼好研究的?
在台灣你就全包了.
客戶要什麼,你就生什麼.

那是你厲害!!
那是台灣害了你!!

pantc328提到：

自己寫底層跟買元件對我而言是一樣的..

(1) 你可能是元件設計師
來兼差應用程式設計,你可能: 初會,中會,高會,財報,審計都沒讀過
(2) 你可能是應用程式師
來兼差元件程式設計,你可能不是台大/清大/交大/成大/中山資工所
可能跟我一樣是南非巫醫大學畢業

登入發表回應

suda

iT邦新手 3 級 ‧ 2010-09-17 14:11:33

1.職務上改天可以輪調一下應用程式設計師 <->元件程式設計師
都是可以協調的,不必只有零和的結果

2.再者應用程式設計師可以設計整合元件的控制元件,
可以向應用面或領域面去發展,工作上配合才有可能 1+1大於2

3.再好的十八般武藝,也得觀眾掏出口袋.
如不能先"求好再求有",退其次先"求有再求好"
只動口,不動手的人最是高段的,我是指的是老闆.

回應 4
分享
檢舉

看更多先前的回應...收起先前的回應...

Albert iT邦高手 1 級 ‧ 2010-09-17 15:05:29 檢舉

suda提到：
應用程式設計師 <->元件程式設計師

理想與事實是可以期待但是發生在遙遠的國度
應用工程設計是非常了解應用工程的人::是 Domain Know How 導向
元件基礎工程是非常了界底層框架的人因此微軟在ERP應用領域一直是失敗!!!

Albert iT邦高手 1 級 ‧ 2010-09-17 15:07:29 檢舉

如不能先"求好再求有",退其次先"求有再求好"

先求退貨
再求倒閉(不用求也會倒閉)
同意 + 1

總裁 iT邦好手 1 級 ‧ 2010-09-17 15:13:52 檢舉

先求退貨
再求倒閉(不用求也會倒閉)

suda iT邦新手 3 級 ‧ 2010-09-17 22:50:57 檢舉

"先求退貨,再求倒閉" 真是一針見血,哈哈

登入發表回應

godstamp

iT邦新手 3 級 ‧ 2010-09-19 02:55:20

程式「設計」者應當明白撰寫好程式碼和壞程式碼，所花費的時間一樣多！不遵守紀律的程式撰寫方式，不僅難以節省開發的時程，更無法順利推動專案的進度。
千萬不可以時程壓力為由，和自己妥協，寫出暫時堪用的程式碼，並期待將來再找機會回頭修正或補足，否則將會付出更大的代價與成本。

如果老闆在時程上過度壓搾又聽不下時程趕不上原因，就跟他討論成本吧！通常老闆聽到成本就很容易開竅^^

回應 4
分享
檢舉

看更多先前的回應...收起先前的回應...

Albert iT邦高手 1 級 ‧ 2010-09-19 10:05:14 檢舉

godstamp提到：
千萬不可以時程壓力為由，和自己妥協，寫出暫時堪用的程式碼

例如::
MOrder 訂單物件::
SOLine[] getLines
MfgOrder[] getMfgOrderByLines
::取得工單物件[]

應用程序員依據規格需求要判斷(取得)
::該訂單之工單"已經領料"
MProductionMILine[] getMaterialIssueByLine
應用程序員是不可以自行創造::
請開立需求單由共用物件開發中心提供::

Albert iT邦高手 1 級 ‧ 2010-09-19 10:09:11 檢舉

元件開發程序員
應用系統程序員

你混為一談

跟大學好的研究員與好的教員混為一談

一樣悲慘

好的研究員
自以為是不會教書
論文多升遷快
無恥台灣
以此為昇教授依據

suda iT邦新手 3 級 ‧ 2010-09-19 16:01:13 檢舉

1.元件開發程序員,應用系統程序員是角色, 像工作輪調一般,可以站在不同的立場來了解及配合,當什麼角色時扮演好本職.

好的研究員也可以當好的教員吧,這沒有規定吧,看個人志向及熱忱.(印度的種性制度算嗎?)

3.台灣的論文升等方式是走偏的,在競爭的小市場中卡個位,但還是有人努力研究並努力教授知識,只因他想這樣做,80/20吧.

4.程式如果採取較鬆散偶合的架構,在出貨時程式來不及時,把未穩定完成的部分介面定好先作Preview code,以維持其出貨的目標,到時候再抽換元件.
dot NET 也有好幾版(2.0版還大翻修),IPhone4 天線有問題也出貨,程式沒有不修的吧,當然好的程序員會用方法來減少更新的難度(oop,ooa,重構等等).
當然在理想及適合的條件下跟本不用這樣多此一舉.