|
|
文/Scott Johnson, WebSphere Application Server JSP 团队负责人, EMC
英文原文：Scott Johnson: Take a lifetime to be a good (and happy) programmer
高速通道和长途旅行
就编程实践，计算机科学博士、Google 的 Search Quality 总监写了一篇很不错的文章，名为“Teach Yourself Programming in Ten Years”。这篇文章中提出了一个大问题：为什么人们这样急于学习编程呢？是因为他们希望能够速成呢，还是因为大家认为计算机是最容易学习的？不管什么原因，做一个好的程序员并非快速学习的结果，而需要深入认真学习，并需要明智地选择学习的内容。关于这点，本文给出了六条建议，供那些准备开始（或已经开始）用一生的时间实现做个好程序员的梦想的人参考。
通过好的例子学习
有些程序员很幸运。他们有良师指导，能告知他们成功解决软件设计和编码的各种成功方法。他们学习了如何区分设计的好坏，如何辨别健壮的实现与不可靠的实现。他们的导师还对如何在编程领域谋得良好的职业生涯给出了建议，而且他们还了解了如何才能获得成功和认可，应该接手哪些项目，应该避免参与哪些项目。
有良师的指导效果非常好，而且很有必要。如果有两个程序员，并给其中一个指派了好的导师，有人指导的程序员将不断进步，而没有人指导的程序员则可能会手足无措地原地踏步。
通过反面例子学习
不过，如果没人指导的程序员了解如何“自救”，他便能够发现学习编程实践技巧的很多其他方法。通过阅读他人编写的代码就是一种所有程序员在其职业生涯中都可以采用的方法，而几乎所有的新程序员在进行代码维护时都不得不进行这样的工作。
在我早期所做的一份编程工作中，在维护我的新上司编写的代码时，我学到了不应该做什么。这个上司是一家正在快速发展的小公司的老板之一，但并不是一个好老师。我们主要用 FORTRAN 进行编码，我进这家公司的时候，他已经编写了很多代码。他使用的变量名称都是 a、b、c、aa、bb、cc，诸如此类。我那时刚开始学习 FORTRAN，但即使这样，我也明显地觉得这种方式很不好。他还通过将这些变量放入 FORTRAN 公共代码块中，使其成为全局变量，这很明显是太糟糕了。这样做就不能在源代码树中搜索变量以进行重命名，也不能对它们进行任何处理。据我所知，当时并没有良好的 FORTRAN 集成开发环境可用于帮助处理这种情况，因此我对很多这样的代码进行了手工清理，并保证编写更好的新代码——从良好的变量名称开始。
从这个反面例子中，我们知道了：要编写可读性好的代码；包、类、方法和变量的名称要反映出其功能；避免采用最流行的命名约定，等等。在上个世纪 90 年代，我尝试过在 C++ 中使用匈牙利标记法，而现在我非常赞同在 Java™ 标识符前使用 m_。对这些构件进行适当的命名是进行良好编码的基础。恰当的命名不但有助于构建良好稳健的体系结构，还可以帮助其他人理解您的代码。但要进行恰当地命名并不容易，Tim Ottinger 就此给出了一些不错的技巧。
认识铁三角的影响
当然，程序员可以进行一定的工作，以提高项目的效率。但也同样有一些东西经常超出我们的控制范围，从而使得项目的成功完成颇具挑战性。请随时谨记铁三角，即使您的管理团队并没有对此引起足够的重视，也不可大意。铁三角描述项目的三个方面，通常定义为时间、资源和功能，这三方面共同影响项目的质量。程序员通常不能控制项目的这三方面，这些方面通常由市场营销部门、公司股东、重要客户等其他人确定。尽管程序员不能参与设定项目的这些方面的过程，但需要在项目进行过程中对项目的铁三角加以注意，特别在经常出现问题时更要如此。以下内容有助于对这方面的了解：
- 通过发现软件开发过程中效率低下的地方，使程序员和编程团队成功实现目标，摆脱由于要求严格和资源不足带来的限制。
- 从专业的角度出发，告知程序员可能是继续进行下一步工作的时候了。
- 至少能够说明，为什么尽管大家都在努力工作、倾力而为，但要成功完成项目还是显得如此难。
我在那家小公司工作时，该公司的管理层与全世界最受认可的一家医疗保健单位谈成了一项大的业务。我们要在一年内为他们提供所需的软件功能；需要雇佣一些新的程序员；这的确令人兴奋。但随后一些现实的问题开始显现出来。通过需求分析，发现一年时间明显不够。然后我们又发现我们所知道的需求并不完整——他们将“逐步提出”。该公司没有雇佣新程序员，但却引入了新的项目需求，员工根本就没有办法处理全部的工作。
在业务达成后，我决定将项目时间延长至三年，随后又增加了四年——总共用了七年时间——最后终于交付了最初计划的功能代码。宣布这项业务达成后的一年，这家小公司被一家大公司收购了；由于铁三角的影响，在业务达成之前，这个项目就是金块，而在几年之后，却变成了臭鸡蛋。
保持简单
在满足需求的同时，使您的软件设计尽可能简单。这可能会要求放弃初期工作的成果，总结早期工作的经验教训，然后重新开始。这并不意味着在项目结束时才进行设计。在项目处于设计阶段时就应该编写代码。即使不负责进行实现，也要考虑到实现时的情况。理解过于复杂的设计（以及据此进行编码）需要花额外的时间和精力。作为程序员，我们处于业务需求和创建良好的设计与编写出色的代码之间的中坚地带。雇佣您进行编程工作的公司需要尽可能快地拿到软件，以达成交易，获得收益。有效简化软件设计的能力需要多加实践才能获得。但这值得化精力去学习，因为从长远来看，这将节约时间和工作的投入量。
与他人进行良好的合作
程序员是团队的一员，成功的程序员要能够与其他人进行良好地合作；如果在这方面存在不足，可能会妨碍某些非常出色的人才的职业发展，因为他们很有可能被排除在较高层次的决策过程之外，而总又不能与决策者进行良好地合作，但他们带来的价值需要掩盖他们在组织方面的不足、羞涩或令人生厌的性格。对于我们大部分人而言，我们的才能并不能抵消这方面的缺点，因此我们必须培养良好的团队工作能力：
- 首先，在本地编译代码，以避免破坏生产版本。
- 其次，请求他人进行代码检查时，要虚心接受批评，并从别人的评审中获得思想上的最大提高。
- 在别人请您进行评价时（而非自己想这样做时），提出一些建议，以进一步加强团队合作。
- 对他人的出色工作予以称赞（因为别人也能出色地完成工作），从而使团队合作达到一个新的层次。
- 在适当时间主动承担不甚舒适的工作（那些资深开发人员所进行的工作），特别在需要早起（而您夜里工作很晚）或晚归（如果您习惯早起）时，从而最终发展成为优秀的团队成员。组织有时喜欢自己的员工有危机感。
知道什么令您真正快乐
现在，软件架构师的角色是很多程序员梦寐以求的。如果问从事入门级工作的年轻程序员他们希望做什么，您会发现他们希望成为架构负责人，借助其很多年开发实践积累的经验确定整个软件组织的方向。为什么初级程序员认为自己会成为架构师呢？因为他们并不真正了解架构师角色的意义。
他们认为软件架构师仅仅借助自己的技术权威领导一个团队或更大的组织，以正确的方式设计软件，选择恰当的技术工具，如此等等。但架构师除了是技术角色之外，也是行政角色。很多技术专家在发现自己必须谈判、和解、做生意、回复每天 200 封电子邮件，而完全放弃埋头编程的快乐时，他们就不会太高兴了。
对于那些希望进行人员管理工作的程序员而言，他们的命运也与此类似。当出现这种情况时，真正爱好编程的人应停下来认真地分析一下当时的情形。是否由于他们不是一个好的程序员才转向管理？是否因为他们擅长编程，并希望从编程团队的角度进行管理，才这样做？作为编程管理人员，他们日常必须进行哪些工作？最重要的是，他们做这个工作时会快乐吗？
学习技能，了解各种角色，了解自己喜欢什么和适合自己的位置。然后，勾画出一条美丽的人生轨迹。
关于作者
Scott Johnson 从事专业编程工作 22 年。他目前在 WebSphere Application Server 的开发团队工作，是 JavaServer Pages 容器团队的负责人、WebSphere 基础体系结构委员会的助理架构师，同时还是任 JSR 245、JavaServer Pages 2.1 规范的 IBM 代表。
it知识库：Scott Johnson：做一个快乐一生的程序员，转载需保留来源！
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
