[閒聊] 寫程式真的這麼邪門嗎?
https://i.imgur.com/NLPJc6B.jpg
科學家:讚啦!有用了!
教授:很好,讓我們看看是如何作用跟怎麼作用!
碼農:讚啦!跑起來了!
主管:別再碰它,沒人知道會不會無預警當掉。
寫程式真的這麼邪門嗎?
--
是 如果這個碼沒問題 就千萬別動
是 動了要是壞掉 不如不要動
程式碼寫的時候就知道原理和作用 又不是亂寫的
開玩笑輕鬆的講而已...
尤其是長年累積不知道傳承幾代的code
我文組辣 不能複製一份來拆嗎?
是 絕對不要動
很多時候我他媽也不知道我在寫啥 反正能跑就好
因為有可能連寫的人都忘記了當初怎麼寫出來的XD
與其複製一份,不如整個打掉重來
可以複製一份來改啊 只是對主管來說去動已經working的東
西可能不如多修幾個bug
理論上要修是可以複製一份慢慢拆啊
100串程式碼 你只要找一條出來DEBUG就算了
但與其複製一份你不如趕快寫新的 下一版要上了
一萬串程式碼 叫你找一條出來DEBUG 看你要不要這樣玩
大概就是這樣吧 既然不曉得他是怎麼成功動起來的
4 如果他能動就不要動==
不然為什麼要拜乖乖
能不動就別動 以後有錯都先怪動的人
那就甚麼事都別做 祈禱不要哪天出問題然後屁股擦不完
程式碼可能有一堆目標變動已無功用的片段 研究無意義
尤其是老系統一個function後面可以trace出一大坨東
西的
理論上可以 但時間人力和金錢的考量 主管會叫你別動
科學也差不多
理論歸理論 我曾經有複製一份慢慢拆。結果只是拆了合併
根本沒改就不動了
是
不只程式部分 硬體也一樣 可以動就不要亂動 連灰塵都
其實上下兩格對程式來說並沒有衝突XD
後來一查。可能是rs324什麼的在我拆時驅動不見了
負負得正啊,你把其中一個負的改成正的試試
跟人體基因很像啊
不要說工作 學生專題或作業這種的
線上的系統才會不動 開發中的動起來要先驗證效能
我的程式跑不起來 我根本不知道為什麼/我的程式跑起來了
我根本不知道為什麼.jpg
而且有時候用一些邪門的方法呼叫IDE可能會trace不到…
你有時候也是莫名奇妙就能動了
@Tsukasa0320 現在有git 連複製都不用 爽改就改
不要清 線再亂也不要重新理
每一條程式碼都可能會有寫的人完全沒有想到的副作用
改一個東西爛了也是馬上可以revert
然後程式碼的位置也會影響副作用的發作程度和範圍
程式碼就跟飛機一樣 會動就是會動
我完全不知道為什麼我的程式沒辦法動
所以你搬一搬把副作用翻山倒海後結果就完全不一樣了
死線在前能用就好
@kirimaru73 這個也是為什麼現在流行 test-driven
我完全不知道為什麼我的程式有辦法動
如果你說我應該寫出完全沒有副作用的乾淨程式
那這是個很偉大的理想,希望你能說到做到
如果是要Debug的話就要讓他當掉你才知道要改哪裡
主要是 哪有那麼閒 下個專案在催了
我以前也覺得寫unit tests超煩XD
很多程式甚至是靠Bug在運行的
不確定其它人call這api而做出多少妥協時就別亂動了
鴿子起飛.jpg
神人可以做得到 但多數人終究是一般人
不過不知道為什麼會work通常是誇大了就是
西洽一堆程式大師:O
經年累月的系統要全部搞懂不如打掉重練,有些人寫的程
式碼除了自己以外只有電腦看到懂,有些時候連他自己都
看不懂
碼農:幹,為什麼壞了?
也是碼農:幹,為什麼好了?
實務上是 不知道為什麼讓這個嚴重的bug不再出現了
改動如果有跟預期不一樣的行為通常不太可能就放著
而在這個過程中最顯眼的是乖乖 那真相就是乖乖了
是 尤其是接手維護的通常是能動就好能不改就不改
乖乖就只是個迷信而已
有些人的習慣就很糟,到處int a int* int**
迷信總比加班好
其實就是那句名言 it's just work
專業點原因在內核運作上你少看幾千萬行的基礎邏輯導
沒注解 沒文件 沒時間 沒問題
致你無法理解有時候出現的不能解釋的錯誤
這種時候就放著比較好
應該是程式碼太多行,再加上通常不寫註解,
#相信乖乖
很多段沒人看得懂他是幹嘛的,但是把那段拿掉就會初四
如果還是祖傳代碼一代改一代還綁定需要編譯的傻逼框
架就會根本無從動起
不寫註解直接git blame找出來幹爆了 操 欠幹
你可以不相信乖乖把它們全部吃掉,但是你要相信當你把
它們全部吃掉之後,一定會有一群人來打你
註解都不寫就是想要挖坑的意思
開branch再改
時間一久,後續再加寫程式碼出Bug,就不知道要改哪裡了
最離譜的還有編譯框架的編譯器居然還是特別版
除非現在在比賽,不然就是做出能動的code就好,優化一
個點爆炸的機率高
尤其是滿滿的goto
以前我不懂為什麼 git blame 要叫作 git blame後來就懂了
有一個很有名的粒子叫做0x5f3759df
是
我很確定寫出這個數字的傢伙絕對不是人類
別懷疑中國的程式碼很多長這鬼樣
你會不記得當時你在寫什麼
看系統需求吧 太爛的效能不優化上線一樣是炸
能動就好 寫得再有嘈點它還是能動
是 能work的碼千萬不要亂動
其實叫做git motherfucker比較信達雅 可惜不太被接受
如果連unit test也很難維護怎麼辦:)
現在程式開發應該都有 unittests 和 end-to-end tests
重構
沒有維護概念的工程師本身在寫或是改程式碼時,
有一個比較少見的粒子是你一定要把程式容量縮小個N倍
4 程式不徹底解決Bug 是因為案子在趕還有很多東西要
做 所以只要不會當掉就好 久了這個問題也被人遺忘 有
一天突然復發 大多數人也都忘記原因是什麼了
是很容易有意無意就忘了註解存在的……
這時就真的要大改,可是現在電腦手機也不需要你常常搞
現在開發何止test程式從系統建設編譯框架就開始測
看到有人在現代環境goto來goto去我一定會發狂
產品有bug無所謂,如果不會掉星就不重要了,管它幹嘛
@zerox1336 還是得維護啊 不然測試程式就沒意義了
git blame還真的是在找motherfucker
沒註解就會變這樣
有些碼農自以為自己的Code很乾淨 變數命名取得好所以
不寫註解==
怕得是註解也告訴你不知道怎麼動的
通通做成函式藏起來,只管輸出入,內容沒事不要動。
註解不知道怎麼動的 那至少要file一張ticket了
It恐怖故事
是 it just works
不需要註解就可閱讀的程式是一種理想,也有可能實現
都寫進10幾層物件的看屁股啊 得寫ide特殊註解才能帶
但如果你的程式裡面每個變數名稱都長得像
repo如果你自己一個人用 想要堅持那理想無妨
nIntegerValueOfCharacterSkillCharge 這樣的話
那你就不會堅持什麼可閱讀性了
“程式出bug了“ , ”最後改的人是誰?“ 大概是這樣
就算最後改的是你 你還是有機會往前追10-20個版本夾出
真正改出問題的那位motherfucker然後把bug轉給他
不要笑,某些新創公司業務需求一直大改又趕著上線,還真
的會變這樣XD
是 他如果會動會跑 就不要去理他
不過希望你家的程式編譯+運行一次小於30分鐘
我都脫離苦海了別再讓我想起來==
新創我「比較」可以理解
是 連一個換行都不敢多加
老闆在後面催進度的東西這樣搞很正常,根本沒時間好好
測
bug還是一定要修的啦 尤其是那種讓4.1顆星變3.9顆星的
而且很多時候會 明明是上午的我寫的東西 下午的我
:這啥?
但如果不是這種bug你管他作啥 肝不要了嗎
舊碼不知道在幹嘛沒辦法...
新創多的是連需求都不確定的 code亂七八糟也正常
很多都上線出問題才修,那時候也不能停太久
下一個接手的倒楣鬼:幹這個在寫三小,為什麼可以動
新創多的是新手村剛出來的啊
「軟體工程師寫的每行程式碼,需要由另一個軟體工程師
向保姆一樣親眼看過並及時提醒改正嚴重的錯誤」
我以為新創一般比較喜歡找老鳥/即戰力
這種概念連一般人都會覺得神經病,更何況是那些老闆
化學的~好像比較在乎能否重現~若無法就沒啥屁用~
迷信總比加班好
都有那種上線兩三年正常運作,某天突然有bug的狀況了
新創進門一切靠口欠
誰都很重視能否重現
it works on my computer :)
幾個月後那code就變成別人寫的code了
沒辦法重現就像你講的一樣:沒啥屁用
那是理想,所以一定要加註解讓後續維護的工程師知道前面
的工程師是用啥想法去寫出那堆東西的。
是 沒問題就不要去動它
只是生科領域如果沒辦法重現你就當他造假的話,這領域的
是 尤其是寫韌體的 很多奇怪的寫法可能是為了幫硬體
不知道變數名稱可以設定多長
擦屎的 不知道真的別亂碰
發展阻力會變得很大,然後才會出現一些生科詐騙仔
幫支援鴿子gif
實驗室裡面架儀器也是一樣啦。在紙上一切看起來都很美好,
實際上每個老師博後組了都不靈,只有某個內建金手指屬性的
學生組的會正常運作。這時不會有人去研究金手指,只有上供
一包乖乖,默默開始量sample。
能動了就不要再去碰它
然而 即便你的團隊都有這樣的好習慣 當你接到 3rd par
ty library...
電子產品就是計算機,正常來說丟同樣的東西進去就會跑出
同樣的結果,所以寫註解很重要……
第一格科學家挺奇怪的,什麼都不知道怎麼做實驗
4444
「你們的程式有問題」
「沒關係我們有提供source code」
提供的source code:
論comments的重要www
正常來說... 機器跟你鬧彆扭的不算
煉金術士轉科學家的話向第一格那樣不奇怪
只是99/100會直接自爆在實驗室內,你看到的是生存者
comments 真的 超重要 寫得像作文都無所謂
純軟比較不會有重現的問題吧
浮點數 :)
寫就對了
久遠的code當然別動
能複製就複製 不要動裡面
很多東西已經上線了,萬一亂改當下可能沒問題把他上上去
,結果經過user用後發現更多問題那賠更大
如果同一台機器 丟進去東西一樣產出不一樣,一定是機器
的文題,純軟:窩不知道
用別人的lib怎麼死的都不知道 十幾年沒人發現的bug之類
程式是按照你邏輯跑~有問題就解決~所以他照著跑~剩下要
3rd party lib 受歡迎的通常有bug也都有ticket了
等等jserv 大神要截圖罵學生了
同一台機器丟進去產出不一樣有可能啊 多線程寫太爛...
4 內碼沒問題就別動 動了就壞了
是機器的問題,但也是你的程式用念針去插機器腦的問題
用大家在用的lib 至少一堆人幫忙debug
memory被你插爛後直接當掉是對你仁慈,沒當掉你就慘了
memory被插爛之後 還要跑好幾個小時才會發生的bug
想起來就覺得背後涼涼的
程式會嚴格照著"你寫的程式碼的邏輯"跑
而這個邏輯通常會內含大量的RNG
致這幾天還要on call 的工程師 (淚
而"你的邏輯"和"你的程式碼的邏輯"中間可能會有兩根手
從硬體到軟體,會出包的可能性太多了甚至會有複合co
mbo,所以沒事別動
指頭(夾宇宙)的差距
所以要寫unit tests啊XD
我總覺得這個問題在西洽也是月經文了==
@kirimaru73 乍看之下還以為你在講五條悟
複合combo真的很high 有時候換個螢幕你程式就爆炸了
是 特別是韌體 跑的動就別再去碰它 你根本不知道前人留
下來的code有多少亂七八糟的workaround
不過也有發生過「我以為他們這樣運轉」但實際上不是的
情況XD 不過反正是在merge前爆開 倒無所謂
雀食 它運作正常就不要動
這問題通常是前人寫的code,把多個功能耦合在一起來
,文件跟註解又沒寫好。專案在跑的時候,通常不會有
這麼多時間給你重構或解BUG,所以才會有人說能動就好
3F 能100%了解程式碼怎麼跑的只有小程式而已啦XDD
寫的人是一定會了解自己想要程式碼怎麼跑
不要分析就還好~畢竟寫程式的~不會只有一個程式要處理~
只是他們不會去全盤了解自己程式的替身能力
沒空啦 老闆是請你來賺錢的 趕時程
有很多東西是精心設計過的,表面看不出來,一動就會出事
你今天是獨立工作者就可以慢慢爬蟲啊
是 會動就不要手賤
啊如果你是吃人飯碗的 哪有那個美國時間一條一條抓
是
就像綠谷剛接到宋七力能力時 也是靠杯難用
有時間在那邊抓動起來沒問題的程式還不如快寫下個月的更新
Production環境跟development環境會分開
新版本也要DEBUG欸
沒有時間怎麽寫Unit tests (父子丟椅
這是真的 能不要動就不要動 我就當過動的倒霉鬼= =
AMI 工程師血淚控訴Intel 跟ms壓榨
要知道程式會動不代表他邏輯沒問題
你有多勇 我動離職同事的code
不然以為legacy code這個詞怎麼來的
別人改了一週才通過QA的Code。再怪也不要重構它
其實就算你是時間很多的業餘開發者,你沒事也不會去找
有git很方便啦 要回覆很簡單
會動只是編譯的過而已吧!
it just work
其實這跟你電腦主機沾滿灰塵一樣,不清理電腦都沒事,
一用噴槍清灰塵後直接掛掉一樣
能動的程式談心啊,除非你的主題是如何寫最優美的程式
那就像一座積木的高塔,你拔掉一塊。整座就會倒下來
4啊,開發系統有時候就是 能動就好QQ
樓上沒遇過用git倒回去也不會動的時候嗎
實驗室的變數相對單純,比較容易找出邏輯,要轉成商用時
就會遇到同樣困難。
之前曾看過一段話:理論就是知道為什麼但實際上行不通,
實務則是實際上行得通但不知道為什麼,程式常常屬於後者X
D
遇到user他媽東加西加邏輯全亂套的時候,千萬就別再
動程式碼了
改程式碼就是扯動接上了一條線然後連帶扯斷其他一千條線
當你的碼大到百萬行以上就會這樣
4 動了又要改好幾天
是,我能不動絕對不動。
gta5之前的陳年讀取Bug大概就是那種思維。結果還是靠
熱心駭客找出問題修復的
看到硬體累積灰塵也不要清 清了會跳機
(X) 寫程式 (O) 複製貼上
這麼邪門?
不要亂動 動了全毀
是因為上面叫學術研究,下面叫商業產品,消費者不會在意
軟體。
複製貼上也有技巧的,不然一堆人在Stack overflow 找
答案的意思是一樣的
是...靠北當系統靠北大,寫這東西的人離職好幾年還沒有
文件,最好的辦法是不要動他
44444
不知道為什麼work比不知道怎麼work還可怕
這就是機械神教的起源 會動就是會動.jpg
實際上重寫代表你得要全面重新測試才不會出問題,
哪怕你只動一小
塊而已
所以最好就是不要動自己不熟悉的code啊XD
是,比這個還邪門,半年後檢查的時候發現邏輯整個寫錯,
但已經上線跑了半年還沒發生任何問題,完全無法理解
程式不邪門 但是寫的人想法可能很邪門
自己寫的可能還能看出所以然,你去接看看學長沒寫完的那個
才是滿頭問號,重點是他寫的還能用
不只寫程式,科學實驗的重複性亦邪門乎
很多時候我回頭翻自己的註解都不知道為什麼能動了
更別說要去翻別人的
這倒是真的 所以只要可以用就拿來用 誰還想重寫
開發文件跟交接沒很嚴謹的話,多換幾個人接手就很容易
就算有留文件或註解,有時候翻一翻就會發現當初根本搞錯
了,但結果莫名其妙還是對的,比撞邪還離奇
發生這種事情,接手的根本搞不懂以前那堆人搞的違建
timing issue真的難解 還是別動
版本控制啊 修錯再回來重修而已
具累積性的業障(誤
現實有時間壓力的,根本不給你重修的時間啦XD
沒錯
@lbowlbow 這聽起來有點像是 test gap
這就是為什麼我們需要綠乖乖
寫程式就跟蓋房子一樣 蓋好了要加東西不變成違建太難了
深究下去我相信有點程度的都能理解啦,可是通常有死
限/不只抱著一個案子/沒有餘力調查,總之得過且過能
跑就好,久而久之就不敢動了…
阿就沒時間 '3' 上線後通常也不給翻修了
其實就是怕裡面有bug 再跑一次就又跑不到惹....
有經驗的帶出來的新創公司會好一點,老公司基本上都會有
給新的需求就是繼續蓋上去,時間夠才能修,但不夠就只
忘記save了
這種殭屍級卻還在賣錢的產品
能裝死不管,久了後就變成大型違建...
打從一開始測試就不夠完善又不斷的疊加新需求上去,永遠
乖乖鎮煞
在要垮跟沒垮成之間徘徊的超大型違建
能動就不要再改
擺那邊不會倒就不要動它的意思
就是這麼可怕
說穿了就你unit test跟整合測試做不夠才會這樣啊
你有維護過超過20年的專案就懂了
就是這麼邪門 不然你以為一群理組畢業的幹嘛要拜乖乖
同樣的code 跑同樣的integration test 跑三次結果都不同
碰過的鬼比我看過的鬼片還多
聽說過最鬼的是程式裡面塞一堆sleep跑多線程
然後只要去改數字 整個程式就等著死
如果要說“邪門”,那剛好相反吧,科學研究裡無法掌握
未知的變數壓倒性地多,程式裡大多數都是已知且可操控
的
問題就是沒時間啊 一方面是你改的東西可能被一堆legacy cod
e包住 光是要整理裡面的邏輯就不知道要多久 再來你改掉的東
西如果相依的部分很多 等於要把那些功能全部重測
sleep wait await 全都是必要之惡 動下去就是一整個sprint
小專案就算了,比較大一點真的會出現某些地方動到就
整個爆炸的情況。首先你要有時間去慢慢修,再來還要
看註解夠不夠細不然花費時間會巨幅上升,然後可能發
生回到舊版本仍然卡死的神奇情況。總之別動是最好的
軟體開發是在跟時間賽跑 你有空去分析這問題的root cause
通常就代表這軟體沒在開發了
TDD跟BDD很棒啊 但是上頭不給時間我有什麼辦法==
代表你們的假太少了 我們都在大型休假時狂做BDD
找不到root cause你要怎麼知道bug確實修好了?
我年末年始加起來已經寫了兩個月的BDD了
有沒有確實修好不重要 重點是現在work然後QA也測不出毛病
這聽起來怎麼像是繞過bug
如果沒有user能觸發這個bug 這還能算是bug嗎
這也是programming的哲學問題
這就是user要跟feature妥協到什麼程度了XD
是
大型違建好貼切
其實反過來也通
開個branch愛怎麼改就怎麼改
可以動就不要動
It's not a bug
It's an undocumented feature
不知道為什麼不能跑和不知道為什麼能跑都很危險
能動就放著是真的,就算測試能過也只是測試能過而已,不
大的專案其實難以避免 但看過說這句話的很多都是接
當初demo做的prototype在說不要動 都不知道他們領
薪水來幹什麼吃的
代表真的完全正確
很多事也是一樣的啊,雖然看起來怪怪的,但只要能動就好
4 千萬別動==
prototype改出來的東西更可怕 沒給時間重用的話
重構可以啊 就是吃力不討好
解不掉的bug讓它變成limitation就好(x
還在放假 討論寫code衝
不要不小心按到可怕的全形空格
不止寫程式吧,機器也一樣,不保養沒事,一ㄅㄠ養完
不要探究他為什麼動了
保養完一堆奇怪的事情
全形空格ide會直接跳出錯誤吧
保養東西修改程式會體會到一句話 "東西在壞掉前都是好的"
沒註解看起來更痛苦
碼農日常
是 有時候根本不知道問題出在哪
除了新手之外還有誰會用有全形空格的輸入法寫程式啦!
老闆不會給你時間去整理重構,廠商不會出錢請你重整
自己搞了可能違規,搞不好爆炸就慘了
還遇過全形符號的勒w
反正驗收的都簽收了,出事讓他們回來求你比較實際
如果是接手前輩留下的就要裝死得更徹底,等出事再說
自動自發根本吃力不討好...
區區個碼農是會接觸什麼東西逆
大家是嫌年假太長嗎 現在就在討論這話題
跟麥塊的紅石建築有點像 沒事別亂動
這就是科學家跟工程師的差別
跟綠乖乖ㄧ樣 不要動萬解
真的
If it ain’t broke, don’t fix it
偷偷告訴你寫程式的其實都會魔法
動就是壞
就能跑就對了 不要隨便動
有時候多人開發程式 彼此的條件設定還真的可能不一樣 再
加上機器的規格問題 有時候怕壞掉就真的不要碰了
這就是為什麼電腦手機明明不斷推陳出新但是時間一久就
開始變慢的關係,每一個軟體裡面的程式碼各個堆積如山
,既龐大又笨重,早就已經沒人在乎裡面當初是怎麼運行
的,反正經手的人幾乎就是不斷疊加上去能動就好。這就
是這一行令人詬病的地方。
有時候是因為改別人寫的 或是跟別人合作寫的吧 全部自
己寫的通常不會有問題 除非你自己真的不知道自己在幹
嘛
415樓,大家都是受薪階級,何互相傷害找碴XDD
真的會有不知道自己當初在想什麼的程式碼出現
三個要素決定:時間、錢、老闆
我看完這串開始相信電腦裡住著小精靈了
有時照打一份程式,一個會動一個不會動
是 沒問題就不要動 即使效率很差也不要動
有時候你的bug會被別人當成功能,改掉以後,所有繼承的cod
e都不會動了
產品要趕上線難免會欠技術債
台灣業界:能動的已經量產的了,不要亂改!
科學家不知道 另一部分很寫實
做研究才更邪門….一堆實驗變因要考慮
是 不要不信邪
祖傳三代的Hello world
程式的bug完全是看coder的能力 做實驗尤其生物實驗
還要看你的生物材料的狀況
不就是習慣好壞的問題
可以動啦 反正壞了就git還原
通常有問題的是機器
祖傳程式碼會,你自己寫的不會
如果你不是原作者 前人的垃圾code總是讓人吐血
高階的硬體也一樣...出問題根本是連帶一堆有的沒的,只
能放乖乖保佑
代碼就有不同的寫法能導致同個結果,然後還有些看似無
意義的代碼,你換個碼農或是工程師自己忘記,一改就爆
炸,然後遊戲進維修被客人罵
因為碼農大部分是抄人家寫好的去拼裝車,很少人從頭
自己寫
能正常動就不要亂改,要改git複製一份到虛擬機上改
幹 不好的回憶都上來了
你就算不是拼裝車 也不會所有零件都自己打吧
說程式的bug只看coder能力的是產品沒上過線嗎?
跟綠色乖乖一樣 不能亂動
天啊 這邊討論好溫馨 大家都來吐苦水
沒有高來高去的感覺 XDD
前人有加不知道的sleep千萬不能刪
程式有些細節 就算邏輯對 但有時候就是跑不動 但有時
候會莫名其妙跑對 所以做好不要動為妙
又不可能保證專案一輩子都是同一個人在維護 說理解的
真的每次都能理解嗎
這樣看寫程式的根本就戰鎚40K機械神教
更何況大部分都是拼裝車
不抄人寫好的是要重新做輪子?你自己做的輪子有專業大場
一堆人使用過的安全可靠?
工作有時間壓力很少能給你打磨
對
很多時候程式跑起來不是寫的完美
而是可能生bug的地方沒有觸發
真的 上帝也不知道它怎麼跑起來的
是 沒事別去動 除非有必要 改爆又剛好要用就哭了
你老闆每次都說很急,給你的時間不夠深究疑惑。而且這行
責任制,如果出事你負責,所以除非有排任務處理或你時間
太多,大多時候不動最好
儘管你預想1000種狀況,有時候就是客戶會有神奇的第1
001種狀況觸發到bug,要防都防不了
It just work
其實原po的圖不用講別的行業 講CS科系->軟工就可以了
真的是這樣 謎一般的程式 有時候為什麼會動也不知道
研究所時你有的是時間去深究為什麼work 但也可能會讓你
延畢 或是看你能不能靠一張嘴瞞過口試委員
paper能不能通過conference check 老闆對你的研究夠不夠
另外在我們這一行不可能有人從零開始做完所有東西,我們
使用的語言、工具、library、框架都是經過全民公測的穩
定產品,沒有那個美國時間深究所有我們用到的東西how it
work,所以有了知識盲區,既然有盲區就容易出事還解不
出來,好不容易解了通過測試你也不會想要再來一次
了解透徹 如果是認真拼升等的教授 基本上不會對你放水
但出了社會就不一樣 為什麼work 沒人在意 大家要的是能用
為何不能動-->為何可以動-->可以動,不要動
如果這東西有技術債 那就是繼續疊上去
如果技術債已經炸開 那就宣布破產 重新搞一個比較快
全部換新比較高 不知道前人多少坑
這主要在講傳承龐大原始內容的問題 後面會一直疊加新的內
容進去 所以當某個空降主管腦袋撞到想要改革程式碼的時候
就是碼農準備加班的時候
老闆只在乎程式能不能正常動作而已
跟乖乖鳳梨一樣
對啊
當你寫超過100個class總共超過1萬行時 出了問題大多時候
你不會知道是哪裡的問題的 更可怕的是如果你整個專案有
10個人寫的量都跟你差不多然後這些code要兜在一起 甚至
綠色乖乖不要不信
還有已經離職的人寫的東西 這種東西一戳下去通常很可怕
因為太多沒人知道怎麼回事的地方了 所以碼農最後都是
現在他能動就別戳他別思考為什麼能動 總之他能動就對了
大學別系去參觀過資工某實作類型的課,除了給學生挑戰
寫短、省資源之外還會討論那行短短的程式碼會隱含什
麼表面上沒寫的副作用,舉例看到一小行的副作用搞爛一
串編碼這種絆手絆腳,就對編碼喪失興趣了w
現在軟體產業已經不可能全部手刻了,你一定會用到開源函
式庫,不然你根本不可能做的完你需要的功能
很容易只是動到設定就壞了
用別人的套件就是為了節省時間 不可能還去看函式庫怎
麼實作
幾年前openssl爆出嚴重漏洞,但是你不用難不成要手刻嗎
程式有很多是為了符合客戶邏輯硬幹出來的,來來去去的一
層一層patch出來,這時候就恐怖了。
牽一髮而動全身不是開玩笑的
同個硬體同套code 跑出來結果一定要一樣? 看起來太年
輕了...
是…尤其是公司內流傳千古的code,拆炸彈(o, 做專案(x
是!已經可以用的系統千萬不要想要去改他
光是套件版本就搞死你了,所以正在賺錢的程式碼,除非有團隊
在維護,能不更新就不要更新
連微軟都不敢動自己的程式碼了,都是往上加,W11還看
得到W98以前的遺產
看是不是自己寫的 自己寫的 要怎麼改都可以 要改別人寫的
真的會怕
沒壞千萬不要動。
接那種醜到不行的程式碼就不會想動他了
Win12有傳要把一些上古產物改良,像是explorer.exe
可以想見大概初期會bug連發
有些寫的bug是很難觸發的 你把它拆解反而會讓bug 100趴
觸發
所以才需要很多碼農
能動,就不要動。
呵呵有聽過複製一份跑不動的……聽過而已
邏輯區塊不是不能動只是懶得去動,因為動下去Z>B
應該是B>Z才對
ML或底層那種無法掌握的才會有這種狀況
科學只能發現、無法改造宇宙原理,但程式是所有參與開發
的人內心宇宙的混合體,在如此混沌的宇宙中每次行進都得
小心地邁步、才能確保走在路上而不會跌進深坑
所以窩才愛玩pc油戲 對某款油戲有愛的玩家會免費魔改放到
網路上供大家用
還要加一包綠色乖乖
確實
崩潰 這是真的
4,特別是必須引用的上層物件封包函式或stored proced
ure不是自己寫的時候...
4 vender patch打進來如果突然就動了我就不搬了
4,當初沒有拆開,累積起來後就不敢動了
大自然跟人工造的差別
不一定拉 我們主管一定要我們解釋為什麼這樣寫可以動的
解釋不出來不會讓我們結案
會較真/注重品管的公司偏上面, 財務吃緊/品管差的偏下面.
自己寫的不太會有這種問題啦,但如果是其他人的就 ...
不過軟體又不太喜歡自己造輪胎,遲早會遇到鬼
現在軟體業也講求快速反應快速開發,要不然等你做出來風
潮都過去了
比如現在流行 AI ,兩間公司要做相關產品,一間從底層開
始自己刻,另一間用現成的開源或商業專案延伸,花的時間
差異可不是一二個月,而是一年兩年
後面維護的人太過分了吧哈哈
5樓正解,傳好幾代的code最棘手
別再動它免得它跑不起來
架構寫很大的時候沒有人腦袋能思考的百分之百全面啊,只
要漏考慮到一點東西程式的結果就是你無法預測xD
其實如果能花時間好好地整理一番 應該是可以理解 但是基本
上根本沒時間在那邊慢慢弄==
有時是接手別人寫的,這時就容易有這種情況
最好都不用更新
你知道同樣的hello world 也有可能編譯失敗嗎?
(有限資金 有限時間資源 寫出了)能動的東西 就不要再動了
就單純重做沒多錢弄壞要賠 你一個小員工太無聊才會想檢查
比較多是出事情怪東怪西就是不怪自己啦
幾天前寫的code 幾天後就忘了怎寫的
慘
工作很看產值啦 沒事去動算浪費時間 除非不動的風險更高
電腦也是,清潔一下風扇就開不了機
不是先建立假設才跑實驗,怎麼先跑才想它怎麼跑得動?
能運作就不要手賤亂動它 除非你有自信能夠看透所有編碼能夠
找出問題所在 否則這樣都是自找麻煩
哈 回我的人說的對 有時候太久以前寫的 又沒註解好 自
己也會看不懂 或是專案太大了寫到昏天暗地自己神經錯
亂也都有可能
是 別懷疑 程式碼摳下來重開一個專案都會不能運作
通常徵人的時候都是徵規劃很好的,上班接手的時候專案
大概燒掉公司一半了,離職後公司沒倒的算幸運大概是這
樣
爛code還要加功能 幹
能動就不要對他做任何事 有時候只是不小心更新作業系
統都會出事
是 大部分會遇到的都是把一個看起來不重要的東西拿
掉後就跑不了
是 可以用的話就不要動任何東西
首先你連自己以前寫得都看不懂,除非你記憶力超級好,
或註解寫得言簡意賅
其次改以前的程式的話,先不說改不改得好,至少也要把
code看一遍吧,小程式還好說,那些大到靠北的你怎麼可
能有時間精力去看完
程式碼都不知拜過幾箱乖乖才穩定下來的,菜雞別想亂動,
寫寫註解的註解才是好菜雞
如果一個程式沒有問題就不要再動他
有些寫程式的寫一團垃圾無法處理
學術研究的話寫的code更噁心
在lab抄學長姐code做垃圾研究的廢物研究生就很常這樣
啊,garbage in garbage out.
咦?說實話,我是能working就好,若非一定要來debug就一
定不會動。因為在實務上,一來工作量已經太大,你有空只
想趕快休息;二來我們一定會參考一些其他大神的code,說
實話,既然是大神了,腦子結構跟我這種碼農怎麼會一樣?
!所以有對應效果即可,很多時候都是試錯才找到方案,當
你昏天暗地時,常常根本不知道自己怎麼完成的(難道我也
有一個佐為嗎?XDD)
沒人嗨賴不動
在寫安全驗證系統時,偶爾還會發現bug本身,就是成功運
作的關鍵= =
有個原因是他寫的只是整體的一部分,尤其是開放架構時,
其他部分有多種設備設置。所以有好結果可能也不是這個工
程師能完全掌控的
其實搞懂怎麼運作蠻有趣的,只是沒必要,不如去弄其
他專案
其實總的來說一個系統或專案涉及的層面太多太深,你很難
保證每個人都能吃透所有東西,更別說一些老東西你想回頭
找文件都不見得找得到,要花時間自己下去弄清楚也不是不
行,但前提是得有時間,很多邪門小故事背後的真相就是,
沒時間研究清楚了,現在沒問題就好
程式可以動了但我不知道為什麼.jpg
4 尤其全部正常的程式merge在一起又有可能壞掉
對 最好不要動
修改一個bug可能會連鎖反應引起更多bug 所以能不動就
不動
其實邪門的都是寫的人 而不是code邪門
對…會動就好,效率沒那麼重要
是
其實就是 純學術 vs 商轉應用
程式是今天寫好 大多半年內就會進入 Production
醫學生技等都是五年十年二十年的功夫
涉及生命和健康議題的 也不像程式出 BUG 修就好
只要那怕一點不確定性 要用在人體身上都是不定時炸彈
通常自己興趣驅使的專案 不會有幾十人百人千人的維護者
就比較沒有圖片說的問題
動了如果壞掉還會怪你
誰動誰負責的概念
是但不是
會壞掉的code怎麼敢上線
所以這一串開頭回文全部的ACG點是什麼?吐槽圖也算?
7
嗯 就算你寫的是C/C++ 也已經是「高階語言」 真的要探究 要了解的東西太多太多15
: 1/sqrt(x) 用神秘的數字y=0x5f3759df 帶入: y+y*(1.5-(x*y^2)/2) 後直接算出來 或是:47
畢竟嚴格來說 只有自然科學才是科學 其他學科因為變數太多 很難嚴格的用科學方法來解決問題 反而很多時候都是經驗主義 甚至有些迷信 以寫程式來說 比起科學他反而更接近工程學 工程學很講究實用主義56
: 初五開工 這邊用C++給大家玩一個小遊戲 一個hello world等級的小程式 #include<iostream>8
之前有陣子做實驗趕著出結果 會開好幾個程式同時去跑好幾個不同的數據 但很常隔天起床看就發現電腦當機了 原本以為是工作量太大電腦扛不住 試過加記憶體、重開機、減少數據量4
針對inverse square root 其實回覆提供的文章沒有很好的解釋神秘數字的由來 我認為這部影片講解得很清楚 簡單來說是利用浮點數bit representation與log base 2近似的特性58
? : 其他學科因為變數太多 很難嚴格的用科學方法來解決問題 : 反而很多時候都是經驗主義 甚至有些迷信 : 以寫程式來說 比起科學他反而更接近工程學 : 工程學很講究實用主義7
呃 講這個其實蠻尷尬的 因為綠乖乖是最省錢的解(?)XD 一般來說要提升程式碼品質 一些軟體工程的東西要確實執行9
話說理工科的人 不是最講究實驗跟理論嗎 怎麼問題一出現 沒有辦法的時候 就突然迷信起乖乖起來了4
其實軟體工程品質在許多業界 還是有在要求的 甚至是成為規範跟SOP 像在以下的業界: ‧ 汽車 ‧ 航空航太和國防 ‧ 醫療設備
32
[請益] 代問:如何寫出讓人看不懂的Python程式碼?繼上集, 朋友被指導教授要求給博後論文草稿和實驗程式碼之後, 朋友除了使用推文有建議的拖,慢,等戰術讓博後拿不到, 78博後對我朋友出了新招,29
Re: [心得] 好的註解是解釋為何需要這段 code上週在重構某段程式碼時,其中一位同事在 code review 中建議把某個註解刪掉,另一 個同事看到這個評論時,在下面留了言說他認為不應該刪掉,於是我們就拉了一個小討論 ,聊在程式碼中寫註解這件事。 因為這個經驗,我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書,並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好26
Re: [請益] 工研院好待嗎?關於我在工研院有多慘,常常加班,假日工作,還常常被經理各種語言暴力,可以搜一下10年工研院工作心得分享,或我的id。 再講一些大家看不到的吧: 1.工研院得了很多國際研發獎項,研發很厲害? 基本寫論文的能力是有啦,畢竟一堆博士。但是常上新聞的那些國際獎項,比得不是學術或科學的研發能力,多得是包裝能力,說故事能力。 所以,不要以為得了國際獎項,叫做研發能力好。當年我也是靠寫一篇word,3,4頁的英文故事,完全沒研發,就得到國際科技獎項了,部門還買新聞報導。這跟研發能力沒什麼關係,比投論文還簡單。7
[問卦] 寫程式的算科學家嗎???????????????????欸幹 一般我們講的理工男 其實應該是應用工的吧 純理的像是物理化學 才是科學家對吧5
Re: [問卦] 美術和程式為何差距這麼大?我知道你想戰UI和工程師 UI 美術跟寫程式最大的差別是 一個不是科學 一個是科學 美術在網頁設計有很多理論也很複雜 例如色彩學 字體學 8point grid system7
[馬娘] 我乃狂氣的瘋狂科學家!!我可是狂氣的瘋狂科學家愛麗速子啊!!7
Re: [問卦] 有沒有"科學迷信"的八卦?但是說真的 一堆科學家晚年都有信仰,像是愛迪生,牛頓.... 不過美國物理學家霍金卻是無神論,他認為這世界上根本沒有神 到底該信神? 還是這世界沒有神 到底如何做到神與科學並存?1
[黑特] 請問綠粉,大仁聖騎士的三百萬呢?綠粉的科學燈塔-大仁哥 之前是綠粉的驕傲。 甚至讓綠粉說出了一段話, 「你們可以不相信民進黨,但是請你們相信 善良學者,相信科學家」
爆
[閒聊] 又到了每年的DLsite性癖統計爆
[閒聊] 50嵐在手搖飲界是怎樣的存在☺96
[討論] 有什麼理由讓你玩鳴潮卻不玩原神?84
[閒聊] 有辦法將綠鬣蜥全部移除掉嗎?82
[問題] 棒球有超能力作品嗎?62
[俄語] 艾莉同學是不是就這樣了?爆
[閒聊] 對面的女孩看過來52
[閒聊] 阿含說的隊友全部都同一個人51
[閒聊] 征服者康演員前女友撤銷對他所有告訴49
[鳴潮] 新角色預告 珂萊塔49
Re: [閒聊] 有台灣人集體遇過的都市傳說嗎?45
Re: [閒聊] 中國情境:當買了蜜雪冰城一口未喝就挨刀43
[問題] 食戟之靈 鬼父篇以前有多強?18
[問題] 為什麼女僕普遍是女性?37
[問題] 為什麼男爵普遍是男性39
[閒聊] 鳴潮今天為什麼突然重拳出擊?24
Re: [活俠] 討論-溫夫人的愛恨,南宮淺的身世37
Re: [閒聊] 中國情境:當買了蜜雪冰城一口未喝就挨刀36
[鳴潮] 白毛偷跑立繪34
[閒聊] 霍格華茲的傳承是不是出太早了?36
[閒聊] 必勝客魔物獵人聯名一公尺披薩37
[問題] 老遊戲視窗太小問題有解嗎?49
[閒聊] 快打旋風的春麗,鄉民可以嗎?33
[閒聊] 說到"歌姬"會想到哪些角色?31
[閒聊] 邦邦的棒球表現是不是還不錯啊?49
[討論] 日本吃海產負擔大嗎29
[火影] 鳴人不裝九尾會更強嗎?27
[問題] PTCGP 稀有挑戰稀有在哪47
[鳴潮] 黎那汐塔抽卡規劃閒聊29
Re: [閒聊] 怎麼?你當台灣人當得很難過嗎?