3、路漫漫其修遠兮,吾將上下而求索...

      差不多fix bug 這項工作搞了一個月左右吧...其實我自己覺得進步挺快的,不懂得的問題,可以問辦公室裏面的同事,實在不行的還可以問Martin,雖然說Martin時間不是很多,但每次聽他講解,都有種徹悟的感覺...幾時我才能達到Martin的水平?羨慕下……嘿嘿。

 

      一個月,我對ywca的系統算是比較熟悉的上手了,有時候在fix bug 的過程中,還能領悟一些很好的編程的邏輯思維,因爲,整個ywca,裏面的c#代碼都寫得非常成熟,包括命名,邏輯,思路等。人人都說c#有多好多好,嘿嘿,我每天的收穫就是,原來和Java對比下,學c#,反而令我對Java的理解更深刻...

 

 

      Walter(Manager)提示我,叫我不要對c#有偏見,其實不是啊,只不過我將其與Java對比,我更喜歡Java多點,自然的就看了c#,然後想着怎樣可以將Java做得更好...呵呵...這也許是我不夠成熟的表現吧!

 

-------------------- split-line of a legend------------------------

 

 

工作兩個多月了,一直都沒做過正式點的開發,現在機會來了,ywca的工作人員交給我們一些enhancement去實現...由於到目前爲止,除了Martin這個系統作者之外,我就是對它比較熟悉的一個人了,所以,the task落到我頭上。

enhancement:  

1、Audit trail function 

Requirements:
Include audit trail so the system can compare what exactly has been changed? At the moment an "activity log" that record transactions by date time, transaction category, etc but no related amounts are captured.

Solution:
The activity log will be totally rewritten to capture the system changes.  For detailed breakdown, please refer to the breakdown table

2、Update receipt

Requirement:
Include Payer’s name of cheque or credit card last 4 digit on receipt

Solution:
Modify the payment module to capture the payer’s name or the credit card number (4digits) if the payment method is cheque or credit card respectively.

3、Programme approval function

Requirement:
Add a programme approval button (similar to the refund approval button) so the department head can authorise on the system before program launch.

Solution:
Add a status = ‘Pending for approval’ between ‘Preparation’ and ‘Running’ stage.  Department head can approve the course individually. 

4、Member form – Note field

Requirement
Including a blank "note" area at bottom of each member's account so CS can type in

Solution nvarchar(1024)
In the member form, add a plain text area field “Note” (maximum 1024 characters) to allow CS type in plain free text (not rich text).

 

-------------------- split-line of a legend------------------------

 

      箇中的具體就不表示出了,除了第一個比較困難點(對於我來說),其他都好辦點。只要的解決方法都是,照着系統裏面已有的功能copy和修改。 

 

-------------------- split-line of a legend------------------------

 

      來點經驗總結:

 

      大部分的程序的bug 都是出現在程序員之間的接口第一,當一個程序員編寫的代碼被另一個程序調用時,不知何故,調用者破壞了代碼編寫時所作的假設;其二,在調用程序時,並沒有考慮到自身由於什麼條件限制,忘記要做一個邏輯判斷自己的程序是否適合調用;其三,數據存儲的SQL語句有問題.....;其四,最簡單的錯誤,拼寫錯字母,SQL語句,字段類型不匹配....(還有很多...)

      測試假設條件是構建正確的程序的最重要一個方法,在你寫一個函數時,你應該考慮並確定你對那個函數做了什麼樣的假設。問題如下:

      1、當這個函數被調用時,這個對象必須是怎樣的(對象初始化,某個內在變量值)?

      2、當這個函數存在時,這個函數將會怎樣(假設調用前是#1,調用後仍是#1,但包括該函數的副作用)?

      3、改函數的任何參數必須是怎樣的(允許空值嗎,輸入的範圍是什麼)?

      4、返回值必須是怎樣的?

一旦問了自己這四個問題後,並作出回答,就把答案放進代碼中去...

 

 

引用《走出軟件作坊》中的<一個人的戰鬥>中的意見:許多從事開發的人認爲,一個老系統要維護好,必須具備以下關鍵因素:有責任心、有文檔、設計前做好詳細的需求分析、要有需求管理、要OO編程、要有專門的測試人員。

 

      一、重點把控輸入數據的校驗。你看見很多橫插進來的代碼,就是由於輸入的漏洞進入,最後引起後續數據處理出錯,所以以前的程序員他不截源頭,他在最後爆發的地方堵漏洞。現在WINDOWS程序都是消息事件觸發式的,還說不準這個流程會走到哪裏,他堵得了這個口,其他根本想不到的觸發,他能堵住嗎?所以,把輸入數據的校驗,在保存按鈕第一步代碼寫好集中的詳細的校驗。而且,這塊代碼要寫成函數,不要大流水,省得代碼複雜性會讓程序加速崩潰。


      二、以後的需求再往上加,都寫成函數。遇到比較大的IF..ELSE判斷,就把其中的代碼段再分出一個函數。


      三、以後再加功能,儘量不要做成聯動觸發的。也就是說:保存,最好是單表保存。即使是主從結構的單據,如果客戶不強烈反對,也做成先保存主表後再讓錄入明細表。而且錄入明細表要單獨的窗口,這樣功能和代碼都簡化了。如查詢一張單據,也不要上邊是主摘要,下面就是明細聯動。這樣影響性能。更因爲速度可能慢,用戶會連續點擊多次,觸發事件就會亂,莫名其妙的錯誤就都產生了。最好是雙擊主摘要,彈出獨立的窗口顯示明細。


      四、你以後寫代碼,把特殊處理業務和正常處理業務的功能代碼分離。就好像你走路,老有人給你下絆子,你就感覺不爽。


      五、現有的功能,把不常用的功能做一些隱藏處理,放到一個不起眼的位置。使用的人就會越來越少。到時候就適機真正藏掉,不讓它觸發了。


      六、其實很多時候,你覺得程序很爛,索性破罐子破摔,是由於以前程序員的代碼排版可能和你不一樣。你喜歡兩個空格,人家喜歡三個空格,你就覺得不爽。人家喜歡把{放在最後,你喜歡新開一行。你可以使用代碼格式化工具重新排一次版。我看到很多關於老代碼維護人員,抱怨變量都是M、N、S、Button1之類,但其實你閱讀理解代碼,這些並不會使你理解有歧義或讀不懂,只不過你不爽而已。理解了這個不爽,你就會心平氣和一些,修改代碼會更加順利一些,你越和舊有代碼生氣,你的工作越亂。(看到這裏,相信很多程序員都會會心一笑。真正的根源在於此,老系統無法維護只是藉口而已,可能希望老闆認爲自己的工作很辛苦很複雜而加薪)。真正危害大的是全局變量和大流水代碼。所以寫代碼,要嚴格避免這兩個壞因素。


      七、修改需求或BUG的時候,要按照模塊來集中修改,而不要挑好改的先改了,不好改的就最後改。按照模塊來集中修改,你會通盤考慮所有這些需求和BUG,而不是糊窗戶式的補窟窿。


      八、我曾經和很多做維護的開發人員都做過交流。他們都覺得一個軟件沒有文檔,沒有註釋,簡直就沒法維護。但確實是很多軟件沒有任何設計文檔,連幫助說明都沒有,代碼也沒有註釋。而這些軟件又出自他們自己之手。也就是說他們一邊抱怨沒有文檔沒有註釋,一邊自己也不做文檔不寫代碼註釋,不知道在等誰來專門做。我問他們到底需要什麼文檔纔可以將一個軟件維護的越來越好,從一套爛代碼扭轉到一套良好漸進的代碼?他們說要要表結構說明、要詳細功能設計書。表結構還好說,可以整理出來,詳細設計說明書就不容易出了。


      我曾經也維護過別人的代碼,也是什麼文檔都沒有,連操作使用幫助都沒有,更別提詳細設計說明書和表結構,代碼當然沒有什麼註釋。我並沒有去整理表結構說明。幸虧這個人喜歡數據庫上倒弄,寫了大量的視圖和存儲過程。視圖中有各個表之間的關係連接,也有各個表中重要字段的中文名。這樣我就不需要表結構說明了。因爲表結構說明不僅需要描述每個表中字段的中文含義,也得描述表之間的關係,這和視圖能表達的效果是一樣的。所以,我現在也建議開發人員寫代碼,多寫視圖,多寫存儲過程。有的老代碼,SQL語句都生寫在代碼中執行,沒有視圖。對於這樣的老系統維護,就是把這些SQL COPY出來,做成視圖,這樣就好維護了。 

 

 

 

 

 

 

 

 

發佈了25 篇原創文章 · 獲贊 4 · 訪問量 4萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章