Re: [討論] 主管不認同書本的知識,說我沒學好程設

作者: allenxxx (fufuxxx)   2016-05-09 11:03:59
個人是半路出家,去資策會閉關半年入這行的
不學無術先請別見怪
以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的
只要能達到目的,效能可以達到,維護不困難
沒必要在那裏鼓吹什麼手法
當然或許是因為我做過很久的維運
個人反而不喜歡一堆抽象化的手法
當客戶火燒屁股電話追殺的時候
我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件
到底幹了那些好事
那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追
每個人都有自己立場
開發的人覺得自己的程式寫得很"優美",不重複
後頭維運的人如果技術層次跟不上
只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理
另外像我有一個傾向
就是一個專案只要開始做,大家決定用甚麼技術後
不管有甚麼新的了不起技術
開會只要有人要用新東西,個人一概反對到底
除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術
這是開發的紀律,要用請用在別的案子
很簡單,專案不是給你練功夫的
你懂別人不懂
不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已
像我就遇過很有進取心的同事
每一個功能,只要有進化的可能,他都要做點小修改
然後最初的功能跟最後寫的差很大...
等到他走了
接手他的功能,大家幹到沒力!
老兄,你還不如每個功能都一樣寫法!
以RD來說,這當然是有點不進取,我也承認啦
不過就像前面說的
個人維運做很久
有時候必須想的不全然只有自己的立場
抱歉以上得罪諸多高手之處,再一次致上歉意
作者: zapion (SZ)   2016-05-09 11:11:00
肯定你對維運的想法, 不過完全這樣子執行也會有盲點DevOps也是因為這個盲點應運而生 可以參考看看
作者: Luos (Soul)   2016-05-09 11:26:00
my code is elegant
作者: atpx (秋雨的心情)   2016-05-09 13:07:00
這種做法就是code無限增加,最後要耗費極龐大人力在維護舊code上金融業很多這種code
作者: GoalBased (Artificail Intelligence)   2016-05-09 13:36:00
所以別請這種技術跟不上也不想跟上的人來拖累團隊
作者: a47135 (金屬史萊姆)   2016-05-09 13:52:00
這種寫法除非你們不給客戶改規格,不然遇到一些特定的事情的時候會很慘就是了(比如有上百個同樣的程式碼之中的一處需要修改的時候)程式碼要寫的大家都懂才好維護沒錯
作者: dreamnook (亞龍)   2016-05-09 13:55:00
我會覺得這是開發者的水準還不夠 因此不好維護沒考慮到維護問題的話其實有隨意交差的感覺我之前維護的code就是這樣 我還因此補了一份文件XD結果最後出問題居然是交接人的在版本控管上弄爆了...
作者: a47135 (金屬史萊姆)   2016-05-09 13:58:00
我是看不出來你所謂的不重複是什麼,但如果是說DRY的話絕對不是他有問題.....補充:除非他是到濫用的地步
作者: bndan (seed)   2016-05-09 14:36:00
別請技術跟不上的 VS 不收水準太高的(相對) XD.以慣老闆的角度來說 如果維運不是問題(反正燒時間是工程師的事) 那當然是前者好...(雖然日後要改組後者時 通常會死路就是了XD)
作者: hichcock (快樂一整年 ^^~~~)   2016-05-09 15:11:00
不能怪你, 因為我在太多公司看過這種觀念的RD
作者: atst2 (atst2)   2016-05-09 15:28:00
"達到目的,效能可以達到,維護不困難"這不就是優劣之分了嗎?
作者: Argos (Big doge is watching u)   2016-05-09 15:38:00
我是覺得 請見人說人話 見鬼說鬼話 如果你的公司就是這樣那拒絕任何新東西 完全土法煉鋼 也無所謂 但如果你公司對於這樣子玩覺得很落伍 風氣就是開放和實驗精神 那就從善如流
作者: johnny12728 (韋)   2016-05-09 15:40:00
那如果出bug的是在你們重複貼上多次的code怎麼辦...改到死然後可能在某個角落還是沒改到 找到機會再來陰大家一把? 專案多小才能這樣玩?
作者: Argos (Big doge is watching u)   2016-05-09 15:42:00
回樓上 ctrl + shift + f 全資料夾搜索一個一個改阿~XDDD
作者: johnlinvc (阿翔)   2016-05-09 15:58:00
sed -i 's/old/new' *
作者: dreamnook (亞龍)   2016-05-09 16:00:00
@johnny: 這個時候就要學著寫程式碼產生器了
作者: newcici7777 (懂了)   2016-05-09 16:17:00
那你的團隊只需要大學生剛畢業就好自己火候不夠,連看懂別人的程式都是困難
作者: vi000246 (Vi)   2016-05-09 16:46:00
可是這麼為接手的人著想 對自已有好處嗎大不了註解寫清楚一點 邏輯別搞太亂就好了
作者: dreamnook (亞龍)   2016-05-09 16:47:00
@vi000246: 懂得如何教人也是一種學習印證啊當然從收入來看又不會多份文件多拿錢...XD
作者: hgkiller01 (克雷斯)   2016-05-09 17:03:00
身為一個碼農 農就對了
作者: sing10407 (阿U)   2016-05-09 17:29:00
推,有時候小小的功能還要抽介面實在是過度優化
作者: glory5566 (榮耀5566)   2016-05-09 17:38:00
有點像文學 有人覺得能表達就好 有人就很在乎文法詞藻
作者: ggBird (ggBird)   2016-05-09 17:58:00
不同意
作者: gn00273680 (jameslin)   2016-05-09 18:47:00
不同意
作者: Masakiad (Masaki)   2016-05-09 19:03:00
如果鼓吹abstract是多餘的,那鼓吹duplicate code又是哪招?
作者: NCUking (中大王)   2016-05-09 19:38:00
想不到已經2016年了會看到這種言論 XDD
作者: superpai (超級白)   2016-05-09 20:06:00
這概念偷換有點嚴重喔,前面說不要用新技術,後面砲有RD 改 code。難道改 code 是一種新技術?另外我是覺得很奇怪啦,code應該每個人都在PR時就該看過了,不懂要問,不然就打槍。到最後才看不懂顯然是沒做好自己的工作。
作者: sayya2311 (ya)   2016-05-09 20:51:00
如果沒方法跟有方法,可以做到一樣的產出,那麼此文成立不過常看到沒方法做著做著就落後/到屏頸了
作者: stosto (樹多)   2016-05-09 21:36:00
kerker,這種你要挑戰年薪破兩百就有點難了
作者: alog (A肉哥)   2016-05-09 21:37:00
火燒屁股是因為沒把程式寫好 而不是抽象化的問題
作者: wuliou (wuliou)   2016-05-09 23:53:00
不同意
作者: ay852852 (ay852852)   2016-05-10 01:12:00
基礎功不好,這樣你程度就跟英文比較好的高中生一樣
作者: laikyo (六元)   2016-05-10 08:54:00
第二段無法認同
作者: stero (認真 發呆)   2016-05-10 09:33:00
完全不會比較好追 莫名其妙
作者: psliurt (反指標)   2016-05-10 13:06:00
資策會的,不意外
作者: ken1325 (優質水瓶男)   2016-05-10 13:32:00
資策會出來也就這種程度了 你還是洗洗睡吧
作者: Dnight (暗夜)   2016-05-10 13:43:00
不過真的要看隊友程度啦
作者: ripple0129 (perry tsai)   2016-05-10 18:26:00
簡單來說工作寫程式最難處理的部分是人XD
作者: tanson (Flash)   2016-05-10 19:48:00
每個公司有每個公司的做法,但這種公司不會是高手的公司
作者: duckfly (Java ass)   2016-05-10 21:54:00
這不是誰對誰錯的問題,而且程度跟思維差太多的結果
作者: b0610213 (StarD)   2016-05-11 13:07:00
但我可不記得資策會的吳老師是這樣教我的....
作者: remmurds (Stronghold)   2016-05-12 06:33:00
資策會不意外 先學學怎麼寫log
作者: comesuck (艾米德)   2016-05-12 19:18:00
複製貼上維護的時候會精神衰弱...「不是改過了?」
作者: kevin979   2016-05-14 21:33:00
全部複製貼上,你在開玩笑嗎?如果要改邏輯!怎麼辦?我也是資策會出來的!完全無法認同這作法...

Links booklink

Contact Us: admin [ a t ] ucptt.com