华仔-技术博客

很多人都学过设计模式，但是大部分人却被设计模式带偏了，乱用设计模式、滥用设计模式、炫技式的应用设计模式，把代码写的更乱了，原因不是23个设计模式本身有问题，而是设计模式背后的设计理念有问题。

github更新安全访问协议后，Sourcetree只能使用Personal Access Token接入，但是mac平台上不是简单的改改Sourcetree就可以了，而需要更复杂的操作，本文记录了这个踩坑和填坑的过程。

tcp连接是网络编程中最基础的概念，基于不同的使用场景，我们一般区分为“长连接”和“短连接”，长短连接的优点和缺点这里就不详细展开了，有心的同学直接去google查询，本文主要关注如何解决tcp短连接的TIME_WAIT问题。短连接最大的优点是方便，特别是脚本语言，由于执行完毕后脚本语言的进程就结束了，基本上都是用短连接。但短连接最大的缺点是将占用大量的系统资源，例如：本地端口

OCP，Open-Closed Principle，中文翻译为“开闭原则”。 当我第一次看到OCP原则时，我的感觉就是这原则也太抽象了吧，什么开，什么闭呢？ 然后我去寻找更加详细的答案，最经典也是最常见的解释就是维基百科了：http://en.wikipedia.org/wiki/Open/closed_principle "software entities (classes, modules,

前面详细阐述了“高内聚低耦合”的总体设计原则，但如何让设计满足这个原则，并不是一件简单的事情，幸好各位前辈和大牛已经帮我们归纳总结出来了，这就是“设计原则”和“设计模式”。毫不夸张的说，只要你吃透这些原则和模式并熟练应用，就能够做出很好的设计。==================================================================【SRP原则详解】SRP

类模型指导我们如何声明类，动态模型指导我们如何实现类！动态模型设计一般都是在类模型设计完成后才开始，因为动态模型设计的时候一般都需要用到类模型中的类。相对类模型来说，动态模型要相对简单一些，主要原因在于动态模型设计的时候没有什么设计原则和设计模式需要应用，只需要对照用例模型，根据用例模型的特点，选取一个合适的动态模型将其表述出来即可。动态模型在实际开发过程中有非常重要的作用，简单来说，如果没有动态

面向对象设计和弹吉他差不多，有很多成熟的理论和技巧，学会弹吉他并不难，但要成为吉他高手或者大师，还是要靠个人天分！【师傅领进门，修行在个人】“类模型”是整个面向对象设计模型的核心，是面向对象设计阶段的主要输出，也是设计师们最能够发挥自己才能的地方。 虽然“类模型”如此重要，但面向对象设计技术经过几十年的发展后，目前已经形成了很成熟的一套体系，因此真正在进行“类模型”设计的时候，其实难度并不高，这也

用例图是用来描述系统的，而SSD（系统序列图）又是来描述用例的，oh my god，这不是在玩我们么？System Sequence Diagram，缩写为SSD（注意不要与SSD硬盘混淆），中文翻译为“系统顺序图”，主要用于描述某个用例的某个分支场景下，外部参与者与系统的交互过程。简单来说：SSD就是用例的可视化描述。 细心的朋友可能会发现，前面我们在介绍“用例方法”的时候说不需要画图，这里又说

高内聚低耦合，可以说是每个程序猿，甚至是编过程序，或者仅仅只是在大学里面学过计算机，都知道的一个简单的设计原则。虽然如此流行和人所众知，但其实真正理解的人并不多，很多时候都是人云亦云。===============================================================要想真正理解“高内聚低耦合”，需要回答两个问题：1）为什么要高内聚低耦合？2）高内聚低耦合

前面通过实例讲解了一个一环扣一环的面向对象的开发流程：用例模型 -> 领域模型 -> 设计模型（类模型 + 动态模型），解答了面向对象如何做的问题。接下来我们就要讲“如何做好面向对象设计”的技巧了===================================================================参考维基百科的解释，内聚的含义如下：cohesion refers t

完成领域类到软件类的转换，这就是面向对象领域设计阶段的主要任务。经过领域模型的分析后，面向对象已经初具雏形，但领域类并不能指导我们进行编码工作，因为领域类只是从用例模型中提炼出来的反应业务领域的概念，而并不是真正意义上的软件类。 “革命尚未成功，同志还需努力”，我们需要再进一步，完成领域类到软件类的转换，这就是面向对象领域设计阶段的主要任务。 设计阶段是整个面向对象分析和设计的高潮阶段。在设计阶段

领域模型是面向对象分析和设计的第一步！！完成了需求分析之后，我们已经有了一个良好的开端，但我们的主角“面向对象”还不见踪影。前面我们提到，需求分析和面向对象是没有直接关系的，需求分析阶段是不区分是面向对象还是面向过程，那么什么时候才真正开始面向对象的工作呢？ 答案就在本章：领域建模。从领域模型开始，我们就开始了面向对象的分析和设计过程，可以说，领域模型是完成从需求分析到面向对象设计的一座桥梁。 领

类模型设计其实就是程咬金打天下 -- 三板斧 而已 ：）第一斧（照猫画虎）：领域类映射面向对象类设计首先要解决的一个问题是：类从哪里来 ？有的人可能会认为，要发挥想象力、创造力。。。。。等各种“力”——这种方法的主要问题是：我们不是在进行纯粹的艺术创造，而是要最终满足客户需求，而不能天马行空。有的人可能会想到，参考其它的系统吧，把类似系统拿过来改吧改吧 ——这种方法的主要问题是：如果没有其它类似系

看起来有点不可思议，需求阶段“白纸黑字”的用例文档，经过我们一步一步的操作，逐步就得到了“图形化”的领域模型，面向对象初具雏形。领域建模的三字经方法：找名词、加属性、连关系。 我们接下来以一个样例看看领域模型具体如何建模。1.1. 找名词我们以POS机买单的用例来看看具体如何建领域模型。 首先，将用例中所有的名词挑选出来（如下用例文档中蓝色加粗的词组）：【用例名称】买单【场景】Who：顾客、收银员

对于大部分人来说，可能并没有机会进行需求分析，因为在大部分的公司里面，需求分析都是有很多工作经验的资深人员，或者是对系统很熟悉的老的开发人员。 所以，很多人都会对需求分析有一种景仰的心态，认为既然做需求的人要求这么高，那么需求分析一定很复杂、很难、很高级了。而且很多需求分析人员动不动就会教训“你要站在客户的角度”、“你要全面的分析”等，然后再抛出几个需求建模之类的玩意吓吓你。。。。。。

封装的概念本身很好理解，意思就是把一堆东东装起来。 但要想真正理解封装，这样还远远不够。第一个问题是：我们要封装什么？这个问题很好回答，封装当然是封装不想让别人知道或者看到的东东了。例如：你的身家。。。。。。漂亮MM的年龄。。。。。。富二代的女朋友数。。。。。明星是否整过容。。。。。。你是如何赚到100万的（想想什么样

完成了用例之后，需求分析的工作基本上已经完成，接下来我们需要趁热打铁，完成另外一个事情：提取功能点！ 有了用例之后，提取功能可以说是一个水到渠成的事情，基本上只是一个文字工作，我们只需要将用例中那些需要系统完成的事情——更简单的说：是动词——提取出来，就成为了系统的功能。 以前面的POS机为例，我们看看如何提取功能，如下粗体字即为提取的功能： 【用例名称】

DIP，dependency inversion principle，中文翻译为“依赖倒置原则”。 DIP是大名鼎鼎的Martin大师提出来的，他在1996 5月的C++ Reporter发表“ The Dependency Inversion Principle”的文章详细阐述了DIP原则，并且在他的经典著作《 Agile Software Development, Principles, Pa

ISP，Interface Segregation Principle，中文翻译为“接口隔离原则”。和DIP原则一样，ISP原则也是大名鼎鼎的Martin大师提出来的，他在1996年的C++ Reporter发表“ The Interface Segregation Principle”的文章详细阐述了ISP原则，并且在他的经典著作《 Agile Software Development, Pri

不管是开发、测试、运维，每个技术人员心理多多少少都有一个成为技术大牛的梦，毕竟“梦想总是要有的，万一实现了呢”！正是对技术梦的追求，促使我们不断地努力和提升自己。然而“梦想是美好的，现实却是残酷的”，很多同学在实际工作后就会发现，梦想是成为大牛，但做的事情看起来跟大牛都不沾边，例如，程序员说“天天写业务代码还加班，如何才能成为技术大牛”，测试说“每天都有执行不完的测试用例”，运维说“扛机器接网线敲

“如何才能成为大牛”，这个问题很多人都问过我，我会写一个系列来回答“如何成为大牛”这个问题，这是第一篇，是拉勾理想之上广州站活动的现场演讲稿。主要讲1000小时理论以及如何找到10000小时

1000小时理论虽然简单，但时间持续很长，是一个大目标，如何将10000小时理论分解为一步一步可操作可执行的行动呢？ 本博客给出了答案

本来想自己写一篇运维体系的文章的，但毕竟不是专业运维人员出身，担心讲的太肤浅，因此转载我的好朋友王金银（江湖人称老王）同学发表在InfoQ的运维体系介绍。老王的牛逼相信很多同学已经领教过了，全球运维技术大会深圳站一个人专场讲运维能讲3个小时，而且会场还爆满，更多老王的介绍可以参考文章的最后，也可以关注老王的微信公众号：互联网运维杂谈。

安装mysql 5.1版本到个人目录

为了实现阿里九游游戏接入系统的业务高可用，技术人员跳出传统的面向系统的高可用的思路，转而从业务的角度来整体考虑高可用，最终实现了一套立体化的高可用架构，本文逐一展示这套立体化高可用架构的一些具体实践。

互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件，但抛开业务的差异，各个互联网业务发展最终面临的问题都是类似的：就是复杂度越来越高，也就是说，业务层面对的主要技术挑战是“复杂性”。幸运的是，面对业务层的技术挑战，我们有一把屠龙宝刀，神挡杀神，佛挡杀佛，不管什么业务难题，用上屠龙宝刀一试都迎刃而解。这把屠龙宝刀就是“拆”。复杂性的一个主要原因就是系统

【运筹帷幄】一般来说，需要架构重构的系统，基本上都是因为各种历史原因和历史问题没有及时处理，遗留下来逐渐积累，然后到了一个临界点，各种问题开始互相作用，集中爆发！到了真正要开始重构的时候，我们可能会发现千头万绪，感觉无法下手，随便整理一下就几十个大大小小的问题要解决。此时架构师或者技术主管面临的主要问题就是怎么去推进。 可以想象一下，假如我们拿到一个架构问题列表，其中有50个问题，那我们应该怎么去

互联网技术发展之路（1） - 技术发展的驱动力互联网行业是一个快速发展、快速变化的行业，新的业务、新的机会层出不穷，新的技术如雨后春笋般冒出，NoSQL、大数据、云、Node.js、Docker等，无时不刻都在轰炸程序员们的脑袋，难怪中国的程序员都流传一个说法：过了30岁不能做技术工作了，因为技术发展太快了！快节奏带来机会，但对于技术人员来说，更多的是带来挑战，甚至有时候是困惑。例如：1）Dock

在系列文章的第2篇“BAT解密：互联网技术发展之路（2）- 业务如何驱动技术发展”中我们深入分析了互联网业务发展的一个特点：复杂性越来越高。复杂性增加的典型现象就是系统越来越多，当系统的数量增加到一定的程度，就由复杂度量变带来了复杂度的质变，主要体现在系统间相互依赖程度加深：比如说为了完成A业务系统，可能需要B、C、D、E等十几个其它系统进行合作。从数学的角度进行评估，可以发现系统间的依赖是指数级

上一篇博文《BAT解密：互联网技术发展之路（6）- 服务层技术剖析》中，介绍了互联网业务发展特点的中的“复杂性”的应对方式，本文介绍互联网业务发展特点的另外两个方面“高性能”、“高可用”。一般人提到高性能时第一想到的就是优化，提到高可用时第一反应就是双机或者备份，但是对于互联网这种超大容量和访问量的业务来说，这两个手段都是雕虫小技，无法应对互联网业务的高性能和高可用需求，互联网业务的高可用和高性能

软件开发领域有一个流行的原则DRYDon’t repeat yourself我们翻译过来更形象通俗不要重复造轮子。开源项目主要目的是共享其实就是为了让大家不要重复造轮子尤其是在互联网这样一个快速发展的领域速度就是生命引入开源项目可以节省大量的人力和时间大大加快业务的发展速度何乐而不为呢 然而

需求分析有三种级别，你自认为属于哪一级呢 ？需求分析的目的是什么？ 你可能会毫不犹豫的回答：需求分析的目的当然是了解客户需要什么！ 这个回答看起来是毫无疑问的，我们当然要了解客户需要什么，我们才能给他们做出他们想要的。但只做到这样就可以了么？ 我们来看一个简单的需求，客户找到你说：“我要一只羊！”这个需求够简单吧？那你是不是毫不犹豫的就抓一只羊给客户呢？

零缺陷开发技巧，简单易懂，一学即会，一用就有效果，让你写10K代码只有1个bug的方法个人实践效果：10K代码1个bug, 个人负责的70%的版本0 bug详细请点击下载：零缺陷”开发技巧内容简介：1个原则：2/8原则2个技巧：防御性编程、代码写三遍3个条件：熟悉编程语言、单元测试、熟悉业务

很多人像老黄牛一样辛辛苦苦做了很多年软件开发，但却连“需求”到底是什么都不清楚。当然，没有人自己会承认这点！凡事都有一个开头，软件项目也不例外，对于软件项目来说，需求就是项目最开始的一个输入。 参考维基百科，需求定义如下：In systems engineering, a requirement can be a description of what a

很多人在分析需求的时候，采用的是东扯葫芦西扯瓢的方式，列出了很多的需求点，但当你看完后，你还是不知道到底要干嘛！！  ---- 写在前面

最近在研究Bigtable的实现原理，网上搜索了一把，几乎全是Google的那篇论文，由于涉及的点众多，看起来比较吃力，也没有一个宏观的架构用于理解，因此，自己画了一个，分享给大家，欢迎各位批评指正，共同完善！HBase可以认为是山寨版的Bigtable，因此其架构也是类似的，只是各个部件换了名字，对应关系如下：Chubby ===> ZookeeperMaster  ===>

mysql的字符集设置众多，从客户端到连接到结果集，从服务器到库到表到列，都可以设置字符集，灵活很强大，但就是很容易出问题，如果不了解其机制，很容易就出现乱码问题。为了普度众生，让大家尽量在工作中少受或者不受乱码的骚扰、困扰，这里我结合之前其它同学在论坛的发帖，并结合自己的理解和实践，详细分析总结了一下，以飨各位看官。关于字符集和乱码的基础知识这里就不详细说明了（请自行搜索），但有一个

1. 解压源码到个人目录；2. 执行如下命令进行configure,注意源码默认情况下不支持innodb，必须使用--with-plugins手工指定（二进制包默认已经支持）：./configure --prefix=$HOME/local/mysql-5154 --with-extra-charsets=latin1,gbk,utf8 --with-plugins=partition

                         如何与你的老大沟通？看了优快云冯大侠的《老大，我想说两句》，深有感触，因为我也曾经遇到过类似的情况，深知这种情况下个人的郁闷感觉。 但现实毕竟是“老大”就是老大，你的前途、薪水都掌握在老大手里，抱怨和郁闷都不能解决问题，反而会使问题更加恶化；而且既然是老大，那么必然有过人之处（不管是技术、还是有关系、还是会说话，那都是老大的优势）。因

                       让技术人员看得懂的流程（4）                                    ——设计模型完成了“领域模型”阶段后，面向对象已经初具雏形，我们已经看到了那熟悉的“对象”了，例如“商品”、“交易”、“商品清单”等，看起来已经进入了面向对象的世界了，你是否已经摩拳擦掌，跃跃欲试，准备开始编码了呢？且慢，“领域模型”只是万里