u013959864的专栏

tips: 程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。 发现错误的时间越早，付出的代价越小。 Created with Raphaël 2.1.2问题定义需求架构构建系统测试将来的改进。。。问题定义的先决条件问题定义的先决条件：为要解决的问题做出清楚的陈述。问题定义在具体的需求分析之前，要用客户...

tips:隐喻是启示而不是算法。因此它们往往有一点随意(sloopy)隐喻把软件开发过程与其他你熟系的活动联系在一起，帮助你更好地理解。有些隐喻比其他一些隐喻更贴切。通过把软件的构建过程比作是房屋的建设过程，我们可以发现，仔细的准备 是必要的，而大型项目和小型项目之间也是有差异的。通过把软件开发中的实践比作是智慧工具箱中的工具，我们又发现，每位程 序员都有许多工具，但并不存在任何一个能

把控制流变得易读条件语句中参数的顺序 关键思想：把条件、循环以及其它对控制流的改变做得越自然越好，运用一种方式使读者不用停下来读你的代码。对比if(length<10){// 1}if(10>length){// 2}while(bytes_received < bytes_expected){// 3}while(bytes_expec...

抽取不相关的子问题所谓工程学就是把大问题拆分成小问题再把这些解决问题的方案放在一起。把这条原则应用于代码会使代码更健壮并且更容易读。本章的建议是“积极地发现并抽取出不相关的子逻辑”。我们是指:看看某个函数或代码块,问问你自己: 这段代码高层次的目标是什么?对于每一行代码，问一下: 它是直接为了目标而工作吗? 这段代码高层次的目标是什么呢?如果足够的行数在解决不相关的子问题，抽取代...

代码应当易于理解把信息装到名字里共6点选择专业的词getPage无从获知来源，专业点的FetchPage和downLoadPage这样表明来源。 通过更加贴切专业的名字来了解方法。找到更有表现力的词，但要注意清晰精确。避免使用如retval和tmp这样泛泛的名字但也不是一定不能用。循环迭代器 例如i，j，k这种在写迭代器是很容易用乱，建议使用这种方式（...