今天整理电脑，发现了去年入职试用期时的每周工作心得。可惜只在试用期公司规定写了，转正后就没写过了。现在看看这些心得，本人其实也是个有思想的人呢。晒晒。
(2012.08.13-2012.08.18)
这周在封装station数据库时，对于某个功能的方法该写在哪个类里，类该如何分布，按什么来组织类，怎样让人很快的明白这个结构的意思… …发现自己在对于整体程序结构布局上还存在一些欠缺。目前来说使用C#语言完成某个功能或某个模块已经不存在多大问题了，但是怎样才能写出质量很高，架构更清晰的代码还需要多进行思考，要思考编程思想的理论如何在实践中体现出来。
(2012.08.20-2012.08.25)
这周写了一些代码，包括修改的和新写的。写的时候只是为了解决某一问题而写，写好后再返回来看整个代码觉得不够严谨，于是再修改。后面测试功能的时候，又发现再换一种写法可能效率更高，再次做修改。从中体会到了两点：
1、
写代码时和写代码后都要多方面思考，将各种可能出现的情况在代码中做好处理，这样才能减少bug的出现，软件才让人用的放心；
2、
写代码前要做好设计，虽然每次也做了设计，但是不够详细。设计应该大于等于写代码的时间，因为只有在写之前做好了设计，画好流程图，将各个分支都列出来，在写代码时就能考虑的更全面，这样写好的功能模块问题就少一些。
(2012.08.27-2012.09.01)
这周在测试功能的时候发现一个规律，自己写好的代码很难测出问题，因为自己写的流程，那么在操作的时候就按照自己预先设计好的流程来测试，这样有些极端情况就发现不了。而且由于以前的惯性总是：写好代码——交付测试——改bug。自己对于测试不是很看重。其实作为一个成熟的程序员来说，测试也是写代码的一部分，因为如果写好了代码然后交付测试，测试后没有发现bug，那一定是大牛的水平。所以现在对于自我测试还应该多加强一些。
(2012.09.03-2012.09.08)
这周修改bug，有的一次性就改好了。有的本地测试没有问题，但是经过测试部还是测出了bug，然后又修改。比如导航条的问题，因为之前用的是图片没有修改，但是给测试的版中有的图片被删掉了，结果就有问题了，后来改的时候将这个模块里所有的导航都改为ListBox了。以前看过一句话：如果某件事情可能会出错，那它一定会出错。代码也是一样，如果觉得这里有可能出问题，那么到时候bug一定会有。所以在写的时候需要将所有的可能性都列出来，然后通过调整流程，增加判断进行逐一避免。最好的结果是：写出的代码可以有流程上的问题，但是一定不能有功能上的问题。
(2012.09.10-2012.09.15)
这周相对事情比较少，改bug一般都是对细节的调整。对一个软件来说细节也确实很重要，一个小bug、一个小细节的不人性化或者让用户不会使用都可能让用户失望。从程序的角度来说就是要做好程序的逻辑和程序的结构合理，逻辑正确的话对于就能很好的避免可能出现的问题；而且在排查bug时也比较确定这段代码是否有问题。而程序的结构也很重要，结构合理对于后续新增功能和调整旧的功能来说都比较方便，而且能避免由于改动引起的问题。程序做好了之后，应该再从程序员的角度看一下用户体验怎么样，因为程序写出来后程序员对于内部的流程是最清楚的，所以也很清楚哪里可能出错、哪里可以通过一些小方法提供方便、什么样的流程会导致程序执行容易出错、以及现有的资源能做哪些功能，效果如何，是否需要做等等。所以一款用户体验好的软件不仅需要策划人员好的创意，测试人员的用心测试，更需要程序人员的负责态度和防患于未然的心态。
(2012.09.17-2012.09.22)
对于软件来说是不可能单独运行和工作的，它是需要硬件的支持，以及一些对操作者的约定，比如要用到系统文件，系统文件就必须存在；要用到的必要的配置文件，那么配置文件就必须有。
因此，在编写代码的时候需要考虑这些外界条件，因为即使代码本身没有问题，但是当外界条件不满足而导致程序崩溃，这也是程序的问题。所以，程序总是要考虑到最坏的情况，这样才能保证程序的健壮性。
当然，仅仅将程序做的很健壮，还是不够的。毕竟一款软件的最终目的是为了给用户解决问题，如果程序正常了，但是硬件环境没有达到要求，用户不能正常使用，那么对于软件来说还是失败的。所以，在程序部署的时候，也是需要软件人员来关注的。必须需要哪些硬件支持都需要告知硬件部署人员，以及可能会碰到哪些情况，对于硬件来说应该如何避免，哪些现象是什么原因等。
所以软件是否做完，不是代码编写完成，而是最终在用户环境上，用户是否能完成预期的操作才算完成。
(2012.09.24-2012.09.29)
1、
写代码还是需要细心。在写预订功能时，将预订方法的返回结果写成了一个类，但是在客户端每次当调用到这个方法时，服务自动停止了。找了很多可能出现的问题包括重新设置了服务的超时，还是不起作用。最后才发现，写这个返回结果的类中一个属性的get set 写错了。
[DataMember]
public string PayLimitTime
{
get
{
return this.PayLimitTime;
}
set
{
this.payLimitTime = value;
}
}
结果就死循环了，程序直接崩溃。VS提示功能太强了，一不小心就写错了，所以还是应该小心一些。
(2012.10.07-2012.10.13)
这周硬件同事反映了持续供电电源的问题，程序运行中切换持续供电电源的数据线端口导致接收不到信息。因为这种情况在真正使用中是不可能有这种操作的，所以写程序时没有做相应处理。但是在特定的情况下出现了，导致怀疑程序本身有问题。
其实对于软件产品来说，程序是最重要的一部分，但是程序并不能百分之百保证产品的正确，比如操作的不当、硬件产品不达标等都会影响到程序的运行。往往这些问题会被归咎为软件的问题，这需要软件人员和其他负责产品的人员共同交流，查找问题根源并解决问题。要认识到在产品中软件不是孤立的，而是和其他各方面协作的，是一个产品的组成部分。
(2012.10.15-2012.10.20)
1、看了项目中的一些代码，可能是编程习惯的不同，总感觉有的部分逻辑不好，没有考虑性能等问题。不过还是先从自己的代码入手，之前虽然对负责的模块做了一些优化，但是还不是很彻底，有些没有用上的代码，当时没有仔细看是干嘛的，所以也没有删除。后面需要抽时间清理掉。
2、想法要及时实现。有时总想写个什么功能，但是过一会儿又觉得可能用不上，就算了。其实这样不好，有了想法就应该马上用代码实现了，可能用不上，但是后面至少为类似的问题提供了一个参考。