开发心得(2)

软件开发小结

1. 在不同分支上同步修改Bug时，切记不要手动拷贝修改，而是通过svn自带的merge功能来合并，优点是，可以让分支合并人员明确知道在此分支上面做的修改已经合并到主线分支上面去，而手动拷贝修改，在SVN上面的log记录中不会有合并的标识，容易造成误解
2. 代码不是写的越多越好，保持对提交代码的克制，保持评论的克制，你的提交、你的发言、你的转发代表了自己的观点。
3. 提交测试Bug时，一定要自测，不要自己骗自己，不要自己被自己的辛苦所感动，如果是快要到下班的时候，千万不要因为快下班了而放松对提交代码的克制，宁可晚一天提交，也要保证提交的合理性。
4. 判断错误码时，如果某一个返回值只有两种是正确的值，假如是0和1，返回其他的值都是错误的。那么在判断的时候，可以判断此值只要不是这两种正确的值，就都认为是错误的。在返回错误时，要明确区分为空和为0这两种情况，一个错误码只和一种错误类型相关联，比如返回0，既可以代表为空的错误，又可以代表为0的错误，那么这个错误码就不能使用,在自己设计函数返回值的时候，要特别注意。

工作小结

1. 当需要找另外一个部分的员工寻求帮助时，如果此人员修改，可以直接打他的手机，询问接替他工作的其他同事，这是最快的方法。

2.当视觉设计人员给出的设计稿中的标注和实际给出的图片大小不一致时，需要询问以哪个为准，如果以设计稿为准，那就需要拉伸图片，如果以实际图片为准，那就和设计稿不一致。商量好最终结论后，在JIRA上面做好记录。
3. 产品人员提出来的需求，需要开发人员去Check,开发人员设计的产品，由测试人员去check。
4. 当打包一系列文件给他人时，最好建立一个新的目录，把需要的文件拷贝到新的目录里面去，然后对这个目录进行整体打包,发送给他人。这样，当别人收到这个文件时，很大可能会放在桌面上，解压后，解压到单独的文件夹里面，方便查找。
5. 需求是针对功能的，测试是针对用例的。开发人员，按照功能点去开发，期间处理各种用例所指示的情况，当测试用例没那么完善时，很多地方的做法需要和产品确认好后再做，相关的确认要做好记录。