如何成为一个专家级的开发者 - gvnhomecobol方面实习报告

　　？这样的问题我们不止一次的提到过，当然，适合大家的专家之并非只有一条。它取决于你为其开发软件的行业是什么，和你的公司使用的工具是什么等等。

　　这篇文章会提供一条一般性的，可以适合你自己情况的专家之，其中包括文章作者的一些观点——关于如何成为一个专家级的开发者。

　　51CTO推荐阅读：充满荆棘的专家程序员之道

　　当你浏览这篇文章的时候请记住：成为一个真正的专家和被当成是一个专家之间是有区别的。许多人都被晋升为专家，但是他们真的不是。但是，如果有人相信他们是，他们就会一直赚很多钱，虽然他们很平庸。另外，有许多专家，没有人知道他们是专家。如果你真的是一个专家，你的下一步行动就是要被大家当成是一个专家。如何做到这一点已经超过了这篇文章的讨论范围。这是一个的不同主题——关于个人品牌等。

　　在开始讨论如何成为一个专家之前，我们先来花30秒的时间来说明专家是什么，和要花多长时间才能成为一个专家。

　　在你使用一项技能3个月以后，你不是一个专家，使用3年以后也不是一个专家。根据MalcomGladwell的图书《局外人》所说，要成为一个真正的专家需要平均花费10000个小时。如果你喜欢自命不凡。10000个小时！如果一天花费10个小时，然后每天都努力，需要3年。或者，更加自命不凡一些，一天花费5个小时，一年只有200天在努力，需要10年。整整10年！

　　根据这个断言，我发现在我有3年经验的时候我曾认为我自己是一个专家或一个资深开发者。现在，在2010年的时候我已经有10年的经验了，我已习了很多需要了解的知识，但是我一直不知道还有多少知识需要学习，现在我不再感觉自己是一个专家了。

　　另外，在最近这10年里，行业（Java企业级开发）已经发生了很大的改变，所以我过去掌握的技能，都不那么“酷”了。即使你是一个专家，你也会发现你自己变得过时了，开发者乐土!回顾Visual Studio经典15年.netframewor。必须要重新开始学习。

　　还有一件事：你不可能是各个领域的专家，这意味着在某种技能上你也许比某人更优秀，但是在另外一种技能上比某人可能就比你更优秀了。你在每一种技能上都比别人优秀或比别人更差，这是不可能的。你总是能从其他人身上学到一些东西的。我过去曾经遇到过几个开发者，他们总是表现的好像他们在所有方面都很优秀似的，即使在事实并非如此的情况下，他们也还是这样做。

　　实际上，这通常是鉴别新手的一种方法：相信他们自己知道所有的事情，在线或离线的情况下一直不停的争论。他们的争论带有绝对倾向，比如“这个总是比那个更好”，或“这是做这件事的唯一方法”等等。专家从来不这样。他们知道，一切都取决于具体情况，你的开发者掌握的技能，你的公司选择的工具，公司策略，个人喜好等等。缺乏经验的开发者（和一般人）都倾向于相信世界黑即白的。而专家知道，世界充满了灰色地带，甚至还有许多额外的颜色和色调。

　　一旦你已会了这项技能的理论知识，你需要实践这项技能，通过实践你的技能，你可以认识到你学到理论知识哪些是正确的，哪些是错误的。是的，往往大学教给你的理论在现实中并不起作用，或者并不能在你现在的情况下使用。

　　一旦你已经使用这项技能很长时间了，并且你发现你能够解决很多需要这项技能的问题，那么该是和其他有经验的人讨论这项技能的时候了。可以讨论一下应用这项技能的最佳方式是什么，理论的在哪里，可以补充些什么等等。简而言之，就是讨论如何进一步推动这项技能（比如一个API，如何使它更好/与众不同等）。

　　把你的技能教给其他人，真的是一个弥补你的技术上的不足的好方法。可能许多事情只是做做而已，但是并没有思考为什么要这样做。如果必须要解释你的方式和方法，可以你思考这样做的原因。

　　另外，可能有一些你技术上的空白点，你从来都不需要掌握它们（比如说，Web服务的规范）。如果必须要传授你的技能，将可以你掌握这些空白点，让你有更大的进步。

　　现在，我已经谈了如何成为一个普遍意义上的专家，下面我来谈一谈如何成为一个专家级的开发者。作为一个开发者，你很可能正在使用一个特定的平台，为一个特定的行业开发软件。如果不是这样，如果你经常要选择工具和行业，就像一些Web开发者那样，那么你很可能从来都没有成为一个真正的专家。你只会成为一个杂而不精的人。你需要集中你的精力。（相关文章推荐：程序员的十大技术烦恼

　　）

　　我从1998年开始了我作为Web应用程序开发者的职业生涯，然后我发现我自己经常要更换工具，这意味着我无法真正的熟练使用其中任何一个工具。我只是一直在努力学习新的工具的使用方法。然后我决定把注意力集中一门面向对象的语言和一个平台上，于是我选择了Java。那时.NET还没有出现。自从1999年，我一直只使用Java。

　　在你的专家之上，你必须选择一个平台，可能还要选择一个行业。行业并不是特别重要，但是业务领域的知识可以增强你的简历。

　　当你学习一个平台的时候，你可以从一门语言来入手。例如：Java语言。在你学习了那门语言以后，你需要学习这个平台（包括所有的API和工具）。在Java中，平台被划分成了两个：标准版和企业版。

　　一旦你开始掌握你的平台，你应该开始学习一些于平台的技能，像设计模式，分布式系统设计，架构，可用性等等。当你取得进步的时候，你会花更多的时间来学习这些技能。这是一件好事情。这些技能可以更容易的迁移到一个新的技术平台上。

　　最后，你可能会完全脱离软件开发工作，进入到像项目管理，架构师那样的完全不同的业务领域。请记住，一旦你停止使用你的开发技能，那么你也就在专家之上驻足不前了。

　　这是一张图表，表示你的“专家级开发者之”。你从底下开始，一直向一层前进。蓝色的层是于平台的层。其他颜色的层是特定于平台的层。即使你的平台不在这里面，你也可以自己把它添加上。

　　

　　你不得不针对你的行业，你的公司和你的平台添加具体的工具。我无法一次性的为每一个人做这件事情。

　　找出你应该学习什么的一个好方法是看招聘广告。看看他们通常需要什么工具和技术？读一下在线的软件。看看他们谈论的最多的是什么技术？浏览一下论坛，看看人们问的最多的问题是什么？还有，人们讨论的最多的是什么技术？换句话说，什么会成为将来的热点？

　　51CTO编者按：每个程序员都希望自己在技术方面更进一步，成为程序达人，开发高手，技术大师……；这不仅能获得更好的职位和更高的报酬，更重要的是，开发高手还代表着一个开发者对自己的肯定以及对技术梦想的忠诚与追求。但如何成为一个开发高手呢？也许我们能从下面这篇博文中获得一些。作者RickWagner是一位Java企业级架构师，具有二十多年的开发经验的资深程序员和COBOLE语言的爱好者。他在文章中指出初级程序员与程序员的根本区别在于所掌握技术的“广度”和“深度”，Rick认为这是程序入门者向程序高手进阶的关键

　　cobol方面实习报告【51CTO】20年前，当我刚开始从事数据处理方面的开发工作时，我在一家为银行承担外包工作的公司工作。开始我只是一个实习生，毕业后进阶为程序员的第一级——“初级程序员”。其实，在我们公司内部，对这些Title都做了一些神秘的标识，比如我的初级程序员的标识是“E07”。

　　不久，我发现了我们公司是如何对程序员的级别进行标识的：

　　◆初级程序员=E07

　　◆程序员=E08

　　◆高级程序员=E09

　　◆超级英雄=E10（一种非常罕见的品种）

　　这些级别不单代表技术能力，还有薪水，当然，薪水是与这些级别排名紧密相关的，这是不会变的，不管是20年前还是现在。

　　像所有初级程序员一样，我希望自己用一到两年的时间在E07级别工作，然后逐渐。但有件事一直令我困惑：

　　”。

　　我当时目瞪口呆。在那一刻，我意识到，在这个项目中我所做的工作与James所做的一样重要。我当时在做数据分析和编码，James也在做数据分析和编码。虽然他以最高级别的E10在工作，但他所用的编译器我也在用；他所用的数据我也在用；他所用的开发也跟我一样。如果他所做的部分遇到困境，我所做的部分也将遇到阻碍。在这个项目中，我们同行。

　　别误会我的意思，虽然所做的工作一样，但初级程序员肯定不如那些程序大牛值钱。今天，我不得不承认这个被广泛接受的事实。但那时，我的这个想法给我带来不可估量的好处，直到今天。

　　我试图寻找我与E10的朋友们到底有哪些区别。我和他之间到底有哪些不同？我得到的结论是，至少在两个方面他比我更优秀：

　　。当时，我只具备一些COBOL编程经验；而E10的朋友不单会COBOL，还精通于汇编、JCL（一种工作控制语言）、操作系统等等多项技能。在今天，这等于一个只会Java的程序员站在另一个Java程序员身边，他身边的这位同时还知道C++、C#、Ruby、Python、Erlang以及每一种语言的流行框架。如果一个项目只是需要使用Java，那这两个Java程序员是平等的。但如果下一个项目需要更多的技术，这种平等的情况就会发生改变。

　　另一个方面是

　　。在过去，我所编写的COBOL代码也许跟我的E10朋友一样好。但如果我的程序有一个Bug，我的办法只是看着诊断报告不断进行调试。我的朋友不单会做这些，他还会阅读一些核心转储的数据，将一些重要数据转变成汇编程序（他可以从中获得一些）等等。在另一个我们一起进行界面编程的项目中，他可以更好的理解我们所操作的平台并知道如何完美的利用这个平台所提供的功能。同样，我的源码可能跟他的没什么太大区别，但如果我们需要向下一个级别进阶……是的，我们之间有一个明显的分界线。

　　在今天的世界里，这可能意味着程序牛人可以知道如何调整JVM，选取有用的数据分析工具；程序牛人知道如何安装、配置、调试和配置平台。牛人知道如何建立编译，而初级程序员也许只知道按照已经确定的方案（平台）进行开发。

　　技术的广度和深度，我想，我找到了成为高手的密匙。我需要学习更多并努力提到自己的广度和深度（直到今天，我还在努力！）。20多年前与James的一席谈使我知道自己哪里需要提高，这对我

　　在过去的几个星期里，我作为父亲一直在教自己年轻的孩子开车。对于新手司机来说，学习控制汽车的整个过程（把握方向盘、使用各种踏板、换挡、看后视镜，等等）是比较伤脑筋的。但是所有这些都是相对简单的事情，大部分年轻驾驶员都能掌握，不会有太大的问题。

　　新手司机在经过一段时间的锻炼之后，当他们跟其他的司机一样外出上时，真正难受的经历才开始。这时才是真正学习开车的时刻，因为仅仅能控制汽车并不能够成为好司机，虽然这是重要的前提条件。相反，能够预料和避免一些意外的情况才能成为一个好司机。不幸的是，你不可能教给他这些技巧。

　　你可以告诉他们一些潜在的问题。你可以描述这些问题，并告诉他们在那些情况下应该怎样做。你甚至可以进行一些实地演习。但是，每个新手必须亲自经历过很多普通的驾驶之后（而且要幸存下来）才能预料类似的情况，然后采取措施避免这些问题。

　　遗憾的是，

　　。咱们来看一下开发一个应用程序，功能是在一个文件中存储一些数据，每次用户启动这个应用程序的时候都调用这些数据。

　　◆新手程序员（已过在文件中读取和写入数据的语法）面对这个问题只会简单的写几行能够读取和存储数据的代码。

　　◆如果他们已经有过一段时间的编程经历，他们可能会写一个测试程序来确保代码读取和写入的数据是正确的。因为所写的代码工作了，初学者就认为可以了，他们会认为已经自己完成了任务，也符合规格，并且还对他们的工作进行了测试。

　　◆一个专家级的程序员，当面临同样的情况的时候，他知道这不是一件简单的事情。当然，写几句在文件中读取或者存储数据的代码非常简单——这只是当一切都顺利的时候。但是如果要让应用程序能够处理所有可能出错的情况，这就不是那么简单了，就算是这种简单的操作也一样。因为，delphi盒子(5)。文件可能不存在，硬盘可能满了，文件可能损坏了，用户可能没有权限去读取文件，这个文件可能正在被使用。如果文件不在本地磁盘，程序可能都接触不到这个文件。

　　当然，不是所有这些问题都会同时发生在某个特定的时刻，但是那些已经把应用程序交付给很多用户的开发人员都知道，

　　一个专家可以告诉初学者去检查这些可能出现的情况，那么对于这些特定的问题，不是专家的开发人员只能对其进行编码，而只有专家才能预料并避免他们。就像开车一样，一个好的程序员不仅要能够解决已经发生的问题，而且还应该能够预料一些没有发生过的问题。不幸的是，专家是靠犯错误才学到这些本领的，这对于人类来说是件伤心的事情。每一代想要成为专家的人只有在经历过上一代人所犯的所有错误之后才能成为专家。NeilsBohr解释说，“专家就是在一个非常窄的领域内犯过所有可能的错误的人。”

　　但是当你跟一个新手驾驶员坐在同一辆汽车上的时候，你可能就会更加欣赏P.J.Plauger的这个版本了，“我对任何领域中专家的定义是一个对什么是真正的事情知如何成为一个专家级的开发者 - gvnhomecobol方面实习报告道得足够多的人。”

　　原文：

　　入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。

　　经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。

　　现在，请看一下我们采用另外一种方式对同一段代码进行的注释:

　　这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。

　　注释是用来帮助读者理解代码的，不是用来解释语法的。我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“//对客户列表进行for循环操作”。读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。

　　很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况下，我们更类似于需要慢慢启动的火车，而不是能突然加速的法拉利;我们需要一定的时间才能进入工作状态，一旦我们进入稳定有效的工作状态，我们的工作效果和产出会很丰硕。不幸的是，当思不断的被客户、经理、以及你的同事打断时，你的大脑很难进入编程的状态。

　　当我们干一件事情时，有太多的琐事需要我们放在心里，我们需要先放下这个事情，处理那个人事情，回头又干这个事情，还不能有差错。这些干扰会中断我们的思，而重新整理清楚思又要你花费大量的时间，这是让人懊恼的、没有比这更让人泄气、让人有挫折感的过程了。

　　范围蠕变（Scopecreep）(也称作焦点蠕变（focuscreep），需求蠕变（requirementcreep），功能蠕变（featurecreep），以及其它一些乱七八糟的演变词语)，指在项目管理里项目的需求变更失控。当一个项目的范围没有明确的定义清楚、没有文档化、不受控时就会出现这种现象。这通常被认为是一种有负面影响的事情，应该尽力避免。

　　范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨无霸。那些负责需求调研的家伙们只需要敲几下的键盘就能把事情变成这样：

　　◆版本1:显示这个地区的地图

　　◆版本2:显示这个地区的地图，要三维立体的

　　◆版本3:显示这个地区的地图，要三维立体的，而且能够使用它作为飞行图

　　一个本来30分钟能完成的任务变成了一项要几百人/天才能完成的超级复杂的系统。更糟糕的是，大多数情况下，需求变更是发生在开发阶段的，这样一来你需要重写代码，重新回归，有时要把前几天才开发的代码删除。

　　管理工作不是一种简单的工作。人是一种让人很讨厌的动物;我们善变、喜怒无常，我们都自以为天下第一。想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。程序员们对此的抱怨相当普遍，这也是产生争执不合的根源。

　　在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的经验，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服等)都能理解的文档手册。

　　我们可以很容易的看出，有些事情程序员们极不愿意去做。你可以简单的回顾一下所有的开源项目。人们的对这些项目的一个索求是什么：文档。

　　我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会说：“不能让其他人去写吗？“。

　　我可从来没说过我们程序员是说一套做一套的人。程序员们经常会在他们的项目里用到第三方的类库和应用。于是，我们需要文档。很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。

　　当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。函数poorlyNamedFunctionA()和函数poorlyButSimilarlyNamedFunctionB()有什么区别？在我使用PropertyX属性前是否需要测试一下它是不是null值？我估计只有通过自己的测试和报错才能弄清楚!。

　　任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时，都会痛苦不已。人们有一种普遍的，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符合需求文档，这样我们才能集中精力去解决这上层的任务。

　　“网站宕机了”.“功能工作不正常”。处理含糊不清的任务是种痛苦。每次当非程序员被要求重现他们所遇到的问题时表现出的都让我吃惊不已。他们似乎不太明白，仅仅一句”它宕机了，修复它！”是无法让我们开始工作的，我们需要更多的信息。

　　软件的运行是(大部分情况下)有迹可寻的。我们也乐见与此。请迁就我们，帮我们指出是在哪个阶段，什么情况下出的问题，而不是简单的说一句”修复它“。

　　程序员经常和其他程序员合不来。诧异吗，但这是真的。这方面的事情我可以轻松的列出十大条，讲细点甚至可以单独写篇博客，所以这里我只列出几个常见的、让其他同事感到懊恼的程序员的特征：

　　◆脾气暴躁以至态度极不友好。

　　◆不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。

　　◆无法进行有效的沟通，使用易于的专业术语。

　　◆自己的事情处理不好。

　　◆对要做的程序和项目缺乏兴趣。

　　那么，这最后的，但不是最糟糕的，序号为1的让程序员们烦恼的…

　　Don’tsneeze，IthinkIseeabug.

　　回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！烧掉!丢到火里！

　　现实是，软件技术界是一个不断变化的世界。今天被看成是最好的方式，明天也许就会过时。我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。真是让人沮丧，因为不论我们如何努力的学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技术发展趋势慢了一拍。对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯（sand-painting）的。

　　本文转载自外刊IT评论，原文标题《程序员的十大烦恼

　　技术的“广度”和“深度”是初级程序与高级程序员的最大区别，也是进阶开发高手的密匙。51CTO认为，“广度”和“深度”是对程序员成长的一个方向性，不断扩充技术外延，努力扎实技术功底是初级程序员成长为高级程序的一个重要途径。