1、改造还是新建？
系统本来有A，B，C,D四个页面，其中B是详细页，其他的都是一些概要的页面，大约如下：
A，C,D的模式，HTML大约如下
<ul>
<li><a href=”B”><img src=”image”/></a></li>
……
</ul>
而B就是A，C，D链接过去之后的详细页。而且，B本身是可以通过URL直接访问，不一定受限于前面3个页面
最近产品需要增加一个PV功能，主要的功能是记录从A中过来的访问B页面的次数。
负责实现的同事决定利用系统本身具有的B页面的记录功能（记录访问B的PV)，直接改造原有的记录功能。将A到B的URL中加一个参数以此标记来源为A。而我对这个设计的意见是，他把两个不同的PV揉合在了一起，而且会因为对老数据的不处理而导致以后提数据的误差。我的建议是，原来的B的记录功能保留不变，增加一个A到B的记录功能，也就是在A页面的每一个到B的a中添加一个onclick事件，以此来记录A到B的次数。这样子一来方便以后统计；二来，因为B本身也不仅仅是一个页面而且是一个子系统的入口，如果以后该子系统独立了之后，对于这些PV的改动将不再会影响到一个单独的系统；三来我们不需要通知C，D有这样子的改变，如果以后C，D也有此类需求，重构也只是一个简单的事情。
2、很多是一个推搪的理由吗？
这个也是在系统开发中遇到的，还是上面的几个页面。因为产品的几次改版，A、C、D的变动比较大，于是A访问B的URL中少了一个约定的参数MissParam（暂定这个）。于是我在处理这种请求的时候将MissParam统一的改为了null（其实这个处理是因为之前很多有用户邮件中到B的链接都少了这个参数）。今天在系统修改的过程中有一个同事过来跟我说，你这个参数（MissParam）不对，我都没有传给你，你怎么多出了一个null出来（原来URL：B.aspx?tttt=xxxxx，处理后的B.aspx?tttt=xxxxx&MissParam=null)。我当时就说，这个是因为你传的时候没有带这个参数，我统一规整成了null。他又说，你这样子不对呀，你改一下。。。。这类的。然后我就说，这B的访问约定一直都是有的，而且A以前有带MissParam参数，现在没有了，很显然是之前的修改搞丢了，要不你改一下吧。他说了一句，我这边很多，怎么改？我无言。很多真的是个理由吗？
3、站立会议真的有需要
不知道为什么，现在开发的时间特别多，每一次一开会就2-3个小时，有时候一开就是一天，开完这个开那个。特别是需求评审，一开起码是一个上午。其实最主要是3个原因。一是会前准备不足，每次开会都说开就开，搞到发起会议的本身对会议内容也没有充分的认识，参见会议的到开发都不知道开什么会，更别提是准备会议了，完全秒杀了墙上的不开无准备的会议的宣传画。二是会上扯蛋的时间比较多，因为项目组中总有一部分人是比较空闲的，所有每次开会这部分人就成了活跃分子（这部分人其实是不确定的），会议中总会有20%左右的时间浪费在这无尽的扯蛋过程中。三是会议室有凳子。于是我想起敏捷里面的站立会议，其实这个真的很必要，记得上次迁移服务器，涉及到那么多的接口，4个部门，我们在会议室中站了半个小时就把迁移的顺序和测试的重点都列出来了，究其原因是因为每一个人都有准备，都知道要做什么，还有就是每个人都站着，没有时间也没有精力扯蛋，开篇直入主题，讨论完，走人，发会议纪要。
4、了解问题的根源很重要
在测试服务器上突然之间出现了很多WebHttpException-The-remote-host-closed-the-connection-The-error-code-is-0x80072746。异常信息如下：
System.Web.HttpException: The remote host closed the connection. The error code is 0x80072746.
at System.Web.Hosting.ISAPIWorkerRequestInProcForIIS6.FlushCore(Byte[] status, Byte[] header, Int32 keepConnected, Int32 totalBodySize, Int32 numBodyFragments, IntPtr[] bodyFragments, Int32[] bodyFragmentLengths, Int32 doneWithSession, Int32 finalStatus, Boolean& async)
at System.Web.Hosting.ISAPIWorkerRequest.FlushCachedResponse(Boolean isFinal)
at System.Web.Hosting.ISAPIWorkerRequest.FlushResponse(Boolean finalFlush)
at System.Web.HttpResponse.Flush(Boolean finalFlush)
at System.Web.HttpResponse.Flush()
。。。。
于是同事就说，你看每一个异常都指向了HttpResponse.Flush()，这个函数，而且我看过你写的代码，有调用函数Response.Flush()，所以肯定是因为你这里的代码
Response.Write(some add script tag text，eg：<script href=”ssss” type=”text/javascript”></script>);
Response.Write(some add script tag text);
Response.Write(some add script tag text);
Response.Flush();
还没有完全输出完全，客户端的js就开始执行了导致的。
其实如果是一般情况下，我肯定是不予理睬的，可是当时他是当着测试面这样子说的。我于是幽幽的回了一句，这是服务器的异常，而且我输出的是tag，不是js函数。
很多时候我们很容易根据一点点的线索就直接断定问题就在这里。但是问题真的有这么简单吗？
（PS：我还没有找到问题的根源，有知道的同学告知一声）
5、自信很重要
今天比较郁闷，陪同事debug了2个小时。原因是同事的项目调用我写的接口一直不成功，而我本身自己的项目调用没有任何问题。搞了两个小时，终于崩溃了，发现问题好像不像想象的那么简单，于是问同事拿了份代码，在自己的机器上调试，这个时候，神奇的事情发生了，所有的浏览器都可以调用成功，包括同事不可以的IE8.额的神呀，于是把同事叫过来，演示了一下，他承认了他人品有问题。有时候人还真的需要点自信。如果一开始就有信心，叫同事装个FF或者chorme，是不是就可以绕开这个rpIE8了。
