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出来，做成视图，这样就好维护了。