1.一定要明确需求(使用业务流程图),特别是到收尾时才发现自己理解错误(很痛苦,这也是程序员通宵加班首要因素)
2.做目前系统用到的,忽略暂时用不到,但要对封装暂时用不到的
3.一定要测试,不要因为不测试会有更多时间去写代码,这是错误理解,在最后集成时才发现错误,由于结构已经编好,一改会变全身,这样花的时间是当场测试时间的几倍时间。
4.编写代码边写注释,比写完代码再写注释好的多,或许,你可能会以为以后可能还会改变,现在写注释了等下还要改,还不如等都写完了在写,刚开始时,我也是这样想,但后来发现这样不仅没省下时间,反而花更多时间去重新看代码,发现bug改代码时,由于不知道参数意义,可能还要花时间重头看一遍,再加上写完代码在写注释时间,这样算起来,还是前者省下时间更多。
5.检索大量数据时,一定要考虑分页情况,到最后发现,这样不符合需求。只能通过添加函数来处理,不能直接修改以前接口函数,因为其他方法会依赖该函数,一改则会发生意想不到的漏洞。
6.确定需求后,需要确定使用技术,再划分子模块,优先处理独立模块(主要是算法模块),画业务需求时序图,接着抽象出模块接口和数据访问接口,最后完成Action编程,需要与界面交流确定需要的数据及其格式(如有草图可以分工合作)
7.模块接近完成时,若需要大部分,需要进行评估,选取代价最小解决方案。
8.漏洞越快填补越好
2.做目前系统用到的,忽略暂时用不到,但要对封装暂时用不到的
3.一定要测试,不要因为不测试会有更多时间去写代码,这是错误理解,在最后集成时才发现错误,由于结构已经编好,一改会变全身,这样花的时间是当场测试时间的几倍时间。
4.编写代码边写注释,比写完代码再写注释好的多,或许,你可能会以为以后可能还会改变,现在写注释了等下还要改,还不如等都写完了在写,刚开始时,我也是这样想,但后来发现这样不仅没省下时间,反而花更多时间去重新看代码,发现bug改代码时,由于不知道参数意义,可能还要花时间重头看一遍,再加上写完代码在写注释时间,这样算起来,还是前者省下时间更多。
5.检索大量数据时,一定要考虑分页情况,到最后发现,这样不符合需求。只能通过添加函数来处理,不能直接修改以前接口函数,因为其他方法会依赖该函数,一改则会发生意想不到的漏洞。
6.确定需求后,需要确定使用技术,再划分子模块,优先处理独立模块(主要是算法模块),画业务需求时序图,接着抽象出模块接口和数据访问接口,最后完成Action编程,需要与界面交流确定需要的数据及其格式(如有草图可以分工合作)
7.模块接近完成时,若需要大部分,需要进行评估,选取代价最小解决方案。
8.漏洞越快填补越好