本帖最后由 slowgrace 于 2009-08-01 10:39:16 编辑

解决方案 »

  1.   

    如果是全局或模块级的,也不能见到它还不是closed的,就简单地close掉。
    个人意见,如果程序逻辑清晰,是没有必要过度防御的。
      

  2.   

    俺是来学习的,对90%和10%也有体会~现在用控件还要考虑微软的升级补丁~~郁闷!!!近来对付KB960715对From2.0的影响。脑袋都涨了~~
      

  3.   

    当然是先写主要的,再调试,再加次要的,再调试;我们在开始写的时候不可能考虑那么全面(包括微软的程序员应该也是一样,要不WIN98怎么会打了三千多个补丁);所以你说的:先实现核心功能再说是对的. 
      

  4.   

    如果是给用户用的系统,一定要按Leftie的方法去写,理由很简单,不进行必要的判断,程序可能出现异常中断的情况(比如那个贴子中如果是系统刚开始启用,Remain中没有数据,那系统将中断。难道比起和那么无知的用户解释为什么中断,比在程序中自己去判断还容易吗?)
      

  5.   

    我习惯于把我能想到的所有可能出现的问题考虑进去,这纯粹是习惯,有时候甚至会写出几乎永远不会出现的一些可能情况,自己也注释一个msgbox说,此种问题应该不会出现1之类的,为什么会这样,就是因为一旦有特殊情况下,出现错误,也容易找到问题出现的位置。另外,我估计lz还没有写过比较大型的程序,也就是代码超过10万行以上的程序,因为不考虑所有情况,就有可能出现莫名其妙错误,而让你无从下手。我就见到过一个写医院管理系统的人,在程序出现计算错误的时候,边看代码边挠头说:怎么可能出现这种错误呢,不会啊,怎么可能呢。等等之类的话(搞了多少天也没明白到底为什么出现错误),我想就是特殊情况没有考虑。
      

  6.   

    csdn解答疑问的话,给个思路就好了,基本上不考虑边界情况写代码的话是左手那样的写法,小习惯不同但是整体还是那个结构。个人觉得这个是流水线产品比较基本的规范了。
    流水线产品不太可能展现个性的,毕竟代码的可读性,通用性,拓展性这些都考虑到的话,就很难体现程序员个性所在了。另外容错是程序员时刻要记住的一条规范,bug可以有,但是不要让系统崩溃,如果系统崩溃于客户眼前是一件很丢人的事情。
    程序员的个性可能体现在解决问题的方法或者说是逻辑思维吧。在注释的写法上也会有些个人风格的言语和幽默至于如何从核心功能拓展到考虑边缘临界状态每个人不同,每个人任务的需求也不同。但是无论如何交给客户是一个稳定的系统,给同伴的可读可接手的代码,给上司的是实现文档的其他相关文档。
    然后大家就都很happy
      

  7.   


    错!应该说clear_zero的软件作品绝对精品。
      

  8.   

    软件开发其实属于“Anything is possible”,如果所有分支都要考虑,就是“Mission Impossible”。
    所有的需求分析、设计、接口定义等工作,其实就是进行各种前提限定的手段,这才使得用有限的资源实现一定的功能有了可能。
    clear_zero 描述了软件过程,我给了代码实例,不冲突。
      

  9.   

    就别说做个优秀可亲快速的软件了,就“稳定没BUG”一条就难死个仍这是这几天看ActiveX Control文档的感想,因为最终用户的行为防不胜防,要把很多情况都考虑到或者按照楼上的说法都限定到,也是超级难的。想想都头疼。看来没什么职业是绝对好玩的。
      

  10.   

    Add-in MZ-Tools 的工具条\Other Utilities\Statistics
      

  11.   

    另外,老马写1万和我写一万很不一样,他高级技术用的多,代码里的技术含量比我写的高很多。API、HOOK、subclass等技术用多了,我还没写过太多,距离老马的一万应该还是有段距离的。
      

  12.   

    刚学msdn2001,在这里只能说是个搞硬件的,一两年编一次vb,还是用于控制。
    小体会如下:
    1.我喜欢自低向上的编。先把和硬件发生关系的程序模块调通,再做楼上说的其他90%的杂活儿。
    2.程序大了,还真得考虑一段时间再下手。
    3.有些还要搜些素材,别人编好的程序看一下。例如:dde和winsock  我是先在网上下个好例子试通了,再加上自己 的东西。真所谓:“天下文章一大抄,就看你会抄不会抄”。
    4.搞硬件的还简单点,硬件、软件的搭配自己说了算。
    5.搞管理软件的最痛苦之处,在于你要去了解客户的使用环境和资料。有些是你不感兴趣的内容。你要在短期内去了解比客户知道的还要多的内容,才有可能完成客户的需求。所以我是干不了这个!
    6.建立自己的程序库,需要的时候贴进来。
    7.自己搞不懂的,有时msdn也没说明白,到csdn\vb请教
      

  13.   

    #39楼 够用就行!!!不一定技术含量高的就是最好的。送一句经典:控制马桶没有必要用DSP,机械按钮是最保险的。具体要看想搞定的对象,够用就好,所以没学C++!简单最重要!!!