backard的专栏

大道至简--软件工程实践者的思想（周爱民 著）注：作者那么轻视工具和语言，估计和他所处的角色有关，从标题“软件工程实践者的思想”可以看出，他讨论的核心是软件工程。 序二......因此我必须阅读大量的技术书籍，每天在Internet上不断地补充新知，以应付工作上的需要。长期的积累，虽然让我学习了许多技术，但是真正让我不断超越昨日自我的因素，并不是这些单点的技术，而是多参考业界大

Praise for The Art of Agile Developmentcontraindication n.禁忌misapplied adj.被误用了的impediment n.障碍 Prefacemyriad adj.无数的course of action 做法first and foremost adv.首先go beyond v.超出conte

Design Patterns Explained: A New Perspective onObject-Oriented Design作者：Alan Shalloway, James R. Trott 第一章 面向对象泛型1.2 面向对象泛型之前：功能分解功能分解是一种处理复杂问题的自然方法。功能分解方法的一个问题在于，它通常会导致一个“主”程序负责控制子程序，这是将功能分

2007.10.16如何提高编译速度？在DMR的开发中，出现了一个怪现象，每次编译的时候，编译一个文件的时间都好长，并且每个被编译的文件都要去连接BCG的Lib文件，这种编译速度简直无法忍受？解决办法：在后面的分析中，发现我将Global.h这个头文件包含在Stdafx.h中了，并且Global.h这个文件是经常变的，程序中的大部分源文件都包含了Stdafx.h

不要期望通过看书就能成为专家，专家必定来自于长期的工作实践。

问题描述：编译流程图时，逻辑复杂，嵌套很深，很多函数都有成功失败返回值，造成每层函数都出现大量的成功失败判断，并且不知道打印日志是该在函数外，还是在函数内打印，感觉每次发现失败的时候都应该打印日志，但是又觉得有打印有重复，同时，打印的日志很容易将做什么和失败原因割裂开。这两个问题困扰了我编码很多年了，一直没搞明白为什么会这样。 日志解决办法：出现上述问题，实际上是因为我犯了一个致命的错误，

1、读书不在多，在于精读。时间有限，只能挑选精品读，效果远胜于滥读，一通百通，万变不离其宗。2、好书应该读多遍，因为随着你经验的不同，每遍的感受和收获都不同。不要期望读一遍就能理解透了，有些书当你功力不够的时候是理解不了的。

当人们不知道世界上存在锤子的时候，估计都会觉得用石头砸可能是一个很好的办法。 有时我们做傻事时，不是我们不思考、不努力，而是我们无知。 所以，我们需要多学习新鲜事物。

不管做啥事，包括分析需求，实现需求或者完全跟写程序无关的事，最好都有自己的一套思考方式或者说做事方法。1、总纲: 多考虑分支，尽量想办法确认假设的客观性，最难知道别人怎么想，涉及到心理学2、要做什么，解决什么问题，真实需求究竟是啥，做了会怎样，不做会怎样3、涉及到哪些人，谁受益，谁损失，有啥想法，有啥矛盾，预期怎样，预期能否调整4、约束条件有哪些，环境，时间，资源等，优先级怎样，哪

写代码无非追求两个目标，第一是满足需求，第二是好维护。好维护的首要前提是我们能够理解代码，其次是代码好修改。代码好修改的核心应该是良好的代码组织，设计模式主要就是用来解决代码组织的。学习设计模式时，估计有的人仅仅是记住了每个模式的形，而没有考虑每个模式是用来解决什么问题的，且更加会忽略只有代码需要变化时才会带来这些问题这个事实。正确的学习思路，应该是首先思考这个模式是用来解决什么变

书名：编程高手箴言 作者：梁肇新   内容简介：  本书是作者十余年编程生涯中的技术和经验的总结。内容涵盖了从认识CPU、Windows运行机理、编程语言的运行机理，到代码的规范和风格、分析方法、调试方法和内核优化，内有作者对许多问题的认知过程和透彻的分析，以及优秀和精彩的编程经验。  第1章程序点滴 1.1程序≠软件 能够产生商业意义的程序才能叫做软件。

1．开闭原则 (Open-Closed Principle)   模块在开放性方面应该是开放的（易于扩展），在更改性方面应该是封闭的（易于修改而不需要更改类的源代码）。   实现OCP的技术主要有多态和模板，均基于抽象。我们应该努力实现OCP以高效地复用和维护代码。2．Liskov替换法则 （Liskov Substitution Principle）   使用指向基类B（抽象类或

一 基础部分IntroductionI assume you are downloading some source code from time to time. You can learn a lot about a programmer while looking at his source code. There are some tips to help you write cl

1.在用一套类的命名规则命名所有向导页之后，需求发生变化，导致新增类的命名规则和已有类不一致，冲突严重。思路:命名时考虑将来的变化，比如说假设需求变了，新的类名是否能适应现有规则，以动态的眼光看问题，不要以为什么东西都是不变的。2.程序写着写着又发现有更好的解决方案，导致改动面很大。思路：解决一个问题时考虑所有的解决方案，不要抓住一个能够解决问题的方案就写。写好一个之后严格测试

停止思考是一种堕落被别人指出自己的问题总不是一件会另人感到愉快的事情同时，由于不愿意进行认真的思考和深入的剖析，我们也提出了许多自不量力、好高骛远和盲目冒进的策略和做法。评判一个工具的好坏，评判使用一个工具的开发人员的水平高低，永远都只有一个标准－－那就是看他能不能很好地解决所需要解决的问题。现在已不是个人英雄主义时代了，没有合作就不会有进步，没有产

最近一段时间总是在做一些拷贝粘贴的工作,有时明显知道我们可以通过一定的方法去提高工作效率,但是因为这些工作我们通过简单的体力劳动也可以在一定的时间内完成,只是多花那么一点点时间,殊不知,就因为我们不够懒惰,导致了我们养成了不善于探索新方法的习惯,危害其实很大的:例如:当选择一个大函数时老方法: 我选择的是用鼠标从前往后拉,要拉好久,如果出错,还要重来.更好的方法: 在UltraEd

1.如何一边遍历一个容器，一边erase某些元素？今天检视胡滔滔的代码，出现了如下形式的代码：    mapint, int> m;    m[1] = 1;    m[2] = 2;    m[3] = 3;    m[4] = 4;    mapint, int>::iterator iter2 = m.begin();    while(iter2 !

重构的目的是让可以工作的代码更好，使面向对象的代码更简单，更容易维护。书上还说，所有的程序员应当能使用重构技术改进他们的代码。 nuts-and-bolts n.具体细节 前言   Chapter 3. Bad Smells inCodestink v.发出臭味 决定什么时候去重构，什么时候该停止重构是非常重要的。vague adj.含糊的

问题描述：编译流程图时，逻辑复杂，嵌套很深，很多函数都有成功失败返回值，造成每层函数都出现大量的成功失败判断，并且不知道打印日志是该在函数外，还是在函数内打印，感觉每次发现失败的时候都应该打印日志，但是又觉得有打印有重复，同时，打印的日志很容易将做什么和失败原因割裂开。这两个问题困扰了我编码很多年了，一直没搞明白为什么会这样。 日志解决办法：出现上述问题，实际上是因为我犯了一个致命的错误，

勤学苦练流程图结构化程序设计有意识地用于实践数据模型和用户界面的程序一定要严格分开，否则程序极难修改不要寄希望于一次就把软件设计好软件结构要分块分层软件设计的主要工作是给类分配责任最重要的是领悟能力的训练知道哪些该学

也谈程序员的沟通与合作 促使我写这篇文章的，主要是有感于《读者》中的一篇文章《请按一下九层》，作者卢青。这是全市最忙的一部电梯，上下班高峰时期，和公共汽车差不多，人挨着人。上电梯前和公司的人力资源总监相遇，说笑间，电梯来了，我们随人群一拥而进。每个人转转身子，做一小小的调整，找到了一种相对融洽的关系。这时，一只胳膊从人逢中穿过来，出现在我的鼻子前头。我扭头望

以下文章都是经典，看不看随你的便，我只希望知识掌握在更多中国人的手里！中国有很多小朋友，他们18,9岁或21,2岁，通过自学也写了不少代码，他们有的代码写的很漂亮，一些技术细节相当出众，也很有钻研精神，但是他们被一些错误的认识和观点左右，缺乏对系统，对程序的整体理解能力，这些人，一个网上的朋友说得很好，他们实际上只是一些Coding fans，压根没有资格称为程序员，但是据我所知，不少

https://code.google.com/p/google-styleguide/