曾经有一句话，叫做**“细节决定成败”**，充分说明了细节对于成功的作用。如果我们注意一下，就会发现很多因为注重细节而获得成功的案例。 **产品的细节** 苹果的系列产品我们都已经非常熟悉了，各种各样i打头的产品，对于细节已经给予了非常大的关注。尤其体现明显的就是在对用户使用的友好度和便利性方面的细节。iPad、iPhone和iTouch等产品都是大大的屏幕，而在正面就只有一个按钮，用户不必考虑到底需要按什么按钮。而系列产品的做工更是让人赞不绝口，这也是另外一个细节。 另外对于国内的电子书产品，bambook我感觉细节做得也很不错，首先所使用的硬件质量都很好，我已经用了快一年的时间了，每个按钮还和刚拥有的时候一样灵活；电池也一直非常耐用，充一次电基本上可以至少用大半个月，这还是因为我几乎每天上下班的路上都会使用它来看书。曾经在使用的时候遇到一位用汉王产品的人，和我抱怨那款电子书的问题，首先就是按钮，没用两个月就坏掉了；还有电池，刚开始的时候能撑一个多月，但不长时间之后，就只能撑几天了。按钮、电池，看起来都是很细节的东西，但确实直接影响到了用户的体验，从而影响了用户对于产品乃至于企业的印象。 **服务的细节** 以上说的是产品，对于服务也是一样，同样需要关注细节。最近一段时间最火的饭店应该就是“海底捞”了，有无数的故事让人来传说，其实他们的服务充分体现了关注细节这一特点，不仅仅是产品的质量，更包括了服务的质量，他们能够关注于客户的各种反应，从而做出让人最满意的服务，那样才获得了巨大的成功。尽管说“海底捞你学不会”，但我们至少可以学习他们关注细节这一点，呵呵。 **程序员要关注细节** 作为程序员，我们的工作有很多，一方面需要创造出各种系统，编写各种程序，制造各种产出物；另一方面要和客户沟通，为最终的业务用户服务。无论哪个方面，我们都需要关注细节，那样才能够把工作做得更好。 在**创建产品方面**，我想我们可以做的有： - 所有程序外观、使用方式统一，从而让用户更容易地学习和使用 - 程序代码遵守规范，便于维护和修改 - 各种功能使用简单，程序帮助用户做尽可能多的事儿 - 协助用户改进不合理的工作方式，帮助用户提高工作效率 - …… 其实这还比较笼统，**更细节**的问题可能会是： - 界面上的文字是否有错别字？ - 文字的大小、颜色是否符合规范？ - 各种提示信息是否规范，是否真正有助于用户发现并解决问题？ - 代码中的注释是否必要，是否能够正确地为代码提供补充说明？ - …… 如果能够做到关注细节，那么不管是对于用户，还是团队中的其他开发人员来说，我们所体现出来的就是一种专业的精神和专业的态度。 当我们需要与用户沟通，为业务用户提供各种**服务**的时候，同样需要关注细节，我们需要： - 清晰地了解用户的需求，并根据需求设计出好的技术解决方案。 - 对于用户提出的问题，能够快速定位并及时修正。 - 与客户沟通的过程中，及时向客户反馈。 - 不仅要理解用户表面提出来的需求，还需要根据自己的理解，挖掘潜在的需求。 - …… 以上还更多的是针对工作方面，想要和业务用户更好地协作，我们可能还需要关注一些**生活上的细节**： - 用户的姓名以及基本的自然信息，是否在一次介绍之后就能够清晰地记住？ - 用户当前的状态，身体状况如何，是否适合工作？ - 用户的某些习惯怎样，采用什么样的方式更有效？ - 用户对我们的服务是否满意，我们还需要在哪些方面需要提升？ - 在活动的时候不迟到，清晰、快速地阐述自己的观点 - …… 从以上内容看来，想要真正做到关注细节，还真的是不容易，而我们又应该如何做好这些事儿呢？我想可以从改变自身开始： - **细心！**这样才能够发现更多细节 - **积极！**这样才能够更有效地利用细节 - **准备！**这样才能够把握好细节，发现更多机会 以上就是我对于关注细节相关的看法，如果你也是个注重细节的人，并且有很多关注细节的好习惯，欢迎与我讨论，:)

*--本文基于我在2011-9-10Qclub大连站上的演讲整理。--* IT业是服务业的一种，而IT人员作为服务业的一员，目的就是要让客户满意，这里所说的客户可能是公司内部的业务用户，也可能是公司外部的业务人员，但不管怎样，我们的目的应该是一致的。 想要让客户满意，我们要达到的工作效果如何呢？借用之前一位前辈的话，他当时是在阐述什么样的软件产品或者说软件系统能够容易销售，“有两条特性， 一是帮客户省时间，一是帮客户省钱，如果这两条能够达到一条，那么就算是基本合格了，如果都能够实现，那么就不愁卖了。”同样，我们想要自己的服务令业务用户满意，同样应该达到上述的目的——省钱、省时间。如果借助我们的服务，能够帮助业务用户和公司赚更多的钱，那么我们的服务就更上层楼了，那应该可以借助人工智能的优势达成。 然而，上述只是我们的理想，它和现实之间往往会有很大的差距，在很多时候，业务人员并不认为IT能够帮他们省钱、省时间，更不用提生钱了。他们认为IT部门是烧钱的部门，每年的软件系统会花费大量的资金，但是并不能带来多少实质性的改变，甚至于无法很好地支持业务。更不客气的说法，IT根本就是浪费钱。 尽管IT人员，特别是销售工程师，都会苦口婆心地告诉业务部门的人们，IT系统能够帮你节省成本，你看，之前很多东西你都需要打印出来才能签字，我们现在可以帮你实现无纸化办公，这样可以节省不少打印的成本啊；还可以提高工作效率，你想计算机算数多快啊，电脑啊，总比人脑厉害的。 然而业务人员在经历了各种系统之后，并不那么认为，上面的那些话根本就是一大堆谎言，为什么呢？有如下问题： - 诸多需求变更无法满足 - 输入麻烦，无法大块地复制粘贴，浪费更多时间 - 因为程序bug、网络、电力等各方面的原因，故障频发，而且一旦出现问题，造成的损失会很大 - 灵活性不够，很多在实际业务中很容易实现的操作因为系统的限制无法进行。 的确，软件系统因为各种原因，存在着上述问题，所以我们作为程序员，更应该从我做起，提高自己的能力，从而更好地让业务用户满意。接下来让我们从软能力和硬能力两个方面来叙述一下，如何才能够更好地提升满意度。 **软能力** 说到软能力，很多程序员朋友会认为没有技术能力重要，但是，我觉得这方面的能力在某些时候是保证我们能够让客户满意的重要条件，因为缺少了这些能力，我们甚至都无法了解到客户在什么地方不满意，为什么不满意，怎样做才能够让他们满意，又从何谈起提升满意度呢？ **沟通能力** 其实在任何工作过程中，沟通和交流能力都是非常重要的，特别是对于能够接触到最终用户的程序员来说，这一能力尤其重要。 不过在沟通之前，或者说在沟通之中，我们要尽可能地和客户成为朋友，因为只有成为朋友之后，才能进行更好的沟通。 这首先要求我们要摆正自己的位置。很多情况下，作为程序员，应该都至少拥有不错的学历，掌握的也是高新科技的知识，不可避免有些程序员会觉得自己高人一等，而业务用户特别是一般企业中的业务员，可能没有这么高的学历，计算机知识也不是特别丰富。然而他们也拥有我们所不知道的东西，三人行必有我师，在沟通的情况下，他们也是我们的老师，如果一味地拒人于千里之外，那么就根本谈不上什么沟通了。 接下来，想要成为朋友，我们可以从细节做起，对于一个人来说，比较重要的东西很简单，首先是名字，其次是生日，如果我们能够清楚地记住一个人的名字，并且在下次见面的时候就能够准确无误地喊出来，那么一定会赢得好感。如果能够在生日的时候送上一句祝福，那么也会带来意想不到的效果。而做到这两点，我们并不需要付出太多，只要留心就好。另外一个细节就是要了解业务用户的爱好或者兴趣，如果正好和自己的有重合的话，就可以经常讨论一下，那也是增进友谊很好的方式。 沟通的方式有多种，比方说： - 面对面沟通 - 电话 - 即时通信工具（Messager、QQ、Gtalk等等） - 邮件 个人认为优先选用前面的两种方式，那样会得到更好的沟通效果，沟通的效率也会比较高。因为这两种方式更为直接，而后面的两种方式则会因为距离而产生更多的误解和歧义。 **分析能力** 对待一个问题，哲学上有三个步骤的说法，也就是：发现问题，分析问题和解决问题，所以我们会看到，其实分析问题是一个承上启下的步骤，作用也是非常明显的。而想要提高分析能力，真正能够把问题分析清楚，绝对是解决问题的必要条件。 在此我想推荐高德拉特先生的《目标》等一系列图书，其中讲述的是，我们在分析问题的时候，要根据情况的变化而适时调整，不断地寻找流程中的瓶颈，其实也就是问题的关键点，找到之后使用一定的方法解决，但是，并非是解决了一个瓶颈之后就万事大吉了，因为解决了一个瓶颈之后，整个流程的瓶颈就会转移到另一个地方，我们必须加以调整。 另外，我在分析问题的过程中，经常会使用到思维导图，从了解这个工具到现在，我已经形成了习惯，每次分析问题的时候都会不自觉地拿出一张白纸，然后用笔在上面写写画画。 **学习能力** 当前的各种知识不断更新，因此对于想要解决问题的我们来说，学习是非常必要的。而对于想要解决业务问题，更必要的是要学习业务领域的专业知识。这并非是说IT相关的专业知识不重要，但想要更好地理解业务的问题，并更好地为业务用户提供解决方案，掌握业务领域的知识是非常重要的。 想要学习那些知识，一种途径是看书，但另一种更加有效的途径就是与业务用户多多交流，甚至在条件允许的情况下，融入到业务团队中，在一段时间内，和他们一起工作。那样得到的经验会非常宝贵，绝对是第一手。并且这非常有利于我们转换思考的角度，真正做到从业务用户的角度来思考问题。 在IT系统中存在IT的架构，或者说软件系统中有系统架构，在业务领域同样有业务的架构，只有二者可以完美地契合，IT的系统才能够更好地为业务服务，从而更有利于业务部门的发展。 **硬能力** 除了上述的软能力之外，想要实现解决业务问题的方案，我们还需要增加硬能力，也就是技术能力。对于程序员来说，这方面的能力主要指的就是语言和工具。但是，学以致用，我们不仅仅要学习这些知识，还要了解到它们的优点和缺点，那样才更有利于使用它们来解决问题。俗话说，尺有所短，寸有所长，我们要做的就是取长补短。 **使用合适的语言和工具** 在软件开发的过程中，对于每个项目都会有一些规范和限制，但是对于一些特定的工具类程序，或者是那种即抛性的小程序，我们就可以采用一些在常规开发过程中不可能使用的方法来做，那样会取得事半功倍的效果。 比方说，在大型项目的开发过程中，我们一般不会使用中文作为变量名，但是，之前我开发的VBA宏程序中，因为用到了很多保险术语，想要为之起合适的英文名非常难，而且那些单词可能过段时间之后自己都不认识，所以里面很多变量名都使用了中文，这样对于开发以及后续的维护都带来了很大的方便。 尽管说在那些程序中可以比较随意地使用一些平时不能使用的方法，但并不意味着可以不注意代码规范，比方说缩进、命名规则等等，如果代码的格式很乱，那样的代码的可维护性还是会很差，而且那些问题应该是程序员最基本的素养，在任何程序中，即便是即抛性的小程序中，也需要认真对待。 另外，就是可以根据需要采用一些不常用的语言和工具，在项目开发过程中，很多东西都是只需要临时维护，对于那些程序，最重要的就是开发的时间，尽可能快递把程序提交给用户使用，才能够发挥出应有的作用。所以，在这种时候，尽管在核心的系统中我们可能使用的Java、.NET等等，我们大可以采用诸如F#、Python等动态语言，或者其它工具诸如Reporting Service等等，那样就可以通过缩短客户的等待时间而获得更高的满意度。 **组合的方式解决问题** 正如上面所说的，各种语言和工具都有自己的优势和劣势，所以，在某些时候，我们可以对其进行组合来解决问题，那样会发挥出各种语言和工具的优势，而避免各自的劣势。 比方说在之前的一个小型的项目中，我们就采用了多种技术的组合来解决问题。项目的目标是要生成一些数据，然后以sftp的形式上传到某个网站中，该网站的厂商会做后续的处理。 所要生成的数据因为实在Oracle数据库中，所以最合适的语言就是Oracle自身的PL/SQL，我们使用存储过程来开发了这部分功能，从而可以避免网络传输，而且不需要高级语言通过数据库连接来调用数据库。并且在数据库中设置了相关的Job，在特定的时间就会生成相应的数据。 由于安全性的限制，在数据库中的操作就到上面为止了，接下来我们采用C#并而借助enterprise library库来生成相应的文本文件。 最后一步上传，我们并没有使用.NET中的类库，因为它对于sftp的支持比较麻烦，所以我们直接建立进程，调用putty来执行上传操作。而该操作使用的东西很简单，就是批处理文件（.bat）。 这样，我们在项目中组合了多种技术，这样开发的时间被大大缩短，效果也很好，而且在各个环节，我们可以监控到中间的产物。 **结论** 由上述内容我们可以看出，在很多企业中，IT的最终目标就是要解决业务的问题，而想要更好地达到这个目的，我们就要软硬兼施，提高自己在各方面的能力。

最近几天对D语言有了一些了解，据说能够具备和C、C++一样的高性能，语法类似于C#和Java，并且支持当前比较流行的语言——像Ruby和Python——的一些新特性，而且微软还提供了Visual D的插件，可以安装在Visual studio中，从而使用它来开发D语言的程序。 我们会发现，其实这门语言，在很大程度上是以往**各种语言长处的结合**（不知道是否实现了这一点，但目的应该是这样），与其说是一种新的语言，不如说是在借鉴了很多语言之后，组合出的一种语言。 由此我们可以发现，借鉴具有很强的力量。通过借鉴，我们能够创造出一些新的有自身特色的东西来。 说到借鉴，就不能不说创新，曾经有位朋友拿微软和苹果做过比较：微软最近几年来，在技术上一直没有非常明显的创新，似乎总是跟在别人的后面走，比方说云计算，比方说手机开发，再比方说服务式的web应用等等。而苹果的东西似乎每一种都具有很强的创新性，iPad、iPhone、手表式的ipod，还有传言中的裸眼3D功能的iPad等等，都让人能够眼前一亮。 的确，**创新很棒**！能够产生不错的效果。相比之下，借鉴似乎就要差一些，而且“山寨”和借鉴之间也有些搞不清楚。然而，我们也应该看到，**创新其实也是建立在借鉴的基础之上，而且借鉴也能够产生很不错的效果。**毕竟，创新力不是说说就能具备的，也需要长时间的积累和思考，而且还有一些天赋的成分在里面，试问世界上又能有几个乔帮主级别的人物。而借鉴往往更适合我们这些普通人，能够让我们从中受益。 作为程序员来说，也有很多地方都可以采用借鉴的方式来提升自己的能力。 比方说前几天我在百度Web app开发大会上的[演讲](http://vdisk.me/?m=t&a=get_share_file&ss=5e5dn3EIvNqhs2jkqq6j8QlRF1fkTH8wPCy9--2BpkxtmStiTphr2uDr--2FRiBP8ojQBDnMts)中，谈到Web应用前端设计如何能够美观的时候，我就借鉴了版面设计的理论（来自于《写个大家看的设计书》），web应用的设计也应该遵循**重复、对齐、对比、亲密性四种原则**，那样就会达到美观的效果。而谈到设计需要规范的时候，我也借鉴了项目中经常会使用的代码规范，对于前端设计也一样要有相应的**规范**，那样才能够更利于开发和后期的维护工作。 再比方说之前的一篇blog中，我谈到了如果《[以投资的观点学习编程](http://blog.csdn.net/lingyun2005/archive/2009/09/23/4613735.aspx)》，这正是在听了公司投资部经理关于投资的一场讲座之后想到的，学习编程和投资一样，也有不少可以触类旁通的地方。 不仅仅如此，软件这个年轻的产业，本身很多方法都是从其他传统行业借鉴过来的，软件架构在很大程度上借鉴了建筑学的知识，而精益的理论更是来自于生产行业，我们能够看到，软件行业的发展与对其他行业的借鉴是分不开的。 而作为程序员，我们应该借鉴什么呢？ 首先我想要**借鉴已有的程序和项目**，当我们想要完成一项任务的时候，不一定要从零开始，毕竟不是考试，我们完全可以先查看一下是否已经有类似的程序或者类似的项目，看看他们是如何完成的，而且在完成的过程中是否有相关的经验和教训，那些都是非常宝贵的财富。当然我们不是要完全地复制，而是要“**批判地学习**”，在理解了已有内容的基础上，加上自己的思考，从而创建出最适合我们自己的程序。在这个过程中，借鉴本身就是学习和提高的过程。 其次我想可以**借鉴在非计算机领域解决问题的方式**。我们知道，计算机真正广泛应用在解决问题上，也就是几十年间的事儿，之前遇到问题，传统的行业中一样可以解决，也都形成了不少方法论。那正是我们需要借鉴的地方，不一定在解决问题的时候完全要依赖于计算机，先从非计算机的方式入手，放宽一下自己的视野，可能会有更好的效果。 想要真正实现良好的借鉴，我想我们**要时刻有借鉴的准备**，机会总是留给又准备的人的，当我们在平时的生活中，或者是在各种书籍中，发现好的解决问题的方法时，就可以试着思考一下，是否可以借鉴到计算机领域中，这样，在以后编程解决问题的时候，可能就会不自觉地使用了。切不可把自己处于一种封闭的状态，对外界的事情不闻不问，更可怕的就是完全排斥了，根本就不接受外界的思想，那样“闭关锁国”的话，如何才能发展呢？（这里貌似也是借鉴，:)） 关于借鉴，你的想法如何，欢迎在此评论，也欢迎通过我的微博：[@侯伯薇](http://weibo.com/houbowei) 和我交流，:)

作为程序员，我想每个人都对于提高和进步非常渴望，也期望自己有朝一日能够从菜鸟变成大师级的人物，能够做出很棒的系统，能够得到他人的尊敬和赞赏，当然还可以得到不菲的收入。 然而，想要达到那个层次，不可能一蹴而就，必须要**踏踏实实，一步一个脚印，逐步提高**。这在每个行业或者说每个人的成长过程中都是一样的，所以我们必须要把握每一个提高的机会，从一点一滴做起。古语云：不积跬步，无以至千里，道理也是一样的。 前几天一位医学专业的朋友谈到了医学上的微创新，他说，如果看医学上一两年的发展，似乎没有什么特别大的进步和创新，但是，这并不意味着医学上没有进步，当我们回头看十年前，再与当前的情况作比较的话，就会发现已经有了很大的创新，而这些创新并非是一下子就出来的，而是经过十年来一点一点的微小的创新积累出来的，其实也就是一个**量变引起质变**的过程。 再说一个程序员会非常熟悉的例子，大家一定都玩过游戏，比方说《暗黑破坏神》《魔兽世界》等等需要打怪升级的游戏，里面的设定并不会让玩家一下子从菜鸟成为超级高手，那样游戏的趣味性就大大下降了，玩家必须通过不断的**积累**，累计经验值，然后在一定的时候升级，在到达一定的级别的时候才能够学会某种技能。其实在这里面，每一次小的升级都可以对应行业中的一次微创新，而学到指定级别下的技能，则可以对应一次变革性的创新。 类似的例子举不胜举，只要稍微注意，就能够发现。 然而，作为程序员，想要成为高级程序员，想要获得架构师、系统分析师、DBA等等诱人的称号，有时候却会比较急躁，在自己的能力还没有达到的时候，就匆匆上马，接受自己的能力范围之外的工作，就为了那个“名”，结果却往往会得不偿失，**一方面有拔苗助长的嫌疑，另一方面对于项目也是一种损害**，做出了不好的架构，系统分析不到位而导致客户不满意，诸如此类的情况，在我们身边相信大家都见过吧。 所以，想要真正做好项目，做好程序员，我们还是需要循序渐进，然而到底应该怎么做呢？我的建议，仅供参考。 对于刚刚踏入软件行业的同学来说，当然就是**多多编写代码，在参与的各个项目中学习并且积累经验**。在这个阶段我们会感觉进步非常快，很快就感觉可以做很多具体的工作了，个人也会非常有成就感。但是，此时千万不可被胜利冲昏了头脑，不能觉得自己已经再也无法从项目中、从团队的成员那里学到东西了，觉得项目离开自己就做不下去了。相反，这个时候应该继续保持低调，以空杯子的心态努力学习更多的知识。 做了三年左右的程序员之后，我想大家都会有一个飞跃，积累出来的经验得到总结，也有了自己的思想，这个时候，很可能项目中所能够学到的东西已经无法满足需要了，所以就要**找寻其他积累经验的方式**。当然跳槽、换项目是一种方式，而另一种方式就是多多从各种渠道——包括网站、书籍等——学习知识，了解行业的动态，另外还要多多与其他人交流，那样会产生很多想法，从而更好地引起个人的思考。 到了七八年或者十年左右，可能会迎来另一次飞跃，做过的项目很多，积累的经验很多，思考的成果也很多，真正形成了自己的风格和思想，这个时候仍然不能放弃学习和交流，而另一方面，**思考会变得更加重要，并且也是要确定自己发展方向的时候了**。到底是做项目经理，还是架构师，还是系统分析师，或者DBA等等，在对自己有了比较清醒的认识之后，就可以确定自己的目标了，然后就要为之做各个方面的积累，准备迎接下一次质变。 上面的内容仅仅是我的建议，时间的长短和具体的做法会因人而异，在以后的我也无法给出建议，毕竟我也还在等待下一次升级。我想大家所要了解到的就是不能放弃学习和提高，而要不断进步，那样经过一段时间之后，一定会有变化的。 其实我们在工作的过程中，循序渐进不仅仅体现在个人的成长上，对于**代码的修改也一样，特别是对于遗留代码，想要完善的时候，也需要使用循序渐进的方式**。 之前曾经看过对于系统是要重构还是重写的讨论，更多人倾向于重构，毕竟那是一种循序渐进的方式，不断地对代码进行修改，质量一步一步提高，形成一定的积累之后，就会发现代码的质量会发生很大的改变。而重构本身，也提倡小步前进，道理是相同的。 如果进行的是重写，则进行的是一种革命式的修改，然而，一切重头开始，不可避免会因为没有积累，而导致所要耗费的人力物力财力都非常大。 总之，作为程序员，应该了解到这个很重要的原则——循序渐进，也希望能够听到大家的想法。

上一篇博客《[程序员应知——放宽视野](http://blog.csdn.net/lingyun2005/archive/2011/04/19/6332605.aspx)》发布之后，收到很多朋友们的评论，大家也认同我的观点，觉得对于程序员来说，放宽视野是非常必要的，然而，也有很多人提到，那篇博客写的比较泛泛，并没有指出如何来放宽视野，我也意识到了这个问题，所以想再继续谈一下“放宽视野”这个话题，:) 我想，想要真正放宽视野，首先要做到的一点就是**把自己的姿态放低**，不要认为程序员这个职业比其他职业高级，甚至在很多传统的职业跟前，我们还是要谦虚地去学习，也就是一种空杯子的心态，那样才能够把其他领域的知识装到我们的杯子里面。另外，要始终有把其他行业的知识与IT知识联系起来的意识，也就是说不能打无准备之战，要**时刻做好准备**，从其他领域吸取自己所需要的内容。 具备了以上两个前提之后，我们就要开始把自己的视野放宽，充实自己的知识了。对于任何知识都是一样，我觉得所要遵循的过程，或者说三种必要的方式就是“[**学习、思考和分享**](http://blog.csdn.net/lingyun2005/archive/2010/11/09/5996741.aspx)”，学习的过程可能是阅读大量的书籍，也可能是参加各种培训，或者向他人请教；学习获得的知识还没有经过提炼，我们需要经过思考这个过程，把其中所要吸取的知识提炼出来，使其真正成为属于自己的智慧，那样才能够发挥出更大的能量；而分享的过程也非常重要，不仅我们可以把自己的想法表达出来，获得他人的反馈，而且能够根据这些反馈以及思想的碰撞进一步地学习和思考，从而形成一个良性的循环。（对于此，更详细的内容可以阅读一下我之前的一篇博客《[程序员应知——学习、思考与分享](http://blog.csdn.net/lingyun2005/archive/2010/11/09/5996741.aspx)》） 接下来的问题可能就是，要把视线落在哪个领域，才能够对我们做好编程的工作起到很好的作用呢？这个问题我想是因人而异的，在此我仅把自己的一些感受说给大家，做个参考。 首先一个必要的领域就是**工作中所要接触到的业务领域**。多年以来，我更多地是在从事业务系统相关的系统开发，所以相关的业务领域知识就比较重要了，有了这些知识，我们可以更好地和业务人员交流，也可以更好地理解业务所提出的需求，并且能够在需要的时候为业务部门提出比较合理的意见和建议。这些年来，我涉及到的业务知识包括：生产、贸易、建筑机械租赁以及现在所从事的保险行业，这些知识对系统开发起到的作用是显而易见的。并且经济学和财务的知识也非常重要，毕竟每一家公司都会涉及到这些内容，是属于必不可少的领域知识。 接下来需要了解的领域我想应该是**管理学**，毕竟每个系统的开发都是项目，都需要进行管理，比方说资源的掌控、进度的把握等等，这都会需要管理学方面的知识。曾经看过的《目标》那个系列的书，还有《一分钟经理》系列、《人月神话》（请允许我把这本书也归到管理学范畴，呵呵），还有大学的管理学课程相关的教材，都对我更好地管理自己、管理团队起到了很好的作用，更多的心得是，要确定问题，找到自己的目标，然后用最直接的方式达到目的，消除各种浪费，相信很多朋友都会有相关的体会吧。 此外，我们也不能放松对**自己的修炼**，不仅仅是自身的**情商修炼、影响力修炼**，还有一些我们所必需的**软技能**，比方说沟通的能力、演讲的艺术、制作PPT的技巧等等，都会对我们更好地进行学习、思考和分享起到很重要的作用。 很多朋友会说，还有一个很重要的方面——**哲学**，没错，这是指导一切学科的知识，当然我们不能忽略，在工作和学习中我们经常会利用哲学的一些思想来解决问题，比方说：主要矛盾和次要矛盾，矛盾的主要方面和次要方面，世界万物都处于运动变化之中等等。 以上就是我的一些想法，希望能够和大家一起继续放宽视野，更好地做好程序员这份工作，:)

前几天和朋友一起交流的时候，他提到了一点问题，作为程序员，有时候会比较narrow-focused，总是觉得IT这个行业是高新技术行业，自己掌握的知识都是最新的知识，而其他行业都需要和我们学习。 古语有句话叫做：万般皆下品惟有读书高，现在放在程序员身上似乎也有一些贴切了。 之所以有这样的想法和情绪，一方面可能是金钱的作用吧，一般来说，在IT公司中的朋友或者是做IT的朋友们，薪资会比做传统行业的人高一些；另一方面可能是和所学习的知识相关，毕竟是一门新兴的行业，最新的就是最好的，很多人都是这样的认识；再可能就是由于做IT的人都太忙了，根本没有时间去关心其他行业的情况，这也造成了大家视野在一定程度上会有些狭窄。 其实，我们根本就没有资本认为自己的工作比其他行业要高级，相反，我们有很多很多需要和其他行业学习的地方。 原因是不言而喻的，仅仅从行业发展的年限来说，没有几个行业的年限要比IT行业短了，多年的积累形成了行业的模式和特点，也形成了很多的派别和模式，而众多派别之间的争论和相互学习，也促进了行业的进一步发展。 而且，反思一下软件开发过程中的各种方法论，很多都是从其他行业借鉴过来的。架构、模块化的思想，很大程度上借鉴了建筑学；规范、流程借鉴了生产行业的经验；而最近很流行的敏捷方法，同样也借鉴了其他行业中的管理思想，特别是看板、精益方法，都是从日本的制造行业中学习得到的。 因此，我们可以看出，了解一下最基本的方法论（比方说哲学思想）和管理思想，然后反思我们在软件开发过程中的方法和管理思想，触类旁通，会有更多不错的想法出来。 当然，有人会认为，很多语言啊、数据库等等方面具体的知识还没有学会，哪里会有时间学习那些非计算机领域的知识呢？我想，那些具体的知识固然非常重要，但是多多了解其他领域的知识，一方面可以让我们的精力有所转移，从而不会固守一隅，钻进牛角尖，从而获得一定程度的放松和休息，另一方面，多做些储备，在学习具体的知识时，就会有灵光一现的情况发生，那是更加珍贵的体验。 总之，我们要多多了解各方面的只是，放宽自己的视野，那也会让我们与各种各类的人交流起来更加容易，好处很多，希望大家都会有体会，:)   本文续篇：《[程序员应知——再谈放宽视野](http://blog.csdn.net/lingyun2005/archive/2011/04/26/6363209.aspx)》

从Martin Fowler最早提出重构的概念开始，到现在已经有很长时间了，重构已经是深入忍心了。与其说它是一种方法，不如说是一种思想、一种习惯。我自己在工作的过程中也一直在使用它来改进自己的程序，所以在此想说说自己的两点认识。 **重构不“挑食”** 上面已经提到，重构不仅仅是固定的那些方法，而更是一种思想和编码时候的习惯，所以，**不管你是用那种语言编程，都可以应用重构。**《重构》那本书上的例子都是Java的，可能很多人会觉得，只有在Java、C#等面向对象的语言中，才能够使用重构的方法，而在面向过程和函数式的语言中，就很难应用重构了。我认为并非如此，的确，在面向对象的语言中，有很多特定的重构方法，比方说抽取接口、变量上移、变量下移等等，但还是有一些通用的重构方法，可以在各种语言中使用。 举两个最常见的例子：重命名和抽取方法。这两个方法不论在什么语言的编程下面都是非常常用的，我们也经常会做这样的重构。比方说我在使用pl/sql编写procedure和function的时候，就经常会做这样的操作。特别是当pl/sql developer的新版本中增加了重构的选项，能够帮我们更好地自动完成重构的操作。在这里，pl/sql这门语言可是过程化的，而非面向对象的。 所以说，我们可以在编写任何代码的过程中都可以使用重构，甚至在HTML代码中、JavaScript代码中等等，都可以使用，因为重构不仅仅是具体的方法，而是一种改善代码，改善系统的一种思想，它的目的就在于让我们的系统的可读性、可维护性更高，从而具有更好的质量。 **重构可以随时进行** Martin Fowler的《重构》一书还有个副标题，叫做“改善既有代码的设计”，这让我在当初产生了一点儿误会，还以为重构只能是在把代码写完了之后才能够进行的。其实不然，我们可以随时对程序进行重构，（我曾经在内部的交流中把它叫做行进中的重构，呵呵）**那样会更有利于之后的编码。** 比方说，在编写程序的过程中，忽然发现有一个变量的命名有些不合理，我们可以立即对其进行重构，修改名称；或者更实用的，发现自己接下来要写的代码完全是之前代码的重复，或者说可以从别处copy，然后稍作修改就可以，那么我们就可以回头把之前的方法抽取出来，而在新的位置直接调用；或者发现想要使用某个方法，但它位于其它类中，就可以想是否可以提取父类或者接口，然后把通用的方法提取到其中，然后再对其进行继承或者实现，那样就可以方便地调用方法了。 还有很多很多的方法，都是可以在编码的过程之中就可以做的，而不需要等所有的编码完成了之后才做。那样的好处是显而易见的，在之后如果再需要实现类似的功能，就可以直接调用已有的方法，而不需要等最后再做调整了。 总之，越是使用，越是觉得在编程的过程中应该始终把“重构”的思想放在头脑中，随时拿出来使用。 你对于重构是否也有想说的话呢？

有人说，程序员是个苦差事，一辈子总是要不停地学习，学习新的技术，学习新的架构，学习新的工具，一旦一段时间不学习，就会发现其他人嘴里冒出来的新鲜词，自己已经搞不懂是什么了。 的确，作为程序员，**学习很重要**。 还有人说，做程序员是典型的脑力劳动者，每天都要思考，想怎样才能做出更易于扩展、安全性更高的架构，思考如何才能够满足客户的需求，思考如何才能够让自己做出来的程序可维护性更好，思考如何让自己的产品更容易被用户所接受，很多很多需要思考的问题。另外，每次做完一个项目，总是要思考一下在其中获得了什么经验和教训，学到了什么知识，然后在仔细做个总结。 的确，作为程序员，**思考也非常重要**。   古语云：学而不思则罔，思而不学则殆。 其实学习和思考的重要性，很久很久以前的人们就意识到了，直至今日，仍然是一样的。   然而，在学习和思考之后，我们还需要做一件事儿，也是让学习和思考更有目的，反过来又能够让我们更好地学习和思考的事情，那就是——**分享**。   当前的社会，当前的程序员，已经都告别了单打独斗就能够搞定一切的时代了，团队变得越来越重要。而在团队之中，或者更广泛一些，在程序员这个圈子当中，没有分享和交流，是不可想象的。那样只能导致固步自封，作为一个井底之蛙，根本不了解外面的世界了。其实，一山更比一山高，外面的世界很精彩，想要了解这些，**我们首先要有一个open的心态，把自己的东西共享给别人**，那样也会获得来自于其他人的分享，了解更多的世界也就变得容易了。 肯定有人会问，我分享了知识，分享了经验，分享了……，我会获得什么呢？我想，**想要做到真正的分享，首先应该就是没有目的的**，不要考虑对自己会有什么好处，那样才能够平心静气地做下去，那样才能够不会因为没有获得什么东西而放弃。当做了一段时间之后，我们会发现，其实得到的东西很多，而且都是无法用money这个东西来衡量的，比方说他人的认可，比方说圈子的扩大，比方说成就感，还有让我们能够坚持做一件事的决心和毅力，有传统的重要的东西，也有富于现代感的东西，而且这样的话，自己的影响力会扩大，能力会有提高，当想要换个工作的时候，可能就会体现在经济利益上了。 既然分享能够让我们获得许多，那么如何分享呢？我现在主要做的就是两种方式，**一是写blog，二是举办交流会**。 不知不觉，从决定坚持写blog，到现在，陆陆续续也有一年左右了，在这期间，不断地把自己学习和思考的结果分享出来，也得到了非常多有意义的反馈，从中也获得了很多。特别是《程序员应知》这个系列，让我交到了很多好朋友。 交流会已经在公司内部举办有半年的时间了，在此期间，我为大家做了至少六次的演讲，此外还支持其他人一起举办了多次交流活动，现在这个活动每次举办一次，系列名称叫做“Happy Time”，似乎大家也很是享受每周固定的这段时间，真的是很快乐的时间。   为了更好地分享，我想还有许多**需要提高的地方**，对于写blog来说，上面所说的学习和思考是必须的，但这主要是在本专业的领域中。而对于做presentation，就不那么简单了，我觉得，设计页面的知识、制作PPT的知识、做演讲的知识等等都很重要，这些知识都是一些软能力，很可能在某种情况下是被我们这些整天埋头于计算机编程中的程序员所忽视的，为了让自己的PPT更漂亮，为了让自己的演讲更有感染力，而不是让人昏昏欲睡，我看了不少书，（推荐阅读：《写给大家看的设计书》《演说之禅》《演讲之禅》《说服力》）也做出了不少实践，感到自己在这些方面都有了一些提高，尽管还没有达到什么高度，但是我想只要坚持下去，就一定会越来越好。   本来是一篇《程序员应知》，结果发现变成一篇自我总结了，希望对大家能有借鉴意义，那就足够了，:)

这里是“程序员应知”这个系列的索引，按照发布日期排列，:)   # [程序员应知——学习、思考与分享](http://blog.csdn.net/lingyun2005/archive/2010/11/09/5996741.aspx) [程序员应知——团队精神](http://blog.csdn.net/lingyun2005/archive/2010/08/09/5797890.aspx)   [程序员应知——你有几种武器](http://blog.csdn.net/lingyun2005/archive/2010/07/29/5772859.aspx)   [程序员应知——把小事做好](http://blog.csdn.net/lingyun2005/archive/2010/07/27/5767972.aspx)   [程序员应知——数据库设计的两个误区](http://blog.csdn.net/lingyun2005/archive/2010/06/30/5705710.aspx)   [程序员应知——首先检查自己的问题](http://blog.csdn.net/lingyun2005/archive/2010/06/07/5654069.aspx)   [程序员应知——破窗与童子军军规](http://blog.csdn.net/lingyun2005/archive/2010/05/25/5623666.aspx)   [程序员应知——我们不是客户](http://blog.csdn.net/lingyun2005/archive/2010/05/21/5613101.aspx)   [程序员应知——技术债务](http://blog.csdn.net/lingyun2005/archive/2010/05/20/5610133.aspx)   每次发布新的文章，我会更新这个列表，希望可以给大家带来方便。

*    写在前面：前几天终于看完了《团队之美》这本厚厚的书，里面叙述了与团队相关的点点滴滴，当然也包括如何创建并维护优秀的团队。让我更深地领略到团队精神在现在的开发中的重要性。感触很多，收获很多，写在这里与大家一起分享。*       大家都知道，现在的软件开发已经不再是20年前个人英雄主义的时代，一个超级程序员就能够搞定一切的情况已经很少存在了。更多的情况是我们都是以团队的形式进行系统的设计和开发，因此，团队精神也变得越来越重要。     早在我刚刚毕业要踏入到软件开发这个行业的时候，就在自己的简历里面写到：具有很强的团队精神。然而，说句实话，当时对这个词的理解真的不是那么透彻，只是觉得人缘好，和别人合得来，就叫做有团队精神。然而，随着工作的年头越来越多，经历过各种不同的团队，也带领过不同的团队，渐渐地，对于“团队精神”的体会也越来越深，也越来越觉得并非那么简单。     那么到底什么是团队精神呢，我觉得它包括了下面这些特点： - **荣辱与共** - **交流分享** - **精诚协作** - **尊重理解**     下面让我分别结合自己多年来的工作经历谈下自己的理解，与大家共享，同时也说说自己理想中的团队的样子。   **荣辱与共**     作为一个团队中的成员，就要把**整个团队的荣辱放在第一位**，这似乎是集体主义精神的体现，与当前更为流行的个人为中心的思想有些格格不入，但是，只有把整个团队的利益放在首位，团队才能够发展和进步。而团队的发展和进步必定会给其中的每个成员带来好处。     在这里我要说个很典型的情况，在团队中一般都会有开发人员和质量管理人员（也就是我们常说的测试人员），一般来说这两种角色都是冤家。前者非常怕后者测试的时候测出无数的问题，而后者经常会经常抱怨说“你自己测没测试啊”。似乎二者之间总是有着不可调和的矛盾。     想要解决这个问题，其实很简单，就是要明确荣辱与共这条原则，开发人员的目的是想要高效高质的开发出程序，这首先就要对自己提高要求，如果开发出来的程序质量不高，那么必然会返工修改，似乎当时是节省了自己的时间，尽快地把程序提交上去了，但实际上，自己后来还需要修改，节省的时间还要再找回来，另一方面，还需要测试人员指出低级的问题，（那些问题只要再稍微细心一些就能够避免），也会浪费测试人员的时间，结果对于团队来说，就花费了两份时间。如果能够想到为团队节省时间的话，也就会自觉地提高自己程序的质量了。     而对于质量管理人员来说，首先当然要仔细地测试，不可敷衍了事，那样的确可以节省自己的时间，而且容易和开发人员搞好关系，但是必定会导致程序质量的下降。而对于客户来说，质量才是程序的生命线。其次，不可以因为自己发现很多缺陷就沾沾自喜，的确这意味着作为质量管理人员，工作做得很到位，但是我们的目的是什么呢？并非是要找到更多的缺陷，而是要想办法提高系统整体上的质量。我想我们大可以将缺陷总结分类，然后将自己的分析结果提交给整个团队，指出在哪些地方比较容易犯错误，那样不仅整个团队的开发质量得到了提高，也节省了自己以后工作的时间，只不过是不会总是找到那么多的缺陷了。   **交流分享**     交流在任何工作中都是非常重要的，**人和人之间只有充分交流，才能够更好地工作**。这些交流不能仅仅限于开发人员之间，团队之中每个人之间都应该充分的交流，否则就会在信息的传达过程中出现理解上的偏差。比方说，如果上游工程（需求分析、概要设计）的负责人不和下游工程（详细设计、编码、测试）的人员充分交流，那么很可能会得到最终用户这样的评价：你们所做的东西不是我要的。这就是由于信息在传达的过程中发生了偏差，失之毫厘谬以千里，导致了最终客户对团队的恶评。     **团队的成员应该成为朋友**。也许这在现在的职场之中，很难得到认同，甚至还听到有人说过，不要把同事当成朋友，但是我不以为然，毕竟我们很多的时间都是与同事一起度过的，很多东西需要和同事一起承担、一起分享。如果不是朋友的话，没有最起码的信任，怎么做事儿呢？的确，有些同事会不值得做朋友，那么就应该去找到值得做朋友的人，或者在组建团队的时候就要慎重地挑选所有的成员，尽量让大家都成为朋友，那样才更有利于工作的开展。     分享意味着什么呢？**我觉得它意味着共同进步，知识要分享，经验要分享，好吃的，好玩儿的都要分享**。这也应该是大家成为真正的朋友的前提吧。尤其是知识和经验的分享，对于组建学习型的团队非常重要。而最有效的形式，就是在固定的期间内举办技术交流会，团队的所有人尽可能地参加，大家可以把自己工作学习生活中所发现、所学到的知识分享出来，这样不仅仅有利于大家共同提高，也有利于解决工作中的各种问题。而这也是我一直在致力推行的一种方式，尽管最近有些障碍，呵呵。   **精诚协作**     想要达到这一点，**首先就不要“事不关己，高高挂起”。**尽管有些事儿不是我们份内的事情，但是团队的事情，我们都应该有责任尽自己所能去做。有人会说，做得多，错就多，帮别人修改了程序，当这个程序出问题的时候，就会怪罪到自己的头上。这种情况的确存在，我也遇到过多次，但是我更珍惜的是在这个过程中和其他团队成员的交流以及所学习到的知识。任何事儿都不可能是完美的，都具有两面性。而且这样做非常有利于形成真正意义上的团队，当出现问题的时候，我们帮助过别人，当我们自己出现问题的时候，也就会有人帮我们。     也有人会说，让一个人做别人的工作，修改自己不熟悉的程序，风险会比较高，很可能会出现其他的问题。的确这种情况也存在，因此在涉及到业务领域知识的时候要谨慎，复核一下也是非常必要的。而对于纯技术的问题，就不存在这种问题了，一个项目中的程序都应该是风格统一的，程序员彼此之间应该可以互相阅读和修改程序。     另外，**协作要体现在整个团队之中，**需求分析人员、设计人员、开发人员、测试人员之间都要协作。在做自己的工作的时候，都要为别人着想，考虑如何才能够更有利于让别人也顺利开展工作。   **尊重理解**     人都有长处，都有短处。这是肯定的，没有谁能够是完美的，何况生活中不仅仅是工作，还有很多其它的事情也会对工作造成影响。因此在发现别人犯错的时候，应该去理解，并且以对事不对人的态度去解决问题。     比方说，测试人员发现开发人员程序中出现了很多缺陷，那么不应该去指责，而是应该记录下来，然后和开发人员一起分析，提醒他以后不要出现类似的错误。     再比方说，当开发人员发现设计人员的设计出现了问题，那么就应该去商量，找到更好的解决方案。     再比方说，设计人员发现最终的程序与自己的本意有出入，也应该去沟通，而不是强硬地要求别人重新编写代码，而应该找到为什么会出现这样的问题，从而去避免以后理解上出现歧义。     **多一份尊重，多一份理解，才能够更好地沟通，才能够更好地协作**。       我想，如果做到了上面的四点，我们应该建立起一个比较优秀的团队，然后接下来要做的就是**保持团队的稳定**，并且在一个又一个的项目的磨练中不断地增进团队的凝聚力和向心力，并且越来越好地根据每个人的能力来分配工作，做到人尽其用，这样团队的工作效率会越来越高，完成任务的质量也会越来越好。     创建一个理想的团队，需要很长的时间，需要团队成员彼此之间不断地磨合、理解和包容，所以，在创建团队之前，要确保团队成员的稳定性，同时，对于人员的增减，都要慎之又慎，必须是完全理解和赞成团队文化，并且能够为团队做出贡献的人，才会加入到团队中来。     上面所述的团队非常理想化，想要真正实现会很困难，而且保持下去更困难，我们要做的也不是一口吃个胖子，一下子就建立一个超级团队，而是要在创建团队的时候就有自己的原则，并且根据这些原则不断地对团队进行改善和建设。   p.s. 这篇文章在我的草稿箱里面待了很长一段时间，一直在对其中的内容考虑来考虑去，生怕误导了大家。不过“丑媳妇早晚要见公婆的”，所以还是在修订了之后，拿出来与大家分享，大家有什么意见，只管提出，希望和大家一起讨论，:)   [**查看所有“程序员应知”系列文章。**](http://blog.csdn.net/lingyun2005/archive/2010/08/13/5808409.aspx)

平日里很少看电视连续剧，因为一连续起来就没完没了。但是也有例外的情况，比方说国内的《亮剑》，八路军又是步枪射击，又是手榴弹攻势，最后刺刀见红，让人很是激情澎湃。还有就是美国的《反恐24小时》，为了看小强jack的精彩表演，甚至可以忍受一年24集，每周一集的煎熬和折磨。小强同志真的是十八般武器，样样精通，一会儿用手枪，一会儿用冲锋枪，还有小手雷，冷冷的匕首，让人不由地感叹，特种兵就是牛啊。 这两部电视剧中，想要解决掉敌人，李云龙也好，杰克鲍尔也罢，**在不同的情况下都会使用不同的武器**。而作为程序员的我们，在想要解决业务需求的时候，手中握有几种武器呢? **首先我们必须有一种最趁手最熟悉的武器**，有人的是java，有人是vb，还有人是c#等等，这种武器是用来解决大型项目中的问题的，我们用的最多，对其了解最深，也最喜欢使用。但是，仅仅这一种武器是否够用，是否足以搞定客户或者业务部门层出不穷的各种需求呢?一般来说还是可以的，**只不过在特定的情况下，比方说时间上的要求，用户界面友好程度上的要求，或者是某些特定功能上得要求，我们可能会采用其他武器，从而得到更高的效率，更便捷的操作，或者特定的某种功能**。 所以说，手里常备几种武器，还是很有意义的。 拿我自己曾经的经历为例吧。之前曾经在博文中讲述过[一个抽奖软件](http://blog.csdn.net/lingyun2005/archive/2010/01/29/5267887.aspx)的开发过程，代码也一起公布了出来。其实我日常工作中用的最多的是JAva，开发环境是EClipse。那次的任务如果用这种武器开发也是可以的，但需要的时间可能会比较长，而当时业务部门才给了我不到一天的时间，所以最终我选择了VBA这种武器，结果只用了两个多小时就完成了开发和测试，而且业务人员还挺满意，第二天就真的用它抽出了各个奖项。 再举个例子，我们平日里将开发好的程序发布到测试环境需要不少繁琐的环节，一不小心就会忘记一个，然后就会导致发布人员的不满和抱怨，所以，有个小工具来提醒自己，并且将整个流程自动化是非常必要的，但是这个工具需要可以和Windows交互，并且能够模拟键盘和鼠标的操作，当然还需要具备编程语言的特点，另外还有可以很容易地编译成可执行文件独立运行，所以用JAva或是C#都不是非常合适。不过我很幸运，发现了Autoit这个工具，它完全满足我的需要，所以我的武器装备库里面有多了一件。花费了两个多小时，我给自己编写了非常好用的[提醒工具](http://blog.csdn.net/lingyun2005/archive/2010/07/14/5733274.aspx)，使用它之后，我近一个月以来都没有在发布环节犯过错误。 所以，我觉得，大家在有空的时候，就应该丰富一下自己的武器装备库，学习更多的语言和工具，那样在面对具体的需求或者任务的时候才能有更开阔的思路，更新奇的想法以及更有效的做法，这样也可以更高质高效地完成任务。 然而，说起来容易做起来难，我们应该怎么做，又应该注意些什么呢?让我来为大家提供一些个人的建议。 选择学习一种武器之前，应该**明确地了解它适用在什么样的情况下**，做什么样的工作最适合。就像我们在电视中看到他们有时用手枪，有时用狙击枪，有时又要用匕首一样。 除此之外，古语有话：尺有所短，寸有所长，在特定的情况下，没有一门语言或者一种工具是完美无缺的，我们还要**了解每种武器的长处和短处**，这样不仅有利于采用最合适的武器，而且还可以让它们彼此之间相互配合，从而达到更好的结果。当初上大学的时候，曾经有段时间在学校的有线中心做视频编辑，那个时候就是用了多种工具，做图的有Photoshop、Photoimpact，做视频的有Premier、我行我速、做3D效果的有3D Max、Cool 3D，总的来说，有些是属于傻瓜型的，只要动动鼠标就可以生成差不多的效果，但是对于细节的处理不是很好，想要做微调的时候，就需要使用比较传统的、笨重的工具，那样做出来的效果才会有专业水准。所以说，**相互配合真的挺重要的**。大家在编程的过程中也一定拥有多种工具，是不是也是不停地在利用彼此之间的配合来提高自己的工作效率了呢？ 还有一点想要说明的就是，尽管我们应该拥有多种武器来处理多种不同的情况，但是对于经验不太丰富的同学来说，不要太急于追求手中武器的数量，那就有些舍本求末了，有些时候，武器（或者说工具）只是外在的招式，而我们的编程思想才是内功，只有先把内功练成了，然后随便使用哪种工具，都会发挥出巨大的威力，那个时候就是充实你的武器库的时候了。因此第一步应该是先彻底掌握一门语言，或者一种工具，然后再去触类旁通。 最后想要问问大家，你有几种武器？   [**查看所有“程序员应知”系列文章。**](http://blog.csdn.net/lingyun2005/archive/2010/08/13/5808409.aspx)

在从事软件开发的这些年中，近期越来越多地听到这样的论点：当前的程序员越来越浮躁。我的感觉也是如此，由于在软件公司中，人才流动特别快，因此很多人的职位也变化的比较快，很可能刚刚工作了三年的程序员，就被冠以项目经理的职位，或者是做过几个项目的人，就成为一家小公司的技术总监、架构师，其实，本身的能力与这个职位真正的要求非常不相配。然而，正是这样的情况更促使了程序员的浮躁心理，或许也可是说是攀比的心态和虚荣心在作怪。 上述情况的直接表现就是，很多程序员在具备了一定的经验之后，就**不喜欢做“小事”**，这里的小事可能是： - 重复性的事情 - 简单的事情 - 编写程序之外的事情（比方做报表的模板） 他们喜欢把这种事交给刚进入公司的新人来做，并且会告诉他们，这都是很简单的事儿，你只需要……就可以了。 把这样的工作推出去之后，这些程序员会**喜欢做什么呢**？可能是： - 技术调查研究 - 新技术的学习 - 复杂程序的编写 - 更高层次的技术工作（架构） - 管理工作（期望成为项目经理） 尽管这些事儿看起来比“小事儿”更有意义，但我还是要说，作为程序员，不管到了什么时候，都要具备把“小事”做好的能力。拿我自己为例，虽然已经工作了十年，也曾经做过所谓的项目经理，也付出过时间和大家一起研究过架构，但是现在还是回归根本，做一个兢兢业业的程序员，还在第一线奋斗呢，呵呵。也还在做着很多大家认为是“小事”的事情呢。 其实，仔细想一下，**想要真正把小事做好并不容易**，举个我实际工作中的例子，公司改名，需要将70多个模板中的原公司名修改为现在的公司名称。 这项工作看起来非常简单，不就是打开模板，查找，替换，然后再保存，替换原来的文件，就一切OK了。 但是，问题就在于所有70几个文件要一个不落，而且里面的公司名称的数量也不一定，需要一个不差。并且还需要尽快完成。总的来说，就是既要快，又要准。这样就不是那么容易了。 我的方法是先做一遍，然后仔细从头到尾检查一遍。不要过分相信自己，一定要做检查，这种重复性的工作很难一次完成的。另外，还用Excel做了一个文件列表，没修改完一个，就做上标记，这样可以保证一个不差。 大家可能也看出来了，做这种事情，需要的是什么呢？也比较简单，一是细心，二是耐心。但这正是浮躁的程序员所缺乏的两点。 也会有人说，做小事对我没有什么好处，也不会有什么长进。 如果只是机械地去完成，而不去思考，不采用一些必要的方式来保证做小事的质量和效率，那么真的就不会有什么长进，而且我觉得可能最终的完成质量也不会太高。 **其实不管做什么事儿，都需要思考，思考之后，都会有进步**，我们可以在做之前，想一下是否存在一些方法能够让我们更快、更高质量地完成任务。很多方法非常简单，但也很有效，关键就在于我们是否能够想到去用。在完成上个任务的过程中，其实首先是要在近千个模板文件中筛选出来那70几个的，如果就直接在原来的文件夹中修改，估计很快就晕倒了，我的做法是先把筛选出来的所有文件copy出来，修改之后在copy回去（当然这里也需要复查，保证复制出来的是所有需要修改的文件，不能多、不能少，更不能错！） 把小事做好的另外一个好处就是，**它能够让你赢得他人的信任**：一个人能够把很简单、重复性的工作做好，那么就足以委以重任；如果连小事儿都做不好，谁敢把大事儿交给他做啊。如果大家做过管理工作，一定会此会有所感触。 所以，我觉得，不管当前的职位如何，不管从事工作有多少年，当接收一些所谓的“小事”的时候，都要努力做好，而不要觉得与自己的现状不相称，那其实就是浮躁，呵呵……   [**查看所有“程序员应知”系列文章。**](http://blog.csdn.net/lingyun2005/archive/2010/08/13/5808409.aspx)

> 原文出处：[程序员应知](http://blog.csdn.net/column/details/proknow.html) 作者：[侯伯薇](http://blog.csdn.net/lingyun2005) **本系列文章经作者授权在看云整理发布，未经作者允许，请勿转载！** # 程序员应知 > 在忙碌完了一天的工作之后，你是否思考过今后应该如何提高自己的工作能力、如何写出更好的程序，如何在职场中更上一层楼？做程序员，本就是要多思考的。