RS项目可改进之处

RS项目可改进之处

多语言方案

微软推荐使用轮辐式方案，即把各语言包做成附属程序集，然后主程序使用ResourceManager来访问语言包，可简化现有的访问代码。MSDN里有详细说明。

数据验证

现有代码可以改进成，定义一个Model继承生成工具生成的Model，然后把验证逻辑写入自定义的Model，这样验证代码只存一处，可消除重复代码，降低维护难度，减少因代码不统一引起的Bug。

Linq是.net3.5的最重要的增强功能，不论是Linq2Sql还是Entity Framework，都能用面向对象的方式访问数据库，它们会生成partial class的Model，可以很容易的扩展验证功能。使用这样的ORM工具无需写Sql，能使开发更容易，效率更高，符合现代软件工程的需要。

各功能的实现方式

我所能肯定的是现有搜索、编辑页面的功能有更好的实现方式。 MVC的PartialView和Ajax是绝配，只需少量代码即可完美的实现以上功能，并消除各功能间的耦合和硬编码，完美隔离表现层和业务逻辑层，享受到MVC模式的真正优势。

编码规范

需要建立代码审查机制，消除代码中的杂乱的缩进，超长的行，低效的实现。只有漂亮的代码和严格的审核标准才能保证开发的质量，所以要用严格的审核标准来约束程序员，使其养成良好的编码习惯，人的素质提高了才能从根本上提高开发效率。

重构机制

我们的目标是相同的，就是要更好更快的实现系统需求。

分歧之一是实现这个目标的方式方法。您认为保持正在写的代码和过去同类代码的整齐划一能使团队最快的完成眼前的任务，并使当人员的任务调动时，别人能读懂并维护他人的代码。我认为应该放眼未来，把控大局，代码的统一性应建立在过去的代码是经过详细设计的基础上，否则就应该对其重构，这样才能使我们的工作成为思考与创新的过程，而不是在疲乏无味中拷贝代码的体力活，要勇于开辟星光大道，而不是延续以前的羊肠小道。代码一时的烂是软件开发的必然过程，关键是不要让其成为后续任务的模范。成功的路上充满了失败与错误，我们应该吸取教训，不重复以前的错误。

另一个分歧是，对改变以前的思路要付出的时间长短的判断。您认为许多开发中的困难会使新方案的研究花费大量时间，并且别人学会使用新方案也要花大量时间。我认为您把困难想的太艰巨了，MVC难吧，我们不是两天就学会了吗？我是底层写代码的，对底层代码的一草一木比您更清楚，我可以肯定的说我在这个团队中有最多的.net代码的知识与经验，当我提出一个方案时，我已经对其实现有了深入思考，当一个方案很繁琐，很难理解时，我必然不会提出它，因为它不是个好方案。

我比较注重了解底层实现的原理，比如MVC的UpdateModel方法的源代码，我研究过的。我对团队中其他成员也都了解过，我确定我和他们的区别在于我整个人的重心在技术上，我不炒股，有技术改变命运的理念，和钻研新技术的激情，比如Linq和ADO.NET Entity Framework，团队中可能只有我做过深入的研究。再比如PartialView的思想来源于Tony，但为何是我而不是Tony拿出了一套新方案呢，就是因为我的重心在技术，肯花时间去研究和实践。

我认为用新的更好的方案做出一个功能并不比旧方案慢很多，恰恰相反，它经常会比旧方案快很多，因为它更简单，别人也能够很快学会新方案，用一句话来证明这个结论，那就是“磨刀不误砍柴工”。几乎在所有情况下，即使新方案要付出多一点的时间，其大为提高的ROI也使这份努力很值得，使未来的开发更快速，大大减少整体开发时间。

重构需要勇气与对未来的正确判断，据我的经验，客户不太可能给我们一个星期或一个月来专门做重构，唯一的机会在于在眼前的任务中使用新方案，并抽时间重构以前的方案。 如果客户真肯给我们时间做重构，我们也应该建议他们给我们多一点的开发时间，而不是专门做重构的时间，应该尽可能早的采用新的更好的方案，因为越早改正错误，付出的代价就越小。

新方法、新理论都有可能是错的，或不合实际的，或不完善的，那我们是否应该抵触它们，限制其发展呢？答案看硅谷就明白了，硅谷的成功恰恰是因为它允许失败，容忍失败。没有失败就没有成功，所以我们也应允许探索性的失败和错误。马云的观点：最大的错误就是裹足不前，维持不变，只要改变，即使是错误的，也比不变要好，因为这让我们知道了什么是错的。所以我们应该鼓励创新，勇于打破一切常规。

测试驱动开发

这是敏捷编程的准则之一，它要求先写测试代码，后写功能代码，一切功能代码均是为了使测试代码通过。这迫使我们面向接口编程，顺便改善了程序结构，使模块间低耦合。

万事开头难，测试驱动开发与大多数程序员的习惯相反，所以刚开始的时候是很痛苦的，任何一种新技术或新方法都否定了以前的旧的技术和方法，我们不得不改变我们的习惯，学习新方法。要注意，如果新方法学的不到家的话，效果还不如用更熟悉的旧方法。敏捷开发也是这样，我们只用它其中一些观点，而不是彻底的贯彻它，效果可能真的不如不用它的好。所以当确定要用敏捷开发的时候，就要彻底的研究它，贯彻它。我对敏捷开发非常有研究，根据我的经验，我认为它是一套非常优秀的价值观与方法论，要采用它的理念需要的是一个有决心和恒心去贯彻它的团队。

页面HTML结构与CSS样式

这些东西应由有逻辑思维的程序员来做，美工并不擅长代码，现在的页面结构和样式定义，都有更简洁的实现。

站立会议应更简短

只用十句话来说明昨天的进度、今天的计划、以及面临的问题。一切细节问题应在会后一个一个解决，在会上的七嘴八舌太肤浅，无助于解决问题，因为细节的问题必须看代码，凭空口述没有实际意义。

做决策的方式

不同的思维互相碰撞才能产生灵感的火花，我的新方案并非我一人想出来的，而是大家共同努力的结果。当一个新方案经历过质疑和推敲之后，它才会变成熟。比如我提出的解决搜索和编辑功能的新方案，它是建立在您不允许Iframe的情况下探索出来的，其性能与可维护性和Iframe方案大致相当，其PartialView的思想来源于Tony，其搜索参数的改进来源于Adam，所以质疑与推敲是促进新方案走向成熟的必然阶段。现在我可以肯定的说，新方案已经可以经得起任何的质疑与推敲了。

我想说的是质疑与推敲的方式应该更正规一点，不应在没有深入了解其实现的时候，主观的肯定或否定它。没有调查就没有发言权，首先要深入分析其实现原理，客观的对比各种数据，然后再提出质疑或肯定的意见，促使新方案走向成熟。