大家在工作应该养成善于总结的习惯，总结你所学习、使用的技术，总结你所工作事项的比较好的地方，善于总结不断的沉淀优化自己。
适时停下来总结下过去走过的路，才能让我们的未来走的更坚定。文章转自JamesLi，没有全部转载，简单摘录，文章如下：
因为马云说了，今天很残酷，明天很美好，很多人都会跌倒在迎接明天的路上。朋友，请坚持，再坚持。无论你是否可以得到一个笑到最后的光环，这不重要的，真的，重要的是你的家人因为有了你的努力，你的付出，他们可以高兴，可以快乐，可以无忧虑的生活着。
1、经过多年积累的通用类库Utility Class Library
.NET Framework已经是一套非常不错的类库，现在在互联网上搜索，.NET的API几乎就是标准的API。一说到打开文件，马上会找到很多StreamReader, File之类的例子供你学习参考，一提到反射，CreateInstance, BindingFlags这类的单词也会碰到很多，为了熟悉这一套类型库(FCL)的用法，至少花了二年的时间。大部分的时间还是在做项目，而不是拿着老板的工资，练习API的用法，所以我说的两年时间，还是很短的时间。把做过的项目中用到的公共模块抽取出来，命名为Common,Control,Component三个项目，然后把到统一的Utility解决方案中。经过反反复复的修改，维护，现在已经很方便，很好用。大部分的项目都会引用这三个项目，在使用过程中发现问题不段完善，而不是拷贝代码，这样积累起来，做项目越来越方便。
2、ORM 对象关系映射
在没有熟悉ORM之前，是用Enterprise Library+Code Smith的模板，搭建了一套快速应用开发的解决方案。熟练，稳定，快速生产代码和调试方便，这种状态维持了两年。接触到LLBL Gen的ORM框架后，照葫芦画瓢，学习它的查询语法，学习它如何对数据库进行操作，甚至到最后，干脆来分析一下它的源代码，于是有了几篇文章
LLBL Gen 3.x 源代码追踪与解析 Type Converter 类型转换器
LLBL Gen 3.x 源代码追踪与解析 验证Validation的原理和流程
依靠这股学习的冲劲，居然也完全接受和学会了ORM。反思过去，一直没有下定决心学习NHibernate，做项目一遇到问题就退缩了，改成原来的老套路，真有些后悔。引用老外的句子，Just Do it。不要为部分人的观念左右，比如NHibernate性能不好，或是难于维护映射关系，当使用NHibernate的经验达到一定程序时，你会找到办法来改善这些，可是，还没有学之前就怀疑这些，这不是治学的严谨态度。还好，还有一次机会，你可以应用到Entity Framework上面。想办法在你的项目中用上这些实用的技能吧，短暂的痛苦过后，换来的是长期不用加班，早回家和家人团聚，技术学习的付出，它的回报比率相当高。
3、Windows Forms开发框架, ASP.NETWeb开发框架
经过项目的积累，对于通用的数据输入窗体Entry Forms, 报表呈现窗体Report Form,查询窗体Query Form，大多都是相似的，只不过换了个数据库和表。于是，把这一块内容抽取出来，做成框架，独立维护，也逐形成了开发框架。比如，要对Northwinds数据库的Customer表进行读写，只需要继承于EntryForm,并设置它的TableName=”Customer”, 重写几个rountine般的代码，就完成了功能，速度的稳定性超级好。对于Web,一套Web Menu,Tab，TreeView构成基本的页面布局风格。对框架页面，Top显示Menu，Left显示Menu的明细项目，Right显示明细的操作页面，基本的页面框架就这些，再封装成JavaScript和.NET代码可以一句话调用的代码，配合集成权限判断，通讯等技术，Web开发的通用框架也初步形成。Web开发中麻烦的地方还是在页面布局，做到美观大方就可以了，不需要达到艺术的境界，还得考虑要脱离美工的依赖，这是迟早的事，你不可能回避。
4、代码生成 Code Generation
这项技术经过多年的锤炼，已经相当有积累。Visual Studio本身也是个代码生成器，帮助生成骨架代码，和MFC+Visual C++ 6一样，非常相似。再后来，自己写了个代码生成器，可以根据选择的数据库表，生成代码。再积累，又发现了Code Smith这个好东西，于是乎所有的代码生成都转换到Code Smith平台上来。有时候并不能总是有Code Smith可用，在小量的代码情况下，又有了运用Reflection+Code Dom生成代码的经验。Code Dom是一套程序代码，可同时生成VB和C#两套代码的好工具。再到后来，接触到ORM框架的代码生成，于是乎有了这几篇文章
Template Studio 模板开发入门 Lpt templates Development
ORM框架-工具-产品开发之四 开发代码生成器 Template Studio Development (一）
ORM框架-工具-产品开发之四 开发代码生成器 Template Studio Development (二）
微软技术实践 智能提示的模板编辑器Template Studio 和 查询追踪器 LLBL Gen Profiler
如今基于模板的生成器T4又出现于江湖，虽然出身名门微软，似乎也没有太多的passion和精力考虑移植到T4。
5、报表 Crystal Report和Reporting Services
曾经在一个公司的软件部门做报表，做了一年多，每天的工作就是负责SELECT数据，然后Sub Total/Grand Total。这一年多的锻炼使我明白了计算机科学技术的基本要求，计算要正确。把数据值加起来求和，或是求平均值，这么看似简单的问题，付诸于实践中才会明白要做对很不容易。比如Decimal.Round方法的将小数值舍入到最接近的整数问题，和数据库中的round函数，这些问题加起来，需要折腾一段时间才能弄懂。没有多少捷径，多练习一下分组，求和或是用代码生成数据，再传递到报表中。最近做出来的报表平台，也是吸取了这两者的通用之处，以达到不同类型的报表，都可以在报表平台中运行，因为有的用户熟悉Crystal Report，有的用户熟悉Reporting Services，兼顾两者。
6、通讯组件 .NET Remoting,WCF
在项目中多次使用两项技术，最后就考虑到把它提炼出来，做成通用的公共代码，应用到新的项目中去。一旦考虑到提炼，这个过程就开始发生变化了。我会设计一个基础的模型项目，它会实现所有的需要的通讯功能，在实践应用中，则根据需要，把部分代码应用到项目中去。比如数据打包这个环节，就是把一些基础的数据，打包加密发送到指定的socket接口中，再把它还原成原始的数据，这个过程本身复杂，但是接口调用代码却很简单。还有Remoting技术，一个简单的接口方法ClientProxyFactory.CreateInstance<>泛型方法，就可以达到在项目中应用.NET Remoting技术。虽然WCF技术比较新，做技术的人员都喜欢追求新的，抛弃旧的，但我以为，.NET Remoting技术还是相当有价值的，至少我见到很多项目还是用这项技术。
请参考这篇文章： .NET Remoting过时了吗？为什么公司的项目还是选择用.NET Remoting,而不是WCF?
7、工作流 Workflow
当实现了一套自定义工作流系统后，才明白工作流活动的本质就是固化的代码片段，工作流是驱动这些活动实现业务。从rehost工作流设计器，到自定义Activity，集成SQL Server的持久化服务，传递业务实体，并且激活睡眠的工作流，自定义业务规则并求值，工作流就像是个玩具拼盘，你需要把写好的代码片段(Activity)添加到流程中，通过条件启动执行。时不时的还要用Reflector反编译，参考.NET Framework是如何实现IF-ELSE活动的，如何实现CodeActivity活动。工作流不是万能的钥匙，当有些流程只有等项目实施之后才能确定，或是依据不同的条件或部门，流程不一样，这样的流程考虑用工作流。而标准的流程，比如销售流程，报表单-> 销售单-->销售送货，这个流程是标准化的，不同的企业可以考虑不需要这里面的部分流程，但是我以为这一块就不需要用工作流来实现。
在学习工作流的自定义表达式的过程中，又学习到了Script.NET脚本语言，请参考这几篇文章
.NET 动态脚本语言Script.NET 入门指南 Quick Start
.NET 动态脚本语言Script.NET系列文章汇总 非常精彩的应用举例
掌握了这几项技术，工作越来越有信心，最重要是的很少加班，按时下班回家。有了充分的时间休息调整，为以后的发展打下基础。以前天昏地暗般的加班，天天加班，项目还是死了，现在做产品了，每天按时下班，项目还进展顺利。生活质量也有了明显的提高，引用别人的话，跟对人，做对事，整个世界就对了。