重构态度
我觉得有点很重要,就是对重构系统的态度,重构是参考而非照搬,前期为什么花了很长时间(将近一个月),却几乎没有什么进展?重要的一点就是我们想读懂源代码,构出数据库,画出UML图,然后在这上面补充。我觉得这是种错误的做法,起码不是很正确,因为重构就是重构,必然有需求的改变,需求的改变也必定带动数据库和UML图的改变。
同时,重构,意味着在基础上开发,实际上更像一种补充和完善,所以借鉴原系统也非常必要,但是要分清楚什么可以借鉴什么不可以借鉴,从这次来看,我认为可以借鉴的有:数据库概念模型、技术难点、算法。
读懂源代码,貌似省了不少时间,其实比重新写用的时间更多。
前提准备
这里说的前期准备就是常见的注释规范规定、命名规定、SVN使用规定。
前两个注释规范和命名规定都是为了代码的美观和可读性,好的代码注释和命名规范,可以让系统更容易维护、更容易阅读、更有一致性,所以开发前有一套统一的规范和命名约定很重要。
试想,当你打开解决方案,满屏的错误,是否有摔键盘的冲动?SVN的使用就是为了更好的合作开发和版本控制,所以对SVN的使用也要有一套使用规则文档,常见的规则:
- 提交前先更新代码到本地
- 提交前自己生成解决方案,确保提交没有错误的代码
- 不要提交pdb、suo等文件(使用SVN忽略)
- 每次提交都要写上更新的注释
- 养成经常提交的习惯
项目计划
项目整体要有一个开发计划,从可行性分析、直到最后的测试部署,每个阶段都要制定完成期限、完成标识和标准,可能一开始制定的不太合理,但随着经验的增多,会逐渐向合理靠拢。
每个开发人员,每天也要要有期望值和总结,然后小组开会讨论,制定第二天的计划。
总得目的就是,不能像“放羊”一样开发,要有总结和规划,逐渐从积累的经验中学习,制定更合理的规划。
开发过程
这次的UML图、文档、代码,体会到的是一定要充分使用辅助软件和功能,比如原型工具、EntityCodeGenerte、正向工程、逆向工程等。
在开发过程中,经常遇到一个叫“度”的问题,即这个页面美化到哪个程度就好了?这个功能简单易用到哪个程度就好了?数据库设计标准到哪个度就好了?如果一味最求完美,一个月的项目可能会拖到一年;如果一味将就,一个功能可能会出多个Bug;这些度的问题都要充分结合项目时间、用户标准、知识存储等才能得到一个适中的答案。
开发过程中遇到的详细问题,见其它博客。
完善
- 修正系统数据库连接问题
- 修改项目中心
- 美化UI显示和动态效果
- 新增权限控制和IP访问控制
- 新增同时进行功能
- 新增历史数据处理
- 完善用户权限管理
- 完善导出功能
- 新增浏览库功能
- 修正其它Bugs
总结