如果您需要更好的證據來證明代碼是藝術，那麼別無所求，就像程式設計師如何看待他們的錯誤一樣。正如世界上充滿著對畫家，建築師，作家和詩人的意見分歧一樣，程式設計師的領域也無法就代碼不會崩潰的要求達成共識。即使是這樣。只要代碼能夠在用戶注意到之前正常恢復，某些方法就可以解決失敗的代碼。
辯論通常源於經驗。當開發人員說不做X時，這可能是因為某個晚上，周末甚至春季假期被破壞了，因為辦公室周圍的某人做了X並且失敗很嚴重。X在當時似乎是個好主意，但它是一個理智的陷阱，現在倖存者希望就此向世界發出警告。
[ 同樣在InfoWorld上：我們暗戀的10種不良編程習慣 ]
當執行與X相反的操作（稱為Y）時，通常也會出現此問題，它也有自己的故障模式。另一個開發人員團隊通過選擇Y避開了X陷阱，但是後來他們陷入了自己失去頭髮拉扯和咬緊牙齒的周末。現在，他們所有的眼淚都被煮成苦酒，然後推向所有客人。當您訪問，你必須突突它，而不是高喊「乾杯」，「斯科爾」或「 Nostrovia， 」你可能會說，「功能性」或「無伺服器」或「拉姆達」明智的選擇，年輕的學徒。條款改變了。
[ 想要提升您的科技職業？這個全面的在線課程教您如何。]
是否有希望統一X和Y？也許不在同一個開發團隊中，但是在您的腦海中。沒有理由不能從兩個團隊的錯誤中吸取教訓。涅ni的最佳途徑通常是中間途徑。您可以借鑑X和Y的經驗教訓，使您的代碼遠離引起嚴重痛苦的問題。
在下面，您會發現最常見的編程陷阱，每個陷阱都有相對的對，這進一步證明了編程實際上可能正在轉變為一門藝術，這需要熟練的手和富有創造力的頭腦才能在兩者之間取得快樂。有問題的極端。
目錄
- 編程錯誤1：快速而隨意地播放
- 編程錯誤2：過度使用細節
- 編程錯誤之三：不簡化控制
- 編程錯誤之四：委派過多的框架
- 編程錯誤5：信任客戶端
顯示更多
編程錯誤1：快速而隨意地播放
不加強基礎知識是削弱代碼的最簡單方法。通常，這意味著忽略任意用戶行為將如何影響您的程序。零輸入會進入除法運算嗎？提交的文字長度正確嗎？日期格式是否經過審查？用戶名是否已針對資料庫進行了驗證？在最小的地方出現錯誤會導致軟體出現故障。
一些開發人員利用代碼的錯誤捕獲功能來掩蓋這些故障。對於所有可能的異常，他們用一大筆錢包裝了整個堆棧。他們將錯誤轉儲到日誌文件中，返回錯誤代碼，然後讓其他人處理該問題。
編程錯誤2：過度使用細節
另一方面，過於固定的軟體可能會減慢爬行速度。檢查一些空指針可能並沒有多大區別，但是某些軟體編寫得像強迫症，必須檢查門一次又一次地鎖上，以使睡眠永遠不會發生。
如果強迫檢查需要通過網絡與遙遠的網站進行通信，那麼對細節的不懈投入甚至可以鎖定軟體。如果我在沒有Wi-Fi連接的筆記本電腦上啟動它們，我有幾個軟體包會緩慢抓取，因為它們瘋狂地試圖打電話回家以查看是否有新版本可用。Wi-Fi LED閃爍，並且軟體掛起，不斷尋找不存在的熱點。
挑戰在於設計代碼層以在數據首次出現時檢查數據，但這說起來容易做起來難。如果有多個開發人員在一個庫上工作，或者即使只有一個開發人員完成所有編碼，則很難記住是否以及何時檢查了指針。
編程錯誤之三：不簡化控制
開發人員常常不簡化代碼中的任務控制而引發災難。
OtherInBox.com的聯合創始人之一Mike Subelsky堅決主張在每個工作的代碼中只有一個地方。如果有兩個地方，則賠率是某人會改變一個，但另一個不會。如果多於兩個，則有人無法使他們全部以相同的方式工作的可能性會更大。
Subelsky說：「在一個代碼庫上工作了三年多，我最大的遺憾是沒有使代碼更具模塊化。」 「我已經學會了為什麼單一責任原則如此重要的艱難方法。我在新代碼中堅持使用它，這是重構舊代碼時我要攻擊的第一件事。」
[ 也在InfoWorld上：10個軟體開發崇拜者加入 ]
如您所料，Subelsky是Ruby on Rails程式設計師。該框架通過假設軟體的大多數結構會落入眾所周知的模式來鼓勵精益代碼，這是Rails程式設計師經常總結為「約定而不是配置」的理念。該軟體假定，如果有人創建Name具有兩個欄位的類型的對象first並且last，就應該立即創建一個名為資料庫表Name有兩列，first和last。名稱僅在一個位置指定，避免了由於某些人無法使所有配置層保持同步而可能出現的任何問題。
編程錯誤之四：委派過多的框架
有時，魔術工具只會導致混亂。通過抽象化功能並假設我們想要的是什麼，框架常常會使開發人員因代碼中的錯誤而蒙受損失。
G. Blake Meike是西雅圖附近的一名程式設計師，是許多開發人員之一，他們發現過度依賴自動化工具（如Ruby on Rails）在生成乾淨代碼時會遇到障礙。
「從定義上說，公約是超出規範的，」 Meike說。「例如，除非您了解Ruby on Rails的將URL轉換為方法調用的規則，否則，您根本無法弄清響應查詢後實際會發生什麼。」
他發現閱讀代碼通常意味著要緊緊閱讀手冊，以破譯代碼在背後的所作所為。
「這些規則雖然很合理，但並非完全無關緊要。為了使用Ruby on Rails應用程式，您只需要了解它們即可。隨著應用程式的發展，它越來越依賴於外部知識中幾乎所有這些瑣碎的部分。最終，所有幾乎平凡的比特之和絕對不是平凡的。這是整個生態圈，您必須學習在應用程式上進行操作並在調試時記住這些內容，」他說。
更糟糕的是，這些框架通常會讓您以及所有跟隨您的人陷入難以理解，修改或擴展的漂亮代碼的困擾。
正如另一位程式設計師邁克·莫頓（Mike Morton）解釋的那樣：「他們用轎廂椅子將您90％的行程帶上山，但僅此而已。如果您想完成最後10％的任務，則需要提前考慮並帶來氧氣和岩釘。」
編程錯誤5：信任客戶端
當開發人員認為客戶端設備將做正確的事情時，就會出現許多最嚴重的安全錯誤。例如，為在瀏覽器中運行而編寫的代碼可以由瀏覽器重寫以執行任何任意操作。如果開發人員未仔細檢查返回的所有數據，則可能會出錯。
最簡單的攻擊之一是基於這樣的事實，即某些程式設計師只是將客戶端的數據傳遞給資料庫，這一過程運行良好，直到客戶端決定發送SQL而不是有效的答案。如果網站要求輸入用戶名並將其添加到查詢中，則攻擊者可能會鍵入name x; DROP TABLE users;。資料庫忠實地假定名稱為x，然後繼續執行下一個命令，刪除填充了所有用戶的表。
聰明的人還有許多其他方法可以濫用伺服器的信任。網絡民意測驗是注入偏見的邀請。緩衝區溢出仍然是破壞軟體的最簡單方法之一。
更糟的是，當三個或四個看似良性的漏洞連結在一起時，可能會出現嚴重的安全漏洞。假定目錄權限足以停止任何隨意的寫入，一個程式設計師可以讓客戶端寫入文件。另一個可能會打開權限只是為了解決一些隨機錯誤。獨自一人沒有麻煩，但是在一起，這些編碼決策可以將對客戶端的任意訪問權移交給其他人。
編程錯誤之六：對客戶的信任不足
有時，過多的安全性可能反常導致漏洞。就在幾天前，有人告訴我解決特定軟體問題的方法只是訪問chmod 777目錄及其中的所有內容。太多的安全性最終使整個工作陷入困境，從而使開發人員只能放寬要求以保持流程正常運行。
Web表單是另一個可以長期保存信任的戰場。銀行級的安全性，冗長的個人數據問卷調查表以及確認電子郵件地址不僅使人們不敢參與甚至與八卦相關的網站，而且一旦數據被收集和存儲起來就必須保護這些數據，其所帶來的麻煩遠遠超過其價值。
[ 同樣在InfoWorld上：程式設計師自言自語的9個謊言 ]
因此，許多Web開發人員都在尋求儘可能降低安全性，不僅使人們易於使用其產品，而且還使他們免於保護超過設置所需的最小數據量的麻煩。一個帳戶。
我的書《半透明的資料庫》介紹了資料庫在提供相同服務時可以存儲較少信息的多種方法。在某些情況下，這些解決方案將在不存儲任何可讀內容的情況下起作用。
編程錯誤之七：過分依賴魔術盒
擔心安全性？只需添加一些密碼即可。希望備份資料庫？只需按下自動複製按鈕即可。不用擔心 推銷員說：「這行得通。」
電腦程式員是幸運的。畢竟，計算機科學家一直在創建充滿無窮選項的出色庫，以修復導致我們代碼失敗的問題。唯一的問題是，我們可以輕鬆利用其他人的工作還可以隱藏複雜的問題，這些問題掩蓋了我們的代碼，或者更糟的是，在我們的代碼中引入了新的陷阱。
密碼學是這裡薄弱環節的主要根源，《軟體安全的24個致命罪過：編程缺陷和解決方法》的合著者約翰·維埃加（John Viega）說。太多的程式設計師認為他們可以連結到加密庫，按一下按鈕，並擁有強大的安全性。
但是現實是，這些魔術算法中的許多算法都有細微的弱點，而要避免這些弱點，需要學習的內容比手冊的「快速入門」部分中的內容還要多。更糟糕的是，只要知道超越「快速入門」部分的範圍，便會具備「快速入門」部分所涵蓋的知識水平，這可能就是為什麼許多程式設計師將代碼安全性委託給「快速入門」部分中的原因的原因。第一名。正如哲學教授所說：「你不知道自己不知道什麼。」
編程錯誤八：重新發明輪子
再說一遍，製作酸奶，宰殺自己的豬，編寫自己的庫，只是因為您認為自己知道一種更好的編碼方法會再次困擾您。
Viega說：「您自己的加密技術是攻擊者的歡迎之舉，」 Viega指出，即使是專家，在試圖阻止他人發現和利用其系統中的弱點時也會犯錯。
那麼，您信任誰？您自己或所謂的專家還會犯錯誤嗎？
答案落在風險管理領域。許多庫並不需要是完美的，因此抓住魔術盒比編寫自己的代碼更好。該庫包含一組編寫和優化的例程。它們可能會犯錯誤，但是更大的過程可以消除許多錯誤。
編程錯誤9：關閉源
對於任何公司而言，最棘手的挑戰之一就是確定與使用該軟體的人員共享多少。
最早的開源軟體公司之一Cygnus Solutions的聯合創始人John Gilmore說，不分發代碼的決定不利於該代碼的完整性，這是不鼓勵創新，最重要的是發現和發現和阻止惡意軟體的最簡單方法之一。修復錯誤。
「打開代碼的實際結果是，您從未聽說過的人會為您的軟體做出改進，」 Gilmore說。「他們會發現錯誤並嘗試修復它們；他們將添加功能；他們將改善文檔。即使他們的改進是業餘完成的，您幾分鐘的思考也會常常顯示出一種更和諧的方式來實現類似的結果。」
[ 同樣在InfoWorld上：即使是經驗豐富的開發人員，也會犯15個菜鳥錯誤 ]
優勢更深。當其他人重新編譯程序並將其移至其他平台時，代碼本身通常會變得更具模塊化和結構化。僅僅打開代碼會迫使您使信息更易於訪問，易於理解，從而變得更好。當我們進行細微調整以共享代碼時，它們會將結果反饋回代碼庫。
編程錯誤10：假設開放是萬能的
數以百萬計的開源項目已經啟動，只有極少數的項目吸引了不止幾個人來幫助維護，修改或擴展代碼。換句話說，WP Kinsella的「如果您建造它，它們就會來」並不總是能產生實際結果。
儘管開放性可以使其他人參與進來並改善您的代碼，但開放性這一事實並不會起到太大作用，除非有其他動機促使外部貢獻者投入工作。開源擁護者的熱情可能會使一些開發人員看不到這樣的現實，即僅憑開放並不能防止安全漏洞，避免崩潰或使一堆未完成的代碼本來就有用。人們還有其他事情要做，公開的代碼必須與遠足，家庭，酒吧和有薪工作競爭。
打開項目也可能增加通信和文檔編制的新開銷。一個封閉的源項目需要為用戶提供可靠的文檔，但是一個良好的開放源項目也需要API和路線圖的大量文檔，以供將來開發。這項額外的工作可以為大型項目帶來回報，但可以減輕小型項目的負擔。
經常在GitHub上發布某些時間有效的代碼，希望魔術精靈停止製造鞋子並急於啟動編譯器-這一決定可能使項目的動力在真正啟動之前就脫軌了。
開放項目還可以剝奪財政支持，並鼓勵一種暴民統治。許多開源公司試圖在其控制中保留一些專有功能。這給了他們一些槓桿作用，使人們可以支付支持核心開發團隊的費用。與付費程式設計師相比，更多地依賴志願者的項目常常發現志願者是不可預測的。儘管廣泛的競爭和創造力可以產生巨大的成果，但有些人卻逃到了結構，等級制度和權威支持有條不紊的發展的地方。
編程錯誤11：遵循過多的流行創意
趨勢通常始於解決一些棘手問題的好計劃。如果我們可以使用新的語言，框架或庫集合重寫代碼，則可以消除這種麻煩。該計劃通常會結出一些果實。問題不在於重寫代碼的代價（儘管通常是很大的），而是向新範式的轉移，這通常會留下故障模式的鏡像。用陽代替陰。
如果您需要做任何實質性的事情，問題就會變得更加嚴重。許多最新的想法和框架僅提供重要的功能。尚未編寫其他所有內容。當然，您將為準備就緒的功能保存一些工作，但是您通常會編寫更多的粘合，背景或填充代碼。站在最前沿是艱巨的工作。
編程錯誤之十二：忽視太多的時尚創意
輕易將愚蠢的，可愛的或巧妙的新代碼視作愚蠢或反覆無常的虛榮項目。很多時候，你是對的。但是有時您會錯，然後醒來看一堆無可救藥的代碼。
首先，您可以通過專注於代碼仍在運行這一事實來進行自我安慰。即使是過時的代碼也可以在一段時間內成功運行。但是，最終，點點滴滴將開始失敗，並且您將沒有簡單的選擇。也許某些API將被關閉而不留下轉發地址。也許合作夥伴將停止獲取XML文件，而您將被迫啟動一個崩潰編碼項目以生成YAML或GraphQL結果。