【摘要】你经常会面临着将dev分支或者很多零散的分支merge到一个公共release分支里。但是有一种情况是需要你处理的，就是在你的dev的分支里有很多commit记录。而这些commit是无需在release里体现的。develop 主分支阅读全文 ...继续阅读 (13)

【摘要】我先基于develop主分支拉出一个功能分支（每个人和每个公司对分支的管理都不太一样，这里不需要太纠结。）。这里的develop是开发主分支，所有的开发功能代码都需要回归到这个develop分支中去。git branch -a –vv阅读全文 ...继续阅读 (20)

【摘要】两年前有机会接触过elasticsearch，但是未做深入学习，只是工作中用到了。越来越发现es是个不错的好东西，所以花了点时间好好学习了下。在学习过程中也发现了一些问题，网上大多资料都很零散，大部分都是实验性的demo，很多问题并没有讲清楚也并没有系统的讲完整一整套方案，所以耐心的摸索和总结了一...阅读全文 ...继续阅读 (16)

这篇文章内容会很短，主要是想给大家分享下我最近在做一个简单的rabbitmq客户端类库的封装的经验总结，说是简单其实一点都不简单。为了节省时间我主要按照Library的执行顺序来介绍，在你看来这里仅仅是一个简单的经验总结，但是在我看来这些经验只有在你真正的封装rabbitmq客户端库的时候且将你的客户端安全稳定的发布上线后才会真的发现这些问题。比如你的库只是链接单个Node的时候和链接高可用集群的HAProxy时候是完全两回事。当你未能在你的库里使用反向注入LOG接口的时候一旦在线上发生网络解析和序列化等一系列在线问题时候你是多么无能为力。当你使用同步循环获取队列消息的时候一旦发生异常你的链接就会断掉等等这些细节。我总结了我在编写这个library的时候慢慢稳定下来的过程和经验。至少目前来看网络上的文章，当然我是指.NET/C#方面的，都没有讲到这些问题，大部分的文章都是简单的介绍了本文链接：封装RabbitMQ.NET Library 的一点经验总结，转载请注明。 ...继续阅读 (60)

最近对软件开发有了一个新的认识，这个认识源自连续看了两本Craig larman大师的书籍《UML与模式应用》、《精益与敏捷开发大型应用实战》和公司目前的项目情况这两件事情一起碰撞导致的感悟。先说下前者，为什么会想到看Craig larman大师的书籍。其实我收藏的书籍已经上千本，在各个电商平台上都有帐号，目的只有一个就是收藏好的书籍。家里也堆了很多，没事浏览新书是我现在最大的乐趣。我相信有这种感觉和爱好的不止我一个人，家里堆上几十本书的在IT行业算是很正常的。书多了有时候不知道要看些什么也很正常，我的原则就是随时调整，看目前所面临的困惑。根据我以往的经验总结，在实际问题面前寻找答案最容易让你有新的感悟和提升。我相信书中自有黄金屋、书中自有颜如玉，要在对的时间看对的书，说白了就是在有困惑的时候就去寻找给你答案的这方面书籍。为什么要看Craig larman大师的书，是因为本文链接：软件工程—思考项目开发那些事（一），转载请注明。 ...继续阅读 (57)

最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。不能用好与不好来判断哪一种方法论，只能根据目前的实际情况综合权衡。RUP的每次迭代中有几个关键的制品对系统分析、设计很重要，可以说是非常重要，如：词汇表、业务规则文档、用例、领域草图。这几个制品对分析、设计很重要，需要从这几个制品中提炼出设计模型最终才能落地。这主要用在业务复杂的应用系统中。而Scrum更加的轻量级，可以用在互联网项目中本文链接：SOA架构设计经验分享—架构、职责、数据一致性，转载请注明。 ...继续阅读 (56)

很高兴我的第一本书由图灵出版社出版。本书总结了我这些年来对框架学习、研究的总结，里面纯干货，无半句废话。书的详情请看互动网的销售页面：http://product.china-pub.com/3770890精彩推荐：“这本书最大的价值就在于告诉你如何在实战中运用平时学到的知识，如何站在不同的角度分析...本文链接：新书出版《.NET框架设计—模式、配置、工具》感恩回馈社区！，转载请注明。 ...继续阅读 (39)

随着应用程序的复杂度不断上升，要想将好的设计思想稳定的落实到线上，我们需要具备解决问题的能力。需要具备对运行时的错误进行定位且快速的解决它的能力。本篇文章我将分享一下我对.NET应用程序调试方面的学习和使用总结。其实对调试程序的使用是不难的，关键是知道它的调试原理才行，因为调试一个程序或者dump文件，都需要了解一定的.NET调试的原理才行，比如你在附加到进程调试时在执行某个SOS扩展命令是需要切换到指定线程上的，而调试dump文件就不需要，但是对Dump文件的分析有些SOS扩展命令是不能用的，类似这样的问题，一旦出现你就一头雾水，所以花点时间学习一下原理是有必要的。本文链接：.NET应用程序调试—原理、工具、方法，转载请注明。 ...继续阅读 (48)

从这篇文章开始我将分享一系列我认为在实际工作中很有必要的一些.NET项目开发的核心技术点，所以我称为必知必会。尽管这一些列是使用.NET/C#来展现，但是同样适用于其他类似的OO技术平台，这些技术点可能称不上完整的技术，但是它是经验的总结，是掉过多少坑之后的觉醒，所以有必要花几分钟时间记住它，在真实的项目开发中你就知道是多么的有帮助。好了，废话不说了，进入主题。我们在开发服务时为了调试方便会在本地进行一个基本的模块测试，你也可以认为是集成测试，只不过你的测试用例不会覆盖到80%以上，而是一些我们认为在开发时不是很放心的点才会编写适当的用例来测试它。本文链接：.NET程序员项目开发必知必会—Dev环境中的集成测试用例执行时上下文环境检查（实战），转载请注明。 ...继续阅读 (53)

随着现在的企业应用架构都在向着SOA方向转变，目的就是将一个庞大的业务系统按照业务进行划分，不管从公司的管理上、产品的开发上，这一系列流程来看，都是正确的。SOA确实带来了解决现在大型企业级应用系统快速膨胀的解决办法。但是本文要说的是，我们都将目光转向到了后端，也就是服务端，而将精力和时间都重点投在了后端服务的架构设计上，渐渐的忽视了显示端的架构设计。然而显示端的逻辑也越来越复杂，显示端轻薄的架构其实已经浮现出难以应付后端服务接口快速膨胀的危险，服务接口都是按照指数级增加，基本上每一个新的业务需求都是提供新的接口，这没有问题。按照服务的设计原则，服务接口就应该有着明确的作用，而不是按照代码的思维来考虑接口的设计。但是由此带来的问题就是组合这些接口的显示端的结构是否和这种变化是一致的，是否做好了这种变化带来显示端逻辑复杂的准备。本文链接：.NET应用架构设计—用户端的防腐层作用及设计，转载请注明。 ...继续阅读 (34)

一直都在谈论面向对象开发，但是开发企业应用系统时，使用面向对象开发最大的问题就是在于，多个对象之间的互操作需要涉及数据库操作。两个业务逻辑对象彼此之间需要互相调用，如果之间的互相操作是在一个业务事务范围内的，很容易完成，但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了。在以往，我们使用过程式的代码（事务脚本模式），将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中，就算你适当的提取重复代码，效果也不大，因为你永远都..本文链接：.NET应用架构设计—工作单元模式（摆脱过程式代码的重要思想，代替DDD实现轻量级业务），转载请注明。 ...继续阅读 (35)

对软件开发方法论有兴趣的博友应该发现最近“领域驱动设计”慢慢的被人发现被人实践起来，园子里也慢慢有了DDD的学习气氛和宝贵实战经验的分享。其实之前我也痴迷于DDD，为什么会痴迷于它并不是因为它是所谓的新技术，也不是因为各种对它的炒作，而是我觉得我找到了能解放我们进行企业业务系统开发的方法论。DDD可以很好的指导我们开发可靠的软件系统，尤其是现在的企业业务复杂多变的情况下，使用DDD可以很好的随着业务变化不断的重构现有的领域模型，最为重要的是我觉得DDD是能够很好的实施敏捷价值观的软件开发方法论。本文链接：.NET应用架构设计—适当使用活动记录模式代替领域模型模式，转载请注明。 ...继续阅读 (37)

要想正确的设计系统架构就必须能正确的搞懂每个架构模式的用意，而不是胡子眉毛一把抓。现在有一个现象是什么呢，项目的结构从表面上看是很不错，层分的很合理，其实对业务系统来说也就那么几种层设计方法，但是现在很多项目的逻辑架构的设计不是理想，有很多概念大家并不是很了解，当然也许每个人对技术的追求不同罢了。不管你追求不追求，事实我们还是要去往正确的方向努力才对的。本文链接：.NET应用架构设计—表模块模式与事务脚本模式的代码编写，转载请注明。 ...继续阅读 (34)

接触分层架构有段时间了，从刚开始的朦朦胧胧的理解到现在有一定深度的研究后，觉得有必要将自己的研究成果分享出来给大家，互相学习，也是对自己的一个总结。我们每天面对的项目结构可以说几乎都是分层结构的，或者是基于传统三层架构演变过来的类似的分层结构，少不了业务层、数据层，这两个层是比较重要的设计点，看似这两个层是互相独立的，但是这两个层如何设计真的还有很多比较微妙的地方，本文将分享给大家我在工作中包括自己的研究中得出的比较可行的设计方法。本文链接：.NET应用架构设计—重新认识分层架构（现代企业级应用分层架构核心设计要素），转载请注明。 ...继续阅读 (33)

至今我都清楚的记得我第一次被面试官问起什么叫”建模“技术时的情景，那是好几年前的事情了，当时是胸有成竹的去面试一个有关系统分析、设计的.NET高级软件工程师岗位。面试官几乎没问我有关.NET方面的任何技术实现，他就简单的问了问：“你如何把握你所分析出来的系统的正确性？”，我当时有点小激动，觉得这个问题应该很简单嘛，都是概念而已，让他直接点问，结果他来一句：“你懂建模吗？，能给我解释一下建模的作用吗？“，接着他出了一个小例子，让我对这个例子进行建模，要考虑到各种扩展性、业务稳定性的关键点，要边建模边说出为什么要这么建模，要说出思路。他最后重点强调了一下：“创建出来的模型是不允许跟任何具体的代码、工具有关联的”。本文链接：.NET应用架构设计—面向对象分析与设计四色原型模式（彩色建模、领域无关模型）（概念版），转载请注明。 ...继续阅读 (38)