技术宅，fat-man

摘要： http://www.cnblogs.com/bangerlee/archive/2011/09/18/2178172.html引言我们提倡编写功能单一、结构清晰、接口简单的函数，因为过于复杂的函数会给我们带来很多问题：加深其他开发人员理解代码的难度；不方便测试人员对其编写测试用例；容易隐藏错误；出现问题难以定位……怎样的函数算是复杂的函数?哪些代码散发着“臭味”?除了依靠经验丰富的程序员的敏锐嗅觉，我们还可以通过工具，对我们的函数和代码进行度量。不像一位严格苛刻的代码检视人员，代码度量工具并不会板着脸对我们说：“嗯……这段代码糟糕透了！"，它反馈给我们的是一组度量值(Metrics 阅读全文

摘要： http://blog.jobbole.com/53376/每当我倍感压力以及有很多事情要做的时候，我总是有这样一种反常的反应，那就是希望做一些其他的事情来摆脱这种状况。通常情况下，这些事情都是些我能够编写并实现的独立的小程序。一天早上，我几乎要被一堆事情给整疯了——我得看一本书、处理一些工作上的事情、还要准备一场Strange Loop的演讲，然后这时我突然想到：“我该写一个垃圾收集器了”。是的，我知道那一刻让我看上去有多疯狂。不过我的神经故障却是你实现一段基础的程序语言设计的免费教程！在100行左右毫无新意的c代码中，我设法实现一个基本的标记和扫描模块。垃圾收集被认为是有更多编程牛人出没的 阅读全文

摘要： http://www.udpwork.com/item/9294.html我想谈一谈这个话题是因为我的上一篇博客在ITEye上有一些朋友回复，说if-else过多的分支可以使用switch或者责任链模式等等方式来优化。确实，这是一个小问题，不过我们还是可以整理一下这个小问题的重构方式。为什么要优化？你没有看错。这是要放在第一条谈论的。有许多人会说，叠起来一堆if-else分支，代码就不优雅了。可是，怎样去定义“优雅”的概念呢？再退一步说，即便不“优雅”，又有什么问题？对于这样一段再普通不过的代码：int code;if("Name".equals(str)) code = 阅读全文

摘要： http://www.udpwork.com/item/8592.html其实本没有什么代码是“史上最烂”的，要有也只有“史上更烂”的，我想随便说说这个话题，也是源自豆瓣的一个讨论。事实上，系统复杂了被骂代码烂是一件司空见惯的事情。当然，也有一些短小的代码片段，就足以看出代码作者是个不怎么样的人。布尔类型的使用是很容易变成最烂代码的：if (isTrue()) if (isTrue()) doSomething();if(boolVal == true) { ..... }有一些毫无意义的注释：return 1; // 返回 1//如果标志为真，就返回truei... 阅读全文

摘要： http://blog.jobbole.com/18304/作为一个程序员，“起名字”是他们工作中非常重要的一部分。Phil Karlton就说过：“在计算机科学领域，有两大难题，如何验证缓存和如何给各种东西命名。”虽然很难，但是每次在写代码的时候，给事物起名字又是不可回避的工作。无论是程序变量名还是数据库表名或者是表里的列名，甚至是文件系统中的文件名，以及你的项目名称、产品名称，给这些东西起名字可不是个轻松活儿。糟糕的命名方式随处可见。你会发现，有的变量名字起得太短，根本没法提供足够的描述信息。或许有这个问题的人都做过TRS-80 BASIC程序员，在这种BASIC语言里，无论你起多长的变量 阅读全文

摘要： http://blog.jobbole.com/23739/酷壳里有很多我觉得很不错的文章，但是访问量最大的却是那篇《6个变态的Hello World》，和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”，以及编程真难啊等这样的文章。可见本站的读者们的偏好，我也相信你们都是“身怀绝技”的程序员。所以，今天给大家推荐这篇文章，相信一定能触动大家的兴奋点。这篇文章的原文在这里（http://mindprod.com/jgloss/unmain.html），我看完后我想说——1、什么叫“创造力”，创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。2、什么叫“抓狂”，抓狂就是 阅读全文

摘要： http://blog.jobbole.com/471/编者按：原文作者Alan Skorkin是一名软件开发人员，他在博客中分享对软件开发相关的心得，其中有很多优秀的文章，本文是其中的另一篇。Alan认为：阅读优秀代码是提高开发人员修为的一种捷径。以下是全文。我突然想起来，很多程序员都讨厌阅读代码。来吧，承认吧！ 每个人都喜欢编写代码，编代码是件趣事。 另一方面，阅读代码也不容易。 不仅不容易（编注：参见《微软资深软件工程师：阅读代码不容易》），而且还非常枯燥，咱们要面对这一事实。任何不是你的代码都不怎样。（虽然我们没有说出来，但我们都是这样想的。）即便是你自己几个小时之前写的代码，也会看起 阅读全文

摘要： http://blog.jobbole.com/31248/1、软件长期运营存在什么问题一个大规模的客户端软件的生命周期中，我们可以把它分为两个比较粗的时期。一个是前期的搭建软件的时期，即从无到有的时期；第二个是搭建完成之后，进入的一个稳定的运营时期。第二个时期才是最关键的，在这个时期我们会持续的迭加需求，持续的优化功能，而且第二个时期也是代码在慢慢变质的时期。在这个时期，你可能会发现：我们的软件慢慢出现模块耦合严重，牵一发而动全身；每个版本都会涌现出老功能的BUG，你没动过的模块也会出BUG；或者改了一个小问题了，带出来很多其他问题；缺乏扩展性，往老模块加新功能非常痛苦；程序的崩溃率越来越高 阅读全文

摘要： http://blog.jobbole.com/30690/随着万圣节越来越流行，我感觉有必要跟大家讨论一下一个在软件开发中非常普遍的问题：僵尸代码。几乎所有我接触过的代码库里都四散着很多小段的，甚至大片大片的被注释掉的代码。这就是僵尸代码。//目前禁用这项功能。Jimmy在写这段代码时肯定是喝醉了。//你可能以为这里发生了恐怖的代码凶手案…不，不，我只是把它们注释掉了…为什么称它们为僵尸代码？你知道，僵尸不并不是真的死的。就像恐怕电影里告诉我们的，尽管僵尸看起来是死人，但它们仍有能力四处出没袭击我们。相同的道理，僵尸代码也是处于不生不死之间…它们在伺机搞砸我们的工作。注释掉的代码还活着，它们 阅读全文

摘要： http://blog.jobbole.com/5643/很多团队都有这个问题，一个项目的代码本来开始设计得好好的，一段时间以后，代码就会变得难以理解，难以维护，难以修改。为什么？我一直在思考这个问题。让我们先看一个人的情况。1.程序员的成长新手的代码新手的代码没有经验，基本不考虑代码设计，代码规模稍稍大一点则自己就乱了。进阶者的代码小规模的时候大规模的时候进阶者已经知道如何设计代码，懂得代码规则，但一般局限于一个模块。规模一大，模块间的调用就会比较混乱，难以维护。有经验者的代码有经验者的代码，模块内部代码整洁，模块之间层次清晰，有设计模式，有成熟的体系。可以保持长期的代码整洁。那么一个团队里 阅读全文