英文原文:18 Critical Oversights in Web Development
我唯一想問的是:為什么?為什么在開發(fā)的時(shí)候要關(guān)閉錯(cuò)誤報(bào)告?
PHP 有很多級別的錯(cuò)誤報(bào)告,在開發(fā)階段我們必須將它們?nèi)块_啟。
如果你覺得錯(cuò)誤不會發(fā)生,那么你把程序太理想化了,在現(xiàn)實(shí)世界中,錯(cuò)誤是必然的。error_reporting 和 display_error 是兩個(gè)完全不同的方法,error_reporting ()設(shè)置了錯(cuò)誤的級別,而 display_errors 則是設(shè)置錯(cuò)誤信息是否要被輸出。
在開發(fā)階段,錯(cuò)誤報(bào)告的級別應(yīng)該設(shè)置成最高的,比如以下設(shè)置: error_reporting (E_ALL);以及 ini_set (‘display_errors’, true);
2、淹沒錯(cuò)誤
和上一點(diǎn)相反,很多程序員喜歡將錯(cuò)誤淹沒了,你明知道錯(cuò)誤會發(fā)生,但是你選擇將錯(cuò)誤隱藏掉,然后可以早早回家睡大覺,殊不知將來會發(fā)生更嚴(yán)重的錯(cuò)誤。
3、代碼中任何地方都沒有使用日志
軟件開發(fā)的一開始你就要牢記使用日志,不能到項(xiàng)目結(jié)束了才去彌補(bǔ)日志功能。很多程序員都會用這樣或那樣的手段進(jìn)行日志記錄,但是很少有人能真正用日志來記錄異常信息,試問一個(gè)沒有人查看的日志系統(tǒng)有什么用?
4、沒有使用緩存
在的應(yīng)用系統(tǒng)中,我們可以在多個(gè)系統(tǒng)層次上使用緩存,比如在服務(wù)端、應(yīng)用端和數(shù)據(jù)庫端等。和日志一樣,緩存也應(yīng)該在一開始就應(yīng)用到系統(tǒng)中去,你可以在開發(fā)階段禁用緩存,等到了產(chǎn)品發(fā)布后再將緩存開啟。
5、丟棄了最佳實(shí)踐和設(shè)計(jì)模式
你看到過多少人使用自己的密碼加密算法?很遺憾的告訴你,有很多,因?yàn)樗麄冋J(rèn)為將更了解它。
最好的實(shí)踐方式和設(shè)計(jì)模式已經(jīng)由前輩創(chuàng)建了,這往往比你自己再造一個(gè)輪子要來的簡單奏效,我們開發(fā)者只需要熟練掌握這些設(shè)計(jì)模式并且合理地應(yīng)用在項(xiàng)目中即可,比如一些加密算法。
6、沒有使用自動(dòng)化測試
在每一個(gè) Web 項(xiàng)目中都會使用到測試,就像日志一樣,如果沒有人管理和使用,那么測試也是一無是處的。
運(yùn)行測試工程是一項(xiàng)枯燥乏味的工作,幸好有一系列工具幫助我們實(shí)現(xiàn)自動(dòng)化測試。在 PHP 開發(fā)中,有一款很好的測試工具叫 Jenkins,使用起來非常方便。
7、沒有做代碼審查
在團(tuán)隊(duì)中工作是一項(xiàng)非常大的挑戰(zhàn),因?yàn)槊恳粋€(gè)成員都有自己不同的工作習(xí)慣和方式,如果沒有良好的規(guī)范,那么項(xiàng)目開發(fā)就會走很多彎路。
團(tuán)隊(duì)中的每一個(gè)成員都應(yīng)該互相審查代碼,就像單元測試,它可以幫助項(xiàng)目變得更加干凈和一致性。
8、編程只考慮理想情況
你是否遇到過自己或者別人的代碼在交到客戶手中后經(jīng)常出問題,甚至是亂套了?我當(dāng)然沒有。
出現(xiàn)這種情況往往是因?yàn)殚_發(fā)者懶惰了,只考慮了理想情況,這會導(dǎo)致數(shù)據(jù)庫崩潰了、PHP 發(fā)生致命錯(cuò)誤、甚至是服務(wù)器被黑。程序員在寫代碼時(shí)不僅要考慮最理想的情況,更要考慮最壞的情況,思考全面,才能讓代碼覆蓋所有的情況。
9、沒有正確運(yùn)用面向?qū)ο缶幊痰乃枷?/b>
大部分 PHP 初學(xué)者都不會再其代碼中運(yùn)用面向?qū)ο蟮乃枷耄驗(yàn)檫@個(gè)概念在剛開始的時(shí)候很難理解。
當(dāng)然面向?qū)ο蟮母拍畈⒉皇呛唵蔚貙⒁恍╊惤M織在一起。
對象、屬性、方法、繼承和封裝等都是 OOP 中最基本的概念,開發(fā)者正確使用了面向?qū)ο笤O(shè)計(jì)模式后,就有能力寫出更干凈、更有擴(kuò)展性的代碼了。
10、“飛行模式”(On-the-fly)編程
大部分開發(fā)者都會遇到這樣的情況:“快,客戶需要一項(xiàng)新功能,要能運(yùn)行 ASAP”,于是你就在源代碼上新增一些功能,然后直接上傳到正在運(yùn)行的服務(wù)器上,這種編程方式我們稱其為“飛行模式”(On-the-fly)編程。
我們在開發(fā)軟件時(shí),尤其是中大型的項(xiàng)目,都必須按照工作流程來進(jìn)行分析、編程和發(fā)布,這將大大減少未來軟件的 bug。這種“飛行模式”并不可取。
數(shù)據(jù)庫級別的錯(cuò)誤
11、沒有將數(shù)據(jù)庫讀寫分離
為了能長時(shí)間運(yùn)行復(fù)雜的系統(tǒng),每一個(gè)程序員都應(yīng)該考慮到系統(tǒng)的可擴(kuò)展性,系統(tǒng) 99% 的時(shí)間都不需要考慮擴(kuò)展,因?yàn)椴]有如此大的流量。
為什么要數(shù)據(jù)庫讀寫分離?
在每一個(gè)系統(tǒng)中,數(shù)據(jù)庫將會是第一個(gè)出現(xiàn)的瓶頸,在大流量的沖擊下,數(shù)據(jù)庫很可能將會是第一個(gè)陣亡的。所以大部分情況下我們會用多個(gè)數(shù)據(jù)庫來分散流量,開發(fā)者經(jīng)常會使用 Master – Slave 模式或者 Master – Master 模式。Master – Slave 是最受歡迎的一種數(shù)據(jù)庫分壓模式,它會將指定的 select 語句路由到每一個(gè) Slave 服務(wù)器,這樣 Master 服務(wù)器的壓力會減輕不少。
12、代碼只能連接到一個(gè)數(shù)據(jù)庫
這和上一個(gè)錯(cuò)誤非常像,但是開發(fā)者有時(shí)候因?yàn)槟承┰蛐枰B接到多個(gè)數(shù)據(jù)庫,比如你會將用戶日志、活動(dòng)信息流、實(shí)時(shí)數(shù)據(jù)分析等高負(fù)載的數(shù)據(jù)放到不同的數(shù)據(jù)庫中來緩解對主數(shù)據(jù)庫的壓力。
13、沒有檢測數(shù)據(jù)庫漏洞
如果你不對數(shù)據(jù)庫進(jìn)行漏洞檢測,就相當(dāng)于給大部分黑客敞開了服務(wù)器的大門。
在眾多漏洞中,數(shù)據(jù)庫漏洞是最脆弱的,最常見的就是 SQL 注入。因此定期做數(shù)據(jù)庫漏洞檢測還是很有必要的。
14、數(shù)據(jù)表不建索引
索引在數(shù)據(jù)表中有著非常重要的作用,合適的索引可以提高每張表的性能,這里有一篇文章就講述了如何創(chuàng)建索引以及何時(shí)創(chuàng)建索引。
15、沒有使用事務(wù)機(jī)制
數(shù)據(jù)完整性對 Web 系統(tǒng)非常重要,如果數(shù)據(jù)一致性發(fā)生錯(cuò)誤,那么整個(gè)系統(tǒng)都會崩潰并且難以修復(fù)。合理地運(yùn)用數(shù)據(jù)庫的事務(wù)機(jī)制將有效地解決這個(gè)問題。比如你要保存用戶數(shù)據(jù),在 table1 中有e-mail, username 和 password,table2 中有 first name, last name,和 gender age。我們可以利用事務(wù)對兩張表更新時(shí)保證數(shù)據(jù)同時(shí)被更新或者同時(shí)不被更新。
16、沒有加密敏感數(shù)據(jù)
對于數(shù)據(jù)庫中的敏感信息,如果你不對它們進(jìn)行加密,或者用簡單的算法進(jìn)行加密,那么在 2014 年你肯定會遇到一些麻煩的問題,黑客們一旦入侵你的數(shù)據(jù)庫,用戶的密碼或者其他重要信息就會一覽無余。
PHP5.5 中提供了一個(gè)哈希加密方法,使用如下:
$hash = password_hash ( $password, PASSWORD_BCRYPT );
17、沒有備份
看到下面這張圖片沒,如果遇到這樣的情況,你又沒有備份,那么一切都 over 了。
·有多少人可以直接訪問這個(gè)應(yīng)用服務(wù)?
·服務(wù)器是否在高負(fù)載下運(yùn)行?
·我們需要用另一臺數(shù)據(jù)庫服務(wù)器來擴(kuò)展系統(tǒng)嗎?
·應(yīng)用系統(tǒng)的失敗點(diǎn)在哪里?
·系統(tǒng)目前正處于離線狀態(tài)嗎?