项目经验分享[转自min.jiang]

    最近三个月，我非常荣幸的做为TeamLeader带领几个小组成员做了一个国外项目，这里想为大家分享一些小经验,尽管我佣有六年多的项目经验，但我一直的方向是架构师。大家知道架构师一般情况是偏向技术方向，我也不例外，前三年，主要精力都花在技术架构上，挖空心思在通用平台上做出自己的东西，体现个人价值。但最近一年也想在项目管理上有所突破，有人可能认为方向走偏了，但我不这样认为，在中国的软件环境下，在很大程度上，公司更希望全才，或者说有些公司并不仅仅希望架构师只懂技术。而架构师如果一味的只走技术路线，在某些方面会存在缺陷：

1：与人沟通
    这个很容易理解，技术人员一般情况下不会和太多的人沟通，大部分情况也就局限于自己所属的Team，但是做为一个PM，你有可能会和产品经理，客户经理等人合作，这是普通程序员不太方便接触的人群。而往往人与人之间的沟通非常重要，沟通的顺畅可以让大家做事都比较顺利，反之，累死但结果并不太好。
    所以我认为，如果做为一个沟通能力非常强的架构师，那么会让他非常容易的被大家接受。

2：每个公司对架构师的理解不一样
    有些公司比较注意架构师的技术水平，所以这类架构师会负责技术部的所有技术难题(比如一些B2C网站，他们也许注重的是架构师能够解决可扩展，性能，平台通用的问题)，但有一部分公司对技术要求并不太强烈，他们也许会要求架构师更多的懂业务，或者能够带领团队完成代表公司标志性的项目。
    尽管往一个方向走下去是最佳方法，但是能够在某一方向做的出类拔萃的人毕竟是少数，何不给自己多些选择呢。

3：如何快速在团队中建立自己的地位
    每个人都想在公司表现自己，但如何让大家认可你，不同的人不同的项目，需要用不同的方式去体现。我个人认为，既然我的方向是架构师，而且我也想将自己以往自己认为不错的项目经验分享给大家，那也许最好的方法就是自己亲自带领团队做项目，并在项目是慢慢应用自己的经验。让一个成功的项目去说服大家。
    
    下面来分享一些项目中的心得：
    1:英语很重要
    由于是国外项目，所以对英语有非常高的要求，由于本人英语太差，口语基本没有与人对话过，需要一个懂英语的高级经理为我们团队做名誉上的PM。平时负责带领我和外国客户开电话会议，以及对外的邮件沟通。实际上这种方法是没有办法的办法，最好是自己懂英语，直接和外国客户沟通，少一级的沟通会顺畅很多，也不会因此消费更多的人力资源。
    2：小的技术细节很重要

我们有一个微软MVP的架构师，水平相当资深，但他对技术细节要求非常严格，这里分享一些我们遇到的问题：

1>:对于web项目，图片不能过大。

实际上应该说，整个页面的大小不能太大，这里我认为一般不超过300K,如果太大，加载过慢也许是所有用户不能接受的，毕竟大家的时间都非常宝贵呀。

我们的问题在于，有一张背景图达到了400K，当项目功能研发完成后，我当时也发现了这个问题，因为我一直对web性能非常关注，所以我马上对图片进行了优化，由400K 下调到110K，但不巧的是，我们理所当然的认为他应该在测试环境上做测试，没成想，他到了另外一个环境做测试，而我并没有将此次变更同步到两个环境，所以发现了此问题，让他认为我们非常不专业。

2>:网页的charset设置很重要

如果你的网站涉及到多语言，那么为了让所有不同国家的用户不至于看到乱码，那么需要为网页设置字符集。
           方法很简单，但如果没有设置而被别人发现了此问题，那么别人同样也会认为你不专业。
           <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

3>:第三方组件的版本问题
          我这里所指的第三方组件，就是指你的项目是引用的别人开发的组件，比如jquery,log4net之类，但是有人也许非常注重你所引用的组件版本，比如jquery,他更加希望你的项目中引用的是最新版本，因为事物总是进步的，新版本也许有更多的优势。至于这点，你可以认为是多此一举，也许你能列出N多种不同意的观点，起码我自己也认为够用就行，但我们需要根据公司架构的要求来，否则会影响最终的项目上线。

4>:TeamLeader需要更多时间来检查项目质量

这里所指的项目质量包含如下方面：

1):项目进度
                   是否有按预期的进度在发展,一旦偏离大方向，以后就越来越控制。
              2):每个功能完成的质量
                  尽管从功能上讲没有问题，但从技术实施的手段也许存在一定问题，也许会为以后的重构带来隐患。我们不能说完成功能就行，需要在一定程序上考虑到你的代码的可维护性，可扩展性。比如项目在第一期交付成功了，当以后客户再提出部分变动时，由于我们的代码可扩展性太差，需要花很多时间去完成，客户就会认为他们的成本太高，我们团队的效率太差。
             3):需要花时间从整个技术角度来审查
               比如我在功能研发完成之后，以我自己的经验，我也发现了背景图片过大问题，但由于我也有相当大的业务功能编码任务，故导致此问题发现的比较晚，以至于架构师发现了此问题，尽管他没有按我们的要求去指定环境做测试。
              所以teamleader不能将自己大部分时间花在具体的业务功能了，需要更多的去关注项目的进展，完成质量，整体的架构以及于客户的沟通。

3 ：学会自己解决问题

有人会说，这不是费话吗，但我想表达的，有时候，有些问题别人无法帮助你，或者公司无法给你提供即时的资源帮助时，如果你想让项目顺利上线，你需要自己想办法解决你不擅长的问题。

1):我们需要自己优化图片

一般情况下，每个项目都会有美工，比如她设计的页面的背景图过大，那么需要她自己去优化，但如果此时正好美工在其它项目中工作，无法为你即时提供帮助时，你需要自己想办法去做优化。

2):teamleader需要设计项目原型

这在某些公司是由产品经理来完成的，但如果没有产品经理，那么teamleader就是产品经理。

3):。。。。。。

==============================================================================

上篇(项目经验分享(上))总结了一些琐碎的小经验，这篇来讲一讲在项目中如何解决一个问题，说它是问题，只是针对我个人来讲，因为以前没有处理过类似的问题，主要是分享下我处理这个问题的过程及方法。
   
   项目技术背景：
   1:asp.net mvc 3 项目
   2:登录机制是采用membership
   3:认证采用Forms验证
   4:EntityFramwork做为数据访问
   
   
   问题描述：
   当我们的项目部署到租用的美国服务器上后 (据说是一个云服务，说的通俗点可能就是在虚似机上的一个IIS站点)出现了用户需要频繁登录的现象，具体来讲大约在10分钟之内就会要求用户重新登录。
   
   阶段一：
   问题是客户发现的，他们在UAT时，提到了用户需要频繁登录的问题。
   
   我的反应：
   由于我提供给大家UAT的是一个公共帐号，大家均使用同一帐号登录，可能会发生不同的人注销同一帐号的现象，可能存在相互的影响，故建议用户重新启用一个全新的帐号。
   
   问题：上面的项目技术背景提到了是采用Forms验证，而我们是采用默认的Forms验证机制，即将数据存储在客户端，以cookie的形式，故即使多人使用同一帐号，发生不同用户注销同一帐户的现象，也不会影响到其它的用户的登录状态。这也是当时没太注意的地方,没找出问题本质的情况下，凭经验下结论。
   
   阶段二：
   客户再次反应此问题，而且他们明确了自己使用的帐户是私人的。
   
   我的反应：
   意识到事情的严重性，马上组织测试人员做了仔细的测试，发现问题确实存在，当时就开始着手解决这个问题，毕竟这属于一个优先级最高的问题。
   
   经过和同事讨论以及网上搜索后得到如下方案：
   1：在web.config中设置forms的一个time out
   我们原来的配置如下：

<forms loginUrl="Account/LogOn" defaultUrl="Account/RaceTemplate">

但发现这个值即使不设置，默认时间也有30分钟，远大于我们出现问题的10分钟，但抱着试试看的心情，将之调大到300分钟，问题依旧。
   
   2：也许和session的设置有关系
   我也忘记当时为什么联想到session了，也许是我原来的项目都是基于sessio机制的验证原因吧，但同样的问题是，session的默认机制也是存储在进程中,且超时时间为20分钟，我同样抱着试试的心情，将这个数值调整到300分钟，问题依旧。
   

3：考虑是否和Membersip的设置有关系

因为我们登录是采用membership，是否是它有相应的设置，于是开始咨询同事，结果是，我们的项目是第一个基于membership的项目，网上搜索无果。

   问题：这是没有搞清楚Forms验证的机制，错误的想法，误认为和mebership本身有关系。

4：怀疑服务器提供商的产品会定期回收我们站点的应用程序池
   这是有依据的，因为我们在自己的本地测试机器上做测试，一点问题都没有，从不出现频繁登录的现象。于时让相关同事发邮件咨询服务器提供商，以等待结果。
   
   5：做好服务器提供商无法给出满意答案的准备。
   如果应用程序池会被定期回收，而服务器提供商无法即时解决被回收的问题时，那么我们尝试将session存入在数据库中。毕竟我们不能一直等别人的反馈。
   
   问题：这也是没有搞清楚Forms验证的机制，错误的想法，误认为和session有关系，好的是，我们当时只有这个想法 ，并没有着手去做，因为它有如下问题：
   
   1):这是一种逃避问题的方式。
   即使存储在进程中有问题，那么我们需要找出其中的原因，而不能因为它有问题就想其它的方法，没有治本。
   2):session存储中数据库中需要部署很多的数据库脚本。
   这样一来是工作量增大，二来对现在的系统会有一定影响。
   3):我们租用的数据库空间很少，只有几十M，怕影响业务数据的使用。

   从技术手段下手

由于服务器提供商未在短时间内给出正确答案，我开始从技术手段下手，从根本上排查原因。
   此次对Forms验证做了比较详细的了解，排除了session和membership的干扰,讲的简单点Forms验证原理是这样的：
   
   首先创建一个用户的票据，经过相应算法的加密，最后将票据保存在cookie中，验证的过程是首先读取用户cookie，如果存在的话，再将票据解密，如果没有问题即验证通过。
   
   于时，开始手动编写登录逻辑，原来是直接调用授权代码：

FormsAuthentication.SetAuthCookie(model.UserName, true);

现在开始尝试以编程方式来授权，即不从配置文件中读取相关设置，于时有了如下代码：

FormsAuthenticationTicket authTicket = new FormsAuthenticationTicket(1, UserName, DateTime.Now, DateTime.Now.AddHours(20),             
true, UserRole); // User datastring encryptedTicket = FormsAuthentication.Encrypt(authTicket); //加密
            // 存入Cookie            HttpCookie authCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);
            authCookie.Expires = authTicket.Expiration;
            Response.Cookies.Add(authCookie); 
 

兴奋的部署上去之后，仍然是失望而归。
    
    再次尝试对读取cookie做手动编码：

string cookieName = FormsAuthentication.FormsCookieName;
            //get Cookie.
            HttpCookie authCookie = Context.Request.Cookies[cookieName];
            if (null == authCookie)
                return;
            FormsAuthenticationTicket authTicket = null;
          
            authTicket = FormsAuthentication.Decrypt(authCookie.Value);
            if (null == authTicket)
                return;

         
            string[] roles = authTicket.UserData.Split(new char[] { ',' });
            FormsIdentity id = new FormsIdentity(authTicket);
            GenericPrincipal principal = new GenericPrincipal(id, roles);
           
            Context.User = principal;

还是失败则归。
     
     最后在网上查看到，如果应用程序池被回收,它会重新分配一个machineKey,而这个machineKey会影响到cookie票据，它有两个重要的属性：
     validationKey，
     decryptionKey
    它和上面说到的对票据数据的加密，解密,验证问题有直接关系，这里我就不多讲了。如果应用程序池被回收，那么对应的validationKey就会不相同，即与之前的cookie就无法匹配上，这样就造成了我们需要频繁登录。
     
     微软也非常建议在web项目中配置明确的machineKey,理由如下：
     1:可以解决站点重启，或者是应用程序池回收造成用户验证失败的现象。
     2:如果是负载均衡的站点，那么他们之间最好也共用同一明确的machineKey。
     
    问题总算找到了，问题也解决了，现在的问题就是应用程序池为什么会被定期回收，这个问题的解释就不是我们开发组能回答的问题了，我们完成解决了对他们的依赖，即使他们不做解释不做处理，我们的问题同样也得到了解决，从而不会影响到用户体验以及最终项目上线。

总结：
         之所以这样一个问题困扰我们这么些天(大约一周时间)，首要原因是没有详细了解Forms验证的机制，这是我做的第一个Forms验证项目，所以走了些弯路,容易凭经验被一些其它信息所干扰。其次是租用服务器问题，我们对于他的定期回收原因，还在排查中，如果不定期回收，此问题也不会出现。所以当出现修改默认值不起作用时，请转换你的思维方式去尝试从不同角度分析问题。