PTT職涯區 / Soft_Job (軟體人)

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

看板Soft_Job (軟體人)作者 (fufuxxx)時間10年前 (2016/05/09 11:04), 編輯推噓6(17推 11噓 43→)
留言71則, 39人參與, 最新討論串12/14 (看更多)
個人是半路出家,去資策會閉關半年入這行的 不學無術先請別見怪 以我自己來說,從來不覺得程式寫法有甚麼優劣,程式是幫客戶解決問題的 只要能達到目的,效能可以達到,維護不困難 沒必要在那裏鼓吹什麼手法 當然或許是因為我做過很久的維運 個人反而不喜歡一堆抽象化的手法 當客戶火燒屁股電話追殺的時候 我還必須要追到抽象的類別或介面,然後判斷到底產生的是啥鳥物件 到底幹了那些好事 那開發者你還不如每一個類別乖乖地用複製貼上,我還比較好追 每個人都有自己立場 開發的人覺得自己的程式寫得很"優美",不重複 後頭維運的人如果技術層次跟不上 只有兩種可能,想辦法跟上,或是把問題踢回給你自己處理 另外像我有一個傾向 就是一個專案只要開始做,大家決定用甚麼技術後 不管有甚麼新的了不起技術 開會只要有人要用新東西,個人一概反對到底 除非不用無法解決現行問題,不然不管多沒水準還是一律要用一開始律定的技術 這是開發的紀律,要用請用在別的案子 很簡單,專案不是給你練功夫的 你懂別人不懂 不代表你厲害,只代表你"搖屁股",替"隊友"製造麻煩而已 像我就遇過很有進取心的同事 每一個功能,只要有進化的可能,他都要做點小修改 然後最初的功能跟最後寫的差很大... 等到他走了 接手他的功能,大家幹到沒力! 老兄,你還不如每個功能都一樣寫法! 以RD來說,這當然是有點不進取,我也承認啦 不過就像前面說的 個人維運做很久 有時候必須想的不全然只有自己的立場 抱歉以上得罪諸多高手之處,再一次致上歉意 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.112.125.79 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1462763041.A.66F.html
→
05/09 11:11, , 1F
肯定你對維運的想法, 不過完全這樣子執行也會有盲點
05/09 11:11, 1F
→
05/09 11:12, , 2F
DevOps也是因為這個盲點應運而生 可以參考看看
05/09 11:12, 2F
推
05/09 11:26, , 3F
my code is elegant
05/09 11:26, 3F
推
05/09 13:07, , 4F
這種做法就是code無限增加，最後要耗費極
05/09 13:07, 4F
→
05/09 13:07, , 5F
龐大人力在維護舊code上
05/09 13:07, 5F
→
05/09 13:07, , 6F
金融業很多這種code
05/09 13:07, 6F
推
05/09 13:36, , 7F
所以別請這種技術跟不上也不想跟上的人來拖累團隊
05/09 13:36, 7F
推
05/09 13:52, , 8F
這種寫法除非你們不給客戶改規格，不然遇到一些特定的事情
05/09 13:52, 8F
→
05/09 13:53, , 9F
的時候會很慘就是了(比如有上百個同樣的程式碼之中的一處
05/09 13:53, 9F
→
05/09 13:53, , 10F
需要修改的時候)
05/09 13:53, 10F
→
05/09 13:54, , 11F
程式碼要寫的大家都懂才好維護沒錯
05/09 13:54, 11F
→
05/09 13:55, , 12F
我會覺得這是開發者的水準還不夠 因此不好維護
05/09 13:55, 12F
→
05/09 13:56, , 13F
沒考慮到維護問題的話其實有隨意交差的感覺
05/09 13:56, 13F
→
05/09 13:57, , 14F
我之前維護的code就是這樣 我還因此補了一份文件XD
05/09 13:57, 14F
→
05/09 13:58, , 15F
結果最後出問題居然是交接人的在版本控管上弄爆了...
05/09 13:58, 15F
→
05/09 13:58, , 16F
我是看不出來你所謂的不重複是什麼，但如果是說DRY的話
05/09 13:58, 16F
→
05/09 13:58, , 17F
絕對不是他有問題.....
05/09 13:58, 17F
推
05/09 14:05, , 18F
補充：除非他是到濫用的地步
05/09 14:05, 18F
→
05/09 14:36, , 19F
別請技術跟不上的 VS 不收水準太高的(相對) XD.以慣老闆的
05/09 14:36, 19F
→
05/09 14:37, , 20F
角度來說 如果維運不是問題(反正燒時間是工程師的事) 那當
05/09 14:37, 20F
→
05/09 14:37, , 21F
然是前者好...(雖然日後要改組後者時 通常會死路就是了XD)
05/09 14:37, 21F
→
05/09 15:11, , 22F
不能怪你, 因為我在太多公司看過這種觀念的RD
05/09 15:11, 22F
→
05/09 15:28, , 23F
"達到目的,效能可以達到,維護不困難"這不就是優劣之分了嗎?
05/09 15:28, 23F
推
05/09 15:38, , 24F
我是覺得 請見人說人話 見鬼說鬼話 如果你的公司就是這樣
05/09 15:38, 24F
→
05/09 15:39, , 25F
那拒絕任何新東西 完全土法煉鋼 也無所謂 但如果你公司對於
05/09 15:39, 25F
→
05/09 15:40, , 26F
這樣子玩覺得很落伍 風氣就是開放和實驗精神 那就從善如流
05/09 15:40, 26F
推
05/09 15:40, , 27F
那如果出bug的是在你們重複貼上多次的code怎麼辦...
05/09 15:40, 27F
→
05/09 15:41, , 28F
改到死然後可能在某個角落還是沒改到 找到機會再來陰
05/09 15:41, 28F
→
05/09 15:41, , 29F
大家一把？ 專案多小才能這樣玩？
05/09 15:41, 29F
→
05/09 15:42, , 30F
回樓上 ctrl + shift + f 全資料夾搜索一個一個改阿～XDDD
05/09 15:42, 30F
推
05/09 15:58, , 31F
sed -i 's/old/new' *
05/09 15:58, 31F
→
05/09 16:00, , 32F
@johnny: 這個時候就要學著寫程式碼產生器了
05/09 16:00, 32F
噓
05/09 16:17, , 33F
那你的團隊只需要大學生剛畢業就好
05/09 16:17, 33F
→
05/09 16:18, , 34F
自己火候不夠，連看懂別人的程式都是困難
05/09 16:18, 34F
推
05/09 16:46, , 35F
可是這麼為接手的人著想 對自已有好處嗎
05/09 16:46, 35F
→
05/09 16:47, , 36F
大不了註解寫清楚一點 邏輯別搞太亂就好了
05/09 16:47, 36F
→
05/09 16:47, , 37F
@vi000246: 懂得如何教人也是一種學習印證啊
05/09 16:47, 37F
→
05/09 16:48, , 38F
當然從收入來看又不會多份文件多拿錢...XD
05/09 16:48, 38F
推
05/09 17:03, , 39F
身為一個碼農 農就對了
05/09 17:03, 39F
推
05/09 17:29, , 40F
推，有時候小小的功能還要抽介面實在是過度優化
05/09 17:29, 40F
推
05/09 17:38, , 41F
有點像文學 有人覺得能表達就好 有人就很在乎文法詞
05/09 17:38, 41F
→
05/09 17:38, , 42F
藻
05/09 17:38, 42F
→
05/09 17:58, , 43F
不同意
05/09 17:58, 43F
噓
05/09 18:47, , 44F
不同意
05/09 18:47, 44F
噓
05/09 19:03, , 45F
如果鼓吹abstract是多餘的，那鼓吹duplicate code又是
05/09 19:03, 45F
→
05/09 19:03, , 46F
哪招？
05/09 19:03, 46F
推
05/09 19:38, , 47F
想不到已經2016年了會看到這種言論 XDD
05/09 19:38, 47F
→
05/09 20:06, , 48F
這概念偷換有點嚴重喔，前面說不要用新技術，後面砲有
05/09 20:06, 48F
→
05/09 20:07, , 49F
RD 改 code。難道改 code 是一種新技術？
05/09 20:07, 49F
→
05/09 20:12, , 50F
另外我是覺得很奇怪啦，code應該每個人都在PR時就該看
05/09 20:12, 50F
→
05/09 20:12, , 51F
過了，不懂要問，不然就打槍。到最後才看不懂顯然是沒
05/09 20:12, 51F
→
05/09 20:13, , 52F
做好自己的工作。
05/09 20:13, 52F
→
05/09 20:51, , 53F
如果沒方法跟有方法,可以做到一樣的產出,那麼此文成立
05/09 20:51, 53F
→
05/09 20:52, , 54F
不過常看到沒方法做著做著就落後/到屏頸了
05/09 20:52, 54F
→
05/09 21:36, , 55F
kerker，這種你要挑戰年薪破兩百就有點難了
05/09 21:36, 55F
噓
05/09 21:37, , 56F
火燒屁股是因為沒把程式寫好 而不是抽象化的問題
05/09 21:37, 56F
噓
05/09 23:53, , 57F
不同意
05/09 23:53, 57F
噓
05/10 01:12, , 58F
基礎功不好，這樣你程度就跟英文比較好的高中生一樣
05/10 01:12, 58F
→
05/10 08:54, , 59F
第二段無法認同
05/10 08:54, 59F
噓
05/10 09:33, , 60F
完全不會比較好追 莫名其妙
05/10 09:33, 60F
噓
05/10 13:06, , 61F
資策會的，不意外
05/10 13:06, 61F
噓
05/10 13:32, , 62F
資策會出來也就這種程度了 你還是洗洗睡吧
05/10 13:32, 62F
推
05/10 13:43, , 63F
不過真的要看隊友程度啦
05/10 13:43, 63F
→
05/10 18:26, , 64F
簡單來說工作寫程式最難處理的部分是人XD
05/10 18:26, 64F
→
05/10 19:48, , 65F
每個公司有每個公司的做法，但這種公司不會是高手的公司
05/10 19:48, 65F
推
05/10 21:54, , 66F
這不是誰對誰錯的問題，而且程度跟思維差太多的結果
05/10 21:54, 66F
噓
05/11 13:07, , 67F
但我可不記得資策會的吳老師是這樣教我的....
05/11 13:07, 67F
噓
05/12 06:33, , 68F
資策會不意外 先學學怎麼寫log
05/12 06:33, 68F
推
05/12 19:18, , 69F
複製貼上維護的時候會精神衰弱...「不是改過了？」
05/12 19:18, 69F
推
05/14 21:33, , 70F
全部複製貼上，你在開玩笑嗎？如果要改邏輯！怎麼辦？
05/14 21:33, 70F
→
05/14 21:34, , 71F
我也是資策會出來的！完全無法認同這作法...
05/14 21:34, 71F
‣ 更多 allenxxx 的文章
文章代碼(AID): #1NB_uXPl (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 12 之 14 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共14篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 allenxxx 的文章
文章代碼(AID): #1NB_uXPl (Soft_Job)