Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

明星软件工程师的10种特质 #13

Open
lietoumai opened this issue Sep 21, 2017 · 0 comments
Open

明星软件工程师的10种特质 #13

lietoumai opened this issue Sep 21, 2017 · 0 comments

Comments

@lietoumai
Copy link
Owner

lietoumai commented Sep 21, 2017

如今,每家公司都似乎成了科技公司。从软件创业公司到投机性投资公司、制药巨头和媒体巨头,它们都越来越多地加入到软件业务行列。

代码质量不仅成为了一个必需品,更成为了一个竞争优势。因为众多公司围绕软件而竞争,开发软件的人——软件工程师正显得越发重要。但是,你该如何发现那种百里挑一的程序员呢?在本文中,我们简明扼要地列出了明星开发人员的10种特质。

  1. 热爱编程
  2. 完成事情
  3. 持续重构代码
  4. 使用设计模式
  5. 编写测试
  6. 善用现有代码
  7. 专注可用性
  8. 编写可维护的代码
  9. 能用任何语言编程
  10. 知晓基本的计算机科学

==================================================================

  1. 热爱编程
    编程是一种为了满足兴趣而心甘情愿去做的劳动(Programming is a labor of love)。和其他任何职业一样,唯有真正的热情,才能完成真正的伟大事情。这里有个误解,认为编写代码是机械化并纯科学性的。事实上,最优秀的软件工程师是工匠,他们能把能量、独创性和创造力融入到每一行代码中。伟大的工程师知道何时该把代码雕琢至完美,知道何时把大型系统像拼图一样组装到一块。热爱编程的工程师从构建软件中获得满足,就好比一位作曲家在完成一部交响乐后而欣喜若狂。正是兴奋感和成就感,才造就了喜爱编程的明星工程师。

  2. 完成事情
    有很多技术人员只谈论软件而不编写代码(只说不做型)。而伟大软件工程师会真正去编码,这也是他们最为重要的品质之一。他们是实际做事的人。聪明人都知道,解决问题的最佳途径是直面问题,而不是花上数周来设计复杂又不必要的架构和函数库。优秀工程师应当会问:解决手头问题的最简单方法是什么?最近的软件开发方法——敏捷实践,正是专注那个。它的思想是,把复杂的项目拆分为短小的迭代,每个迭代只关注一小部分的增量功能。因为每个迭代对应的编码只需要数周,所以功能易于管理并简单。

  3. 持续重构代码
    编码很像雕刻。要像艺术家一样不断完善自己的作品,软件工程师也要通过可能的最佳方式来持续完善自己的代码,以达到目标。重新塑造代码的原则称为“重构”,Martin Fowler在他的创意书中有相应描述。重构背后的原始思想是:改善代码而不改变其功能,移动调整部分代码以确保系统不腐,还有确保系统完成基于当前需求该完成的事。持续重构可以让开发人员解决另一个著名的问题——“黑盒遗留代码”(这个问题基本无人想触及)。

几十年的软件开发文化要求我们,不应该去改变正常工作的东西。然而,随着时间推移,问题是我们成为了老旧代码的奴隶,老旧代码变得不稳定和不兼容。而重构正好可以改变这一状况,因为我们是代码的主人,不是它的奴隶。重构在工程师和代码之间建立起持续的“对话”,并带来所有权、确定性、自信心和系统的稳定性。

千万不要成为老旧代码的奴隶。如果代码是他人所写,或许你可以轻易推脱责任。但大多数时候,那些代码是自己所写,要拿得起放得下,旧代码该埋时,就把它埋了!

  1. 使用设计模式
    自从所谓的“四人帮”(Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides)发表他们的著作——《设计模式》后,全世界的软件工程师一直都在讨论模式。在我们所处世界,不管是自然界还是人类行为,模式无处不在。软件工程自然也不例外。模式就是不断重现的跨语言跨系统的场景和机制。一位优秀的工程师通常能识别并利用模式,而不是受制于模式。工程师不应(强制)让系统去适应某种模式,而需发现在系统中使用模式的时机(恰当使用模式)。在使用模式来确保正确性时,应借鉴利用前人的智慧结晶,使用以前能正当解决特定工程问题的方法。但请切记:模式不是万灵药;不要为了使用设计模式而使用设计模式。

  2. 编写测试
    曾有段时间,软件工程师们认为测试不值得他们去做。然而,如果你不做测试,你怎么能确保代码就能正常工作呢?敏捷实践中的“单元测试”已获得普遍认可,因为它注重编写测试来反映代码是否有效。随着系统增大,测试也随之增大。有经验的工程师知道并了解测试的价值所在,因为测试的目的就是创建一个能正常运作的系统。优秀的工程师通常会确保出现过一次的Bug不会再出现第二次。但优秀的工程师也知道,不应该浪费时间写那些琐碎或多余的测试,而需要专注测试各个组件中的核心部分。

  3. 善用现有代码
    “重新发明轮子”一直是软件行业中的巨大问题之一。从发明新语言到从写函数库,忽视并重写那些已经存在并已能工作的奇怪驱动力,已经造成大量软件开发的失败案例。一位明星工程师会专注三种基本类型的重用:第一,内部基础架构的重用,相应代码是他自己或同事编写的;第二,使用第三方的函数库,比如JDK。最后,研究使用某些大型网络服务商提供的相应服务,比如Amazon。总之,正确善用现有的代码,使得软件工程师能真正专注于最为重要的事情上——应用程序本身。

  4. 专注可用性
    优秀的工程师通常都专注于用户。无论用户是企业还是个人,无论是为消费型的软件公司还是投资银行,需要关注的都是可用性。用户如何和系统交互?系统是否提供一种简单、直接和平稳的操作体验?有种说法,因为软件工程师是技术人员,他/她和“用户如何与系统交互”没有关联,这种说法严重错误。优秀工程师努力工作是为了什么?不正是让系统简单并易于使用。他们无时无刻都会想到用户,不会尝试去发明那些令人费解,只有极客才能理解并欣赏的东西。

有些时候,一些软件工程师过于投入,反而忘记所编写的程序/软件,是供他人使用,不是做给自己看的“艺术品”。所以,在软件开发过程中,一直要把“用户”放在心中。

  1. 编写可维护的代码
    软件开发界的另外一个小秘密是:编写优秀代码和糟糕代码所花费的时间是一样多。一位训练有素的工程师,他/她会从第一行代码开始就考虑可维护性和代码的演化。没有任何理由编写“丑陋”的代码、长达数页的函数,或是稀奇古怪的变量名。优秀的工程师编写代码会遵循命名惯例,代码编写紧凑、简单和不过度炫耀聪明。代码的每一行,都应恰如其分地展现出其原有目的。在给不便理解的代码(块)合理注释时,别忘了命名规则。清晰明了的函数名和变量名可以让代码不言而明。

在编码时,有些程序员会有这种心态:过一会儿再来修改或完善某部分代码或某条语句。但谁知这一“过一会”竟然是“一天”、“一周”、“一个月”或“一年”,甚至以后根本就没机会再回头修改。所以,尽量别妥协写出暂时堪用的代码。否则,不仅不会节省开发时间,也可以阻碍整个进程。当然也不利于后续维护人员的工作。

  1. 能用任何语言编程
    优秀的软件工程师或许有自己一门特别钟爱的编程语言,但从不会执迷于当中。如今已有很多优秀的编程语言,也就是说,如果你只会使用其中一门语言,说明你缺乏多样性。你可以用Java、C#或C++编写任何现代软件,可以用PHP、Perl或Ruby编写任何网站的后台。简而言之,编程所用语言,远远没有语言相应的函数库重要。优秀的工程师能够认知到这一点,并愿意去学习新语言、新函数库和构建系统的新方法。

  2. 知晓基本的计算机科学知识
    最后,但肯定不是优秀工程师最不重要的特质就是:扎实的基础。优秀的工程师或许并没有计算机科学的学位,但他/她必须知道基础——数据结构和算法。如果不知道哈希表,或者不知道链表和数组之间的差别,你如何构建一款大型的软件?。这些都是每位从事软件开发的开发人员应当知道的。算法也同样重要,从二分查找到各种排序,到图形遍历,一位明星工程师必须知道并内在消化这些基础东西。因为这些基础就是你在构建任何现代软件中做抉择时的必备品。

结束语

以上就是区分伟大软件工程师的诸多特质。其中讨论的“热情”,是非常重要的。代码重用、设计模式、基础数据结构和算法都是必须知道的,而敏捷实践中的重构和单元测试则有助于工程师应对复杂的软件。尤为重要的是,明星工程师相信简洁和常识。也正是这些信念,帮助他们成功构建当今世界所需的看似不可能又错综复杂的系统。

原文出处:http:https://www.readwriteweb.com/archives/top_10_software_engineer_traits.php

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant