程序员需要具备的基本技能+十条不错的编程观点+十个让你变成糟糕的程序员的行为

1.程序员需要具备的基本技能

软件开发是一个跨度很大的技术工作，在语言方面，有C，C++，Java，Ruby等等等等，在环境方面，又分嵌入式，桌面系统，企业级，WEB，基础系统，或是科学研究。但是，不管是什么的情况，总是有一些通用的基本职业技能。

这些最基本的职业技能通常决定了一个程序员的级别，能否用好这些技能，直接关系到了程序员的职业生涯。很多程序新手也是因为缺少、达不到或是不熟悉在这些基本技能，所以，他们需要有老手带，需要努力补齐这些技能。而高级程序员应该非常熟悉这些基本技能，而且有能力胜任并带领其他经验不足的程序员。

下面这些基本职业技术可以用来做为对一个程序员的评估，很明显，下面的这些技能都可以用来做面试。虽然，还有很多非技术的因素，但对于评估一个程序员的技术能力来说，其应该是足够的了。

下面是程序员所应该具备的基本职业技能：

基本技能	技能描述
阅读代码	这个技能需要程序员能够具备读懂已经存在的代码的能力，这样的能力可以让程序员分析程序的行为，了解程序，这样才能和开发团队一起工作，继承维护或是改进现有的程序。（当发现读不懂别人代码的时候，就说明自己基础和代码量不够了）
编写程序	编写程序并不包括程序设计。不要以为编程是一件很简单的事情，很多程序员都认为编程只需要懂得程序语言的语法，并把设计实现就可以了。但是这离编写程序还远远不够，使用什么样的编码风格成为编写程序员最需要具备的基本技能。能否使用非常良好的编程风格直接决写了程序员的级别。
软件设计	这一能力直接决定了需要吏用什么样的代码技术达到怎么样的功能，而系统架构设计直接决定了软件的质量、性能和可维护性。并不是所有的程序在这一方面都非常优秀，但每个程序员都需要或多或少的明白和掌握这一基本技能。
熟悉软件工程	每个程序员都应该明白软件工程是什么东西，都应该知道，需求分析，设计，编码，测试，Release和维护这几个阶段。当然，几乎所有的人都知道这些东西，但并不是每个人都很清楚这些东西。现在很多高级程序员都会混淆“需求规格说明书FS”和“概要设计HLD”。另外，程序员还需要知道一些软件开发的方法论，比如：敏捷开发或瀑布模型。
使用程序库或框架	一个程序员需要学会使用已有的代码，无论是标论的程序库，或是第三方的，还是自己公司内部的，都需要学会做。比如：C++中，需要学会使用STL，MFC，ATL，BOOST，ACE，CPPUNIT等等。使用这些东西，可以让你的工作事半功倍。
程序调试	程序调试是分析BUG和解决问题最直接的能力。没有人能够保证程序写出来不用调试就可以运行正常，也没有人可以保证程序永远不会出BUG。所以，熟练使用调试器是一个程序员需要具备的基本技能。
使用IDE	学会使用IDE工具也会让你的工作事半功倍。比如，VC++，Emacs，Eclipse等等，并要知道这些IDE的长处和短处。
使用版本控制	一定要学会使用版本控制工具，什么叫mainline/trunk，什么叫tag，什么叫branch，怎么做patch，怎么merge代码，怎么reverse，怎么利用版本控制工具维护不同版本的软件。这是程序员需要明的的软件配置管理中最重要的一块。
单元测试	单元测试是每个程序都需要做的。很多单元测试也是需要编码的。一定要学会在xUnit框架下进行单元测试。比如JUnit, NUnit, CppUnit等等。
重构代码	每个程序员都需要有最基本的能力去重构目前已有的代码，使代码达到最优但却不能影响任何的已有的功能。有一本书叫《软件的重构》，每个程序员都应该读一下。
自动化编译	程序员需要使用一个脚本，其能自动化编程所有的工程和代码，这样，整个开发团队可以不停地集成代码，自动化测试，自动化部署，以及使用一些工具进行静态代码分析或是自动化测试。

当然，还有很多的基本技术也是非常重要的，比如，与人的沟通能力，语言的表达能力，写作能力，团队协作能力，适应变化的能力，时间管理能力，多任务处理能力，自我学习能力，故障处理能力，等等，等等，这里只是列举了和技术相关的能力，这些是程序最最最基本的能力，只要是程序员就必需要有的能力。

转自：http://coolshell.cn/articles/428.html

2.十条不错的编程观点

在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》，翻译成中文就是“你认为最有争议的编程观点是什么？”，不过，在400多个主回贴，以及千把个子回贴中，好像并不是很有争议，而是令人相当的茅塞顿开，下面罗列一些，并通过我自己的经历和理解发挥了一些，希望对你有帮助。

1） The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式，框架，那些著名的方法、模式、框架只代码赞同他们的人多，并不代表他们适合你，你应该更多的去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“best practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2）Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的娱乐方式去生活，无论是编程，还是运动，还是去旅游，那么你只不过是在应付你的工作，无时无刻不扎在程序堆中，这样下来，就算是你是一个非常聪明，非常有才华的人，你也不会成为一个优秀的编程员，要么只会平平凡凡，要么只会整天扎在技术中成为书呆子。当然，这个观点是有争议，热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3）Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。

4）XML is highly overrated

XML可能被高估了。XML对于Web上的应用是不错的，但是我们把其用到了各种地方，好像没有XML，我们都不会编程了。

5）Not all programmers are created equal

这是那些junior经理或是流程爱犯的错，他们总是认为，DeveloperA == DeveloperB，只要他们的title一样，他们以为他们的能力、工作速度、解决问题的方法，掌握的技能等等都是一样的。呵呵。更扯的是，在某些时候，就算是最差的程序员，他们也会认为其比别人强十倍，这就是现代的SB管理。

6）”Googling it” is okay!

Google只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度的使用Google，只会让你越来越离不开他，你越来越去要去立马告诉你答案，而你越来越不会自己去思考，自己去探索，去专研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们的智力发展大大的没有好处。

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言，了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.

你的工作不是保守，那种教会徒弟，饿死师父的想法，不但是相当短浅的，而且还是相当脑残的。因为，在计算机世界里，你掌握的老技术越多，你就越没用，因为技术更新的太快。你对工作越保守，这个工作就越来越离不开你，你就越不越不能抽身去学新的东西，你也就越来越OUT了。记住：If you can’t be replaced then you can’t be promoted!

9）Design patterns are hurting good design more than they’re helping it.

很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱动编程”，正如第一点所说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

10）Unit Testing won’t help you write good code

准确地说，我们可以认为这是Test-Driven开发，其实，这种开发就是先写unit test case，这样的开发方式的主要目的是，为了防止你不会因为一个改动而引入Bug，但这并不会让你能写出更好的代码。这只会让你写出不会出错的代码。同第一点，这样的方法，只不过是防止糟糕的程序员，而并不是让程序员或代码质量更有长进。反而，通过Unit Test会为程序员的为自己代码做辩解的一种托辞。

最后，顺便说一下，以前去那个敏捷的公司面试，发现那个公司的某些技术人员中毒不浅，具体表现在上述的1）9）10）观点上。

 

之前本站发表过《优秀程序员的十个习惯》以及《程序员需要具备的基本技能》，那是我们需要去学习和培养的。这里，我们主要讨论十个糟糕程序员的特征，主要是需要让我们去避免和小心的。

转自：http://coolshell.cn/articles/2424.html

3.十个让你变成糟糕的程序员的行为

1) 情绪化的思维

如果你开始使用不同颜色的眼光来看待这个世界的话，那么你可能会成为一个很糟糕的程序员。情绪化的思维或态度很有可能会把自己变成一个怪物。相信你经常可以看到很多很糟糕的程序会使用下面的这些语句：

• 我的程序不可能有这种问题。
• Java就是shit。
• 我最恨的就是使用UML做设计。
• 需求怎么老在变，没办干了。
• 受不了这些人，他们到底懂不懂啊。
• …… ……

这些带着情绪化的思维和态度，不但可以让你成为一个很糟糕的程序员，甚至可以影响你的前途。因为，情绪化通常都是魔鬼，会让你做出错误的判断和决定，错误码率的判断和决定直接决定了你的人生。

2) 怀疑别人

糟糕的程序总是说：“我的代码一定是正确的，我怀疑编译器有问题”，“我这应该没有问题吧，STL库怎么这么难用啊”。我曾经见过有程序员这样使用STL类：map<char*, char*>，当他发现这样放入字符串后却取不出来，觉得那是STL库的BUG，然后自己写了一个map！我的天啊！

某些时候，过早的下结论是一个很不好的习惯，任何事情都有其原因，只有知道了原因，你才能知道是谁的问题。一般来说，总是自己出的问题。

3) 过多关注实现，陷入问题细节

有些时候，当我们面对一个问题或是一个需求的时候，糟糕的程序员总是会马上去找一个解决方案或是实现，这是一个很不好的习惯。设计模式告诉我们，“喜欢接口，而不是实现”就是告诉我们，认清问题的本质和特性要比如何实现更重要。

• 对于一个客户的问题来说，首先应该想到的是如何先让用户正常工作，如何恢复正在“流血”的系统，而不是把用户放在一边而去分析问题的原因和解决方案。
• 对于解决一个bug来说，重现bug，了解原来程序的意图是首先重要的事，而不是马上去修改代码，否则必然会引入更多的BUG。
• 对于一个需求来说，我们需要了解的需求后面的商业背景，use case和真实意图，而不是去讨论如何实现。只有了解了用户的真实意图，实际使用的方式和案例，你才能真正如果去做设计。

糟糕的程序总是容易陷入细节，争论于如何实现和实现难题，以及问题的根本原因，而忽略了比这些更重要的东西。只有看懂了整个地图，我们才知道要怎么去走。

4) 使用并不熟悉的代码

糟糕的程序员最好的朋友是 Ctrl-C 和 Ctrl-V（以后一定要改，刚入门的都喜欢这样干，自己当时也是） ，有些时候，他们并不知道代码的确切含义，就开始使用它，有证据表明，由拷贝粘贴引发的bug占了绝大多数。因为，代码总是只能在特定的环境下才能正常地工作，如果代码的上下文改变了，很有可能使得代码产生很多你不知道的行为，当你连代码都控制不住了，你还能编出什么好的程序呢？

5) 拼命工作而不是聪明的工作

对于糟糕的程序员，我们总是能看到他们拼命地修正他们的bug，总是花非常多时间并重复地完成某一工作。而好的程序可能会花双倍的时间来准备一个有效的开发环境，工具，以及在开发的时候花双倍甚至10倍的时间来避免一些错误。好的程序员总是会利用一切工具或手段来让自己的工作变得更有效率，总是为在开发的时候尽可能得不出错。后期出错的成本将会是巨大的，而且那时改正错误的压力也是巨大的。所以，糟糕的程序通常会让自己进入一种恶性循环，他们看上去总是疲惫的，总是很辛苦的，所以更没有时间来改善，越没有时间来改善，就有越多的问题。所以，拼命工作有些时候可能表明你不是一个好的程序员。

6) 总是在等待、找借口以及抱怨

当需求不明确的时候，当环境不是很满意的时候，他们总是在等待别人的改善。出现问题的时候，总是在找借口，或是抱怨这也不好，那也不好，所以自己当然就没有做好。糟糕的程序员总是希望自己的所处的环境是最好的，有明确的需求，有非常不错的开发环境，有足够的时间，有不错的QA，还有很强的team leader，以及体贴自己的经理，有足够的培训，有良好的讨论，有别人强有力的支持……，这是一种“饭来张口，衣来伸手”的态度，这个世界本来就不完美，一个团队需要所有人去奋斗，况且，如果什么都变得完美了，那么，你的价值何在吗？driving instead of waiting, leading instead of following.

7) 滋生办公室政治

有句话叫“丑女多作怪”，意思是说如果一个自己没有真实的能力的话，那么他一定会在其它方面作文章。糟糕的程序员也是这样，如果他们程序编不好的话，比不过别人的话，他们通常会去靠指责别人，推脱责任，或是排挤有能力的人，等等不正常的手段来保全自己。所以，糟糕的程序通常伴随着办公室政治。

8 ) 说得多做得少

糟糕的程序员总是觉得自己什么都懂，他们并不会觉得自己的认识和知识都是有限的。这就是所谓的夸夸其谈，是的，什么都做不好的程序员能靠什么混日子呢？就是吹啊吹啊。

另一个表现方式是他们在评论起别人的程序或是设计，总是能挑出一堆毛病，但自己的程序写得也很烂。总是批评抱怨，而没有任何有建设性的意见，或是提出可行的解决方案。

这些糟糕的程序员，总是喜欢以批评别人的程序而达到显示自己的优秀。

9) 顽固

当你给出一打证据说明那里有一个更好的方案，那里有一个更好的方向的时候，他们总是会倔强的认为他们自己的做法才是最好的。一个我亲身经历的事例就是，当我看到一个新来的程序员在解决一个问题的时候走到了错误的方向上时，我提醒他，你可能走错了，应该是另外那边，并且我证明了给他看还有一个更为简单的方法，有。然而，这位程序员却告诉我，“那是我的方法，我一定要把之走下去，不然我会非常难受”，于是，在三天后的代码评审中，在经过顽固地解释以及一片质疑声中，他不得不采用了我最先告诉他的那个方法。

这些程序员，从来不会去想，也不会去找人讨论还有没有更好的方法，而是坚持自己的想法，那怕是条死路都一往直前，不撞南墙永不回头。

10) 写“聪明”的代码

他们写出来的代码需要别的同事查看程序语言参考手册，或是其程序的逻辑或是风格看上去相当时髦，但却非常难读。代码和文档本应该简洁和易读，而他们喜欢在代码中表现自己，并尝试另类的东西，以显示自己的才气。是的，只有能力有问题的程序员才需要借助这样的显示。

记得以前的一个经历，一位英语很不错的程序员加入公司，本来对我们这些英语二把刀来说，我们喜欢看到的是简单和易读的英文文档，然后，那位老兄为了展示他的英语如何牛，使用了很多GRE中比较生僻的短语和词汇。让大家阅读得很艰苦。最有讽刺意味的是，有一位native的美国人后来在其邮件中询问他某个单词的意思。呵呵。

你是一个糟糕的程序员吗？欢迎你分享你的经历。

转自：http://coolshell.cn/articles/1081.html