討論區快速選單
知識庫快速選單
最紅的App開發語言:Kotlin 討論區最近新進100則主題 政府補助!學嵌入式+物聯網
[ 回上頁 ] [ 討論區發言規則 ]
給MIS新鮮人的建議 (續)
更改我的閱讀文章字型大小
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/3/25 上午 10:12:57
建議四:建立分析、溝通及管理方面的正確觀念
  資管系的學生都修過"資訊管理"、"系統分析"、"系統設計"等課程,這些課程大部份偏重 於理論的介紹,就算書中或教授舉了許多實務上的例子,對於無工作經驗的學生還是體會 得有限吧!因此囫圇吞棗、臨考前死背者比比皆是,到了畢業後就還給老師了。倒是技術 面,因為新軟體、新名詞一直出現,感受到的壓力是直接的,因此大多數的人都會再進修 。 

  除非您立志終生於研發或專業職的工作,否則我建議上述那些Priority 排到後面的課程 還是要投入心思,因為它會幫助我們建立正確的"Sense";這個 "Sense" 或可解釋為「處 理工作上一些沒有標準答案問題的直覺」。 

  舉例來說,一家公司剛來了兩位無經驗的程式設計師(A &B),都被指派了相同的練習題( 或許是幾支簡單的維護與報表程式);當完成後就以下項目評分:(滿分為五顆星) 

                      A       B 
        寫作速度         ★★★★★   ★★★ 
        正確性          ★★★★    ★★ 
        測試項目是否齊全     ★★★★    ★★★ 
        USER 操作介面友善程度  ★★★     ★★★★ 
        效能(Performance)     ★★★     ★★★★ 
        程式碼結構化程度     ★★★     ★★★★ 
        程式碼中的註解說明    ★★      ★★★★ 
        總分           24      24 


   同樣是24分,誰的表現較好呢? 

  我比較傾向於給B較好的評價;以前三項A領先的項目分析:A在Coding 上的經驗較豐富, 可以快速上手,對於任務也可以如期交差,通常主管會依賴他來快速完成專案。但就觀念 而言,則B有進一步成為SA 或PM 的潛質,為什麼呢?介面的 Friendly 及效能考量,代 表他能為使用者著想(程式正確並不代表使用者會樂於使用!);程式碼的結構化及註解, 將為團隊合作(別的PR.接手維護他的程式)及共用性帶來好處。這些觀念通常在程式撰寫 的Know-How 中較少被人提起,但長期而言它們卻是影嚮系統成敗的重要關鍵! 

  我接觸過一些優秀的 IT 人員;憑著多年的磨練,他們大多對於架構及實作一個系統駕輕 就熟,但使用者或同仁的評價卻非很好,其中之一的原因,在於他們忽略或不重視某些 "隱性要素" (Invisible Factors),造成系統品質不良,而這種觀念的養成,在學生時代 能多接觸一些相關理論是很有幫功的。 

  以上是個人就工作上的經驗,提供給晚進的一點建議,當然諸如:「虛心求教」、「建立 人脈」、「慎選行業」等,不但適用於資訊業,我想放諸求職上無不正確,因此就不多提 了;另外,以上或因個人環境而有不適用之處,也請各位自行拿捏了。   
作者 : jammy98(Jammy)討論區板主 站務優秀好手貼文超過3000則人氣指數超過300000點
[ 貼文 3524 | 人氣 316866 | 評價 3440 | 評價/貼文 0.98 | 送出評價 3493 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/5/5 下午 01:06:21
感謝提供這篇文章, 這對入門的網友有很大的幫助.
我已將它加入本站的初學入門單元.
作者 : wewe(wewe)
[ 貼文 3 | 人氣 270 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/7/23 下午 08:44:17
我不了解為何B的正確性只有兩顆星
而效能(Performance)確能有4顆星
作者 : programlin(programlin)
[ 貼文 113 | 人氣 9857 | 評價 130 | 評價/貼文 1.15 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/8/10 下午 02:59:27
的確是B較好,但台灣目前企業型態,B真的會比A受到欽賴嗎?尤其當主管本身不具備程式設計的能力.
作者 : chm(()()())
[ 貼文 7 | 人氣 14 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/8/12 下午 08:09:35

>我不了解為何B的正確性只有兩顆星
>而效能(Performance)確能有4顆星
嗯嗯 我對這點也很懷疑

文中還提到   "程式碼的結構化及註解, 將為團隊合作
(別的PR.接手維護他的程式)及共用性帶來好處。"

結構化及註解是為了對抗複雜度來減低錯誤而出現的
我不太相信寫出正確性只有兩顆星的程式的人
在這兩點上會有高評價
而錯誤的程式更是對共用性是一大打擊

我覺得這文章論點很好 但舉了個爛例子
作者 : chou_judas(judas) 貼文超過200則
[ 貼文 243 | 人氣 5085 | 評價 140 | 評價/貼文 0.58 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/8/15 下午 11:09:11
既然例子是作業,正確性並不是唯一重點。
設計是注重過程及方法,這並不是考試一味地講求答案。

硬要講個發生邏輯,有些原因: 
 1User操作介面佳,造成測試項目變多
 2測試變多,相對遺漏未測的就多
 3測試不足的情況下,結構化往往會造成意外的錯誤
以上或許可以硬ㄠB正確性較低的原因。
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/8/26 下午 04:16:26
我是原文的筆者; 第一次發言, 也許文筆尚欠純熟, 造成大家的誤解, 在此補充一下; 當然, 若你不是誤解而是觀念上與我有所出入, 那也在所難免, 畢竟這些只是我"個人"的感想, 並不是bible..

To Jammy:
  這是我構想中一系列有關MIS經驗分享文章的第一篇, 感謝能得到你的認同!

To WeWe & ()()():
  我舉的例子比較極端, 因為要突顯" 程式不是只要寫完可以正確地RUN就OK"的觀念; 所謂"正確性"是針對Syntax 及 Logic 而言, 這些對程式老手來說當然是駕輕就熟的, 但沒有Syntax error 及 Logic error 並不代表Performance 好, 我想這點你們也同意吧!很多時候MIS 在寫商用AP時, 並沒有人去約束他User Friendly或效能評估的標準, 更不要說程式中的comment了(軟體公司的SA 會比較CARE), 因為這些
user不懂, 即時你寫的程式慢如當機, 只要"正確"結果出來, USER還是會請喝飲料吧? 但MIS 心裡知道, 只要多去研究一下, 多幾道加工, run的速度可以快上10倍!難道這不是mis該自我要求去改善, 一定要有人audit 才要去作嗎? 另外如程式註解, 我想有管理過程式或文件版本的人都知道, 不管一個人寫程式再怎樣"快""狠""準", 那也只代表他單兵作戰強而已; 只要是CO-WORK, 沒有註解的程式碼有時就和天書一樣, 在發生離職或ROTATION的時候, 幾行精簡的COMMENT可是能幫上大忙的!

  程式寫作的正確性及速度, 屬於"技術"性質的東西, 只要有心加上有實作的環境, 相信絕大多數的人都可以從菜鳥到高手, 但其他評分項目, 在開發商用AP時常被程設人員忽略, 可是對專案品質及後續可維護性care的SA 或 PM而言, 這些可是重點(只求交差了事心態的人不在討論之列)! 這就是我文中所謂"B有進一步成為SA 或PM 的潛質"的意思; 對任何想UPGRADE自己成為領導階層的MIS人員我也會給同樣的意見.

  "我不太相信寫出正確性只有兩顆星的程式的人在這兩點上會有高評價", 您說得沒錯, 不過我比較想強調的是, 正確性5顆星的人, 比不上能"真正"為USER設想及為team work 設想的人.

~以上, 歡迎討論~

作者 : bluetulip(BlueTulip) Visual Basic優秀好手貼文超過1000則人氣指數超過10000點
[ 貼文 1127 | 人氣 28366 | 評價 4070 | 評價/貼文 3.61 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/13 下午 05:28:54
想徵求太子前輩的同意。
是否能讓我將這系列的文章稍加整理後,
放在班級網站上供同學們參考呢?
作者 : bogie(阿崎)
[ 貼文 16 | 人氣 3023 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/15 下午 09:28:04
我也想把此文轉載給系上的班版~
是否可以,謝謝^^
作者 : bogie(阿崎)
[ 貼文 16 | 人氣 3023 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/15 下午 09:33:02
我也想把此文轉載給系上的班版~
是否可以,謝謝^^
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/16 上午 09:26:36
To BlueTulip & 阿崎:

  Of couse you can! It's my pleasure! 記得註明是在這堣犍峈煽N好了~~
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/16 上午 09:26:51
To BlueTulip & 阿崎:

  Of couse you can! It's my pleasure! 記得註明是在這堣犍峈煽N好了~~
作者 : bluetulip(BlueTulip) Visual Basic優秀好手貼文超過1000則人氣指數超過10000點
[ 貼文 1127 | 人氣 28366 | 評價 4070 | 評價/貼文 3.61 | 送出評價 15 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/16 上午 09:43:05
多謝太子前輩  期待您的文章喔 ^^
祝    順心   2002.9.16
作者 : jeans(藏鏡人)
[ 貼文 101 | 人氣 850 | 評價 430 | 評價/貼文 4.26 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/9/26 下午 04:56:14
前文述刪。
>  我比較傾向於給B較好的評價;以前三項A領先的項目分析:A在Coding 上的經驗較豐富, 可以快速上手,對於任務也可以如期交差,通常主管會依賴他來快速完成專案。但就觀念 而言,則B有進一步成為SA 或PM 的潛質,為什麼呢?介面的 Friendly 及效能考量,代 表他能為使用者著想(程式正確並不代表使用者會樂於使用!);程式碼的結構化及註解, 將為團隊合作(別的PR.接手維護他的程式)及共用性帶來好處。這些觀念通常在程式撰寫 的Know-How 中較少被人提起,但長期而言它們卻是影嚮系統成敗的重要關鍵! 

我覺得你講得太理想化了,在實際環境中,很多當大頭的都不懂 code,
我部門新來一個人,寫程式不加註解,和他講 Coding Style 被當白痴,
寫程式是真的很快(效能就別提了),使用者介面另人斐疑所思,
反觀雖然我的程式 Users Friendly 做得比較好,
效能比較佳,但是因為我程式寫的不夠快,再加上我改他的程式不好改,
但是他可以很輕易的改我的程式(因為我的註解實在是寫的太多了),
所以現在被當白痴的人是我。呵呵。
長期而言?別騙小朋友了好嗎?現在台灣誰在和你談長期的理想。
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/3 上午 09:31:20
>我覺得你講得太理想化了,在實際環境中,很多當大頭的都不懂 code,
>我部門新來一個人,寫程式不加註解,和他講 Coding Style 被當白痴,
>寫程式是真的很快(效能就別提了),使用者介面另人斐疑所思,
>反觀雖然我的程式 Users Friendly 做得比較好,
>效能比較佳,但是因為我程式寫的不夠快,再加上我改他的程式不好改,
>但是他可以很輕易的改我的程式(因為我的註解實在是寫的太多了),
>所以現在被當白痴的人是我。呵呵。
>長期而言?別騙小朋友了好嗎?現在台灣誰在和你談長期的理想。

每個人有不同的經驗和感想, 至少我願意分享出來, 而且我也強調那只是我個人的看法;你不相信作MIS的該有自己的堅持和自我要求我也不能勉強你, 但討論時請別用一些情緒性的字眼, 什麼叫:"別騙小朋友了好嗎?" , 這種話很有營養嗎? 對新手有幫助嗎? 

本身MIS已作了6年了, 我程式寫不快, 技術面也不強, 唯一慶幸的是, 對品質和速度上求一個均衡點及為 USER 著想的堅持讓同事們和長官們都對我刮目相看, 換了三家公司, 我也從來沒被當作白痴...閣下若是覺得這些只是理想, 那你就改變作風, 和你那位新人一樣啊! 不必一句"現在台灣誰在和你談長期的理想" 這種酸溜溜的話打翻一竿子的人; 抱怨有什麼用呢? 還不如持續自我反省和改善吧!
作者 : guns2(Jimmy)
[ 貼文 -1 | 人氣 1770 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/3 下午 04:22:31
 其實藏鏡人老大說的並非完全沒有道理,只是語氣衝了點。根據小弟的觀察,是有愈來愈多的程式設計師寫作時的習慣不是很好,讓後面接的人很頭大(像我現在就碰上了這種情形,要修改前人的程式時,發現程式碼亂七八糟,註解沒有,排縮也沒有,實在很難看得懂。當然啦,小弟才疏學淺也是原因之一,以前從來沒有修改別人程式的經驗,正好趁這個機會多磨鍊一下)。

 其實大家各有各的想法,倒不一定誰對誰錯,討論區咩,就是來發表意見的呀!! ^^
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/4 下午 01:32:01
我很常看 bbs 或 news 但少有留言, 最大的原因就是懶得打口水戰; 要是大家都有像你這樣客氣的態度就好了....^^
加油哦! 把一個亂七八糟的 source 整理得井然有序才是功力! 以後別人接你的系統才會感激.... 呵呵
作者 : justice1(阿肚仔)
[ 貼文 2 | 人氣 120 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/8 下午 06:23:16
我有個問題想請問各位高手,糸統分析與設計,這一門課程真的是很難理解,也很難了解自己是不是完全懂,完全是死背的東西,是不是還有更好的方法或講思能去學習這課呢?
作者 : jacky_jang(太子) 人氣指數超過50000點
[ 貼文 24 | 人氣 62806 | 評價 770 | 評價/貼文 32.08 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/11 上午 08:48:19

>我有個問題想請問各位高手,糸統分析與設計,這一門課程真的是很難理解,也很難了解自己是不是完全懂,完全是死背的東西,是不是還有更好的方法或講思能去學習這課呢?

在學校期間, 盡量用理解的方式去學習(當然, 為了考試, 重點還是非背不可); 在作CASE Study 時用心作, 可能的話多與老師及有實務經驗的同學討論, 先對各個SA&SD手法建立起廣度的概念, 等到將來工作上再來累積實力.

一點建議, 參考看看.
作者 : prettyamy(艾咪)
[ 貼文 14 | 人氣 1090 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/13 下午 12:50:48
嗯.非常贊同.
作者 : toono(谷月軒)
[ 貼文 21 | 人氣 994 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/10/13 下午 01:01:39
真的很謝謝你提供這篇報導..
我會作參考的
作者 : tienyu01(Rex)
[ 貼文 2 | 人氣 49 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/11/29 上午 12:10:52
總之,要為您的留言喝采!!
作者 : vovo-chen(Johnson)
[ 貼文 9 | 人氣 804 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2002/12/10 上午 09:31:14
在台彎言語是自由的嗎~
好的建議我會接受
壞的建議我會檢討
你這文章寫的不錯~
只少你願意分享你的經驗及觀念
大家加油多為台彎提升產業等級
作者 : bearlai(Bear)
[ 貼文 10 | 人氣 29 | 評價 50 | 評價/貼文 5 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/4/14 下午 02:21:27
太子兄的論述令人收穫良多
不過其中好像都著重在電腦程式的加強與應用

我個人覺得MIS最重要的應該不是在電腦專業,而是要了解到你所處的行業他的Know-How.因為MIS人員主要的工作是幫助公司作業進入電腦化流程、或是將其他部門所需的資料能正確的提供,就我個人感想,台灣MIS人員很多都會跟其他部門有溝通不良的問題存在,兩邊人員都使用自己的專業語言和對方交談,因此造成很多認知上的困難•

因此我覺得MIS人員應該把部分時間花在研究該行業或產業的生產或是營運流程,能夠幫其他部門人員完成他所想要的資料報表或是程式管理,我想比讓他的原有程式速度加快,會讓他們更受用•

當然並不是說增加程式的Performance是不對的事情,而是應該將正確性先達到標準後再來加強程式的Performance•因為MIS部門雖為公司的後勤單位,但是公司很多政策都需要MIS所產生的資料報表當作參考•

以上僅是個人拙見,望大家不吝批評
作者 : dinotai(DINO)
[ 貼文 2 | 人氣 5 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/5/20 下午 12:39:07
同意 BEAR 的看法
如果沒有與其他部門在想法上有一定的共識的話
我想使用者的反應 通常也不會太好吧 !? >.< ~
作者 : ayano(風晴綾)
[ 貼文 13 | 人氣 194 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/7/8 上午 10:16:00


> 我舉的例子比較極端, 因為要突顯' 程式不是只要寫完可以正確地RUN就OK'的觀念; 所謂'正確性'是針對Syntax 及 Logic 而言, 這些對程式老手來說當然是駕輕就熟的, 但沒有Syntax error 及 Logic error 並不代表Performance 好, 我想這點你們也同意吧!很多時候MIS 在寫商用AP時, 並沒有人去約束他User Friendly或效能評估的標準, 更不要說程式中的comment了(軟體公司的SA 會比較CARE), 因為這些
>user不懂, 即時你寫的程式慢如當機, 只要'正確'結果出來, USER還是會請喝飲料吧? 但MIS 心裡知道, 只要多去研究一下, 多幾道加工, run的速度可以快上10倍!難道這不是mis該自我要求去改善, 一定要有人audit 才要去作嗎? 另外如程式註解, 我想有管理過程式或文件版本的人都知道, 不管一個人寫程式再怎樣'快'狠'準', 那也只代表他單兵作戰強而已; 只要是CO-WORK, 沒有註解的程式碼有時就和天書一樣, 在發生離職或ROTATION的時候, 幾行精簡的COMMENT可是能幫上大忙的!
沒錯!!不然接手的人真的是不知道該怎麼辦耶!註解很重要的.
作者 : marace(Marace)
[ 貼文 64 | 人氣 1115 | 評價 110 | 評價/貼文 1.72 | 送出評價 2 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/11/12 下午 02:32:26
很久沒來
今天一來就看了許多文章也回了逼謝意見
看到這篇時的感覺真的是"公說公有理.婆說大道理"
其實兩派人馬的意見都直得參考
因為事實上真的可能就是這樣(是哪樣???當然就是你覺得有道理的那一樣呀...)
所以不太想給與什麼樣的評價
因為實在是沒有一個完美的方法我覺得....
如果說沒有註解的確會讓接手的人想要跳樓(尤其是被抓來新任職且老闆要感進度的情況下)
不過註解一多雖然可能詳細點也比較容易切入跟維護
但先撇開效能問題不談.註解多起碼直接影響到程式碼或片段的可讀性
舉個例子:看過java src裡面隨便一樣東東的人應該能體會.隨便一支小小程式裡竟然註解比程式本碼還多!?=_+
為的是要讓開發者能順利使用與了解.但等看到血都乾了都還不見得搞的清楚
用意是好的!但卻造成反效果????是呀是呀!

再論MIS . 雖說是Management Information System
不論是部門單位或系統
用"MIS"這字眼為議題的名稱我覺得實在不是很恰當
寫程式是不是MIS本質上的工作???
MIS範圍太過廣泛
大一點的公司連"資訊系統"."網路"."設備"."規劃企劃"."軟管".都分的清清楚楚
小一點得公司一個MIS也許就是上述的總合
用MIS來談論程式開發問題...老實說我並不太喜歡
因為容易會" 誤導 "
MIS 跟 IT 人員有何差別??? 又跟 PR有何關係??
PM屬於MIS嗎???? MIS會直接影響到產品的情況應該只有在部份"軟體或系統產業"吧??
因為PM是跟PRODUCT有關的職稱
而MIS對企業產品會有直接的影響嗎???
MIS範圍太廣...用PM做MIS前景的這種說法我不太贊成
程式設計師是程式設計師.MIS這字眼不要"濫用"比較不會誤導他人. . .
作者 : wessley(wessley)
[ 貼文 1 | 人氣 5 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2003/11/29 下午 09:06:27
現在不管做那行....
A 絕對不會被 Fire...
都是 B 被 Fire....
XX+OO
因為 B 把一切善後的用的太好了...
別的人也能接手...
更糟的是..如果有一個 A 跟 B 同時存在...
老闆一定 Fire B
老闆只看到錢而已....
如果跟老闆熟的話...
再來做 B 也不遲...
作者 : trueway(trueway)
[ 貼文 96 | 人氣 7657 | 評價 120 | 評價/貼文 1.25 | 送出評價 13 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/3/24 下午 07:20:53
我非常同意Bear兄的意見, 我的功力不深, 當MIS的時間也不長, 但我覺得MIS人員應該是要走出去的, 而不是待在電腦室裡, 多去了解各部門的需求, 多去分析公司各種作業流程, 多去關心公司做的的瓶頸, 針對這些部分去寫程式, 相信你一定會成為公司裡的紅人, 我也是當了MIS之後才深入的了解會計.倉管.財物.進出貨流程, 久而久之想想當初應該去念商科的, 這樣程式會好寫多^^"
作者 : minnie(minnie)
[ 貼文 71 | 人氣 6745 | 評價 950 | 評價/貼文 13.38 | 送出評價 27 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/6/21 下午 02:27:17
大家都認為台灣的環境不適合有品質的軟體開發,有的人註解寫得好,程式寫得佳,讓接手的人容易看得懂,接手的人或許覺得沒有什麼,老闆或許以為誰都可以取代你。但是良好的軟體品質是對自我的要求,而非老闆或後人的意見。
當別人看不懂你寫的程式,而認為需重寫的時候,也許那時您不必在意後人的想法,但實際上浪費的是公司的成本、社會的成本。我認為台灣所謂程式的維護已經淪落到重寫、重寫再重寫的作法,這好像不是維護的目的...這也難怪台灣的程式設計師最討厭接手前人的東西。能讓人容易接手,代表您的用心。也是在累積自己的程度...別人說你的程式寫得很容易,那表示你寫得太好了,若人家說寫得看不懂,會因此而稱讚的好像很少,多半都是xxx地被動地改或重寫的居多。
老闆或許目前不能瞭解您的好,但是若他一直在重新找"強手"來作同樣的工作,我想久之作老闆的人會慢慢去思考,要找人作正確的事。近來我所認識外包的案件已從單純的功能多少錢,到需要有註解需要有流程規劃... 這代表企業對於企業的系統需求,不再是一個功能值多少錢... 而是正確能解決他問題的功能是什麼。我很贊同上面的大大說瞭解user的需求是很重要的。
作者 : 020645903(ReLife) 人氣指數超過10000點
[ 貼文 81 | 人氣 14439 | 評價 30 | 評價/貼文 0.37 | 送出評價 9 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/5 下午 08:58:28
謝謝您的文章,我覺得讀了受用的.
作者 : 020645903(ReLife) 人氣指數超過10000點
[ 貼文 81 | 人氣 14439 | 評價 30 | 評價/貼文 0.37 | 送出評價 9 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2004/9/5 下午 08:58:38
謝謝您的文章,我覺得讀了受用的.
作者 : tt7171kimo(tt7171kimo)
[ 貼文 1 | 人氣 2 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2005/1/12 上午 11:32:01
看完了這篇文章,我覺得真的受用無比,很多人覺得A比較不會被fire,但我覺得今天要寫一個要讓人可以看得懂並且可以方便更正的B,更是了不起,一步一腳印,好的人才是不會被埋沒的,我相信只要你寫出來的程式,實用性與操作性佳的話,在工作岡位上絕對是受用無窮的,本人也再此感謝太子所寫的文章,有道是英雄有所見略同,這只是我們的看法與理念,不見得每個人都有同樣的看法與想法,所以只一句話送給大家,不要為了目前短暫的利益,而放棄可以讓你超越自已的機會,機會只有一次,過了就很難再有.......

PS:一起在此分享文章所有人,有你們真好,互相學習、分享經驗真的是一件不錯的事哦....
作者 : evo691001(sky)
[ 貼文 1 | 人氣 1 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/2/17 下午 03:50:47
感謝前輩的一番真言,本人是夜校生看完了文章有一番的感想;真的要當一個MIS的人員,除了基礎的觀念很重要,重點是範例多作、多問多請教別人,在來是要多看看管理跟分析的書對經驗來說會增加許多。
作者 : propsychokiller(Ben) Java優秀好手資訊類作業求救卓越專家C++卓越專家貼文超過1000則人氣指數超過10000點
[ 貼文 1380 | 人氣 20444 | 評價 6650 | 評價/貼文 4.82 | 送出評價 13 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/11/3 上午 05:06:01

>>我覺得你講得太理想化了,在實際環境中,很多當大頭的都不懂 code,
>>我部門新來一個人,寫程式不加註解,和他講 Coding Style 被當白痴,
>>寫程式是真的很快(效能就別提了),使用者介面另人斐疑所思,
>>反觀雖然我的程式 Users Friendly 做得比較好,
>>效能比較佳,但是因為我程式寫的不夠快,再加上我改他的程式不好改,
>>但是他可以很輕易的改我的程式(因為我的註解實在是寫的太多了),
>>所以現在被當白痴的人是我。呵呵。
>>長期而言?別騙小朋友了好嗎?現在台灣誰在和你談長期的理想。
--------
comment 太多 真的很煩
重點寫一寫就好了
而且如果真的做到了 open for expansion, close for modification
其實 維護也蠻簡單的
只要他的code 沒有bug
簡直可以來當API用:)
作者 : lgd(lgd)
[ 貼文 87 | 人氣 927 | 評價 200 | 評價/貼文 2.3 | 送出評價 4 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/11/3 上午 10:13:18

同意Ben提的

我覺得原作者提的A,B的比較,甚至其能力的比較,看得出建立在"傳統的"系統開發之上
嚴密控制,小專案,系統分析先於程式設計, GUI為使用者的接觸面,所以最重要
大概是教科書裡常常會提到的內容, 但是...這真的能遵循嗎?

首先在專案裡 程式碼結構程度 與正確性 與寫作速度 與效能應為正相關
一團亂的程式, 要寫得快又要正確, 最後還要效能很好
... 除非只是寫九九乘法表 , 否則是矛盾的

再來程式碼註解 implies 程式 source code可維護不對
程式 source code 可維護 implies 系統可維護也不對
應為 Ben 提的比較正確, 品質比較重要
舉例來說 binary code 的元件替換 , 不需管到 source code level 的結構與註解
舉例來說 若接手過的人己超過數十位, 一個龐大無比的垃圾 , 也可以寫成非常結構化及充滿註解

再來是過份強調GUI的友善程度
GUI的友善程度會影響, 但是因為這好解決 , 你可以做到我也可以做到
大家都能做到的東西通常都不是會發生問題的地方, 也不是決勝的關鍵
作者 : ping320(ping)
[ 貼文 1 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2006/12/25 上午 03:45:49
非常同意發文大大的看法
果真是非常中肯的建議

且針對給第四項建議
其實我想大大要說的是
做為一個優秀的程式設計開發者
其實在user friendly and Performance
這兩項真的是很重要的

換個角度想..程式寫出來就是要幫助使用者
如果程式雖然功能好像齊全
但是操作介面和Performance都不理想
那這程式就不算成功

這是我在這職場上,非常感同身受的...
作者 : winkard(william)
[ 貼文 2 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/2/16 上午 03:01:08
感謝您提供這麼詳細的論點,這讓我非常受用。
我也是程式設計的入門者,我所學是廣告設計,職業是AE,學習程式設計的原因是因為想擴大知識領域,從被動者改為主動者,不在被程式設計師牽著鼻子跑...。
基本上看完這篇文章後,我有很多感想想提供出來,這些是我個人的經驗,僅提供參考。
關於MIS人員的定位問題,我今天總算有所了解,過去的認知裡,MIS=網路管理者。。。,我知道網管的定義,但我們請MIS人員來真的只是管理伺服器、管理網站,然後定期做報告給我們以及把我們想放的東西放上去網路,還有一個重點,公司大小電腦維修包含網路問題都找他,差點沒變成水電工...........,OK!一個月4萬5的薪水,我認為是在小公司中,我們能提供專業人員薪水的冠軍了!!資深平面設計師也是這個薪水。。。,但是重點來了,為何要給這麼高,因為我們都不懂程式。。。
不好意思廢話太多,但重點來了,前面朋友所提出的AB的觀點,其實都沒錯,重點是,聘請你的人,如果他是指講求結果不論過程,搞不好賺一票就要跑了,那這對他而言叫做投資,投資就是講求效率,不管你理想如何高我都能配合,前提是我不喜歡輸的感覺,達到目的之後,你的理想才有意義。
剛剛講的是社會的殘酷面,但基本上我相信一點,你所有的努力都將會開花結果,最大的受益者就是你自己,用我的觀念來看,A絕對能成為薪水族或是接案族的高手,錢包可以比較快長大,如果顧客不懂程式,哈!日後維修也必然是你的固定收入,因為後面接案的人有可能報高價或是建議顧客重寫,但找你卻可以省錢又省力,只要你不甩態,孩子是你生的當然要你來教嚕!但我們用另一個角度來看,目前這個市場上誰越懂得消費者習慣,誰就越有機會吃下市場,OK!雖然速度慢了一些,但市場接受度較大,雖然太為他人著想的個性導致您的可替代性增加,但你老闆知道,請了你讓他後面省了時間與精力,有句話叫做日久見人心,即便他真的瞎了,我相信你所學的會讓你更壯大,因為你能做的不在是解剖、分析、製造、修復這些工作,而是多了創造、管理的能力,你可以讓這些事情從此變的更簡單,就像倒吃甘蔗,你可以讓這些東西規模化,產生更高的經濟效益,你也比較有機會跳居幕後,呵!該怎麼說呢?很理想化嗎?理想如果可以成為實際,他就值得去追求,而且熟能升巧,觀念通了,後面的路也好走了,一切的一切都觀看你想成為什麼樣的人,見人見智,互勉之∼

不好意思,我個人還有一個問題想請教,MIS和CP兩個系統走的方向幾乎完全不同,但如果兩個都是最高頂尖狀態,誰能賺到最多錢?投資報酬率計算下去的話,以時間、技術價值、難度、創業難度、未來發展性來分析,以一個想要投入這個技術面的新手來說,您建議該從哪個方向投資呢?原因為何?價值觀是以哪種角度來判斷呢?


感激不盡!末祝各位資訊業的大大們新年愉快∼財運亨通∼豬事順利發大財∼
作者 : winkard(william)
[ 貼文 2 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/2/16 上午 03:05:16
不好意思打錯,是MIS與CS∼∼∼感恩!
作者 : nugundamhws(菜味重)
[ 貼文 4 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2007/5/16 下午 01:09:26
>不好意思,我個人還有一個問題想請教,MIS和CP兩個系統走的方向幾乎完全不同,但如果兩個都是最高頂尖狀態,誰能賺到最多錢?投資報酬率計算下去的話,以時間、技術價值、難度、創業難度、未來發展性來分析,以一個想要投入這個技術面的新手來說,您建議該從哪個方向投資呢?原因為何?價值觀是以哪種角度來判斷呢?
>

絕對是MIS,只是要到mis最高段,比到cs最高段要困難的許多(還有運氣好)
而且位置少是最主要的關鍵
市場上現在是cs薪資較高,因為台灣是重製造業,重硬體的社會型態
我覺得這兩種人都不太好創業 mis會比cs好創業一點,畢竟創業商業sense比技術來的重要的多
但是又比商科的差很多
未來發展性....近五年我想還是cs比較好
mis強不易被發掘,cs強如果是研發或生產單位的,老闆當然重視

短短回應,不好意思(要休息)
作者 : sacredzaro(§煌§)
[ 貼文 2 | 人氣 0 | 評價 0 | 評價/貼文 0 | 送出評價 0 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/2/8 下午 03:15:13
謝謝分享
對初學者的我幫助十分大
THANKS
 板主 : Jammy
 > 新手入門 - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - 新手入門 - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
新手入門
1 Raymond 900 
2 BK. 820 
3 Jasper 500 
4 太子 500 
5 Benson 410 
6 joe 400 
7 DEMO999 370 
8 青衫 300 
9 小朱 300 
10 Eric Ho 290 
新手入門
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2018 程式設計俱樂部 http://www.programmer-club.com.tw/
0.3125