[英]How do you deal with your past programming atrocities?
我們都沒有成為專家（我們大多數人還沒有）。 當然，我們都知道如何用我們喜歡的語言編寫程序，但編寫高質量的應用程序和編寫語法正確的程序是兩回事。 我們工作，學習，努力，不斷學習，最終達到其他人可以向我們學習的門檻。
如果你的學習過程與我的學習過程類似，你可能會寫一些功能齊全，可靠的應用程序，這些應用程序仍然每天都在使用，但每當你想到它們時，都會感到羞愧。 程序代碼？ 混合業務和表示邏輯？ SQL注入漏洞？ 代碼荒蕪荒蕪的任何評論？ 名單還在繼續。
不幸的是，我們都不能指望我們的雇主允許我們回去重寫我們的舊應用程序，因為只要我們想到它們就會給我們做噩夢。 更糟的是，我們中的一些實際與我們的舊應用程序的工作 ，但要知道，這將是太危險的和/或費時做了一大堆的好盡可能重構去。
你如何應對過去曾經犯下的編程暴行，以及那些發現骯臟秘密的人，你並不總是知道自己在做什么？
每當我小時候做一些不太理想的事情時，我的父親會說，“好吧，生活是一種學習經歷。” 我們的應用也可以學習：
在我們的每個應用程序版本中，我們提供了各種變化：
因此，我們逐漸嘗試用第三和第四項替換麻煩的代碼。
有時你可以拋棄你的錯誤。 我認識一位高級開發人員曾經被雇用過一家公司，並被要求生產類似於他為第一家公司所寫的東西，但更好 。 他們給了他工作人員和工具，他做到了 。
我的第一個程序僅存在於TRS-80磁帶上，其中氧化鐵已剝落。 一對夫婦打印出一個7針40列熱點陣打印機，將字母刻在特殊的銀色金屬塗層紙上。 一個夏天，所有那張紙都在閣樓里變黑了。
我覺得我很好。 我最古老的暴行被安全地摧毀了。
實際上，有一個暴行繼續啃着我。 我為Amiga創建了一個名為“ Sliced HAM ”的視頻模式，這種模式很受歡迎。 它改變了每行的基色，以允許更逼真的圖像，更少的邊緣。
我很快寫了一個轉換器和查看器。 在觀察者中，我坐在忙碌的循環中等待用戶關閉圖像。 Amiga是第一個大眾市場多任務計算機系統，這是不可接受的。 我應該等待窗口的關閉事件。
多年來，人們說視頻模式很慢，但它只是我糟糕的示例查看器。 圖形協處理器正在完成每條掃描線的所有工作。
仍然困擾着我。
這是一個很好的問題。
除非您正在編寫開源軟件或者只是將舊代碼轉移到網上，否則我認為這不是一個大問題，因為未來的雇主不會看到您過去的輕率行為。 您也可能不會受到前雇主的約束，他們也不會發布源代碼。
大多數（好的）開發人員會隨着時間的推移而改善，過去的同行會意識到你今天可能比以前更好，就像他們可能更好一樣。 您的雇主根據您的經驗而不是您現在的經驗向您付款，因此他們得到了他們付出的代價。
如果除了你以外的其他人關心你的應用程序並且每天都使用它，那么他們可以自由地維護它（如果他們有源代碼）。 代碼變得陳舊。 沒有得到維護，改進和重新考慮的應用程序要么完美（不太可能），要么不夠重要，不值得付出努力。 如果一位前雇主在沒有維護它的情況下繼續在你的舊應用程序上賺錢，那就是他們的問題和他們客戶的問題，最終現金牛將會枯竭。
如果您覺得您的應用程序被廣泛使用，那么代碼是免費提供的，並且可能會在下一個thedailywtf帖子中顯示某些內容，請繼續修復它。 否則，很高興有足夠的舊平庸代碼，所以你不會引起注意。
我認為更大的問題是我們早年留下的文字廢話 - 舊的論壇帖子，不正確的博客帖子，語言功能的火焰戰爭等等。
也許您所在的組織中您可能有或沒有機會糾正過去的錯誤。
你可以做的就是記得保持謙虛，樂於助人的人誰現在在哪里，你曾經是一個階段。
這比以前更加困擾我。 我已經認識到它只是開發過程的一部分。 沒有人從第1天開始（甚至現在就開始）編寫完美的代碼。鑒於您當時擁有的技術和資源，您編寫的代碼很多時候已經足夠了。 將您在10年前編寫的代碼與1周的截止日期與當前使用當前技術和技能組合的代碼進行比較是不公平的（對於您或其他任何人）。
我公開道歉。 我想借此機會為INewWindowManager道歉。 抱歉。
如果沒有損壞，請不要修理它。
我知道可以更簡單，更優雅地完成某些事情的感覺，也許是因為你現在更好地理解了框架，或者因為你學到了一些新技術。 但是，當你想要擴展或改變一些代碼時，這才真正有用，否則只要它運行就讓它運行。 如果它不工作 （即如果它是越野車，速度太慢，吃資源等），你仍然應該修復它開始，因此有一點遺憾，只是還沒有。 否則，你還在擔心什么？ 代碼之美是如此短暫......; o）
從另一個角度來看，如果你進入其他人的代碼，甚至是你自己的舊代碼，你不應該對找到次優代碼感到驚訝。 我們都這樣做。 事實上，當你成功地重構舊代碼時，這是一個讓自己變得沾沾自喜並扮演英雄的機會。
非最佳代碼只是工作的一部分。 我們應該期待它遍布每個角落，並且在我們需要觸摸時始終准備重構舊代碼。 如果管理層不了解它並且不允許你有時間這樣做，這只是一個問題。
鑒於工作仍然存在，你仍然有機會提交新的東西，修復廢話並檢查！ 修復錯誤永遠不會太晚。 並沒有什么可尷尬的。 每個人都會犯錯誤。
我也相信誠實，好的進攻是最好的防守。 只是大聲說，“這是我的代碼，它是廢話”，人們會和你一起笑:)沒有必要嘗試隱藏你的代碼。 它在您的VCS中，無論如何都有您的名字。
編碼器有一項新服務： 錯誤代碼偏移 。 支付以彌補過去的編程暴行......
處理這些不良記憶的最好方法是向他們學習，我相信你已經有了。 當您向團隊成員請求寬恕時，同樣重要的是，這也很重要。 最重要的是，當你指導團隊的初級成員時，你應該記住這些“壞榜樣”。
它可以是一種平衡的行為。 我一直被“改進”一些正在運行的代碼所困擾，但我認為這很難看，並引入了一些愚蠢的新bug。
另一方面，在我職業生涯中的幾次，我一直在努力設計一些設計糟糕的垃圾代碼（由我或其他人編寫） - 有時會持續數周 - 因為我覺得我沒有時間修復它。
在每一種情況下，我終於咬緊牙關並再次正確地完成它，問題幾乎立即消失了。 然后我希望我早點修好它 - 從長遠來看會更快。
把你的精力集中在給你實際悲傷的部分 - 你需要處理的部分（新功能，錯誤修復），但你害怕因為它們太脆弱或太可怕而觸摸。
這可能是一個很好的指標 - 你越害怕它，就越需要修復它。
-Tom Bushell
我在網上匿名發布，讓別人受苦！ 不用等了，我在我的博客上做了，可能會被同行嘲笑。
我確保我先備份舊的東西，“以防萬一我不像我想的那樣聰明”，“如果我像我想的那樣聰明，我就能證明這一點！” :)
您是否經常需要在日常編程中創建真正的類層次結構？
[英]How often do you need to create a real class hierarchy in your day to day programming?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
