Re: [閒聊] 會程式沒什麼

看板Soft_Job作者 (fashionguy)時間12年前 (2012/05/13 10:41), 編輯推噓2(2034)
留言36則, 5人參與, 最新討論串11/15 (看更多)
※ 引述《thinkniht (不下棋=.=)》之銘言: : ※ 引述《fashionguy (fashionguy)》之銘言: : : 如果是我大概也會說類似的話 : : 但這句沒什麼並不是瞧不起這個程式設計的意思 : : 應該是比較接近,比方說寫一份report : : 可以用的方法太多了,不管是資料庫的內建function : : 用程式語言寫,還是市面上的報表工具自己定義的script : : 程式語言的話,java, c, c#...更是每種都能用 : : 如果僅止於使用這些工具,的確是「沒什麼」 : : 就算原本不會,上手這些工具只是時間的問題 : : 但你寫出來效能就是好,這就是價值所在了 : ^^^^^^^^^^ : : 其他前面也有網友提到看程式快。這種對陌生架構的快速掌握能力 : : 這種能力也是也是基植於經驗的累積,這也是價值的所在 : : 另外對於bug的敏感度也是一種價值 : : 這些能力我覺得對於PG來說,才是真正的有價值的技能 : 效能如何算好呢? : 這是很主觀 而且要看需求的事情 : 對使用者來說 感覺順就好 : 如果是"某些"軟體產品 : 可能就會對客戶說"我們軟體產品運算比較複雜 所以電腦要好才行" : 我曾經遇過一種情況 : 我覺得程式的寫法在效能上挺有問題的(演算法有問題 其實有更好的解法) : 不過主管認為OK...效能不錯(大概因為跑的電腦等級很高) : 客戶那邊...主管他們會有說法可以應付的 : 在這種狀況下..."再提升效能"這件事情...有價值嗎? : 我覺得能力再強...如果沒有被放置在對的地方 : 是無法產生價值的 基本上你說的我認同 這是環境的問題造成價值是否可以凸顯出來 但我還是想回一下,怕說有些新手就此覺得「唉呀,反正增加這些能力也沒用」 變成這種負面的心態 單純面來說,僅就效能這件事,能寫出有效能的價值是比寫不出來的高 我想這無庸置疑 我也有遇過類似的情境反過來的狀況 用戶不滿意效能,但工程師A說程式沒問題沒辦法再更好了 但工程師B指出其實程式本身有很大的tunning空間 最後的結果也的確增進很多,最後的結果A就不見了 如果今天沒有這個要求,B的價值可能像你說的沒有被凸顯 但是當需求發生時,沒有這個能力的A則是連應變的能力都沒有 所以環境雖然會影響價值是否會被看到 但不影響價值的本身 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.104.79.33

05/13 10:42, , 1F
看來A會覺得很委屈。><
05/13 10:42, 1F

05/13 10:51, , 2F
「有效能的價值是比寫不出來的高」這件事情只有在「客戶不滿
05/13 10:51, 2F

05/13 10:51, , 3F
有人適合奮不顧身地開疆闢土,要快速發展得靠他。
05/13 10:51, 3F

05/13 10:51, , 4F
意」的前提下才成立。不然都有高效率的靜態語言,弄一個比較
05/13 10:51, 4F

05/13 10:52, , 5F
有人適合精細地檢視特定的細節,怪異的bug與tuning得靠他
05/13 10:52, 5F

05/13 10:52, , 6F
慢得動態語言來寫而且還是一樣創造價值的人,就可以證明你的
05/13 10:52, 6F

05/13 10:52, , 7F
顯然 A, B 是不同屬性的人。
05/13 10:52, 7F

05/13 10:52, , 8F
論點謬誤了。
05/13 10:52, 8F

05/13 11:47, , 9F
TonyQ你指的應該是語言的效率問題,但我指的是PG的
05/13 11:47, 9F

05/13 11:48, , 10F
架構與寫法問題,比如只需要呼叫一次的方法卻寫在迴圈
05/13 11:48, 10F

05/13 11:49, , 11F
中之類的問題。
05/13 11:49, 11F

05/13 11:51, , 12F
這種差異無關乎語言,但是取決於PG的經驗與能力
05/13 11:51, 12F

05/13 11:53, , 13F
我的意思是,效率這回事是只有在他需要的時候才有用。
05/13 11:53, 13F

05/13 11:53, , 14F
不是無止盡的追求好就好,不然就不會有人用比較慢得語言。
05/13 11:53, 14F

05/13 11:54, , 15F
以你的例子來講,關鍵點不是工程師寫出的效能不好,(若真追
05/13 11:54, 15F

05/13 11:54, , 16F
求效能,還有很多方式可以改善,作不完的。),而是
05/13 11:54, 16F

05/13 11:54, , 17F
「用戶不滿意效能」<這句。
05/13 11:54, 17F

05/13 11:54, , 18F
而你改善效能的標的,通常也僅止於「讓用戶滿意效能」,所以
05/13 11:54, 18F

05/13 11:54, , 19F
使用者需求 drive 你的技術需求。
05/13 11:54, 19F

05/13 11:55, , 20F
而不單純是追求寫得更快這件事情,在你的例子你可能覺得那只
05/13 11:55, 20F

05/13 11:55, , 21F
是技能的問題,但那是基本的效能調校。
05/13 11:55, 21F

05/13 11:56, , 22F
高階的效能調校(cache、改演算法等),大多是牽扯專案架構
05/13 11:56, 22F

05/13 11:56, , 23F
的整體結構,並且會有對應的限制、開發上的複雜度,到那個層
05/13 11:56, 23F

05/13 11:56, , 24F
次就不只是要考慮效能問題了。
05/13 11:56, 24F

05/13 11:56, , 25F
舉個例子,concurrent高又需要即時互動的系統,可能甚至就得
05/13 11:56, 25F

05/13 11:57, , 26F
採用 nodejs 這類能作為前端大量 client 承載的系統作為第一
05/13 11:57, 26F

05/13 11:58, , 27F
個入口或者 api server,但是也會因為這樣而帶來技術複雜度
05/13 11:58, 27F

05/13 11:58, , 28F
跟專案複雜度。
05/13 11:58, 28F

05/13 12:00, , 29F
而且追求效能到一個程度之後,基本上事情大多也只是取捨。
05/13 12:00, 29F

05/13 12:03, , 30F
我的意見是,與其追求效能更好,倒不如積極研究找出哪裡讓系
05/13 12:03, 30F

05/13 12:04, , 31F
統變慢的能力,能作這個的價值恐怕還比改善效能來得高許多。
05/13 12:04, 31F

05/13 12:09, , 32F
@TonyQ:怎麼不用回文的方式回呢?
05/13 12:09, 32F

05/13 14:30, , 33F
to TonyQ:我很認同你的看法,所以同我本篇的一開頭,
05/13 14:30, 33F

05/13 14:31, , 34F
我回這篇的目的是不希望有些新手看完後直接內化為
05/13 14:31, 34F

05/13 14:33, , 35F
「這種能力不重要」所以半點也不努力。
05/13 14:33, 35F

05/13 14:37, , 36F
如果基本的調校都做不到,也沒法進入到你說的地步囉
05/13 14:37, 36F
文章代碼(AID): #1FhnzPdE (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1FhnzPdE (Soft_Job)