摘要： 一提到写文档，可能很多程序员可能会不屑一顾，但是，无论处于规范开发流程，还是就于逃避嫌责的目的，能够将自己所从事的工作用文档描述记录下来，还是一件很有成就感的事情，抛开其功用不谈，就个人的成长进程看，也是一个循序渐进式的好习惯，还是值得大家稍微关注一下的。 阅读全文

摘要： 想来，工作已经2年有余了，从进入公司的第一天开始，“产品需求”这个名字就一直萦绕在耳边，这也难怪，做产品开发这个行当，就注定要与“产品需求”打好交道，否则，只能给自己增加无尽的烦恼和忧愁，下面简单说下自己与“产品需求”之间的这点经历。 自己首先从修复产品的功能缺陷开始切入我们的产品，此时对需求的理解无外乎“正确”与“不正确”，因为既有的需求已经确定，但产品没有按照确定的需求工作，我的工作呢，就是修正这些“不正确”的代码，让他们按照“正确”的方式执行。 阅读全文

摘要： 今天在后台编写一个用户验证功能的时候，需要根据用户的不同权限进行不同的页面跳转，使用的跳转语句如下： Response.Redirect(“LogonIn.aspx”); 但是，总是提示下面这个异常：Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack. 阅读全文

摘要： 刚刚完成的一次实施支持，可算是给自己上了宝贵的一课，让自己明白在处理对产品的修改问题上必须严格按照操作流程，否则后果可能会非常严重！ 事情经过简述如下： 我们开发的一个升级工具，被实施人员拿到一个客户处进行产品升级操作，由于客户数据中出现了一种特殊的数据，导致升级工具在备份系统数据的时候，发生了异常，并被系统强行关闭，因为数据量比较大，反复重复3次，用了将近3个小时的时间，已经确认是工具bug无疑。 阅读全文

摘要： 写程序久了，明显发现自己的表达和沟通能力有所下降，当然了，以前也不咋突出…… 前天晚上，为了教老爸如何正确地调整播放器的声音，可是费了九牛二虎之力，当然，最终是搞定了，但从这件小事使自己联想到，我们这些做开发的在和我们的实施人员、客户的技术人员等沟通的时候，何尝又不是一样的道理呢，当我们沟通的内容没有办法达到双方都理解的程度时，沟通会变得极其困难，这就更加会加剧我们自己的焦急的情绪，于是更加让对方摸不着头脑，其实可能就是一个简单的操作，如果我们不能用对方能够明白的话来表达，就算是说一个晚上，那么对方还会是一头雾水…… 那么，怎样才能尽量减少沟通的代价呢？自己在这里总结一下自己个人的一些想法： 阅读全文

摘要： 最近公司面临重大重组，在经历了前一阵人员流动风波之后，我们的开发团队已经面临不小的压力，别的自己暂时也不想谈，只简单谈下作为一个领导和下属之间该如何共渡难关？ 为啥这么说难关呢？我还是结合自己个人的角度来谈谈自己的一点浅见： 在一个小的团队中，少则2、3人，多则8、9人，如何才能让团队关系更加融洽，如何才能保持大家持续的战斗力？ 阅读全文

摘要： 在编写代码的过程中，我们编写的类往往会有需要支持多条分支条件的情况，一般情况下，我们可能会通过设定一些参数变量的方式，来对这些分支条件进行区分，那么就引出了一个问题，我们是采取尽量少的变量来代表多种条件分支好呢，还是先根据条件性质进行区分，然后用不同变量分别代表好呢？ 本人也经常遇到这样的情况，这两种方式，当然各有利弊，前者可以体现简约精神，而后者更加注重分类，前者的弊端也很明显，就是会增加其他开发人员阅读我们代码的代价，相反，这正是后者的优势！ 阅读全文

摘要： 在团队开发过程中，发现bug和处理bug似乎是一件很平常的事情，但是，我们有没有考虑过，造成这些bug的原因，进而会占用我们大量调试时间的根源都有哪些呢？ 你可能会对这个问题不屑一顾，既然是bug，无非就是因为程序代码运行出错，或者由于相关设定没有正确配置的关系。没错，上面两种情况的确会造成bug，但是相对而言，这两种bug一般耗费的时间也不会太多，因为程序层面的问题或者配置方面的设定，基本都可以在很少量的调试过程中被发现，尤其是函数错误，一般情况是很容易定位的。 阅读全文

摘要： 写了这么久的代码，一直是照搬照套的成分居多，知道最近，自己设计和编码的内容变得多了，才逐渐感觉到数据结构对一个功能模块是多么的重要，下面谈谈自己的一点理解: 首当其冲，我们设计功能模块无非是对数据的处理，一个好的数据结构，不但能够简化我们的数据传递，更能在数据处理的各个环节达到简化处理步骤的效果。 阅读全文

摘要： 熟才能生巧，这里的所谓“生”，其实并非是“一下子就”的概念，但是，自己以前对它的理解就是这么的浅显，或许是自己的脑袋瓜子太过笨重，有很多的道理和东西，要重复N遍，还有可能会忘掉…… 阅读全文