常高伟的专栏

开发中的一些总结，有些乱。主要描述，如果使用Python协程，该如何设计tsapi程序。为最终的调度设计积累一部分的经验，并且，最终形成一个框架，在这个框架上，可以方便的新增新的功能，让其他的员工不再对Python协程望而生畏。1、整个框架主要的部分是call模块，主要负责呼叫流程的控制。它把对asapi的调用全部集中到一个模块中，可以实现对模块的封装，便于以后的替换。2、call模块和上层模块的

前几天为新员工写一个简单的测试框架，可让他们方便的写测试用例并且执行。期间遇到一个问题就是如何让他们增加测试用例而用不影响测试框架的代码？c++的单件模式可以解决这个问题，但是其中一个难点是要在main之前注册单件。c++可以通过构造函数来实现注册，c如何注册？最后查了下资料，原

1.1.1  自顶向下和自底向上自顶向下的设计者可能会首先考虑主事件循环，然后在考虑插入具体的事件；自底向上设计者通常会考虑封装具体的事务，以后再按照某种相关次序把这些东西粘合在一起。单纯的使用自底向上和自顶向下都无法达到好的效果。一方面设计程序逻辑（自顶向下），一方面整理底层的

这里的接口，更多的指的是对用户的接口。接口的五个特性：1、  简洁：指一个事务处理需要的动作时间及复杂度有较低的上限。2、  表现力：接口可以出发广泛的行为。3、  易用性：使用接口需要记多少东西？4、  透明性：用户动作的效果，能够自然的给出中间结果，反馈，错误通知。程序的运行

“软件的缺陷率和使用的语言无关。”我曾经设计过一个机遇xml的微型语言。另外，xtest项目让我向设计一个全新的，类似于真正语言的语言，而不是简单的标记语言。在学习这一章的时候，结合整xtext一起学习一下。发现xtext有一个问题，它只可以运行的jvm上。我想设计一种DSL，我

最有效的优化往往是优化之外的其他事情，比如：清晰干净的设计。最有效的优化技术就是不做优化：摩尔定律会进行优化。如果确实需要优化，那必须找到真正的瓶颈。可以使用工具。但是有几个问题：1、  工具的误差。工具一般要插入代码，而这些代码也要消耗时间。越小的函数，消耗越大。所以还要结合调

1、  过滤器模式：接收标准输入，然后转化为标准输出。把自己当成一个过滤器。使用时的原则：宽进严出，不需要的信息也绝不丢弃，绝不增加无用数据。比如grep。2、  Cantrip模式：没有输入，没有输出，只调用一次，参数状态值，然后退出。比如rm。不需要交互。3、  源模式：不需

“设计良好的函数往往比较小，而过大函数的设计往往一塌糊涂，或者存在很大的优化空间。”也许你认为讨论函数的大小没有必要，原因是函数设计的本质是内聚，它的大小只是它的表现形式。而上面的原因有必要让我们讨论一下函数的大小问题。我对函数的核心思路：我提出代码最小处理单元的概念：一个基本操

复杂度有三个来源：1、  代码规模：一般就是代码的函数。2、  实现复杂度：程序员为了理解一个程序从而建立其思维模型并调试该程序的困难程度。3、  接口复杂度：主要是和用户接口的复杂度，比如用户界面，功能，操作等。面对上面三个复杂度比较陷入三个陷阱：1、  manularty（人

前言：最近在学习《Unix编程艺术》。以前粗略的翻过，以为是介绍unix工具的。现在认真的看了下，原来是介绍设计原则的。它的核心就是第一章介绍的unix的哲学以及17个设计原则，而后面的内容就是围绕它来展开的。以前说过，要学习适合自己的资料，而判断是否适合的一个方法就是看你是

最近在学习《unix编程艺术》。第一章非常不错，讲了很多Unix的历史，哲学基础，其中最重要的是提到的十七条设计原则。很多原则自己也知道，但是从来没有总结的如此详细深刻。下面的内容大部分来自《unix编程艺术》这本书，少部分是我的一些理解。这是我读书的一个习惯，对于我认为

最近在学习《unix编程艺术》。第一章非常不错，讲了很多Unix的历史，哲学基础，其中最重要的是提到的十七条设计原则。很多原则自己也知道，但是从来没有总结的如此详细深刻。下面的内容大部分来自《unix编程艺术》这本书，少部分是我的一些理解。这是我读书的一个习惯，对于我认为重要的，

为什么需要简单的设计？我想这和人的特点有关。我不止在一个地方看到过，人同时能够处理的信息不超过7个。我想这应该就是人们追求简单设计的根本原因，人需要用一个简单的设计去解决现实中的问题。如果真的存在完美，也许简单的东西就是完美的东西。很多人都崇尚简单设计的思想，那么什么是简单设计？

可以将系统划分为子任务组，每个子任务组在一个特定的抽象层次上。1． 例子ISO7层模型。2． 语境一个需要分解的大系统3． 问题假设有一个系统，它明显的混合了底层与高层的问题。强制条件：1） 一个地方的更改，被限制在某组件或某层内，不会扩散到整个系统。2） 接口应该是稳定的，甚至可以用标准件来限定。3） 系统的各个部分应该可以替换，组件可以被其他的实现方法来替换而不影响系统有的其他部分。则可能基于优秀的接口定义。

如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不应该通过编译；如果代码通过了编译，它的作为就是客户想要的。1、 好的接口很容易被正确使用，不容易被误用。你应该在所有的接口中努力达成这些性质。2、 “促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。3、 阻止误用的办法包括建立新类型，限制类型上的动作，束缚对象值，以及消除客户对资源的管理责任。4、 tr1::shared_ptr支持定制型删除器，这可防范DLL问题。可被用来自动解除互斥锁。

1、以对象管理内存（Use Objects to manager resources.）这一条款主要说的是如何进行动态内存申请释放。RAII原则：Ø 获得资源后立刻放进管理对象内；Ø 管理对象运用析构函数确保资源被释放；我自己也写过一个动态申请释放的类。这个类的一个假设是，一个资源在被申请后会马上被使用，而在函数返回后就需要释放。为此我写了一个基类，每个资源类都要继承这个基类。每个资源子类的构造函数和析构函数都是private，这样就杜绝了new和delete

1.1.1  紧凑性紧凑性就是一个设计能否装进人脑的特性。——它是设计的可读性？紧凑不等以薄弱：如果一个设计构建在易于理解利于组合的抽象概念上，则这个系统能够在具有非常强大、灵活的功能同时保持紧凑性。紧凑不等于易于学习：对于某些紧凑设计而言，在掌握其精妙的内在概念模型之前，要理解

1.1  程序库强烈倾向于把程序分解成有胶合层连接的库集合，特别是共享库。使用库来达到c语言的模块性。库分层的一个重要形式是插件。实例分析：GIMP插件1.2  UNIX和面向对象语言Unix的模块化传统就是薄胶合层原则。也就是程序底层和顶层之间的抽象层越少越好。原因可能是因为c

模块性体现在良好的代码中，但首先来自良好的设计。下面是问题清单：1、  有多少全局变量？全局变量时模块化的毒药，很容易使各个模块轻率，混乱的泄露信息。2、  单个模块的大小是否在hatton的“最佳范围内”（物理行在400~800间）？如果回答是不，很多都超过的话，就可能产生长期

前言：这篇文章写作过程断断续续持续了两个月，终于写完了，最近事情有些多。这次技术会议的主办方虽然是阿里巴巴，但是还有很多其他的互联网企业，比如百度，新浪，腾讯，盛大，360，小米。会议共有两天，主要面向互联网技术，参与者也大多是互联网公司从业者。人还比较多，讨论也比较活跃。我主要参与的是aDev(应用架构和后端技术)，这里简单总结一下：1、SOA的落地。记得Infoq上一篇文章曾说过：大意是，当一

不知道这样好不好，在做一个事情的时候，总是想上一下网，看一下技术。而看到一个技术点，总会不自觉的研究一下，搜索一下相关的内容。这样对工作效率会有影响的。后面要注意啊。刚才看服务框架。把底层的组件、功能服务化，对业务层提供统一的开发接口（将异构的开发接口统一为服务）。这样做的好处：1、避免重复开发。将很多公共的东西，抽象构造为服务。2、对应用系统，降低开发复杂度。一起要连接很多提供服务的实体，现在，

前言：我一直在关注如何让开发变得更容易，效率更高，更不易出错。之前做过类似的努力，结合SOA和工作流引擎做的一个流程编辑：http://blog.youkuaiyun.com/chgaowei/article/category/597366。它有它自身的缺陷：脚本和程序之间的耦合太大，脚本限制太多。后来接触并且学习Python，它简洁而强大，应该是解决这类问题的一个思路。那天看到Python自带的生成器yie

不知觉python总结都有四十页了，虽然可能很多都是基础性的，仍然有成就感。和之前一样，仍然全部贴出来，而不是把新的贴出来，请谅解。这次新增的部分包括c扩展，排序，ftp，源码安全，性能，代码检查等。后面在python上努力的几个方向：1、继续在开发中多使用，积累开发经验。2、针对我们公司完善基础库，在我们公司推广。3、抽时间，系统学习一下python。4、学习一下高手在怎么使用python。毕竟

首先声明一点：这里的“高并发”是相对的，相对于硬件而言，而不是绝对的高并发。后者需要分布式来实现，这里不做讨论。本文关注的是单机的高并发。最近在做一个语音通信系统，要求在线用户2W，并发1K路通话。硬件是两台服务器，酷睿多核，4G内存，千兆网卡（我用过的最好的硬件，负担这些应该问题不大）。系统的另一个指标是呼叫时延和语音时延。这是这个系统的关键。最终我们的系统拿到用户现场测试的时候，效果可能有点太

在一个博客上看到类似会这样的文章，感觉不错。有些内容虽然不成系统，但是对自己还是很重要的，有必要总结出来。好了，开始第一篇：1、epoll相对于select的优势： 不受套接字个数的限制。select默认应该是2048，而epoll没有这个限制，他的限制在系统的内存； select每次都要创建一个列表传递给内核，而epoll则直接写到内核中。 每个套接字可以传递用户数据，这样可以方便的设置回调。2

我看书有个特点，不写笔记，就感觉好像没有看过书，印象不深刻（虽然写了也未必深刻），所以我看书会比较慢，笔记会很多。这里总结一下并发。最近学习《深入理解计算机系统》，最后一章中讲到了并发。之前一直以为并发是为了提高性能，书中将并发理解为逻辑控制流在时间上的重叠。简单的说，就是让机器能够同时处理多个事情，充分利用机器的能力。特别是现在多核机器的普遍，并发可能越来越重要。现代操作系统提供了三种基本的方法

不知不觉我的python开发总结已经18页了。原谅我把所有的都贴到博客上，而没有列出更新部分。如果你是第一次看，这样可能最有帮助。两本不错的书：《Python参考手册》：对Python各个标准模块，特性介绍的比较详细。《Python核心编程》：介绍的比较深入，关键是，对Python很多高级特性都有介绍。一个开源代码：openstack，关于云计算的，用Python写的，可以重点学习一下。套接字编程

最近在接触python，感觉python之所以开发效率高，可能有三个因素：1、语言表达能力强悍。2、支持很多高级的语言特性。3、第三方开源库非常的丰富。两本不错的书：《Python参考手册》：对Python各个标准模块，特性介绍的比较详细。《Python核心编程》：介绍的比较深入，关键是，对Python很多高级特性都有介绍。一个开源代码：openstack，关于云计算的，用Python写的，可以重

本文示例代码采用的是c语言。之前介绍过数据驱动编程《什么是数据驱动编程》。里面介绍了一个简单的数据驱动手法。今天更进一步，介绍一个稍微复杂，更加实用的一点手法——表驱动法。关于表驱动法，在《unix编程艺术》中有提到，更详细的描述可以看一下《代码大全》，有一章专门进行描述(大概是第八章)。简单的表驱动：《什么是数据驱动编程》中有一个代码示例。它其实也可以看做是一种表驱动手法，只不过这个表相对比较简

之前发表过一篇文章《如何学习一门新的语言》。之后就开始学习python了，具体原因也不是很清楚了。我先是从python简明教程开始，写了两篇笔记《python初体验1》《python初体验2》，但是没有太多的感受。后面因为一个小的项目，我想尝试一下python，在这个过程中，体验了python的简洁和高效，有一种飞起来的感觉——也许我是一名c语言程序员。事实也再次证明，学习一门新的语言最好的方法就

透明性和可显性同模块性一样，主要是设计的特性而不是代码的特性：1、  程序调用层次中最大的静态深度是多少？不考虑递归，为了建立心理模型来理解代码的操作，人们将要调用多少层？这个应该不是实际的代码调用层次。我现在倾向于小函数，所以调用层次会比较深。它这个应该是理解上的层次。2、

1.1  程序库强烈倾向于把程序分解成有胶合层连接的库集合，特别是共享库。使用库来达到c语言的模块性。库分层的一个重要形式是插件。实例分析：GIMP插件1.2  UNIX和面向对象语言Unix的模块化传统就是薄胶合层原则。也就是程序底层和顶层之间的抽象层越少越好。原因可能是因为c

Unix最具特点的程序模块化技法就是将大型程序分解成多个协作的进程。这种设计可以降低全局的复杂度，但是需要更多的关注进程间传递信息和命令的协议设计。对于通信协议的设计，真正的挑战不是设计协议语法而是设计协议的逻辑：即要有表达能力又要有防范死锁的能力。它是模块化的延续。在开发出可以

可显性是指是否容易入门；透明性是指入门后是否容易理解。为透明性和可显性设计运行各种方法保持代码简洁，也要专注同其他人交互的方式。 透明性之禅要追求代码的透明，最有效的方法很简单，就是不要在具体操作的代码上叠放太多的抽象层。这里作者又在批判OO的厚胶合层和过多的抽象层。：要设计简单

注意：1、 为内置对象手动初始化，因为c++不保证初始化他们。2、 构造函数最好使用成员初值列，而不要在构造函数中使用赋值操作。初值列中成员的顺序，应该和他们在class中声明的顺序一样。3、 为避免“跨编译单元值初始化次序”问题，请以local static对象代替non-local static对象。

注意：1、 为内置对象手动初始化，因为c++不保证初始化他们。2、 构造函数最好使用成员初值列，而不要在构造函数中使用赋值操作。初值列中成员的顺序，应该和他们在class中声明的顺序一样。3、 为避免“跨编译单元值初始化次序”问题，请以local static对象代替non-local static对象。

代码整洁可用（clean code that works ）是TDD的追求目标。 测试驱动的规则：1、 只有自动测试失败时，我们才重写代码。2、 消除重复设计，优化设计结构。上面的规则派生的规范：1、 我们必须通过运行代码提供的反馈来做决定，并以此达到有机设计的目的。2、 我们必须自己写测试

最近两个把《代码大全》的4至25章学习完了，感觉收获还是挺大的。下面是我的学习笔记，和大家分享http://d.download.youkuaiyun.com/down/1712490/chgaowei学习笔记中大部分是书中的重点内容，和部分我的个人理解。希望能和大家一起交流。  

《重构》第三章学习笔记我们必须培养自己的判断力，来决定在什么时候进行重构。1.1 Duplicate Code（重复代码）如果你在一个以上地点看到相同的程序结构，那么将他们合而为一会更好。1.2 Long Method（过长函数）拥有短函数的对象会活得比较好，比较长。间接层所能带来的全部益处：解释能力（可读性），共享能

1.1 何谓重构重构（名词）：对软件内部结构的一种调整，目的是在不改变“软件可察行为”的前提下，提高其可理解性，降低修改成本。重构（动词）：使用一系列的重构准则，在不改变“软件可察行为”的前提下，调整其结构。1、 重构的目的是使软件更容易被理解和修改。2、 重构不会改变软件“可察行为”。1.2 为何重构