記得剛來這公司的時候，心比天高，對公司的現有專案很多都看不上眼：無架構，無技術，無需求，無注釋，無文件的五無產品，編碼凌亂，效能低下，每個人各自為政，對於修改別人寫的**的最好方式不是修改，而是重寫，不是借助現有架構重寫，而是徹頭徹尾的從ui層寫到儲存過程：html,css,js,c#,sql...。覺得自己一定不能成為這樣的coder,
一 定要改變這一切。於是等啊等，終於公司給了乙個專案的模組，讓我單獨頁責。於是我很努力的去做，卻發現我做的越深就做的越累，但工期又近在眼前，於是就慢 慢忽視一些細節而先去把功能完成，又發現原先的設計有問題，原先寫的一些小模組無法適應業務的變化，但是我之前所寫的很多另外一些小模組完全是依賴於它 的，修改又太費力，於是就
copy了乙份，然後對其某些部份重新寫了一遍。忽然又發現我所做的介面所展示的資料比需求少乙個，於是又從介面改到了db。忽然又發現某些**執行的結果有問題，但是單獨拿出來執行又沒有問題了，找了半天才發現一些是第三方控制項本身有問題，一些則是與原有的系統有衝突。沒有辦法，只有想另外乙個曲線救國的方法了......終於，我把它做完了。累啊，沒等我好好休息一下，測試的反饋下來了，某某某地方有bug
， 需要修改。沒辦法，只能照辦，但是當我重新開啟這個專案的時候，卻發現己經找不到當時所思考的方式了。對於乙個值的修改起碼有三個地方以上，我如何去確定 到底是哪乙個起作用，當我修改了乙個地方後，如何又能確定不會對系統的期它地方有影響。最省力的方式就是重新寫一遍。等等，如果一段**寫成了這樣，不就 很象本文開頭所提到的五無產品嗎：無架構，無技術，無需求，無注釋，無文件。原來乙個立志不要寫成那樣**的我，在不知不覺中將**寫成了那樣
......
我很沮喪，就象乙個想考100分的學生只考了60分，而明明他有機會考100分的。其實，每個人都不希望把**寫成那樣，都希望寫出邏輯嚴密，結構合理，條理清晰，通俗易讀，可復用性可擴充套件性好的**，但往往結果卻不是人所想象的那樣。有乙個好的願望是好的，但更重要的是如何去實現這個願望。我花了一早上的時間去思考這個問題，現總結如下：
1.在專案中所出現的問題：
a.變數字段風格不一致：比如outley，有的地方寫:outlay，有的地方寫outley，比如createtime，有寫成create_time，比如beginemp，有寫成beginemp。其實不是故意寫成這樣的，這樣寫也並沒有錯，只是在專案的開始階段沒有統一風格，這帶來的問題是在後續的工作中會花大量的精力來辯認變數欄位的具體含意。
b.數 據庫設計不完善：在開始階段只是按照最基本的方式將業務資料編入資料表，做了一半才發現當我要進行資料統計的時候需要若干個記錄狀態的字段，而資料庫並沒 有將其設計進去。於是結果就是在表中加了若干個字段，然後對先前寫的一步一步的排查，相當煩燥。還有乙個問題是有張主表將歷史記錄與當前記錄混在一張表 中，於是每次取資料運算的時候都會先寫段大幾
10行的**將當前資料取出,很不好！
c.做事無規化：有個需求是客戶會輸入一些資訊。於是我就想當然的寫了乙個介面，結果發現不是這樣，於是就改，又不是這樣，就又改。這其實是很打擊士氣的。既然要改這麼多次，為何當初不好好規化一下呢？
d.與舊有系統的整合：這其實不應該全算在我頭上，但我確實也沒有考慮進去。舊有的js純手寫，我的js運用了jquery，在某些地方純手寫的js不會引發jquery所寫js的某些效果，很頭痛......
2.以上講了這麼多，其實可以歸結為一句話：我做事的方式有問題！我是典型的想到哪做到哪，做著做著發現寫的東東有問題於是就回過頭來改，又發現有問題，就又改。改著改著**就一團糟了。總結了一下，應該用以下方式來解決，其中大部份是老生常談，就不多講了：
a.明確需求，就是你要徹底理解需求
b.理解/優化資料庫設計，起碼你所涉及到了表與字段要相當的熟
c.介面demo。這步很重要，不要慌張的去做，而是先畫個demo出來，起碼是介面的架構，要知道ui是最費大腦了~~~html,css,js......
d.構思**。成竹在胸，才能下筆如有神。
e.統一風格，**規範。
f.制定時間表，每天按時按量完成。這個按量很重要，不要一味追求進度而超量完成。還有一點很重要：不要隨意將乙個模組的時間超過兩個星期，人會疲的。
3.以上是大體的做事方式，俗話說光說不練假把式，任何專案還是靠具體的技術支撐的，以下就是我所總結出web的技術與工具組合：
資料庫設計：powerdesigner/visio
demo實面：axure/visio
前台：以jqeury為核心，jquery控制項
前後臺互動：以json為核心
後台：將json字串直接序列化成實體物件，然後再進行操作
db：or框架與dbhelper配合。
4.具體程式設計經驗：
a.對於資料庫設計，如果一張表既存當前記錄又存歷史記錄，當遇到大計算量的時候是每煩人的，比較好的方式是分為兩張表，一張存歷史，一張存當前，當然，具體問題具體分析。
c.一般我們會把所有js存在一起，所有css存在一起，但是對於一套完整的js控制項，這並不適用。js控制項有其自己的體系有點分開存會帶來困惑或者不可預知的後果，所以不要將js控制項體系內的內容分開。
5.下一步研究方向：雖然不一定搞一輩子web開發，但是現在搞的就是web，搞一門就要精一門。
a.當前最重要的是繼續豐富我的jquery控制項，讓前端開發的速度更快些更可靠些。
b.然後解決乙個軟體架構的問題。我們現在用的最多的就是三層架構：ui+bl+db，結果我現在把它搞的本質上只有兩層了，因為bl基本就是乙個二傳手。優點就不說了。對於小專案還可以，但是如果是個大專案，假設有10張表，100取法，那我是不是就要寫100個儲存過程，100個db層的調動方法，100個bl二傳手，ui上再寫100個賦值方法呢？
c.引入or框架，具體就是nhibernate
d.引入單元測試
乙個專案的感想
去年真正做了乙個專案，有些感言，寫下來，為以後作專案積累經驗。這個專案很簡單，但是從這個較簡單的專案中，我體會了很多，其中包括對使用者需求的理解 自己的做事風格的反省 專案實施的情況。首先，我談談專案的情況 這個專案是乙個資訊發布系統，很簡單吧，但是，其中有一方面是規章搜尋，並且要生成規章成冊。而且...
最近開發的乙個專案的一些感想
從過年收假到昨天，每天都在公司待著，今天，終於可以休息下了，從未有過的疲憊感，一下子席捲而來。這段時間一直在加班，特別是本週，連續三個通宵工作，而且均是從早上九點到第二天下午下班才回家，不通宵時也是凌晨一二點才回家，現在終於告一段落了。忙碌的工作讓人無暇思考，今天靜靜地思考了下，為什麼會這樣呢？總結...
乙個bug引發的感想
上周五，系統出現乙個bug。基本描述如下 b功能上傳乙個到 b路徑 a功能要獲取b路徑的，但是獲取路徑寫錯了，寫成了a路徑。線上突然出現此問題，訂單無法完成。該功能用到的頻率還比較大。無法馬上布版本。首先的想法想通過改資料來解決，但是發現不行。資料是動態的，不能改，也改不過來。其次的想法 新增b路徑...