對於Web開發中要注意的18個關鍵性錯誤

前幾年,我有機會能參與一些有趣的項目,並且獨立完成開發、升級、重構以及新功能的開發等工作。
 
  本文總結了一些 PHP 程序員在 Web 開發中經常忽略的關鍵錯誤,尤其是在處理中大型的項目上問題更爲突出。典型的錯誤表現在不能很好區分各種開發環境和沒有使用緩存和備份等。
 
  下面以 PHP 爲例,但是其核心思想對每一個 Web 程序員都是適用的。
 
  應用程序級別的錯誤
 
  1、在開發階段關閉了錯誤報告

 

    我唯一想問的是:爲什麼?爲什麼在開發的時候要關閉錯誤報告?

 

  PHP 有很多級別的錯誤報告,在開發階段我們必須將它們全部開啓。

 

  如果你覺得錯誤不會發生,那麼你把程序太理想化了,在現實世界中,錯誤是必然的。error_reporting 和 display_error 是兩個完全不同的方法,error_reporting ()設置了錯誤的級別,而 display_errors 則是設置錯誤信息是否要被輸出。

 

  在開發階段,錯誤報告的級別應該設置成最高的,比如以下設置: error_reporting (E_ALL);以及 ini_set (‘display_errors’, true);

 

  2、淹沒錯誤

 

  和上一點相反,很多程序員喜歡將錯誤淹沒了,你明知道錯誤會發生,但是你選擇將錯誤隱藏掉,然後可以早早回家睡大覺,殊不知將來會發生更嚴重的錯誤。

 

  3、代碼中任何地方都沒有使用日誌

 

  軟件開發的一開始你就要牢記使用日誌,不能到項目結束了纔去彌補日誌功能。很多程序員都會用這樣或那樣的手段進行日誌記錄,但是很少有人能真正用日誌來記錄異常信息,試問一個沒有人查看的日誌系統有什麼用?

 

  4、沒有使用緩存

 

  在的應用系統中,我們可以在多個系統層次上使用緩存,比如在服務端、應用端和數據庫端等。和日誌一樣,緩存也應該在一開始就應用到系統中去,你可以在開發階段禁用緩存,等到了產品發佈後再將緩存開啓。

 

  5、丟棄了最佳實踐和設計模式

 

  你看到過多少人使用自己的密碼加密算法?很遺憾的告訴你,有很多,因爲他們認爲將更瞭解它。

 

  最好的實踐方式和設計模式已經由前輩創建了,這往往比你自己再造一個輪子要來的簡單奏效,我們開發者只需要熟練掌握這些設計模式並且合理地應用在項目中即可,比如一些加密算法。

 

  6、沒有使用自動化測試

 

  在每一個 Web 項目中都會使用到測試,就像日誌一樣,如果沒有人管理和使用,那麼測試也是一無是處的。

 

  運行測試工程是一項枯燥乏味的工作,幸好有一系列工具幫助我們實現自動化測試。在 PHP 開發中,有一款很好的測試工具叫 Jenkins,使用起來非常方便。

 

  7、沒有做代碼審查

 

  在團隊中工作是一項非常大的挑戰,因爲每一個成員都有自己不同的工作習慣和方式,如果沒有良好的規範,那麼項目開發就會走很多彎路。

 

  團隊中的每一個成員都應該互相審查代碼,就像單元測試,它可以幫助項目變得更加乾淨和一致性。

 

  8、編程只考慮理想情況

 

  你是否遇到過自己或者別人的代碼在交到客戶手中後經常出問題,甚至是亂套了?我當然沒有。

 

  出現這種情況往往是因爲開發者懶惰了,只考慮了理想情況,這會導致數據庫崩潰了、PHP 發生致命錯誤、甚至是服務器被黑。程序員在寫代碼時不僅要考慮最理想的情況,更要考慮最壞的情況,思考全面,才能讓代碼覆蓋所有的情況。

 

  9、沒有正確運用面向對象編程的思想

 

  大部分 PHP 初學者都不會再其代碼中運用面向對象的思想,因爲這個概念在剛開始的時候很難理解。

 

  當然面向對象的概念並不是簡單地將一些類組織在一起。

 

  對象、屬性、方法、繼承和封裝等都是 OOP 中最基本的概念,開發者正確使用了面向對象設計模式後,就有能力寫出更乾淨、更有擴展性的代碼了。

 

  10、“飛行模式”(On-the-fly)編程

 

  大部分開發者都會遇到這樣的情況:“快,客戶需要一項新功能,要能運行 ASAP”,於是你就在源代碼上新增一些功能,然後直接上傳到正在運行的服務器上,這種編程方式我們稱其爲“飛行模式”(On-the-fly)編程。

 

  我們在開發軟件時,尤其是中大型的項目,都必須按照工作流程來進行分析、編程和發佈,這將大大減少未來軟件的 bug。這種“飛行模式”並不可取。

 

  數據庫級別的錯誤

 

  11、沒有將數據庫讀寫分離

 

  爲了能長時間運行復雜的系統,每一個程序員都應該考慮到系統的可擴展性,系統 99% 的時間都不需要考慮擴展,因爲並沒有如此大的流量。

 

  爲什麼要數據庫讀寫分離?

 

  在每一個系統中,數據庫將會是第一個出現的瓶頸,在大流量的衝擊下,數據庫很可能將會是第一個陣亡的。所以大部分情況下我們會用多個數據庫來分散流量,開發者經常會使用 Master – Slave 模式或者 Master – Master 模式。Master – Slave 是最受歡迎的一種數據庫分壓模式,它會將指定的 select 語句路由到每一個 Slave 服務器,這樣 Master 服務器的壓力會減輕不少。

 

  12、代碼只能連接到一個數據庫

 

  這和上一個錯誤非常像,但是開發者有時候因爲某些原因需要連接到多個數據庫,比如你會將用戶日誌、活動信息流、實時數據分析等高負載的數據放到不同的數據庫中來緩解對主數據庫的壓力。

 

  13、沒有檢測數據庫漏洞

 

  如果你不對數據庫進行漏洞檢測,就相當於給大部分黑客敞開了服務器的大門。

 

  在衆多漏洞中,數據庫漏洞是最脆弱的,最常見的就是 SQL 注入。因此定期做數據庫漏洞檢測還是很有必要的。

 

  14、數據表不建索引

 

  索引在數據表中有着非常重要的作用,合適的索引可以提高每張表的性能,這裏有一篇文章就講述瞭如何創建索引以及何時創建索引。

 

  15、沒有使用事務機制

 

  數據完整性對 Web 系統非常重要,如果數據一致性發生錯誤,那麼整個系統都會崩潰並且難以修復。合理地運用數據庫的事務機制將有效地解決這個問題。比如你要保存用戶數據,在 table1 中有e-mail, username 和 password,table2 中有 first name, last name,和 gender age。我們可以利用事務對兩張表更新時保證數據同時被更新或者同時不被更新。

 

  16、沒有加密敏感數據

 

  對於數據庫中的敏感信息,如果你不對它們進行加密,或者用簡單的算法進行加密,那麼在 2014 年你肯定會遇到一些麻煩的問題,黑客們一旦入侵你的數據庫,用戶的密碼或者其他重要信息就會一覽無餘。

 

  PHP5.5 中提供了一個哈希加密方法,使用如下:

 

 

$hash = password_hash ( $password, PASSWORD_BCRYPT );

 

  17、沒有備份

 

  看到下面這張圖片沒,如果遇到這樣的情況,你又沒有備份,那麼一切都 over 了。

 

  18、沒有監控

 

  沒有監控,你將不知道接下來會發生什麼事情,對於監控,要注意以下幾個問題:

•有多少人可以直接訪問這個應用服務?

•服務器是否在高負載下運行?

•我們需要用另一臺數據庫服務器來擴展系統嗎?

•應用系統的失敗點在哪裏?

•系統目前正處於離線狀態嗎?

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章