最近 程序开发心得

最近做了一个模块的详细设计和代码实装以及另一个模块的单体测试。
详细设计被指摘了。。。
代码实装也被指摘了。。。
单体测试还是被指摘了。。。

*----------------------------------------------------------------------------------------------------------------------------*
其中详细设计部分被指摘的原因是：式样书理解的不够准确。
模块要实现的是数据的集计，需要关联两个表（依赖表、依赖明细表）。
式样书中提到了关联条件。
集计部分的说明：「XXXをキーに依頼の集計を行う。」

接着我就这样做了
//
SELECT
XXX
FROM 依赖表, 依赖明细表
WHERE
依赖表.AA = 依赖明细表.BB
GROUP BY
依赖表.XXX
/

也许是长期以来，一直以技术为自己的发展目标的缘故 -——这完全是给自己找借口。
没有仔细的推敲其中的细节。
每个依赖对应多个依赖明细，这样集计出来的结果不是针对依赖表的集计，而是依赖明细表的集计。

这是个大大的BUG。

为了减少这样的错误再次发生，我觉得要增加式样理解的时间---其中大部分时间要花费在业务的理解上。


*----------------------------------------------------------------------------------------------------------------------------*
代码实装过程中，出现了三个bug。
bug1.出力的csv文件中的区分值没有转换成区分名称。
bug2.出力的csv文件的SQL文中没有加入ORDER BY ---而同一机能中的另一个出力文件的SQL中加入了ORDER BY。
bug3.画面的label中「前月」写成了「月前」。

分析了一下：
bug1〉这是一个常识性的问题。
bug2〉机能中有三个这样的SQL，其中有一个追加了ORDER BY,另外两个却没有。。。
bug3〉这属于语言常识的问题。隐约记得当初是逐字逐句检查过了的。。。

为了减少上述的错误再次发生，我想到了一种方法。
在代码实装前，将式样书中容易发生错误的部分、特殊处理的部分、业务复杂的部分等
用[描点]的方式画在一张纸上，并做出标志性的文字。
当然这些点越多越好，也可以在开发中不断追加。
代码实装结束后，自行测试时去测试这些[描点]，如果正确在[描点]处打一个[对号]。


*----------------------------------------------------------------------------------------------------------------------------*
单体测试时出现的bug比较。。。
内容如下：
要将[依赖]和[依赖明细]两张表关联起来做集计。
为此制作了一个view，用于存放两个表结合后的数据。
检索view的结果是这样的：
-----------------------------------------
依頼コード      書類コード      経費区分
１０                JM            １
１０                EG            ２
-----------------------------------------
由于集计的key是[依頼コード]，这样的话这里的结果将是2，而不是1。
这当然不是我想要得结果。
所以。。。
我把修改了[依赖]表中[書類コード]是[EG]的那条记录的某个FLAG的值，这样view中就不会出现这条记录了。
---一切都在掩盖事实的真相。
但是在单体测试结果报告书中，view的evidence被修改成了。。。
---当时的情形大概是这样的。
-----------------------------------------
依頼コード      書類コード      経費区分
１０                JM                         １
１０                EG                        １
-----------------------------------------

所以，又一次被指摘了。
事情并没有因此而结束。。。

式样书中的两个字[のみ]成了另一个恶梦的开始。
式样书中提到
「書類の中に営業資料以外の書類が含まれている場合」的时候，[経費区分]=1
「営業資料のみ」的时候，[経費区分]=2
我理解成了
[営業資料以外場合]的时候，[経費区分]=1
[営業資料場合]的时候，[経費区分]=2

看来这些助词和副词完全左右了整句话的含义。
它们被我低估了。。。

上述的bug，我得到以下启示
1.测试结果报告书中，程序运行出来的结果，一定不要去手动修改。
  如果做了某些调整影响到运行的结果，应该重新将结果拷贝到结果报告书中。
2.坚持学习日語。

写blog的途中发生一点小故障，使用了blog提供的[另存为草稿]功能，原本写的一堆内容不见了。。。
只好重写。

教训：当使用你不知道的或不熟悉的工具时，先将你已经写好的内容保存在你最熟悉的地方，然后再使用那种工具。