主题：[分享]分享考勤核算和文件管理两个项目的开发思路

这一个多月来主要重写了2个方面的内容，一个是考勤核算，另一个是文件管理。重写这两个模块，主要原因是因为工作需要和学习新的编程理念。

 

1.考勤核算

整个系统软件最初就是从考勤开始的，当时界面很简单只有一个签到界面，需要人工统计。之后增加了个人工作日期设定，公司工作日，但最终还是卡在考勤核算的环节上，逻辑过于麻烦，计算不准确等，最后搞了半自动化就不在弄了。

今年初，需要重新把这个功能完善，该考勤核算功能实现以下功能：

1）  能够设定公司默认工作时间。

2）  能够设定用户默认工作日期和时间，覆盖公司默认工作时间，周六周日不覆盖。

3）  能够设定用户特殊上班时间。

4）  能够设定用户年假天数及每天工作小时。

5）  <!--[endif]-->用户每天可以有多组签到离开。

6）  用户每天可以有多次考勤申请。

7）  考勤申请可以跨日，跨月，跨节假日，核算结果不受影响。

8）  不会重复计算同时间段的多次请假申请。

9）  根据考勤申请，签到记录，默认工作时间，特殊工作时间，公司默认上班时间，综合进行核算每天考勤结果。

10）  考勤分为迟退，旷工，请假，外出，其它等五种，并能分别独立计算。

11）  精确到分钟的核算，核算时间忽略不计。

 

以上这些功能全部都由SQL语句完成，数据库采用MSSQL2005，涉及代码约330行，包括两个内联表函数，两个存储过程，涉及7张基础表。一个存储过程主要用于插入数据和调用核算数据，另一个用于优化核算方案，使得原来核算需要接近6秒，降低到只有0.3秒。整个核算及优化到此完美完成。

从设计方案定型，到最终优化完成历时1个月，其中设计占了90%以上时间，实际写SQL语句花了30个小时，其中20个小时是为了解决性能优化问题。

其实这个方案早在2年前就已经设想过，最终能力所限无法完成，现在终于能够实现了，也是一种突破。

 

2.文件管理

之所以重写是因为半年前写这个类的时候花费了大量时间，最终是实现了，结果代码无法阅读也难以修改。后续再进行改进已经几乎不可能了。而接下来需要对功能进行更新，因此重写也是必须的事情。

经过半个月的学习和改进，终于实现重写。而且整体思路清楚，很容易维护，并实现了以下功能：

1）自动对比文件是否一致（MD5），数据库中同一目录下，相同文件只有一行记录

2）记录文件信息，包括存储路径。

3）记录文件添加，修改，删除等情况

4）自动检查缺失文件，并自动更正。

5）当添加的文件名相同，文件不同（MD5）不同时，自动重命名旧数据，再添加新文件。。

6）当文件相同，名称不同或者相同，提示用户是否进行覆盖操作，若覆盖，则记录为文件覆盖。

7）删除文件时，自动重命名，并转移到一个回收文件夹，记录为删除。

8）当文件删除或者丢失，添加该文件时，记录为恢复文件

9）用户可以对文件进行重命名

10）所有系统自动操作，都会将文件重命名并带上编号。

 

以上功能全部使用.NET编写，采用面向对象的设计思路，代码约950行。原来是采用面向实现的方案，代码行数相当。现在将原来功能进行分解，采用面向接口进行重写。大量精简了IF嵌套语句，使可读性大大提升。分解后，由原来的1个类，重写为21个类，采用策略模式，工厂模式，模板模式等，较好的解决了整个功能结构，并具有良好的可扩展性。

 

小结:

1）软件开发需要不断学习，当遇到瓶颈的时候就需要去看更多方法类的书籍。光看实例你未必看的懂，甚至会引导你误入歧途。

2）当你编写的逻辑非常复杂的时候，就需要将该逻辑不停分解直到不超过2个嵌套语句，你的代码才具有良好的可读性，以及可维护性。

3）良好的命名也会极大的提升代码的质量。

4）数据库开发不会SQL语言，就好像在一个五彩的世界里，你却是个色盲。

 

因为涉及到一些其它问题，整体代码就不附上了。附上修改后的文件管理类图，类的名字不算理想，但是看到类的名字，也能知道它是用来干什么的。在这里推荐一本书籍，《Head.First.design.patterns》，中文名《Head First 设计模式》，或许能给你更多启迪。

此主题相关图片如下：文件管理类图.jpg

一看就是 过来人 返工次数不少吧

是否能发上来学习下？楼主