程序员 | 酷壳 - CoolShell

弱爆程序员的特征值

2011年08月23日 sumtec 评论 69 条评论 58,458 人阅读

【感谢网友sumtec投递此文，很欢乐也有意思，与大家共勉】

首先说明：

1、以下特征是真实遇到过的，同事犯过的，乃至我自己也犯过的；
2、为了剧情需要，某些例子进行了一些夸张修饰等演绎创作，如无雷同，请勿生气；
3、如果你出现过以下症状之一，并不代表你就是弱爆了，但是如果你一直出现，乃至一说到这个大家就能联想到你，那么你就得小心了；
4、如果你是集这几个的大乘者，恭喜你，你已经找到了离开这个行业的充足理由了。

好了，搞定！

“那个Bug解决了吗？”

“好了，搞定！”

“这么快？”

正当你非常欣喜的时候，就传来了噩耗：刚才还能编译成功的，就失败了。（好吧，我们的集成编译尚未成功配置上，理论上这种事情应该会被退回。）又或者能编译成功，但是呢，原来明明能起作用的一个下拉框，突然发神经的不起作用了。最隐蔽的莫过于，一切正常，但是当你看到代码的时候，你就晕厥过去了。比如我们曾经发现了一个Bug，简单说就是每次用户点击某个东西，就会执行下面的这段C#代码：

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这个Bug很明显会导致速度越来越慢，因为同一个更新操作会被更新N次，并且这个N会越来越大。其实这个Bug已经够弱了，但是后来居然被修改为：

…

阅读全文 Read More

(25 人打了分，平均分： 3.88 )

你曾去想重构一个很老的模块，但是你只看了一眼你就恶心极了。文档，奇怪的函数和类的命名，等等，整个模块就像一个带着脚镣的衣衫褴褛的人，虽然能走，但是其已经让人感到很不舒服。面对这种情况，真正的程序员会是不会认输的，他们会接受挑战认真分析，那怕重写也在所不惜。最终那个模块会被他们重构，就像以前和大家介绍过的那些令人销魂的编程方式中的屠宰式编程一样。下面是重构代码的几个阶段，文章来自：The 7 stages of refactoring，下面的翻译只是意译。

第一阶段 – 绝望

在你开始去查看你想要重构的模块的，你会觉得好像很简单，这里需要改一个类，那里需要改两到三个函数，重写几个函数，看上去没什么大不了的，一两天就搞定了。于是你着手开始重构，然后当你调整重构了一些代码，比如改了一些命名，修理了一些逻辑，渐渐地，你会发现这个怪物原来体型这么大，你会看到与代码不符甚至含糊不清的注释，完全摸不着头脑的数据结构，还有一些看似不需要方法被调了几次，你还会发现无法搞清一个函数调用链上的逻辑。你感到这个事可能一周都搞不定，你开始绝望了。

第二阶段 – 找最简单的做

你承认你要重构的这个模块就是一个可怕的怪物，不是一两下就可以搞定的，于是你开始着干一些简单的事，比如重新命名一下几个函数，移除一些代码的阻碍，产生几个常量来消除magic number，等等，你知道这样做至少不会让代码变得更糟糕。

第三阶段 – 再次绝望

但是接下来的事会让你再次撞墙。你会发现那些代码的瑕疵是些不痛不痒的事，改正这些事完全于事无补，你应该要做的事就是重写所有的东西。但是你却没有时间这么干，而这些代码剪不乱理还乱，耦合得太多，让你再一次绝望。所以，你只能部分重写那些不会花太多时间的部分，这样至少可以让这些老的代码能被更多的重用。虽然不完美，但是至少可以试试。

…

阅读全文 Read More

(32 人打了分，平均分： 4.31 )

你确信你了解时间吗？

2011年08月01日陈皓评论 93 条评论 52,225 人阅读

你还记得“软件真的好难做”中的那个有意思的例子吗？那个例子告诉我们软件开发中假设可能会是致命的事。今天，我又在StackOverflow上看到一个关于时间的问题——为什么1927年12月31日的午夜时间这么奇怪？提问题的这个人给了下面的一段java代码（我做一些修改，保证让你可以copy过去就可以编译运行）

我在其中高亮了几行，这个程序就是想比较一下“1927-12-31 23:54:07” 和 “1927-12-31 23:54:08” 差几秒，很明显，是差一秒。但是程序的输出却不是这样的。

import java.text.SimpleDateFormat;
import java.text.ParseException;
import java.util.Date;
import java.util.TimeZone;
class time{
    public static void main(String[] args) throws ParseException {
        SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        sf.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"));
        String str3 = "1927-12-31 23:54:07";
        String str4 = "1927-12-31 23:54:08";
        Date sDt3 = sf.parse(str3);
        Date sDt4 = sf.parse(str4);
        long ld3 = sDt3.getTime() /1000;
        long ld4 = sDt4.getTime() /1000;
        System.out.println(ld3);
        System.out.println(ld4);
        System.out.println(ld4-ld3);
    }
}

…

阅读全文 Read More

(33 人打了分，平均分： 4.30 )

程序员技术练级攻略

2011年07月18日陈皓评论 656 条评论 10,225,237 人阅读

注：该文最新的版本在这里《程序员技术练级攻略（2018版）》（需要付费阅读）

月光博客6月12日发表了《写给新手程序员的一封信》，翻译自《An open letter to those who want to start programming》，我的朋友（他在本站的id是Mailper）告诉我，他希望在酷壳上看到一篇更具操作性的文章。因为他也是喜欢编程和技术的家伙，于是，我让他把他的一些学习Python和Web编程的一些点滴总结一下。于是他给我发来了一些他的心得和经历，我在把他的心得做了不多的增改，并根据我的经历增加了“进阶”一节。这是一篇由新手和我这个老家伙根据我们的经历完成的文章。

我的这个朋友把这篇文章取名叫Build Your Programming Technical Skills，我实在不知道用中文怎么翻译，但我在写的过程中，我觉得这很像一个打网游做任务升级的一个过程，所以取名叫“技术练级攻略”，题目有点大，呵呵，这个标题纯粹是为了好玩。这里仅仅是在分享Mailper和我个人的学习经历。（注：省去了我作为一个初学者曾经学习过的一些技术(今天明显过时了)，如：Delphi/Power builder，也省去了我学过的一些我觉得没意思的技术Lotus Notes/ActiveX/COM/ADO/ATL/.NET ……）

前言

你是否觉得自己从学校毕业的时候只做过小玩具一样的程序？走入职场后哪怕没有什么经验也可以把以下这些课外练习走一遍（朋友的抱怨：学校课程总是从理论出发，作业项目都看不出有什么实际作用，不如从工作中的需求出发）

建议：

不要乱买书，不要乱追新技术新名词，基础的东西经过很长时间积累而且还会在未来至少10年通用。
回顾一下历史，看看历史上时间线上技术的发展，你才能明白明天会是什么样。
一定要动手，例子不管多么简单，建议至少自己手敲一遍看看是否理解了里头的细枝末节。
一定要学会思考，思考为什么要这样，而不是那样。还要举一反三地思考。

注：你也许会很奇怪为什么下面的东西很偏Unix/Linux，这是因为我觉得Windows下的编程可能会在未来很没有前途，原因如下：

…

阅读全文 Read More

(312 人打了分，平均分： 4.75 )

给程序员新手的一些建议

2011年07月12日陈皓评论 129 条评论 75,299 人阅读

前段时间因为实习生计划花了很多时间做了实习生招聘的工作，产生的一些想法，写在这里。

这次招聘过程中，我发现我们在校的学生有下面的这些特点：

1）NB的项目。当说到自己做过的项目时，我发现他们做的事都是很NB。要么是研究Linux的底层内核，要么是图像识别处理，要么是推荐算法，要么做高性能计算，要么做数据挖掘，要么是移动方面的协议，还有一些很高深的课题我听不太懂的项目。这让我想起当年我在学校里的实习，对比起我用Java Applet 和 HTML做操作系统的教学课件，或是在公司里用Delphi/PowerBuilder做的那些MIS系统。让我觉得有些汗颜。

2）OK的解决问题能力。当问到算法题时，我发现他们的问题解决能力还OK。我一般问1到2个中低难度的算法题和1个基本的面向对象设计的题，都不难。我相信只要在学校里好好学习的人都应该答得出来。无非就是一些基本的算法和基本数据结构操作的问题，和比较基础的面向对象设计的题，说白了就是作业题。可惜的是，只有5%不到的同学能够在不给提示的情况下答出来，70%的人可以在给一定的提示下答出来，15%左右的同学需要提示到几乎给出答案才能答出来，还有10%的同学怎么给提示都答不出来。

3）WTF的编码能力。老实说，对于解算法题，我还是比较可以接受的，因为80%左右的同学在给予提示后都能描述出解题的算法，于是，我让他们把这个算法用他们最熟悉的语言写出来。但结果让我出乎意料，一段在解法很清楚的情况下只需要不到30行代码的小算法题，只有一个人能在10分钟几写完，其它的人基本所有的需要30分钟左右（甚至40分钟），有2、3个人居然写不出来。有一个比较极端的case是——有个同学花了十分钟都写不出从一个整型数组中找到最小的正数的代码。这个事让我觉得很惊讶，难道大家在做项目的时候不编程吗？

对于这种情况，我想给大家以下后一些建议：

…

阅读全文 Read More

(61 人打了分，平均分： 4.54 )

软件公司的两种管理方式

2011年07月06日陈皓评论 110 条评论 91,999 人阅读

这篇文章是我的一个外国的同事Gareth推荐给我的，我和他一起工作过一段时间。他之所以觉得非常不错，是因为这篇文章让他身有体会，他觉得我也一定会有体会，并让我考虑一下翻译到我的blog上来。我看完后觉得很有代表性，而且觉得说得太对了，所以翻译过来，希望大家都读一读，最好转给你的公司老板。

这篇文章来源于 StakeExchange上的一个问题——“为什么BA和PM的薪水要比程序员要高？”，顶在一楼的回复分析了这个原因，并指出了两种管理文化。

———————————————————正文开始————————————————————

一个简单的回答应该是——“因为在我们的社会里，我们总是会认为薪水和会和职位的层次绑在一起”。但是，这个答案同时也折射出一个事实——我们的薪资是基于我们的所理解的价值，但这并没有解释

为什么PM（Project Manager）和BA（Business Analysts）在很多软件公司里在组织的上层？
为什么软件项目团队总是在最底层？

这两个问题真是非常地值得我们去问，去思考。

总体来说，这个世界上存在两种不同的软件公司的组织结构。我把他们叫做 Widget Factory（小商品工厂）和 Film Crews（电影工作组）.

Widget Factories 想要去解决怎么去激发被X理论所影响的人。X理论由 McGregor提出，这个理论是说，一般人的本性是懒惰的，工作越少越好，可能的话会逃避工作，大部分人对集体（公司，机构，单位或组织等）的目标不关心，因此管理者需要以强迫，威胁处罚，指导，金钱利益等诱因激发人们的工作源动力。于是，经理总是要去做他下属的工作。于是，基于这种前提下所思考出来的管理方式，很自然的就是——整个团队能够容易地被经理一个人所取代，这种团队中的每一个人都很容易被别人取代，在这种团队里，经理的工作能力不断地被加强。因些，这种公司一般使用树形层级的组织结构，而不是水平式的工作角色。

…

阅读全文 Read More

(56 人打了分，平均分： 4.64 )

一个空格引发的惨剧

2011年06月20日陈皓评论 106 条评论 156,701 人阅读

你是否相信如果你的程序里没有检查一个变量会导致怎么系统瘫痪？无论你相不相信，这是我一个亲身经历过的案例，你可以在本站的程序员那些悲催的事儿中找到很多这样的事。这样的事昨天在发生，今天同样在发生。Unix40多年了，在这40年里，程序员发生过各种各样的的惨剧，但是大多数的事情一而再再而三的重演。

今天的你，可能在开发者各种各样NB的系统，你会相信你的一个空格也能导致系统瘫痪吗？也许你可能很难相信这个事。不过，再下面这个事将告诉你这个血淋淋的事实 —— 一个空格产生的bug可以让你的系统瘫痪。

bumblebee是一个开源项目，这个名字也就是变形金刚里的大黄蜂，这个项目是这样介绍自己的——

bumblebee is Optimus support for Linux, with real offloading, and not switchable graphics.. More important.. it works on Optimus Laptops without a graphical multiplexer..

Optimus 是NVIDIA的“优驰”技术，其可以将您的笔记本电脑PC提升到绝佳状态，提供出色的图形性能，并在需要时延长电池续航时间。这个项目是把这个技术移到Linux上来。

这个项目本来不出名，不过，程序在其安装脚本install.sh里的一个bug让这个项目一下子成了全世界最瞩目的项目，这个bug的fix如下：

@@ -348,7 +348,7 @@ case "$DISTRO" in
-  rm -rf /usr /lib/nvidia-current/xorg/xorg
+  rm -rf /usr/lib/nvidia-current/xorg/xorg

看明白了吗？空格。这个空格会导致什么样的问题呢？呵呵。你有没有感到菊花一紧？这个bug绝对的霸气外露！真是验证了“如何写出无法维护代码”的那句话——“测试你的程序是一种懦夫的行为”。

不过，最精彩还不是这个bug，而是全世界程序员的对这个bug 的 code review comments，真的相当的欢乐。请强势围望！

…

阅读全文 Read More

(27 人打了分，平均分： 4.00 )

“另类” 设计模式

2011年06月16日陈皓评论 12 条评论 18,878 人阅读

下面这篇文章来自这里：http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns，这篇文章有点意思了，山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译，也许我翻译的不好，大家多指正。另外，这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词，一走眼你还以为是正二八经的设计模式。呵呵。所以，我在下文中，我会保留原有的英文单词，并把真正的23个经典设计模式的英文名放在旁边（灰色）。这篇文章和之前的如何写出无法维护的代码有异曲同工，个人感觉都是比较欢乐的。

辞职模式
Resign Patterns
Design Patterns

不合式的非面向项目软件开发病症
Ailments of Unsuitable Project-Disoriented Software
Elements of Reusable Object-Oriented Software

作者：Michael Duell

概要

任何一个熟悉那本由四个人写的经典的设计模式书的朋友，应该知道那本书里的模式都是非常优雅和划时代的。然而，不幸的是，从那些老代码中无法提练出这些模式，因为，在出现这些模式前，大家都不会使用模式。因此，这项工作是从大量的代码中提练出一个模式的目录。这些模式都有充足和永恒的示例。希望你能享受阅读这些模式，但千万不要模仿并使用他们！

1. Cremational Patterns 火葬模式 | Creational patterns 创建模式

下面是五个 cremational patterns.

1.1 Abject Poverty 一贫如洗 | Abstract Factory 抽象工厂

Abject Poverty 模式能让你的软件相当难测试和维护，并且需要巨大的财政支出，预算已经完全赤字。

1.2 Blinder 眼罩模式 | Builder 建造模式

Blinder 模式是一个应急有效的解决方案，其不需要考虑需求在未来的变化。目前，我们还不太清楚我们为什么叫Blinder模式，一种说法是他们会在写代码的时候被设计人员戴上眼罩，另一种说法是他们希望在维护代码的时候挖出双眼。

1.3 Fallacy Method 错误方法 | Factory method 工厂方法

Fallacy方法主要是在于处理一些不明显的案例。代码逻辑看上去是正确的，当只要某想要去测试一下，或是某个不明显的案例发生了，那些代码中的错误也就出现了。

…

阅读全文 Read More

(18 人打了分，平均分： 4.00 )

软件真的好难做啊

2011年06月10日陈皓评论 78 条评论 55,543 人阅读

还记得以前本站的那一篇“编程好难啊”吗，那是一篇众程序员调侃程序新手的文章，有恶搞的成分在里面。今天要和大家说的这个事没有一些恶搞和调侃的意思，是比较严肃的话题，你一定可以从中收获一些东西。这个话题来自StackOverflow上的一个问题——Cycle in Family Tree Software，这个程序员问了下面这个问题：

我是一个写家族族谱软件的程序员（我用的是C++和Qt），这个软件基本上没有什么问题，直到有一天有个用户报告了一个bug。这个问题是这样的——我这个用户和他女儿生了两个孩子。

于是，我程序员的一些断言和硬性条件导致程序报错，因为我的程序在处理这个关系的时候，其发现X即是Y的爸爸，又是Y的爷爷，所以只能报错。

请问，在不需要移除我的断言和数据验证的情况下，我怎么才能解决这个问题？

看到这里，请重点阅读一下下面的两点：

如果你看到这里开始兴奋了，请你为你阴暗的心理去面壁反省10分钟，因为这是一个很技术的问题。
如果你开始陷入了深深的思考如何解决这个问题，那么你绝对是一个合格的程序员，因为你已陷入技术已经很深了，有点呆了。

我在前面说过，“这个是一个严肃的话题，你可以从中收获一些东西”，当然，我并不希望你来收获乱伦的知识和心得，酷壳是一个技术博客，应该是收获技术方面的东西。

…

阅读全文 Read More

(29 人打了分，平均分： 4.38 )

如何写出无法维护的代码

2011年06月03日陈皓评论 146 条评论 248,722 人阅读

酷壳里有很多我觉得很不错的文章，但是访问量最大的却是那篇《6个变态的Hello World》，和它能在本站右边栏“全站热门”中出现的还有“如何加密源代码”，以及编程真难啊等这样的文章。可见本站的读者们的偏好，我也相信你们都是“身怀绝技”的程序员。所以，今天给大家推荐这篇文章，相信一定能触动大家的兴奋点。

这篇文章的原文在这里（http://mindprod.com/jgloss/unmain.html），我看完后我想说——

什么叫“创造力”，创造力就是——就算是要干一件烂事都能干得那么漂亮那么有创意的能力。
什么叫“抓狂”，抓狂就是——以一种沉着老练的不屈不挠的一本正经的精神一点一点把你推向崩溃的边缘。

我把文章节选了一些，也并没有完全翻译，简译一下，也加入了一些自己的调侃。对于有下面这些编程习惯的朋友，请大家对号入座。另外，维护程序的朋友们，你们死定了！！

If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization. （如果建筑师盖房子就像程序员写程序一样，那么，第一只到来的啄木鸟就能毁掉我们的文明）

~ Gerald Weinberg (born: 1933-10-27 age: 77) Weinberg’s Second Law

程序命名

容易输入的名字。比如：Fred，asdf
单字母的变量名。比如：a,b,c, x,y,z（陈皓注：如果不够用，可以考虑a1,a2,a3,a4,….）
有创意地拼写错误。比如：SetPintleOpening， SetPintalClosing。这样可以让人很难搜索代码。
抽象。比如：ProcessData, DoIt, GetData… 抽象到就跟什么都没说一样。
缩写。比如：WTF，RTFSC …… （陈皓注：使用拼音缩写也同样给力，比如： BT，TMD，TJJTDS）
随机大写字母。比如：gEtnuMbER..
重用命名。在内嵌的语句块中使用相同的变量名有奇效。
使用重音字母。比如：int ínt（注：第二个 ínt不是int）
使用下划线。比如：_, __, ___。
使用不同的语言。比如混用英语，德语，或是中文拼音。
使用字符命名。比如：slash, asterix, comma…
使用无关的单词。比如：god, superman, iloveu….
混淆l和1。字母l和数字1有时候是看不出来的。

…

阅读全文 Read More

(66 人打了分，平均分： 4.41 )

酷壳 – CoolShell

享受编程和技术所带来的快乐 – Coding Your Ambition

Browsed by
标签：程序员

弱爆程序员的特征值

2011年08月23日 sumtec 评论 69 条评论 58,458 人阅读

好了，搞定！

重构代码的7个阶段

2011年08月16日陈皓评论 77 条评论 58,828 人阅读

你确信你了解时间吗？

2011年08月01日陈皓评论 93 条评论 52,225 人阅读

程序员技术练级攻略

2011年07月18日陈皓评论 656 条评论 10,225,237 人阅读

前言

给程序员新手的一些建议

2011年07月12日陈皓评论 129 条评论 75,299 人阅读

软件公司的两种管理方式

2011年07月06日陈皓评论 110 条评论 91,999 人阅读

一个空格引发的惨剧

2011年06月20日陈皓评论 106 条评论 156,701 人阅读

“另类” 设计模式

2011年06月16日陈皓评论 12 条评论 18,878 人阅读

概要

1. Cremational Patterns 火葬模式 | Creational patterns 创建模式

1.1 Abject Poverty 一贫如洗 | Abstract Factory 抽象工厂

1.2 Blinder 眼罩模式 | Builder 建造模式

1.3 Fallacy Method 错误方法 | Factory method 工厂方法

软件真的好难做啊

2011年06月10日陈皓评论 78 条评论 55,543 人阅读

如何写出无法维护的代码

2011年06月03日陈皓评论 146 条评论 248,722 人阅读

程序命名

…

阅读全文 Read More