桂林職場問答

程序員在桂林都有過哪些崩潰的瞬間？

18*******60
2022-04-05
3個回答
77人關(guān)注

全部回答已有 3人回答

19*******67 2022-04-05

說到程序員，在外界眼里，他們是掌控代碼的大神，他們是改變世界的王者。其實程序員的工作不容易程序員其實很容易崩潰的，只是一般大家看不出來。他們每天看似坐在那里編程，不悲不喜，情緒穩(wěn)定，其實他們可能正在經(jīng)歷著某種崩潰。之所以不發(fā)出聲音，因為他們都是跟機器生氣，而不是跟人。當然，你可能說他們還跟產(chǎn)品經(jīng)理慪氣——不，在程序員眼里，產(chǎn)品經(jīng)理不是人。程序員們可能經(jīng)歷的崩潰很多，其中主要包括以下這些瞬間

作者：貓貓姐姐
鏈接：https://www.zhihu.com/question/483939272/answer/2139009821
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
13*******33 2022-04-05

還是上面的這個項目，老的.net項目，被領導要求用.netcore重構(gòu)一遍，理由是公司要慢慢不用Windows Server了，用Linux的，我感覺就是高層領導拍腦袋搞出來的想法。沒辦法，人在屋檐下不得不低頭，我把里面的模塊全部用.netcore重新構(gòu)建了一遍，不過主要是把不兼容的地方改一下，業(yè)務基本沒啥變化。好不容易上線了，內(nèi)存泄漏了，跑一晚上內(nèi)存飆升，我當時一個應屆生也沒啥線上處理問題的經(jīng)驗，所以先找部門里的人，最無語的事情來了，部門里沒啥人懂.netcore的這類問題，問就跟我說“重啟試試，多看看代碼巴拉巴拉”，在內(nèi)網(wǎng)也沒啥有用的帖子，我這時候才知道我可能就是來背鍋的，重構(gòu)效果好領導的功勞，沒重構(gòu)好出了問題我背鍋，都對這技術(shù)棧沒本質(zhì)的了解的情況下就轉(zhuǎn)在我看來是一件很荒謬的事情，不過也怪我事先沒了解部門情況。最后我硬著頭皮按著微軟官方工具來查dump，每天加班一點一點來找，最后找到是一個前人封裝的模塊的代碼問題，不過我也沒替他擦屁股，晾那里不久離職了。

作者：Eureka
鏈接：https://www.zhihu.com/question/483939272/answer/2192661898
來源：知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
19*******01 2022-04-05

都是在維護老代碼的時候。第一次，在一個老項目里加一個接口，有多老呢，我看代碼注釋的時間是寫的2011年，整個項目的所有邏輯都是寫在存儲過程里，里面批量保存的接口是將實體類拼成XML形式的字符串，然后在存儲過程里解析XML再批量保存。當時接手的時候看得我人傻了。我的需求也是實現(xiàn)一個批量保存的接口，但是由于和里面有些老業(yè)務有交叉，我要改動里面的老存儲過程，結(jié)果不看不知道，一看嚇一跳，那個存儲過程足足有將近1000行，存儲過程的創(chuàng)建時間是2012年，里面各種臨時表，就是SqlServer的tmpdb里的那種臨時表，從一個取出來存到另一個去，刪這個更新那個，我光捋清楚這存儲過程的邏輯就花了我一個下午，我都不敢在上面加我自己的代碼，最崩潰的是存儲過程對調(diào)試非常不友好，只能靠在存儲過程里打print來驗證自己的邏輯對不對。