PTT職涯區 / Soft_Job (軟體人)

Re: [討論] 程式設計師,好吃技術的職業喔!

看板Soft_Job (軟體人)作者 (紅框獨居帥老人傳說)時間17年前 (2008/12/28 09:35), 編輯推噓8(8推 0噓 44→)
留言52則, 5人參與, 最新討論串11/19 (看更多)
※ 引述《iincho (..)》之銘言： : 搞軟工最討厭的就是這種只看皮相不看內涵的東西...<o> : 以這個例子來說，如果程式錯誤處理做的好，那我比較傾向是分析比較完善， : 而不是每個if後面都有加else這種鬼扯淡的說法... 倒也不算是鬼扯淡啦。 很多寫程式的人有的時候會對自己的邏輯跟分析太有自信， 其實邏輯或分析能力可能沒有自己以為的那麼好， 在一定程度上養成好習慣可以快速找到問題所在。 有的時候實作的問題就剛好出在自己或一群人沒有考慮分析到的地方。 加上個 else 補個 debug message 順手一下又不一定有什麼損失。 例如在下搞一個很冷門的 Embedded System （為了省空間幾乎只有基本的簡單kernel.. ）， 而搞 Embedded System ，其實常常發生 overflow 的問題， 畢竟常常有東西是 8 bits 或 16 bits 的， 於是我就漸漸養成一定會去檢查溢位的習慣。 常常被溢位搞到於是自然很重視這個檢查， 要不然以前覺得只是個加減還加什麼溢位檢查，根本是嗤之以鼻^-(oo)-^。 當然這是在我這家公司我才會重視這種問題啦， 因為不小心不是道個歉就算了，而是有可能出一個到很多個人命，賠不起的… 不過在大部分的場合，這種事情通常不用這麼吹毛求疵啦。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.124.152.16
推
12/28 09:56, , 1F
怎麼到現在, 加else還在跟嚴謹綁在一起?
12/28 09:56, 1F
→
12/28 09:58, , 2F
else又跟debug message 綁在一起 ...
12/28 09:58, 2F
→
12/28 09:59, , 3F
基本上嚴謹有很多方法可做
12/28 09:59, 3F
→
12/28 10:03, , 4F
design by contract, guard condition, mock object ....
12/28 10:03, 4F
→
12/28 10:04, , 5F
exception handling .. 等等
12/28 10:04, 5F
→
12/28 10:05, , 6F
加個 else 算哪門子的嚴謹? 老實說只感覺是對程式的掌握力
12/28 10:05, 6F
→
12/28 10:06, , 7F
不夠，才會在程式中的每個地方都有不確定的事
12/28 10:06, 7F
推
12/28 10:12, , 8F
樓上，以之前的例子來看，建議可以偶爾試試加點垃圾else
12/28 10:12, 8F
→
12/28 10:13, , 9F
或許會發現PG對「程式的掌握力」倒底有多不足
12/28 10:13, 9F
推
12/28 10:14, , 10F
加垃圾else是好事? 以我來看掌握度不足才危險...舉個例子
12/28 10:14, 10F
→
12/28 10:15, , 11F
程式新鮮人寫的糟糕code常會有的特點, 像
12/28 10:15, 11F
→
12/28 10:16, , 12F
到處充滿註解的程式, 滿是 //XXX 只為了隨時要 debug
12/28 10:16, 12F
→
12/28 10:18, , 13F
程式中重覆的function一堆, 重覆的檢查也一堆
12/28 10:18, 13F
→
12/28 10:19, , 14F
或者程式中充滿debug message, 比正常的程式還多
12/28 10:19, 14F
→
12/28 10:20, , 15F
這些特徵都是"危險"的指標, 代表新人對程式的掌握度不好
12/28 10:20, 15F
→
12/28 10:21, , 16F
我覺得應該做的，是鼓勵他們去思考與掌握自己的程式
12/28 10:21, 16F
→
12/28 10:22, , 17F
而不是教他們去使用一些, 沒效率但一定能解決的方法
12/28 10:22, 17F
→
12/28 10:23, , 18F
回到那些垃圾else, 你不覺得那是"不好"程式的特徵?
12/28 10:23, 18F
→
12/28 10:25, , 19F
因為"垃圾"code，不管是重覆的什麼，都是好程式所要避免的
12/28 10:25, 19F
→
12/28 10:59, , 20F
lol, I said it's a VERY SIMPLE KERNEL. lol
12/28 10:59, 20F
→
12/28 11:00, , 21F
簡單來說，你說的這些東西完全不支援，那個 kernel 根本
12/28 11:00, 21F
→
12/28 11:00, , 22F
是垃圾，是該丟棄的廢物，可是不巧在我這領域用很多 lol
12/28 11:00, 22F
→
12/28 11:01, , 23F
因為要把這麼多東西塞在 2mb 的空間太痛苦了， lol。
12/28 11:01, 23F
→
12/28 11:03, , 24F
連個 TLB 都沒有的 os, contract 又根本不合實際開發 lol
12/28 11:03, 24F
→
12/28 11:03, , 25F
算了，大家開心就好，況且我也沒說這樣叫嚴謹，只是要避
12/28 11:03, 25F
→
12/28 11:04, , 26F
免錯誤在我的工作中我必須要這樣處理，本來就跟嚴謹無關
12/28 11:04, 26F
→
12/28 11:05, , 27F
我的開發環境中沒有這些東西，所以有支援的人要惜福喔:P
12/28 11:05, 27F
→
12/28 11:07, , 28F
我只能努力讓我的工作不要誤作動免得出人命，其他跟我無
12/28 11:07, 28F
→
12/28 11:09, , 29F
關 lol 我的產品賣到醫療跟航空管制，我不想出人命，就
12/28 11:09, 29F
→
12/28 11:09, , 30F
這樣，大家開心就好。 lol
12/28 11:09, 30F
推
12/28 11:28, , 31F
keric 你提的只是一些開發的除錯技巧,並不是什麼良好的模範
12/28 11:28, 31F
→
12/28 11:29, , 32F
我並沒有說我的是良好的模範啊，只是逼得不得不這樣做
12/28 11:29, 32F
→
12/28 11:30, , 33F
所以我說了，大家開心就好。 lol
12/28 11:30, 33F
推
12/28 12:11, , 34F
不管是註解、debug message、else和所有垃圾除錯碼
12/28 12:11, 34F
→
12/28 12:12, , 35F
出發重點就是在於不要相信「人」的能力
12/28 12:12, 35F
→
12/28 12:13, , 36F
不一定會派上用場，只是種保險作法。我不認為這是「好程
12/28 12:13, 36F
→
12/28 12:14, , 37F
式所要避免」的，再熟練的人類高手，也有恍神的時候。
12/28 12:14, 37F
推
12/28 12:31, , 38F
加個debug message就可以讓你的程式不會出人命?
12/28 12:31, 38F
→
12/28 12:32, , 39F
你都不覺得你這些經驗，跟你的結論沒什麼關連？
12/28 12:32, 39F
→
12/28 12:34, , 40F
是啊，你開心就好。 :)
12/28 12:34, 40F
→
12/28 12:35, , 41F
我什麼都沒說，大家開心就好。 :D
12/28 12:35, 41F
→
12/28 12:36, , 42F
我並不想在這種地方作員工教育訓練以及洩漏公司機密 XD
12/28 12:36, 42F
→
12/28 12:38, , 43F
況且這只代表我們工作的性質不一樣，其實沒有什麼意義。
12/28 12:38, 43F
→
12/28 12:38, , 44F
而且我只是說順手作個 debug ，並沒有說我不去作 correct
12/28 12:38, 44F
→
12/28 12:39, , 45F
反正人命是我在背負的，其他人開心就好。 :)
12/28 12:39, 45F
推
12/28 12:45, , 46F
所以結論是加else可以舒解你對於人命的壓力？
12/28 12:45, 46F
→
12/28 12:46, , 47F
但其實對於程式可靠度，嚴謹等...並沒有任何幫助？
12/28 12:46, 47F
→
12/28 12:46, , 48F
你的推論非常奇怪，恕我不回應。 :)
12/28 12:46, 48F
推
12/28 12:46, , 49F
keric是對溢位的發生很小心 加else的市cheng那篇裡面的
12/28 12:46, 49F
→
12/28 12:47, , 50F
希望你以後不要進來這種吹毛求疵的領域。 :) 很累的 :)
12/28 12:47, 50F
→
12/28 12:47, , 51F
主管啦. 我完全認同嚴謹, 我只是真的不懂cheng那篇的主管
12/28 12:47, 51F
→
12/28 12:48, , 52F
把嚴謹對應到if必加else 是如何成立的
12/28 12:48, 52F
‣ 更多 kerickuo 的文章
文章代碼(AID): #19LjVpxR (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 11 之 19 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共19篇)
Soft_Job 近期熱門文章
1
1
Offer選擇
[ Soft_Job ]
wangdanzzz
23小時前, 02/26
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 kerickuo 的文章
文章代碼(AID): #19LjVpxR (Soft_Job)