程序员中的怪象

① 为什么都说程序员不好

因为程序员这个职业的工作状态不利于身体健康，要长期伏案工作，而且经常处于一种忘我的状态，自己很难控制工作时长，而且有些团队承受任务期限的压力，不得不经常加班。

所以大家都说程序员不好。

② 程序员的鄙视链是什么

编辑器的：

Emacs → Vim → Sublime → Word → Power Point

Vim →→ Emacs + evil插件

notepad++ → notepad

all → Source Insight → notepad

编程语言的：

asm → C ↔ C++ ↔ Java ↔ C# → JavaScript → VB → VBScript

Common Lisp ↔ Scheme → Emacs Lisp →→ Python

Python ↔ Perl → shell

PHP → all

操作系统的：

Unix → Linux → Windows → DOS

Solaris →→ 其他Unix

*BSD ↔ System*

OpenBSD ↔ FreeBSD → NetBSD

Arch → Debian* → Redhat*

Debian → Ubuntu

Fedora → CentOS → RHEL

OSX → all

IDE的：

Emacs + plugins ↔ Vim + plugins → 其他加插件的编辑器

IntelliJ → Eclipse → NetBeans

Code::Blocks → CodeLite

VS → all → Turbo C 2.0

③ 我们对程序员的刻板印象就是格子衬衫加秃顶，实际上他们真的是这样吗

在现在的生活之中，身边的朋友从事程序员工作的人也变得越来越多了，有很多人对于程序员这一个群体的印象相对来讲也是比较客观的觉得他们总是穿着格子衬衫，并且头发也是比较稀少的，面对这样的情况会让很多人产生一种错觉，就是在见到了程序员之后都觉得他们是这样的形象，那么实际生活中的他们是不是真的是这个样子的呢？

虽然在平常工作比较繁忙的时候这些程序员的形象相对来讲是比较枯燥无味，并且也不会给大家带来特别多的惊喜，但是在放松的时候，这些净程序员们也能够散发出年轻人的活力，并且能够和其他人很好的玩在一起，所以大家对于程序员千万不要有这样的固定印象。

④ 什么是程序员编程中的老大难问题

上周，我发起了一个“程序员编程中的老大难问题”的投票，主要是基于最近Quora上的跟帖讨论。根据大家的反响和投票结果，有一项投票遥遥领先，稳居第一——对于软件开发人员来说，最大的难题是：如何命名（例如：给变量，类，函数和过程命名等等）。
对于这个结果，我多少有点意外，因为作为一个多年的开发人员，我不会投给这一项（我想我会投给“修改或维护别人的代码”）。但是真正让我惊讶的是，看起来好像不怎么重要的命名居然排列第一，跟期待的结果实在差太远了。下面是投票结果的分布图。

该结果是来自Quora问答网站和更早的Ubuntu论坛跟帖的4500个开发者的投票。“如何命名”一项的选票几乎是其它八项的投票结果的总和，哇！
的确，这些基于自我筛选的群体的投票结果是完全不科学的。但是我认为这个结果还是有一定意义的，换句话说，如何命名的确是个很棘手的问题，许多非编程人员可能会意识不到。
几年前在StackExchange社区里对于这个话题刚好有个跟帖，为了强调这一点，我引用了一些内容是关于程序员在编程中对于命名的的痛苦和纠结。
“我确实在编程的时候花了很多时间在考虑如何命名。”
“我不得不同意命名是一门艺术。”
“如果你想要提高代码的可读性，命名的确很重要。”
我认为最后一条抓住了部分核心，解释了命名为什么会这么难，因为它太重要了。准确的命名可以提高代码的可读性，让人容易理解，方便调试，也给以后修改和维护你的代码的人带来方便。一旦开始做了，很快你会发现要想出一个简洁又准确的名字没那么容易。就像Jeff Atwood 所写的：
“想出好的命名的确很难，但是有难的道理，因为好的命名需要只用一两个单词出表达你的根本意思。”
而且，许多人认为，正确的命名能帮你写出好的代码。如果不能为一个变量或者函数想出一个清晰又简洁的名字，那可能是你的代码有问题。那样的话，你就得考虑重写或者进行代码重构了。

⑤ 为什么有的程序员的代码结构混乱

程序员都有一颗工程师的心，所以当他们到一片新的场地想做的第一件事就是，将旧的一切推倒重来。是的，他们决不会满足于简单的增量劳动。

或许这种微妙的心理定位可以解释：为什么程序员进入新项目组后宁愿丢掉旧代码重新写，也不愿意修修补补。他们认为旧代码简直一团糟。

但是，事实上真是这样吗？你之所以认为旧代码一团糟，其实是由编程的一个基本定律决定的，那就是：写代码容易，读代码难。

为什么你觉得旧代码异常混乱？因为读代码更难。

这大概就是代码Reuse难以实现的原因。 这就是你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的，重新写一个自己的功能要简单和有趣多了。

作为这个公理的推论，你可以问问身边的程序员他们正在奋战的代码怎么样？“简直是一塌糊涂！”他们肯定会这样说。“我简直想推倒重来！”

为什么认为代码这么糟糕呢？“额，看看这个功能，竟然有两页长！完全不知道这些东西为什么在这里！完全不知道这些API是干什么的。”他们会这样回答你。

漫画：读别人代码是一种怎样的体验？

曾经，Borland的创始人 Philippe Kahn当初就是向记者们吹嘘：Quattro Pro会比Microsoft Excel要好用得多，因为它是从头开始编写的，全部都是新的源代码！

但是，认为新代码比旧代码好简直就是荒谬。旧代码是已经运行过的，测试过的。无数的bug在被发现前都上线运行过，发现之后程序员们可能在花了好些日子才修复了这些bug。这种修复可能是一行代码，也可能是几个字符，无数的时间和精力都花在了这些bug修复上。

当你决定抛弃这些旧代码从零开始的时候，你也丢掉全部前任努力的结果。

新代码一定比旧代买好？NO，重写可能会带来更大的风险。

对技术领导者来说，重写项目的代码也是一个异常艰难的决定。因为从公司层面说，重现代码甚至会威胁产品的市场竞争力。一旦决定重写代码，那么与竞品相比，你可能落后了2~3年——在软件行业，这时间可够长的。

你理想中的新代码会带来产品功能的提升▼

但事实上，即便重写的新代码可以实现旧代码的所有功能和需求，但是为产品带来的市场竞争力只有边际提升。因为重写用的新技术、新语言、新框架并没有给产品带来质的飞跃。

更不用说在重写的漫长过程中可能会遇到一些意外情况，比如：

1、缺钱：资金链的断裂▼

2、缺人：核心程序员离职

最终导致效果不佳：达不到原产品应有的所有功能和需求，白白浪费了时间和金钱，也丢掉了市场竞争力。▼

所以重写代码意味着，你在把自己置身于非常危险的境地，可能几年后你也写不出比以前更好的代码。你只是花了一大笔钱把已经存在的代码又写了一遍。

当你觉得眼前的旧代码很烂时，该怎么办？

你觉得旧代码写的很烂，那又怎样呢？它们已经上线，已经在实际运行中经受住了考验。所以当你发现前任留下的代码乱七八糟的时候，不妨冷静下来，从以下三个方面入手理解代码、改善代码：

1、代码的结构有问题

如果一段网络代码突然弹出了自己的对话框，应该是UI代码需要被处理。这些问题可以被解决掉，你要一次次小心地移动代码，重构，改变接口。还需要一位细心的工程师立马仔细地检查这些改变是否有问题，从而不打扰到其他人。事实上，甚至比较大的结构变化也可以不扔掉代码来完成。

大牛程序员Joel Spolsky回忆说，曾经在某个项目中，他和他的团队花了好几个月重新架构在一点上：把代码动来动去、清理、创建有意义的基类，并创建了模块之间的完美接口。但是他们始终非常小心翼翼，并没有产生新的bug、也没有丢掉任何旧代码。

2、代码的效率不高

曾经，Netscape的渲染代码被传非常缓慢。但事实上，这只会影响该项目的一小部分，这部分是你可以优化甚至重写的。你完全不必重写全部代码。优化速度的1％工作量，会让你获得99％的爆炸性提高。

3、代码写得很丑

有些代码真的写的很丑，比如Joel曾参与一个项目，开始用下划线做开始的成员变量约定，但后来改用更标准的“M_”。所以一半的功能用“_”开始，一半用“M”开始，这看起来真的很丑陋。但这个问题5分钟就能解决，而不用从头开始写全部的代码。

最后，你要记住，从头开始再写一遍并不意味着你会写出比以前更好的代码。因为你没有参与到上一个版本的创建，所以你其实根本就不算有经验。一旦你准备推倒重写，你可能会再犯一遍版本一犯过的错，甚至会产生更多的新问题。

一个总结：

面对糟糕的旧代码，Keep Calm & Carry On !

在大型商业项目中，推倒重来是非常危险的行为。当然，如果你是在做实验，想到新算法可以随时重写。

⑥ 程序员都有怎样的通病

中国的大部分程序员都有一个通病，眼高，手低，知识面宽，深度浅；有自己的理想和目标，但实施的决心太小，还总闲工资太少，觉得老板太扣。于是总是“跳呀跳”。

⑦ 外界对程序员都有什么样的刻板印象

认为程序员非常不懂得人情世故嗯，认为他们只知道每天自己去编写程序，他们的世界只有0和1，他们的情商很低，并且，不善于与人沟通交流，喜欢宅在家里，朋友很少

⑧ 论：为什么别人眼中的程序员都是傻×

｛要嫁就嫁程序员！钱多话少死得早｝这句话本身带着玩笑又警世的意思。可以说，每一个程序员一天绝大部分的时间都猫在电脑面前，程序员作为一个高端行业的设计人员做一个程序员的前提条件是一个超级网虫，熬夜辐射伤身伤害眼睛伤害脑细胞饮食不规律什么的，在电脑面前总是最容易得到的毛病。一般程序员都会有，损害健康损害寿命。程序员是一个高端的职业，往往开发出一个程序就可以赚到比平常人超出几倍十倍百倍不等的金钱价值，当然了这要看开发出来的东西有没有经济价值。但是往往一个值钱的程序软件什么往往要很多很多程序员日夜煎熬加班猜得出的成果，所以就是赚钱也可能搭上了健康，死得早。奉劝人们不要为了工作金钱搭上了健康。

⑨ 为什么程序员的思维很难理解

1、程序员的思维比普通人要严谨。
对编程有一定了解的人都能理解这一点，一是一二是二，电脑不认模棱两可的回答，因为“模棱两可意味着更多的可能答案”，所以你跟程序员交谈的时候，如果你问他“为什么要这样问”或“你为什么听不懂”，你就会知道你自己的描述有多么的不严谨了。
最简单的例子，你妈妈让你去市场买水果，如果看到有苹果就买一个苹果，看到梨就买两个。你看到市场有苹果和梨，你会买什么回家？
首先给出一个大前提，在程序上不存在“潜台词”或者“潜规则”这种东西，唯一起作用的只有“字面意思”。
一般人肯定是买一个苹果和两个梨。当然程序员也不是脑子有坑，以一个正常人的思维考虑也会买一个苹果和两个梨，但是看到这问题的第一个瞬间的直觉反应，却是“如果看到梨就买两个苹果”。这个问题不存在潜台词，所以所有人都会直接从字面理解老妈的意图。
按照程序的逻辑分析，这句话共分为两个部分，代表两个程序任务。“如果看到有苹果就买两个苹果”为任务一，条件是“看到有苹果”，目标对象“买苹果”，数量“一个”；“如果看到有梨就买两个”为任务二，条件是“看到有梨”，数量“两个”，没有给出新的目标对象。
因此按照程序逻辑来讲，第二句话将继承上一个目标对象，也就是“买苹果”，所以这句话被看起来像职业病一样的思维直接翻译成了“如果看到有苹果就买一个苹果，如果看到有梨就买两个苹果。”

————————————————————

2、程序员看问题比一般人透彻。
这是职业特性导致的，因为电脑编程的严谨性，因此程序员面对一个问题、一个需要实现的目标或者一个bug时，他会思考更底层的问题，并且会习惯性采用归纳法来尽量避免以后可能遇到同样的问题。
比如用输入法输入中文的词句，有的时候打出了一串拼音，然后按下数字2选取发现不是自己想要的词，然后发觉数字1对应的才是自己想要的，删掉，重新输入拼音，这次按下数字1的瞬间却发现两个词的位置调换了，于是又删掉重新键入，这次认真地看了看，终于选对了想要的词的序号。
这个时候你会说，啊，我下次应该更小心一点，不要马虎大意想当然，看清楚了再点。
程序员不这么想，他会想，导致这个问题的看来是输入法的“词语顺序自动调整”功能，他会自动监测使用者输入的各种词语的频率，来自动调整词语的顺序，底层代码实现的逻辑很简单，每个不同的词对应一个从输入法安装到现在的输入次数的计数器，直接按计数器排列顺序就好了；也有的输入法会监测你输入后是否会将其删掉，那么这时候会被智能识别为打错字，计数器不会加一。
然后再一思考，这种功能一般都是可以开关的，如果我想要靠记忆记住顺序使用而不用输入法自动调整的话，比如对汉字输入的速度有一定要求需要考记忆记住汉字序号，我只需要进入输入法设置将其关掉即可；如果我想要它帮助我调整词句位置，但是又不需要频繁地调整，那么在我有工作需要的时候我会提前关掉，平时开启即可；而如果我想单纯依赖这一功能，那就不用管它，下次看清楚再选就好了。

⑩ 为什么都说悲剧的程序员程序员很悲剧吗

情景一：

程序员的悲哀，不是情商问题，不是衣着问题，更不是自黑之类的，悲哀是并没有决策权。项目做成什么样，你有决定权吗？那是领导和产品经理的事。注意流程是这样的：领导或经理决定要改需求，然后通知你，然后你等设计给你图，然后你做好。程序员只是一个执行者，别人叫你干啥你就只能干啥，除非产品是傻逼到让你实现不可能的功能。最后项目做坏了，裁员了是谁？程序员。

做程序员越久，越是感到：我们就是新时代的手工艺者。只有少数的人，从手工艺者，变成了发明手工艺制作机器的人，少部分人变成了设计手工艺品的人，少部分人变成了车间主任罢了。

“码农”这个词有着深深地悲哀。

欢迎大家都来吐槽！