有感於csdn上的一些個提問
阿新 • • 發佈:2018-11-09
我首先宣告,我也是個菜鳥,真正開始搞軟體也就最近一兩年的時間.這一兩年,搞的東西不少,從asp,到mfc,到asp.net,到C#的winform,可以說煉成了一個萬金油,什麼也沒精通. 但目前我的專案都已經成功地實施,客戶沒有不良反應(當然也沒有稱讚:)).是我值得自豪的地方.
以我比較低的眼光,我都發現有些初學者越來越不重視基礎甚至對程式設計人員來說應該是常識性的問題了:
(下面的看法不針對任何人,只是描述一些現象)
1.不清楚BS結構和CS結構的區別,搞不清伺服器回發是怎麼回事.對他來說,這些都是透明的,他面對的只是一臺電腦. 比如,他可以要求伺服器端程式執行時彈出一個MessageBox.Show(). 還要求滑鼠移到某某按鈕上面(MouseHover)的時候,執行某asp.net後臺函式."我的程式如何和js程式互動?" 等等.
2.作網站程式的,對js, css一無所知. 這也許是微軟的asp.net值得自豪的地方(很大程度上避免了直接操作這些東西),但絕不是我們從事web開發值得自豪的地方. 不懂這些,你無法做出一個真正有實用價值的哪怕是簡單的系統.有的人動不動就"js我不會啊","css我不懂啊", 好象很理直氣壯似的. 其實現在web開發的門檻已經夠低的了,連這都不會,你還會什麼?
3.英文水平低下,看不懂出錯的英文提示, 發展下去,連中文提示也懶得去看去分析了,出錯以後的反應有如普通使用者.原樣COPY發到論壇來問.要知道你可是專業人士. 我甚至多次看到那個asp.net常見的一大堆提示 <customerror="off">的常規錯誤資訊,一股腦地貼上進來,問是哪裡出了錯.令人哭笑不得.
4.缺乏最基本的除錯技巧. 除錯方法最有效的是執行到某一處中斷然後列印檢視變數,其次是跟蹤. 現在的開發環境在除錯功能方面簡直太強大了,不知道好好利用. 正因為如此,對一些"未將物件引用到例項","index下標越界"的常見執行錯誤一籌莫展. 或者對執行得不到所要的結果感到一片茫然,不知如何是好.
5.有的人缺乏"靈感", 這個"靈感"我指的是對一些簡單問題"一點就透". 說白了,就是"太笨了"(當然,專指軟體這塊,他去幹其他的說不定會很出色,上帝對每個人都是公平的). 和他對話很費勁.往往提示了還不夠,比如說,要他新增一個RowEnter事件,這個事件在哪啊?我雙擊是Click啊?點閃電圖示! 閃電在哪啊,我暈,恨不得鑽到電腦的另一頭去幫他.
6.不懂得簡化問題. 將複雜的問題簡單化,這應該是軟體業(也許是所有行業)的原則. 甚至可以說是一種人生態度,提到世界觀方法論的高度也不過份. 但是我經常看到有"我的表有幾百個欄位,怎麼搞","我的頁面裡有幾千個控制元件,怎麼弄",還有"我的頁面想實現像Excel那樣的既點既輸功能,還能拖放"等等. 我不是說這些都辦不到. 凡事皆有可能,但是要考慮成本.
7.無原則地使用try catch.這個其實是我看周圍同事的程式碼有這樣的問題, 也稍帶在這裡發表一下感想.他們都認為這種結構很時尚. try catch絕不是拿來給你逃避錯誤用的. 而且try catch一定要用在自己確信有可預見的錯誤的地方.比如檔案讀寫.遠端通訊等.這些對程式來說都是外部的不可控因素. 而不是用來回避邏輯錯誤(你自己的錯誤). 正因為如此,catch中的Exception最好精確一些,比如IOExcption,FormatExcption等,而不是簡單的一個Exception了事.
所以try catch要儘量少用,用在最需要的地方. 在初步除錯階段,最好不用.
以我比較低的眼光,我都發現有些初學者越來越不重視基礎甚至對程式設計人員來說應該是常識性的問題了:
(下面的看法不針對任何人,只是描述一些現象)
1.不清楚BS結構和CS結構的區別,搞不清伺服器回發是怎麼回事.對他來說,這些都是透明的,他面對的只是一臺電腦. 比如,他可以要求伺服器端程式執行時彈出一個MessageBox.Show(). 還要求滑鼠移到某某按鈕上面(MouseHover)的時候,執行某asp.net後臺函式."我的程式如何和js程式互動?" 等等.
2.作網站程式的,對js, css一無所知. 這也許是微軟的asp.net值得自豪的地方(很大程度上避免了直接操作這些東西),但絕不是我們從事web開發值得自豪的地方. 不懂這些,你無法做出一個真正有實用價值的哪怕是簡單的系統.有的人動不動就"js我不會啊","css我不懂啊", 好象很理直氣壯似的. 其實現在web開發的門檻已經夠低的了,連這都不會,你還會什麼?
3.英文水平低下,看不懂出錯的英文提示, 發展下去,連中文提示也懶得去看去分析了,出錯以後的反應有如普通使用者.原樣COPY發到論壇來問.要知道你可是專業人士. 我甚至多次看到那個asp.net常見的一大堆提示 <customerror="off">的常規錯誤資訊,一股腦地貼上進來,問是哪裡出了錯.令人哭笑不得.
4.缺乏最基本的除錯技巧. 除錯方法最有效的是執行到某一處中斷然後列印檢視變數,其次是跟蹤. 現在的開發環境在除錯功能方面簡直太強大了,不知道好好利用. 正因為如此,對一些"未將物件引用到例項","index下標越界"的常見執行錯誤一籌莫展. 或者對執行得不到所要的結果感到一片茫然,不知如何是好.
5.有的人缺乏"靈感", 這個"靈感"我指的是對一些簡單問題"一點就透". 說白了,就是"太笨了"(當然,專指軟體這塊,他去幹其他的說不定會很出色,上帝對每個人都是公平的). 和他對話很費勁.往往提示了還不夠,比如說,要他新增一個RowEnter事件,這個事件在哪啊?我雙擊是Click啊?點閃電圖示! 閃電在哪啊,我暈,恨不得鑽到電腦的另一頭去幫他.
6.不懂得簡化問題. 將複雜的問題簡單化,這應該是軟體業(也許是所有行業)的原則. 甚至可以說是一種人生態度,提到世界觀方法論的高度也不過份. 但是我經常看到有"我的表有幾百個欄位,怎麼搞","我的頁面裡有幾千個控制元件,怎麼弄",還有"我的頁面想實現像Excel那樣的既點既輸功能,還能拖放"等等. 我不是說這些都辦不到. 凡事皆有可能,但是要考慮成本.
7.無原則地使用try catch.這個其實是我看周圍同事的程式碼有這樣的問題, 也稍帶在這裡發表一下感想.他們都認為這種結構很時尚. try catch絕不是拿來給你逃避錯誤用的. 而且try catch一定要用在自己確信有可預見的錯誤的地方.比如檔案讀寫.遠端通訊等.這些對程式來說都是外部的不可控因素. 而不是用來回避邏輯錯誤(你自己的錯誤). 正因為如此,catch中的Exception最好精確一些,比如IOExcption,FormatExcption等,而不是簡單的一個Exception了事.
所以try catch要儘量少用,用在最需要的地方. 在初步除錯階段,最好不用.