 |
VOOZH | about |
|
VOOZH | about |
根據「帕累托原則」的界定，特定事件中80%的最終結果往往實際源自20%的可能性因素。這種劃分方式被稱為二八開原則，而且幾乎影響到了人類活動所觸及的每一個領域。
在軟體開發領域，該原則也可以被解釋為，大部分問題實際都是由一小部分不良編碼實踐所引發。只要消除這部分因素，我們的工作將會變得更輕鬆也更加富有成效。
下面我們就一起來看這十種給工作帶來無窮困擾的糟糕編碼實踐。
1. 代碼當中的拼寫錯誤
這類問題的出現頻繁可能超出大家的想像，它們之所以如何普遍與猖獗、是因為這一切與我們的編程技能水平並沒有必然聯繫。再出色的開發人員也有可能在代碼中寫出錯誤的變量名或者函數名，而這最終將成為一股肆虐無忌的狂暴力量。更重要的是，揪出它們實在是件困難的差事。
那我們該如何解決這一難題呢?使用一款良好的集成開發環境(簡稱IDE)甚至是選擇一種專門面向程式設計師的文本編輯器，這些都能大大降低拼寫錯誤出現的機率。除此之外，我們還有另一條道路可以選擇：刻意選擇較容量拼寫的變量與函數名稱，這樣一來發現錯誤的過程就會變得相對輕鬆。最好不要使用receive這類詞彙，因為不管檢查多少次、我們都不太可能發現它被錯寫成了recieve。
2.沒有對代碼進行縮進或者格式調整
一定記得為代碼行設定縮進或者作出格式調整，否則大家一定會發現自己的代碼內容既難於理解又不容易從中找出錯誤。此外，簡潔明確的格式設置還能帶來一致化的顯示效果，進而降低他人對代碼的維護難度。
如果大家使用的IDE不具備代碼格式自動調整功能，則不妨考慮使用Uncrustify等代碼美化工具，這類方案能夠根據我們事先設定好的配置機制完成格式轉換。
3. 未能實現代碼模塊化
在編寫函數時保證其能且只能實現一種效果絕對算是非常重要的良好編碼實踐。這種處理方式能夠讓代碼保持精悍，並因此更易於理解與維護。過長的函數可能擁有多種可能的接入路徑，從而導致其更難於進行測試。
這裡教大家個好辦法：一個函數最多不要超過單一屏幕的顯示極限。另外，如果代碼當中包含十個甚至更多「if」語句或者循環，那就說明其關係太過複雜、應該重新進行編寫。
4.不要被IDE功能所帶來的虛假安全感所蒙蔽
IDE以及其它能夠自動實例代碼的工具能夠奇蹟般地提升生產效率。它們會根據大家已經輸入的內容給出建議變量以及其它相關提示內容。不過這類工具在實際使用時也有可能帶來潛在問題——由於能夠毫不費力地從看似正確的選項中挑出自己需要的內容，大家往往會因此而放下戒心。不要這樣，請務必確保我們選擇的與自己需要的確切吻合。從本質上講，這類功能相當於將思考工作轉移到了工具身上，在這種情況下確保其思路正確自然是第一要務。
這相當於給我們提供了一條新的思考準線。代碼完成工具可以消除當中的拼寫等錯誤並提高生產力，但它們同時也可能在我們放鬆警惕時悄悄把錯誤埋入其中。
5. 硬編碼密碼
以硬編碼方式創建秘密帳戶與密碼可謂極具吸引力，大家可以藉此在隨後的使用過程中直接進入系統。我相信大家都知道這種作法不好、不對——沒錯，這種方式確實非常方便，但同時也等於是給任何有意訪問原始碼的人士提供了便利之門。
真正的問題在於，硬編碼密碼最終總會擴散到我們意料之外的人群當中。這就使其成為一種巨大的安全威脅，而且很難得到徹底修復。
6.沒有利用良好的加密機制進行數據保護
敏感數據需要在網絡傳輸的過程中受到加密，這是因為在傳送期間它被可能遭遇惡意人士的攔截。這並不僅僅是什麼好主意或者推薦方案，這是一種監管要求——甚至可以上升到法律的高度。
也就是說，直接發送數據內容的作法必須得到「明令禁止」。此外，大家也絕對不要使用自己的加密或者模糊處理方案。編寫自己的安全加密系統難度很高——大家看看WEP的遭遇就能明白——因此請務必選擇符合相關行業標準的加密庫並加以正確使用。
7. 過早對代碼進行優化
傳奇程式設計師Donald Knuth曾經說過，「程式設計師們把大量時間浪費在了考慮或者擔憂程序當中非關鍵性部件的執行速度上，這些嘗試往往會給代碼的調試與維護工作帶來嚴重的負面影響。」
在我們的代碼上多花心思可能確實會讓它的執行速度不斷提升，但同時也會給調試與維護帶來更高難度。最好的處理辦法是：以清晰的方式編寫代碼，然後在真正有必要的時候再通過優化提升其性能表現。
8. 不具備超前思維能力
我們的項目是用來做什麼的、預計將會擴展到怎樣的程度、有多少用戶會對其進行操作、又將以怎樣的速度付諸運行?這些問題的答案在開發過程中也許並不明確——但如果大家不能提前作好規劃，那又該如何準確選擇合適的框架來開發出能夠滿足這些需求的應用程式呢?
Twitter技術團隊遇到的實際情況就是個很好的例子：如果對未來的實際使用情況估計不足，後續處理將變得極度困難。Twitter不得不放棄了Ruby on Rails並利用Scale及其它技術方案對代碼進行重新編寫，這是因為Ruby代碼在最初設計上根本沒有考慮到Twitter會擁有增長速度如此迅猛的用戶群體規模。
9.添加人手來加快開發進度
幾乎每一個軟體項目都無法真正實現預定時間進度。添加人手來加快進度並使其符合原本計劃聽起來像是個好主意，但這僅僅是種理論而非現實，而且通常甚至屬於嚴重失誤。在現實世界中，向項目中添加新人幾乎總會導致整體生產效率產生下滑。
10.堅持根本無法實現的時間規劃
與此同時，我們還應該保持清醒的頭腦、意識到在團隊規模不變的情況下根本不可能重新趕上預定進度，這樣的理性思維非常重要。如果大家沒能遵循原有時間表，那很可能是因為這份進度規劃在制定時就存在失誤。也就是說，大家需要創建一份新的項目時間規劃，而不是盲目堅持原先這份已經被現實證明為不可能的錯誤方案。
Web服務開發
咱們約會吧 Web設計師教你不一樣的語言
前端研發生態環境構建經驗談
代碼整潔之所以重要的七個理由
軟體開發就像炒股 關鍵看你怎麼選股票！
事後諸葛亮：如何寫出沒有bug的軟體
2014年web開發者應該學習的技術盤點
2014七個最明顯的web設計趨勢生存技巧
你應該放棄的八大設計元素
為什麼添加越多的控制軟體開發越快？
代碼審查最佳實踐
2014年對Web開發的十大預測
總結企業軟體開發實施失敗的罪魁禍首
如何選擇適合自己的程式語言
精簡代碼 為網站減負的十大建議
學編程就像選家具：去宜家還是從種樹開始？
Meteor PK Django：誰更適合開發實時Web應用？
2014年編程興衰趨勢預測
「十倍效率」程式設計師/開發人員的習慣
2014年十大Web設計趨勢
提升軟體開發者效率的十個提示
項目開發：如何在質量與速度之間找到平衡點？
關於何時償還技術債務的建議
Web應用程式完全測試指南
UX設計程序的五個謬論
泯滅Web App可用性的七個開發錯誤
如何走出選擇PHP還是ASP.NET的兩難境地？
為開發者準備的11個新鮮方便的框架
從頭開始實現領域驅動設計
Web軟體測試完全檢查清單
軟體領導不斷改變 團隊才會不斷強大
需求決定設計 面向對象最大的設計陷阱
如何成為有代碼潔癖的程式設計師？
GUI功能測試自動化模式
Web設計師和Web開發者之間的區別是什麼？
十款超實用且高效的線框設計工具
Web設計里需要避免的八大糟糕趨勢
UEM乃更好用戶體驗的設計關鍵
Web開發中常見的九個安全誤區
軟體架構十個技巧及成功團隊具備的氣質
Web開發者需養成的八個好習慣
Web設計過程中三做三不做
寓教於樂 給代碼審查者的幾點建議
高效使用PortletSession小技巧
如何讓代碼並發效率更高
成功的軟體開發技術：權衡管理關鍵
獻JSF 2.0 Facelet開發人員：性能和故障排除密技
注意！Web開發者易犯的五大嚴重錯誤
十大足以搞砸項目的糟糕編程實踐
軟體測試管理:教你遵從規則和打破陳規
新入行程式設計師應知的十個秘密
支持Swift！全新「四步測」BDD框架Quick誕生
基準測試：Swift並不像蘋果說的那麼快
程式設計師眼中的Swift語言：簡單、易學
Objective-C最令人深惡痛絕的九大特性
2014年Web開發的七個轉變方向
軟體質量策略的用戶角色識別
在發布站點前 Web開發者需要關注哪些技術細節？
Clouda框架介紹與應用場景
淺談導航設計 開發者必備的十大實用技巧
投資於質量 不再有技術債務
如何讓軟體項目取得成功
12款最佳的網站速度和性能測試工具
應用開發工具Scriptkit：把複雜代碼可視化
程式設計師一定要避免的五種程序注釋方式
一定要知道的Web設計八個流行趨勢
2013年流行的十個線框圖和界面原型工具
面向服務軟體開發和設計的三個祈使句
如何成長為優秀的互動設計師
為你的應用準備最佳負載測試的九個技巧
合併日誌文檔操作優化Tomcat性能
Tomcat性能設置兩在常見錯誤
軟體開發時間管理：記錄生產效率是關鍵 原因何在
開發人員都應銘記的十句編程諺語
REST vs. SOAP：如何挑選最好的Web服務
成功的軟體產品：客戶的主要焦點在哪
避免PortletPreference性能干擾的原因
直言不諱：SOA專家十問十答之Rob Daigneau
良好的軟體開發需求說明書有利於測試
如何滿足軟體開發的非功能性需求？
菜鳥必知：成為偉大開發者的「九步曲」
每個軟體工程師都應該去嘗試的五件事情
如何從JPA 2.0 EntityManager獲得Hibernate Session？
Web開發者注意：請不要忽略API的安全性
代碼審查的實踐要素
企業軟體產品本土化處理的十個技巧
枚舉對異常：應用程序錯誤處理新敏捷方法
避免代碼注釋的五大理由