Programmer | 酷壳 - CoolShell

程序员技术练级攻略

2011年07月18日陈皓评论 665 条评论 10,354,669 人阅读

注：该文最新的版本在这里《程序员技术练级攻略（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

(328 人打了分，平均分： 4.74 )

给程序员新手的一些建议

2011年07月12日陈皓评论 131 条评论 89,550 人阅读

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

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

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

(64 人打了分，平均分： 4.44 )

软件公司的两种管理方式

2011年07月06日陈皓评论 111 条评论 108,614 人阅读

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

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

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

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

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

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

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

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

…

阅读全文 Read More

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

一个空格引发的惨剧

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

你是否相信如果你的程序里没有检查一个变量会导致怎么系统瘫痪？无论你相不相信，这是我一个亲身经历过的案例，你可以在本站的程序员那些悲催的事儿中找到很多这样的事。这样的事昨天在发生，今天同样在发生。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

(28 人打了分，平均分： 3.89 )

“另类” 设计模式

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

下面这篇文章来自这里：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

(19 人打了分，平均分： 3.84 )

软件真的好难做啊

2011年06月10日陈皓评论 79 条评论 63,200 人阅读

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

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

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

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

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

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

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

…

阅读全文 Read More

(31 人打了分，平均分： 4.29 )

如何写出无法维护的代码

2011年06月03日陈皓评论 147 条评论 279,703 人阅读

酷壳里有很多我觉得很不错的文章，但是访问量最大的却是那篇《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

(70 人打了分，平均分： 4.39 )

读书笔记：对线程模型的批评

2011年05月03日 Ian.sino 评论 37 条评论 37,372 人阅读

——感谢Ian.Sian投递本文——

多线程模型是主流的并发编程模型。在过去几十年来，多线程模型一直是开发并发程序的有力工具。然而，它的历史并非总那么美好。1997年，NASA 的“火星探路者”号在执行任务的途中遭遇了严重的时序异常（参见 “What really happend on Mars“，注目 follow-up 中的现身说法），无法发回探测数据。如果不是 NASA 远程刷新了程序，它的结局就只能是报废在火星上。这一切都是由程序中潜藏的一个优先级反转 bug 造成的。更早的例子还有80年代的一系列 Therac-25 型医用粒子加速器事故。在这些加速器释放出的过量辐射照射之下，数位病人死亡。事后调查显示，至少有一次发生事故的原因，是加速器的控制软件中，存在一个只能由特定操作序列引发的竞争条件 bug。你也许认为这些只是陈年往事，但是直到现在，即便是世界500强公司们高价买来的信息系统，也同样避免不了这些问题。这导致许多程序员认为线程是个潘多拉魔盒，对它采取能躲就躲的态度。然而近来计算机的发展使得躲猫猫的空间越来越小：随便从市场上淘一个CPU，它里面也有不止一个核心。未来的程序员只会有越来越多的机会接触到并发编程，而无法再独善其身了。

加州大学伯克利分校教授，爱德华 A. 李在2006年做了一次题为《线程的麻烦 (The Problem with Threads)》的学术报告。在报告中他提到：看上去，多线程只是对核心语言的小小扩展，甚至可以以第三方库的形式存在。但实质上，多线程程序和原有的核心语言编写的程序已经完全不同了。其原因在于，由于多线程程序可能以任意的次序交错执行，程序再也无法像顺序执行时那样产生确定的结果。多线程程序容易编写(因为写的是顺序程序)，但是难分析，难调试，更容易出错。

在我的想法中，产生问题的根源，是多线程模型作为对并发问题的一个抽象，是很不完善的。 …

阅读全文 Read More

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

对程序员职业的一些建议

2011年04月26日陈皓评论 121 条评论 84,862 人阅读

自从四年前被CSDN采访后（“职业规化就像软件工程”），经常会有网友（尤其是刚毕业的）写邮件来问我一些程序员职业生涯的一些问题，至到今天。比如，国企还是外企的选择，一直编程有没有前途等等问题。面对这样的邮件，我感到有很大的压力，因为如果我的回复很有可能会误人一生，但我另一方面又很想帮助这些人。所以，我基本上还是会尝试回一下这样的邮件。昨天，我又回了一封。但是我心里还是有点忐忑不安。害怕说错了什么。

今天，我想把我的一些思路和建议写在这里，一方面供大家参考，另一方面也想听听大家对我的评判，这样不但对更多的人有帮助，同时对我自己也是一个帮助。

下面是某网友前天给我发来的邮件：

我是一个刚刚毕业的大学生，我觉得自己对于程序员这个行业感到很迷惘，所以发邮件打扰您一下，麻烦了。

我今年正在找工作，我现在有几家国企的offer，百度的offer还在等待，我觉得第一份工作对我来说很重要，因为第一份基本决定了近几年或者一辈子你在哪个行业发展。家里人都是希望我签国企，但是我自己对技术很感兴趣，一直希望能在技术上面走下去，签国企虽然很轻松但是我总觉得在技术上学不到什么有用的东西，所以我个人倾向是去百度。

我现在很迷惘的是，如果我一直在程序员这个行业上走下去，以后的出路应该是什么呢？还是一直到高级工程师，还是项目管理这种程度吗？

我现在听很多人在说程序员必需要转行，因为一辈子在编写代码，没有什么好的出路，对于这点，您有什么看法吗？我现在才刚刚从学校毕业，对IT这个行业也不是非常了解，但是我觉得自己自学能力很强，而且确实很想学些东西，你对于一个刚刚毕业的计算机学生有什么建议吗？

信件的内容我没有改变，我相信很多人都有相似的问题。我昨天给这们朋友回复了邮件，下面是我回复内容的一个整理。欢迎大家讨论。

首先，我想说的是，这些东西只是我根据我的经历给出的建议，仅仅供大家去参考，你的路你的人生要你自己决定，不要轻易的让人帮你决定，那怕是你的家人。

如果我们把所的问题一起谈，那怎么说也说不清楚，所以，请允许我“关键点分离原则”来分开说说。

…

阅读全文 Read More

(71 人打了分，平均分： 4.69 )

再谈“我是怎么招聘程序员的”（上）

2011年04月20日陈皓评论 94 条评论 136,684 人阅读

我以前写过一篇“我是怎么招聘程序员的”的文章（在CSDN那里有很多人进行了回复）。今天，我想再谈谈关于招聘和面试这方面的东西，主要是以下这些原因：

近半年来我在进行了大量的招聘工作，对面试有一些新的体会。
酷壳最近发布了几篇趣味面试题（面试题一，面试题二，面试题三），从回复中让我有一些思考。
我有一个同事最近面试了一家公司，他和我分享了一个博士专家对他的面试，也让我思考了一些。
在豆瓣上看到“知乎上某人写面试豆瓣产品经理的经历，很欢乐”(亮点是面试官现身知乎亲自作答)

所以，我很想把自己的这些新的想法再次写下来的。还是和以前一样，这篇文章同样是献给面试官的。我认为，面试的好坏完全在面试官而不是面试的人。下面是我对“我是怎么招聘程序员的”一文中的一些加强性的观点。（关于一些点评，请参看本文下篇）

为了让我的文章有连续性，请允许我重申一下前文的几个重要观点。

只有应聘者真实和自然的表现，才能了解到最真实的东西
重要的不是知识，重要的是其查找知识的能力
重要的不是那个解题的答案，而是解题的思路和方法

操作，知识，经验，能力

我们有很多的面试官似乎分不清，什么是操作能力，什么是知识，什么是经验，什么是能力，这导致了我们的面试官经常错误地对面试者下结论，我认为分不清这些事的人是没有资格做面试官的。所以，我有必要在这里把这个问题先讲清楚。

…

阅读全文 Read More

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

酷壳 – CoolShell

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

Browsed by
标签： Programmer

程序员技术练级攻略

2011年07月18日陈皓评论 665 条评论 10,354,669 人阅读

前言

给程序员新手的一些建议

2011年07月12日陈皓评论 131 条评论 89,550 人阅读

软件公司的两种管理方式

2011年07月06日陈皓评论 111 条评论 108,614 人阅读

一个空格引发的惨剧

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

“另类” 设计模式

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

概要

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

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

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

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

软件真的好难做啊

2011年06月10日陈皓评论 79 条评论 63,200 人阅读

如何写出无法维护的代码

2011年06月03日陈皓评论 147 条评论 279,703 人阅读

程序命名

…

阅读全文 Read More

读书笔记：对线程模型的批评

2011年05月03日 Ian.sino 评论 37 条评论 37,372 人阅读

对程序员职业的一些建议

2011年04月26日陈皓评论 121 条评论 84,862 人阅读

再谈“我是怎么招聘程序员的”（上）

2011年04月20日陈皓评论 94 条评论 136,684 人阅读

操作，知识，经验，能力