程序员能力

这里分享一篇 Peter Norvig的 《十年学会程序设计》 （Peter Norvig 系Google研究院主任、美国计算机协会（ACM）资深会员（Fellow））。全文如下： 十年学会程序设计 Peter Norvig (Copyright 2001) 原文网址 为何大家如此匆忙? 走进任何一家书店，你会看到书架上一排不见尽头的放着如 <7天自学Java语言> 以及几天或者几小时学会Windows, 因特网或者Visual Basic 这类书。我在 Amazon 网上书店用一下的方式进行 高级搜索 : 出版年份: 1992以后　书名包括：“天” 和 “学习” 或 “自学” 得到了268条搜索结果，其中前78条都是计算机书（第79条是 30天学会孟加拉语 ）。 我用 “ 小时 ” 代替“天” 作为关键字，得到了神奇般类似的结果：这次有253本书，前77本是计算机书， 第78本是 24小时自学语法和写作风格 。排名前200的书中有96%是计算机书。 由此可见，人们要不就是急着想学会计算机，要不就是计算机相比于其他事情太容易学会了。比如说把，没有书是写在几天弹奏贝多芬或几天学会量子物理，甚至也没有几天学会帮小狗打扮这样的书。 让我们分析一下 三天学会Pascal语言 [英文网页] 这样的标题表达了什么意思： 学会: 在 三天内，你没有时间去写几个有意义的程序

【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】 最近形势不好，这基本是大家的共识了。不管是外面的贸易战，还是现在的制造业萎缩、升级转型，越来越多的裁员搞得大家人心惶惶的。说到程序员35岁危机，其实这也不是软件工程师特有的，中年危机是广泛存在的。一方面生活对自己的要求越来越高，家里开支越来越大；另外一方面个人精力有限、无法在专业和业务上有更多的提高了。那么，作为年纪大的程序员应该怎么做？ A、增加业务的能力 早期的开发可能更加偏向于技术，但是我们知道一个项目的成功是多方面的，因此有必要知道自己做的产品有什么用。同样的技术在不同的产品、不同的行业可以发挥不同的价值。就拿嵌入式技术来说，在一些行业就是配角，而在另外一个行业却是主角，这个从成本占比就可以看出来。 B、整体把握产品 拿摄像头来说，安防行业会用、家庭会用、汽车行业也会使用。但是对于公司里面的员工来说，他可能负责的只是很小的一个领域。要么做驱动，要么做应用，要么做上位机，这个时候如果没有从具体的技术走出来，那么他是很难理解自己的工作对于整体的产品有什么价值。从更高的角度来思考，自己做的是什么行业，当前做的是什么产品，有哪些客户的问题还没有解决，哪些问题已经解决了，自己可以在这中间发挥什么作用，这些都是可以好好反思一下。 C、产品和市场 做技术的人很少考虑自己的用户在哪里

不想成为将军的士兵不是好士兵，不想成为架构师的程序员不是好的程序员。 互联网行业的技术迭代是非常快的，我们总是想18般武艺加身，出手便能解决所有的问题。但是每个人的时间和能力都有限，专注于自己的领域，做好做精我觉得便足够了。之前我一直都是知识的索取者，碰到不会的问题就百度，搜博客。虽然我历经艰辛找到我要的结果，但是大多数时候知识的传播在此处就断开了，我解决了我的问题，但是没能使下一个人受益。 我有时在想，什么样的事是有意义的，有价值的。作为一名系统开发人员，能够开发出一套国民级的项目可能对于我们大多数人来说都是一个梦想，看着别人每天用着自己的系统，心里想想都自豪。然而我们既写不出Spring这种伟大的项目，也参与不了支付宝、微信等系统的开发。我们能做的是应用我们掌握的知识，将手中的项目做得完美。 将自己的学习心得，项目经验分享出来，和大家来场对话，让下一个人能从中受益，这便是我的初衷，这便是有意义的事。 来源： CSDN 作者： MAX_VALUE 链接： https://blog.csdn.net/MAX_VALUE/article/details/103858764

作为一名拥有15年开发经验的工程师，最早让我开始“懂事儿”的，是简洁明了的一句话： 出色的代码，是表达能力更强的（expressive），而不是令人印象深刻的（impressive）。 我记得当时自己对此感到很疑惑，表达能力更强的和令人印象深刻的，他们在本质上有什么区别呢？ 实际上，表达能力更强意味着清晰、明确、具体。因此，一段表达能力较好的代码需要能解决一个特定的问题。在为了写这样一段代码所付出的时间与努力的背后，是非常清晰、明确、具体的目标，而这段代码也必须能够真正地实现这个目标。 而令人印象深刻的，则表示要在写代码的过程中留下明显的个人标志或印记。一段自身结构复杂，夹杂着多种深奥算法的代码，也许可以为你吸引来他人的关注、赞叹与掌声，在充分满足你的虚荣心的同时，也有可能转化为那个在未来接替你继续维护代码的工程师的满腔怒火。如果他正好是一个脾气暴躁且知道你住在什么地方的人，那么接下来会发生的事情恐怕就不会那么让你感到高兴了。 这就是程序员应该选择明智而不是聪明的原因。一个精明的开发工程师需要具备那种能够预见自己的哪些行为在什么情况下会带来什么后果的能力，并能对「自己写的是什么样的代码」、「自己为什么要这么写」，以及「这些代码在未来可能会有怎样的演变」这三个问题有着清楚的认知。简单来说，精明的工程师不会去做“亡羊补牢”式地救火开发工作，他们在写代码时坚信应当一劳永逸地解决问题。 而

星期六是我的休息日，这天一般我不安排自己做什么和工作有关的事情，一般就是去看看电影，出去逛逛，或者在家上上网吹吹牛。昨天 总结 了一部分由 推特 上的讨论，现在继续剩下的一部分。不过，这次的内容可能就要和技术或产业略远一些了，其中大部分是我自己的一些体会和感想。现在我打算谈三个东西，一是《史上第一混乱》这部话剧，《程序员的爱情》这本小说，以及Nobody和Sorry Sorry（您不知道这是啥？你成奥特曼啦！）。 史上第一混乱 上周五公司开年会，其间我侥幸拿下喝啤酒比赛第一，赢得价值300元的电磁炉一个——这还是整场年会中唯一比蛮力的项目，我那个自豪啊。呃，扯远了，其实下一件事才和我要谈的事情有些联系。那就是后来我又在年会上表演节目，唱了两首歌，因此拿到了昨天晚上《史上第一混乱》话剧的门票。至于为啥是这个话剧，后来我才意识到原来这个话剧改编自盛大文学旗下 起点中文网 上的 同名小说 ，如此说来盛大准备几张该话剧的门票自然就顺理成章了。 昨天下午先去看了场电影，锦衣卫，甄子丹演的，我对于此类动作片的兴趣始终不减，不过看完后倒也没有什么留下什么深刻的印象。看完后吃了晚饭，发现时间尚早，想票子不要浪费了吧，于是便去看了这场话剧。座位不太好，第一排，需要一直仰着头。不过由于距离够近，因此可以清晰地看到演员横飞的唾沫星子，还有演女人的mm身材也不错，腿细胸大的。 提起话剧内容

作为一名拥有15年开发经验的工程师，最早让我开始“懂事儿”的，是简洁明了的一句话： 出色的代码，是表达能力更强的（expressive），而不是令人印象深刻的（impressive）。 我记得当时自己对此感到很疑惑，表达能力更强的和令人印象深刻的，他们在本质上有什么区别呢？ 实际上，表达能力更强意味着清晰、明确、具体。因此，一段表达能力较好的代码需要能解决一个特定的问题。在为了写这样一段代码所付出的时间与努力的背后，是非常清晰、明确、具体的目标，而这段代码也必须能够真正地实现这个目标。 而令人印象深刻的，则表示要在写代码的过程中留下明显的个人标志或印记。一段自身结构复杂，夹杂着多种深奥算法的代码，也许可以为你吸引来他人的关注、赞叹与掌声，在充分满足你的虚荣心的同时，也有可能转化为那个在未来接替你继续维护代码的工程师的满腔怒火。如果他正好是一个脾气暴躁且知道你住在什么地方的人，那么接下来会发生的事情恐怕就不会那么让你感到高兴了。 这就是程序员应该选择明智而不是聪明的原因。一个精明的开发工程师需要具备那种能够预见自己的哪些行为在什么情况下会带来什么后果的能力，并能对「自己写的是什么样的代码」、「自己为什么要这么写」，以及「这些代码在未来可能会有怎样的演变」这三个问题有着清楚的认知。简单来说，精明的工程师不会去做“亡羊补牢”式地救火开发工作，他们在写代码时坚信应当一劳永逸地解决问题。 而

记得有这么一句广告词：“软件以用为主”。这句广告词的背后传达了时下人们对于软件的一种普遍的认识和价值取向：软件是而且仅是一种工具。不仅软件的普通用户或者高级用户，就算是软件供应商也对软件持这样一种价值观。功用或者功能似乎成了软件的全部。且看我们在做软件需求的时候，重中之重就是对功能需求的完整把握。衡量一个系统或者软件的成功与否的唯一标准就是是否全部实现了用户的需求，实现需求所要的功能成了软件的最高目标。这一标准作为唯一的线索，不仅在贯穿在开发的过程中，甚至贯穿了软件的整个生命周期中。功用性的要求成了悬在开发人员和软件公司头顶的一把斯巴达克之剑，而其他的因素似乎成了一种可有可无的或者并不是特别重要的因素，程序员们每天就背负着这样的十字架生活着。国外的软件在这方面情况可能还不是很严重，然而国产的软件和国产的程序员们似乎无一例外能够逃脱这个宿命的诅咒。 难道软件的价值就仅仅是这些吗？软件是否应该有自己的灵魂呢？软件的灵魂应该是什么呢？当一个软件没有或者失去灵魂又会是什么呢？如果软件应该有自己的灵魂，那么应该创造一种什么样的灵魂呢？如果软件应该有自己的灵魂，那么应该如何来体现呢？ 我想所有热爱软件的人都会承认其实软件系统是有着鲜活的生命的。也许你还记得大学一本教程里这样的一句话：“如果电脑是躯体，那么软件就是躯体里流动的血液。”正是因为有了软件，计算机的世界里才会如此绚烂多姿

当软件失去灵魂 记得有这么一句广告词：“软件以用为主”。这句广告词的背后传达了时下人们对于软件的一种普遍的认识和价值取向：软件是而且仅是一种工具。不仅软件的普通用户或者高级用户，就算是软件供应商也对软件持这样一种价值观。功用或者功能似乎成了软件的全部。且看我们在做软件需求的时候，重中之重就是对功能需求的完整把握。衡量一个系统或者软件的成功与否的唯一标准就是是否全部实现了用户的需求，实现需求所要的功能成了软件的最高目标。这一标准作为唯一的线索，不仅在贯穿在开发的过程中，甚至贯穿了软件的整个生命周期中。功用性的要求成了悬在开发人员和软件公司头顶的一把斯巴达克之剑，而其他的因素似乎成了一种可有可无的或者并不是特别重要的因素，程序员们每天就背负着这样的十字架生活着。国外的软件在这方面情况可能还不是很严重，然而国产的软件和国产的程序员们似乎无一例外能够逃脱这个宿命的诅咒。 难道软件的价值就仅仅是这些吗？软件是否应该有自己的灵魂呢？软件的灵魂应该是什么呢？当一个软件没有或者失去灵魂又会是什么呢？如果软件应该有自己的灵魂，那么应该创造一种什么样的灵魂呢？如果软件应该有自己的灵魂，那么应该如何来体现呢？ 我想所有热爱软件的人都会承认其实软件系统是有着鲜活的生命的。也许你还记得大学一本教程里这样的一句话：“如果电脑是躯体，那么软件就是躯体里流动的血液。”正是因为有了软件

关于烂代码的那些事（上） - Axb的自我修养 http://blog.2baxb.me/archives/1343 关于烂代码的那些事（上） 六月 21, 2015 57 条评论 目录 [ 显示] 1.摘要 最近写了不少代码，review了不少代码，也做了不少重构，总之是对着烂代码工作了几周。为了抒发一下这几周里好几次到达崩溃边缘的情绪，我决定写一篇文章谈一谈烂代码的那些事。 这里是上篇，谈一谈烂代码产生的原因和现象。 2.写烂代码很容易 刚入程序员这行的时候经常听到一个观点：你要把精力放在ABCD（需求文档/功能设计/架构设计/理解原理）上，写代码只是把想法翻译成编程语言而已，是一个没什么技术含量的事情。 当时的我在听到这种观点时会有一种近似于高冷的不屑：你们就是一群傻X，根本不懂代码质量的重要性，这么下去迟早有一天会踩坑，呸。 可是几个月之后，他们似乎也没怎么踩坑。而随着编程技术一直在不断发展，带来了更多的我以前认为是傻X的人加入到程序员这个行业中来。 语言越来越高级、封装越来越完善，各种技术都在帮助程序员提高生产代码的效率，依靠层层封装，程序员真的不需要了解一丁点技术细节，只要把需求里的内容逐行翻译出来就可以了。 很多程序员不知道要怎么组织代码、怎么提升运行效率、底层是基于什么原理，他们写出来的是在我心目中烂成一坨翔一样的代码。 但是那一坨翔一样代码竟然他妈的能正常工作。

程序员生存定律这系列的目录在这里： 程序员生存定律--目录 喜欢从头瞄的，可以移步。 ------------------------------------------------------------------------------ 1． “博”与“专”上的迷失 假设说一个人的学习已经聚焦，并且学习的内容和自己实际参与的项目也相吻合，那么是不是就没有问题了？很不幸，答案仍然是否定的，在任何一个子领域里，仍然需要进一步去考虑“博”与“专”的均衡。 对于软件开发而言，设计是再常见不过，再简单不过的一个词了。可如果把视角拔高一点就会发现，单以设计而论仍然是一个不可穷尽的领域，我们可以快速扫描一下和设计相关的部分概念： 面向对象分析与设计 结构化分析与设计 模型驱动开发 契约式编程 面向方面的开发 基于组件的开发 元编程 有些时候方法论也会和设计牵扯到一起： 测试驱动开发 敏捷软件开发 如果感觉这个还不够多，那可以去 Wiki 上查编程的范式 ( paradigms ) 这个条目，那里列了 47 种范式，每个都和设计多少有点关系。 上述这些还只是说了设计，如果横向展开，那么在特定领域中必然还会牵涉到框架的选用、辅助工具的使用等等。这也就意味着，从博的角度来看，即使是在设计这样一个看似狭小的领域中仍然是没边界的。 与此同时，把一个 API 研究的再透，也是低值人群