PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   七嘴八舌異言堂 (https://www.pcdvd.com.tw/forumdisplay.php?f=12)
-   -   宏達電 今年獲利創7年新低 (https://www.pcdvd.com.tw/showthread.php?t=988481)

dyoo 2012-10-28 09:57 PM

這邊和01相反,不看好htc的比較多。

01若非有三星資助,恐怕現在都是h粉的天下。不過,現在已經很糟糕了,只要對htc有一丁點質疑,就會被砲,還會被當成三星的工讀生。

上次宏達電在美國銷售不佳時,就有憤青級的h粉,在htc員工私下成立的臉書專頁上貼文,說宏達電被台灣給糟蹋了。這次又傳出獲利創新低的消息,一定更多h粉替htc抱不平。

passerx 2012-10-28 10:11 PM

你沒看懂我的意思,
你要不要去問問為什麼寫opensource的人幾乎都不用UML,CMMI,流程圖?

不管你前面做了什麼, 最後一定要寫成程式碼,
是程式比較真確還是UML? 有問題是會去看程式還是UML?
你有那個時間去看兩份東西, 為何不省下這個力氣去把程式寫好不就什麼事都沒有了嗎?


程式不好的人才會去用其他的輔助工具, 程式好的人都直接寫成程式碼了,
你沒辦法直接看懂程式碼那表示你程式基礎不好, 那是你自己的問題不是別人的問題,
要叫程度好的配合你? 應該是你要加強自己的程度吧!

你們這種行為就好像, 現在大家在講微積分, 但你要別人先定義加減乘除, 程度好的根本不會理你.

:think:


引用:
作者TigerTigerTiger
我不太喜歡宏達電

但是你對UML的看法似乎不太真確

我同意在UML的實際應用上,面臨很大的困難,特別是在台灣

一方面UML還不夠普遍,另外一方面台灣的軟體生態過度要求速度

小的程式,的確不需要UML,我所謂的小程式,指3~10人開發一年以內完成的之類的案子

不太需要持續改版精進的軟體開發也不太需要UML

台灣很多公司會想推UML其實最主要的私心在於想幹掉台灣的軟體工程師

台灣的高層想幹空殼軟體設計公司,一切外包出去,最佳方案就是UML

這種心態一開始就注定失敗,UML 是溝通工具,而不是軟體本身

實作軟體的工程師很容易在UML上面看到軟體運作的縮影

而非程式設計人員也可以從 UML看到一些非程式相關的資訊,

如 User Diagram,Deploy Diagram

我相信日後的軟體發展,要持續精進,最重要的不是一次性的把code寫好

而是有一個依循的方式,如MS Sprial Model

一各大...

youporn 2012-10-28 10:23 PM

引用:
作者TigerTigerTiger
我不太喜歡宏達電

但是你對UML的看法似乎不太真確

我同意在UML的實際應用上,面臨很大的困難,特別是在台灣

一方面UML還不夠普遍,另外一方面台灣的軟體生態過度要求速度

小的程式,的確不需要UML,我所謂的小程式,指3~10人開發一年以內完成的之類的案子

不太需要持續改版精進的軟體開發也不太需要UML

台灣很多公司會想推UML其實最主要的私心在於想幹掉台灣的軟體工程師

台灣的高層想幹空殼軟體設計公司,一切外包出去,最佳方案就是UML

這種心態一開始就注定失敗,UML 是溝通工具,而不是軟體本身

實作軟體的工程師很容易在UML上面看到軟體運作的縮影

而非程式設計人員也可以從 UML看到一些非程式相關的資訊,

如 User Diagram,Deploy Diagram

我相信日後的軟體發展,要持續精進,最重要的不是一次性的把code寫好

而是有一個依循的方式,如MS Sprial Model

一各大...

同意你的看法。

很容易就可以看出台灣軟體業為何總是發展不起來,這些輔助的工具和文件永遠不會被重視

靠自幹的工程師太多了,結果跳槽後留下來的精華沒人看得懂,又要浪費時間重新 trace 甚至改寫。

當然這不能怪工程師,上頭管理階級只想賺快錢,目光短淺才是主因。

TigerTigerTiger 2012-10-28 10:29 PM

引用:
作者passerx
你沒看懂我的意思,
你要不要去問問為什麼寫opensource的人幾乎都不用UML,CMMI,流程圖?

不管你前面做了什麼, 最後一定要寫成程式碼,
是程式比較真確還是UML? 有問題是會去看程式還是UML?
你有那個時間去看兩份東西, 為何不省下這個力氣去把程式寫好不就什麼事都沒有了嗎?


程式不好的人才會去用其他的輔助工具, 程式好的人都直接寫成程式碼了,
你沒辦法直接看懂程式碼那表示你程式基礎不好, 那是你自己的問題不是別人的問題,
要叫程度好的配合你? 應該是你要加強自己的程度吧!

你們這種行為就好像, 現在大家在講微積分, 但你要別人先定義加減乘除, 程度好的根本不會理你.

:think:


我相信不管它叫不叫UML,絕大多數的人寫程式的時候,一定會在圖紙上塗塗抹抹畫畫

Stereotype 是什麼無所謂,但是一定會有自己看的懂的方式去表現這程式的輪廓

在UML裡面有一個Boundary的概念

如看User Diagram的,可以不用懂程式碼,完全不懂都可以

看Deploy Diagram的,也可以不用理解程式的運作,但是他可能比較懂系統權限網路架構等

即便很懂程式碼的,也可以透過不同的Boundary,侷限理解一小塊程式碼即可,而不用全面性的去發掘問題


我還是強調,UML其實還不算很普遍,還在摸索發展中,但我們可以看到這的方向的發展潛力,所以推廣

但是在工程界,劃藍圖是基本,即便藍圖中還是可能發生出錯,互相杆格違背,如結構圖上的3D設計沒有考慮好水電圖的配置,導致某些管線騰空穿過...
但是沒有人會說,高手不需要畫藍圖(大師的確很少畫精確的藍圖,都是徒弟們賣命在劃)

PAN_PAN 2012-10-28 10:30 PM

CMMI 只能說是那些不懂寫程式的商人賺錢的嘴砲工具. :unbelief: :unbelief:

所有東西沒有可能可以一次到位的啦. 程式需要有人幫你用, 並且改來改去這樣最後才會 tweak 到一個大家都可以接受程度

我寫的東西都是程式交了, 開始用了才會被要求畫 UML, 但是每次寫/畫出來都沒人想要看

TigerTigerTiger 2012-10-28 10:37 PM

引用:
作者passerx
你沒看懂我的意思,
你要不要去問問為什麼寫opensource的人幾乎都不用UML,CMMI,流程圖?

不管你前面做了什麼, 最後一定要寫成程式碼,
是程式比較真確還是UML? 有問題是會去看程式還是UML?
你有那個時間去看兩份東西, 為何不省下這個力氣去把程式寫好不就什麼事都沒有了嗎?


程式不好的人才會去用其他的輔助工具, 程式好的人都直接寫成程式碼了,
你沒辦法直接看懂程式碼那表示你程式基礎不好, 那是你自己的問題不是別人的問題,
要叫程度好的配合你? 應該是你要加強自己的程度吧!

你們這種行為就好像, 現在大家在講微積分, 但你要別人先定義加減乘除, 程度好的根本不會理你.

:think:


我舉個說明好了,如果某個特殊時候,程式出錯,初步判定是某個狀態Flag出問題了

State Diagram 簡單看出設計的理念,與邏輯的缺失

還是看落在幾十萬行中的程式?

甚至直接撈Debug 模式出錯的Dump data ? du da ....去查

更慘的是,假如原始撰寫程式人員離職了的話?!

台灣的交接 Give and Go 會是怎樣?

TigerTigerTiger 2012-10-28 10:42 PM

引用:
作者PAN_PAN
CMMI 只能說是那些不懂寫程式的商人賺錢的嘴砲工具. :unbelief: :unbelief:

所有東西沒有可能可以一次到位的啦. 程式需要有人幫你用, 並且改來改去這樣最後才會 tweak 到一個大家都可以接受程度

我寫的東西都是程式交了, 開始用了才會被要求畫 UML, 但是每次寫/畫出來都沒人想要看


因為你是寫程式兼SA

台灣開發大型軟體的架構機會比較少,其實認真說這種機會真的很多國家也不太多

如果你是SA,PROGRAMER遠在幾千公里外的印度,美國,澳洲,或是反過來

你還是會跟對方採用某種溝通的方式來協同處理工作事項

UML是工具,幾張圖表不是全部都要寫,也不是全部的程式碼都必須劃出來

好像木雕大師,手上有很多種不同的雕刻刀,但是不是每一種都很熟手

運用順手來雕塑作品才是最重要,而不是什麼地方就必須用哪種刀具

(喜愛打高爾夫的人也可以套用高爾夫的案例)

相知猶按劍 2012-10-28 10:47 PM

引用:
作者youporn
宏達電目標價 外資砍到100元

http://tw.stock.yahoo.com/news_cont...28/1/3g6ti.html


100 耶... 會不會太狠,應該 50 以下比較好吧 :laugh:

想空它耶
該怎麼做呢???

TigerTigerTiger 2012-10-28 10:50 PM

引用:
作者相知猶按劍
想空它耶
該怎麼做呢???


給你真心的建議

別碰 

台灣的老闆不是吃素的

簡單的說,你借券空到了

台灣老闆看上車空的人多了,砸錢拉上去

拉四根停板後,放消息開股東會強制回補

坑殺空軍

然後老闆爽爽的等高價補給你

passerx 2012-10-28 10:51 PM

引用:
作者TigerTigerTiger
我舉個說明好了,如果某個特殊時候,程式出錯,初步判定是某個狀態Flag出問題了

State Diagram 簡單看出設計的理念,與邏輯的缺失

還是看落在幾十萬行中的程式?

甚至直接撈Debug 模式出錯的Dump data ? du da ....去查

更慘的是,假如原始撰寫程式人員離職了的話?!

台灣的交接 Give and Go 會是怎樣?




:jolin:
程式爛的人才會講這種話, 交接? 交接的人程度太差做什麼都沒用, 程度好的自己都會解決.

你去叫 linus 畫個 linux kernel UML 你看看他會不會理你.
linus : Talk is cheap. Show me the code.

去想想為什麼這麼龐大的opensource不用這些工具就能成就現在.

:think: :unbelief:


所有的時間均為GMT +8。 現在的時間是04:27 AM.

vBulletin Version 3.0.1
powered_by_vbulletin 2026。