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
我们原来的配置如下：
2：也许和session的设置有关系
我也忘记当时为什么联想到session了，也许是我原来的项目都是基于sessio机制的验证原因吧，但同样的问题是，session的默认机制也是存储在进程中,且超时时间为20分钟，我同样抱着试试的心情，将这个数值调整到300分钟，问题依旧。
3：考虑是否和Membersip的设置有关系
因为我们登录是采用membership，是否是它有相应的设置，于是开始咨询同事，结果是，我们的项目是第一个基于membership的项目，网上搜索无果。
4：怀疑服务器提供商的产品会定期回收我们站点的应用程序池
这是有依据的，因为我们在自己的本地测试机器上做测试，一点问题都没有，从不出现频繁登录的现象。于时让相关同事发邮件咨询服务器提供商，以等待结果。
5：做好服务器提供商无法给出满意答案的准备。
如果应用程序池会被定期回收，而服务器提供商无法即时解决被回收的问题时，那么我们尝试将session存入在数据库中。毕竟我们不能一直等别人的反馈。
问题：这也是没有搞清楚Forms验证的机制，错误的想法，误认为和session有关系，好的是，我们当时只有这个想法 ，并没有着手去做，因为它有如下问题：
1):这是一种逃避问题的方式。
即使存储在进程中有问题，那么我们需要找出其中的原因，而不能因为它有问题就想其它的方法，没有治本。
2):session存储中数据库中需要部署很多的数据库脚本。
这样一来是工作量增大，二来对现在的系统会有一定影响。
3):我们租用的数据库空间很少，只有几十M，怕影响业务数据的使用。
由于服务器提供商未在短时间内给出正确答案，我开始从技术手段下手，从根本上排查原因。
此次对Forms验证做了比较详细的了解，排除了session和membership的干扰,讲的简单点Forms验证原理是这样的：
首先创建一个用户的票据，经过相应算法的加密，最后将票据保存在cookie中，验证的过程是首先读取用户cookie，如果存在的话，再将票据解密，如果没有问题即验证通过。
于时，开始手动编写登录逻辑，原来是直接调用授权代码：
现在开始尝试以编程方式来授权，即不从配置文件中读取相关设置，于时有了如下代码：
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做手动编码：
//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验证项目，所以走了些弯路,容易凭经验被一些其它信息所干扰。其次是租用服务器问题，我们对于他的定期回收原因，还在排查中，如果不定期回收，此问题也不会出现。所以当出现修改默认值不起作用时，请转换你的思维方式去尝试从不同角度分析问题。