網絡編程的幾個準則-經驗之談
2024-07-09 22:39:41
供稿：網友
一、先寫個程序規劃和數據庫規劃。比較小的程序沒這么麻煩，程序大的時候是必備的，一些功能沒弄好結果導致后續功能無法實現，搞到推翻重寫，實在不值。數據庫文檔是必寫的，必須要寫明白表跟字段的類型和用途，不然數據庫字段多了連自己都搞不清楚。另外很重要的一點是，程序是你寫的，在碰到一些狀況的時候，完全可以通過新加數據庫表、字段等方法來解決，都是你設計開發的，主動權都在你手里，還怕什么？當然，新開發可以，升級要考慮的情況就很多了，呵呵。
二、程序縮進和變量命名一定要規范。程序縮進規范了，差錯可以少很多功夫，以后修改起來也方便。變量命名隨你喜好，但是至少要自己能看懂某個變量是做什么用的，給定義個i1,i2,i3,i4,i5，過個兩星期你自己都搞不懂這變量是干嘛用的。
三、先實現功能，后優化。有時候寫程序一下子無法很簡單的實現，這里有兩種可能，一種是有好方法未發現，一種是就這么麻煩沒辦法，在這個時候可以先把功能實現了，以后再來改進。這樣做主要是為了避免在某一個功能上花費太多時間而導致整個程序進度被拉下。寫程序沒有一次性到位的，不需要每次都考慮要做到多少完美，完美是沒有底線的。
四、實現完整功能，保證無錯。某一個程序，就是為了實現某個用途而編寫的，脫離了這個用途，哪怕做的再好，沒用上也是白搭，程序寫好后只有最終產生效應了才有價值。哪怕功能寫的簡單一點，丑陋一點，只要實現功能能夠用就是成功。功能不完整或者一堆錯誤，除了鍛煉了你的寫作能力，我不知道還有什么價值。
五、傾聽用戶意見，但不一定就要按用戶說的來。這個準則有個度的問題，首先是傾聽用戶意見，程序是給用戶用的，用戶的意見才是最真實的，一些特殊流程和情況沒有實際碰到是很難想到的，閉門造車目前來講還不現實，除非你是寫給自己用的，大多數情況都能考慮到。其次是不一定要按用戶說的來，用戶是不懂編程的，他只能說明他需要什么樣的功能和什么樣的結果，具體開發實現還是由你來做的，只要實現他的功能，用什么手段什么方式完全可以由你來決定，當然，決定之前要跟用戶商量下是否可行。假如不是定制的程序，是你自己寫的玩的，假如用戶的意見與你的規劃有沖突且那個功能不影響使用的，可以不理會，當然，需要給用戶稍微解釋，這樣大家都開心。
六、稍微注重下用戶體驗。在寫程序的時候要換位思考下，你不能要求用戶跟你一樣懂電腦懂程序，下至六七歲的孩童，上至八九十的老人，不同的人群有不同的特點，所以該加大字體的時候加大字體，該給提示的時候要給提示，該限制的時候要給限制，你可不能擔保用戶會做出什么事情來，反正給用戶需要的最小權限就好了。
七、考慮其他因素的時候不要忘了功能實現。這點比較難講明白，舉個例子吧。比如安全中的防注入，很多人會用所謂的防注入系統，判斷是否有select之類的字符串來實現，假如我要寫篇文章《論Mysql中select語句的應用》，會出現什么效果呢？其實防注入只需要做到是數字就進行數字判斷或進行強制轉換，是字符串的時候就要強制轉換單引號就OK了，在考慮其他因素的時候盡量不要影響功能實現。有人說，進行數字強制轉換可能報錯，你管他呢，正常情況下通過頁面鏈接點擊會出報錯情況么？不正常的情況下報錯就讓他報好了。。
八、只要可能出現的問題，就一定會出現。這點我深有感觸，即使再難以發現的問題，都會被用出來，所以在編程的時候不要吝嗇那么幾個語句，一定要把已知問題扼殺在發布之前。
九、寫好程序后根據情況給寫個幫助吧，哪怕沒時間，把流程截幾個圖都好。用戶在使用的時候不可能像你一樣熟練的，尤其一些技術名詞，用戶并不認識，你只需要簡單解說下就好了，大家都看得懂，就不會一個個來問你了。
十、還有十么。。似乎有，程序正式使用后，肯定還會有這樣那樣的不足和問題，這時候要用一種樂觀的心態去看待。沒有一個程序敢說自己第一版發布就沒有任何問題的，即使是正式使用之前經過了嚴格的測試。程序出了問題不可怕，出了問題不彌補才只最可怕的。
做程序員是辛苦的，尤其我這樣的IT民工，以上準則看似把自己折騰麻煩了，實質上會減少大大自己的工作量，寫程序不麻煩，應付不斷出現的問題和不斷有問題的用戶才最折騰人！
