天天看点

每个软件工程师应该知道的十件事

请花点时间看一下我们全新的Java Resource Collection 。

以下十大清单收集了我在过去18年中作为IT专业人员学到的一些重要知识。 这是一个非常个人化的选择,不一定反映软件工程组织的意见。

尽管我试图将更重要的事情放在首位,但是列表中没有严格的排名。技术和业务知识对年轻的软件工程师来说更重要,而软技能对于高级软件工程师则越来越重要。

1)情绪智力基础

我们几乎所有人都与很多人一起工作。 大学毕业后的第一年,我有机会从事一项明确的大任务,而没有任何客户,并且需要与同伴们进行很多交谈。 简直是天堂! 只需完成一个复杂的任务,并从编译器中获得乐趣。 后来,麻烦开始于更复杂的任务,越来越多的责任以及与我根本不喜欢的人一起工作的需要。

在我的职业生涯中,我参加了一些所谓的软技能课程。 在这些损伤中,我学到了很多有关沟通技巧,谈判策略和团队动力的知识。 所有这些都是机械工具或心理学理论。 众所周知,但是情商的概念却有所不同。

Wikipedia对情绪智力的定义始于句子“情绪智力(EI)是识别,评估和控制自己,他人和群体情感的能力。” [1]这句话的重要关键词是情绪。 情绪智力描述了情绪在我们生活中的作用。

几年前,我参加了与一些高级管理人员举行的项目会议,老板的老板对我说了一些话,就像“嘿,马库斯,您忘了及时给我XYZ信息!”。 我感到尴尬,像个罪魁祸首,并向他解释说他不对。 结果是我赢得了与他的讨论,并且那天我失去了公司的重要支持者。 我的反应是愚蠢的,毫无价值。

是的,我赢得了一场战斗,但输掉了这场战争。

这场灾难的根本原因是我网站上的自动反应以及这个高级管理人员与我之间的相互影响。 有了更好的自我感觉和自我调节能力,我将能够以更好的方式处理这种情况。

如果您有时会开会,对自己说:“哦,该死! 我为什么这么说?”,也许学习一些有关情商和自己的知识是一个好主意。

我最喜欢的情绪智力分类是:

  • 人际智能描述了人与人之间建立积极关系和/或良好沟通的能力。 这意味着您了解人们的堕落和需求。 人际智能的主要能力是:
    • 自我感觉:

      –认识自己的感觉,情绪和反应

      –正念以获得更好的认识

    • 自我调节

      –控制当前内部状态

      –想到自己的自动反应并打断

    • 个人领导

      –了解并领导自己的个性

      –关心自己的优点和缺点

  • 人际交往能力描述内省和自我反思能力。 能够控制自己的反应,了解自己,自己的情绪以及自己的弱点或优点。 人际交往的关键能力是:
    • 同情

      –认识他人的感受和情感

      –以适当的方式表示同情

    • 减少自动互惠效应

      –引起他人的自动反应并打断(如果需要)

    • 建立关系

      –与他人建立中长期关系

2)了解客户的业务

在不深入了解目的或用途的情况下,如何设计和实现好的软件? 答案很简单:“如果您不知道具体内容,则无法决定如何做。” 对客户和/或用户业务的深入了解将导致更好的要求,设计,实施和测试。大多数软件功能不会带来任何业务价值。 挑战在于选择可创造业务价值的功能。 您对业务越了解,实施最佳系统的可能性就越高。

3)每个主流开发范例至少一种编程语言

讨论什么是最好的编程语言具有宗教性质,更多的是信仰问题。 我不想在此宣扬自己对最佳语言的个人信念,但重要的是:“学习更多的编程语言,每种主流开发范例至少要使用一种。”

  • 过程编程语言(C,COBOL,PL / I,FORTAN等)
  • 面向对象的编程语言(Smalltalk,Java,C ++等)
  • 功能性编程语言(Erlang,Clojure,F#等)
  • 声明式编程语言(SQL,XSLT,正则表达式等)

知道至少一种多范例编程语言(例如Python,Java,C ++或C#)是一个好主意。 您可以在Web [2]中找到许多按类型或其他类别列出的编程语言列表。

根据您的行业,个人喜好和日常任务,您应该选择编程语言的前1个列表。 了解它们,并尝试至少定期使用其中的3种。 俗话说:“如果您唯一的工具是锤子,那么您所有的问题都会像钉子一样”对于开发范例而言尤其如此。

4)了解您的工具

有大量工具专门针对不同学科,例如:需求管理,软件和数据库设计,软件配置管理,构建和部署,持续集成,开发,调试,配置文件,代码分析或测试。

应当提到的是,来自基础架构/运营部门的专家还拥有具有有趣功能的工具箱,例如网络监视,网络分析,操作系统分析,渗透测试,日志文件分析,数据库性能调整。

软件工程师不能完全了解所有工具,但是他/她应该了解关键概念和基础技术。 知道正确的工具以及使用方法可以提高生产率和质量。花一些时间来学习工具。

5)标准数据结构,算法和Big-O-表示法

当我说要开发软件时,绝对有必要了解很多数据结构和算法。 这样做的原因是缺少标准实现。 如今,大多数语言都具有用于容器,排序和其他操作的综合库。

了解更多仍然有意义。 主要有两个原因:

  • 正确使用标准库
  • 有时您需要单独的解决方案。

您应该能够分析自己的代码或其他代码。 The Big-O-Notation是描述根据数据数量来描述预期的时间或内存消耗的标准方法。 [3]

如果难以进行手动分析,则只需建立一个微型基准并使用不同大小的测试数据进行测量即可。 在绘图中绘制它,并找到可能的模型函数的良好拟合。 总比没有好。

6)未经充分测试就不要相信代码

十年前,我信任我的代码。 为什么不? 经过8年的C ++工作,他们拥有出色的技能和丰富的经验。 我刚刚进行编码,测试,一切工作正常。 但是多年来,我犯了很多错误。 由于这些错误,我失去了对自己和他人代码的信任。

今天,我不信任代码,直到代码通过:

  • 单元测试,
  • 集成和系统测试
  • 使用实际数据检查性能和内存,
  • 静态代码分析,
  • 测量测试的代码覆盖率,
  • 负载和压力测试以及
  • 同行评审。

这听起来超出了设计水平,但是您必须在开发或维护期间花费时间。 我喜欢以高质量进行一次工作,而不是花时间进行故障排除。

7)项目管理,精益管理和敏捷概念的基础

即使您不喜欢担任项目经理,您也需要团队合作,至少必须组织自己的工作。 要与技术领先者相处,您应该了解他们的措辞和思维方式。 今天,每个人都可以担任项目经理,Scrum主管或技术主管。 花时间学习管理知识,因为有时您应该管理这些人。

一个很好的例子是工作量估算。 我的个人经历说,如果您向软件工程师询问某项任务的工作量,那么在80%的情况下,您会大大低估该工作量。 软件工程师倾向于只估计好情况而不会出现意料之外的问题。 这会导致延迟和/或质量差,因为经常会发生意外的问题。另一个问题是“完成”的定义。 项目经理意味着一切都已完成,并且开发人员常常只估算技术方面的东西。

上周我有这样的情况。 开发人员估计只有一周的工作时间。 经过全面的计划,我们看到了几个月的努力。 开发人员估计了实施时间,却忘记了估计文档,安全概念,数据保护问题,与工人委员会的协调,审查,项目管理工作,部署等。

8)软件开发的关键指标

了解您的软件,流程,团队和您自己的工作中发生了什么。 控制一些您无法计数的东西非常困难。 我鼓励您提出问题,并尝试找到一个现实的方法作为答案。 然后,您可以获取目标值,进行工作,然后确定目标结果是否奏效。 重要的是“现实世界的措施”一词。

在软件工程中,我们发现许多模糊的度量和/或派生的度量。 例如所谓的可维护性指数(MI) [4] :

MI = 171 – 5.2 x ln(avgHV)– 0.23 x avgCC(g')– 16.2 x ln(avgLOC)+ 50 x sin(sqrt(2.4 x perCM))

其中HV是Halstead体积,CC是圈复杂度,LOC是代码行,perCM是注释行的百分比。 这不是我所说的现实世界的衡量标准,我也不理解。

我的建议很简单:“永远不要使用您不完全理解100%的度量标准。 在某些时候,只要花一些毛钱就可以了(请参阅精益IT如何帮助减少由于软件开发中断而造成的浪费? )。

9)最后缺陷的根本原因

也许您的最后一个错误没有那么严重,但是要了解更多有关根本原因和负面影响的信息,您应该对其进行分析。

  • 根本原因是什么?
  • 在哪个开发阶段出现了软件错误?
  • 如何更早地检测到它?
  • 工具会帮助避免这种情况吗?
  • 规则会有助于避免这种情况吗?
  • 这是资格问题吗?
  • 是工作环境(大量中断等)的根本原因?
  • 这是文档问题吗? 还是沟通问题?
  • 修复它的成本是多少?
  • 受影响的组件中是否存在更多错误?
  • 测试用例是否足够好/完整?

您会看到很多问题,列表仍然不完整。 最重要的一点是,找到随着时间的推移变得更好的根本原因。 这适用于您自己的资格和工作方式。 它为您的团队工作。 您只需要问一些问题。

10)了解基础架构

我在IT领域度过了最初的10年,而对基础架构的思考却没有超过一分钟。 没必要,因为我不在企业环境中工作。 目前,我在一家银行工作(对这些雷曼兄弟的股票感到抱歉,没人问我)。 在银行中,您有很多这样的基础架构人员。 他们实际上是软件工程师的不同形式。 但是,我不想在这里讨论与它们相处的差异和可能性。

重要的是他们的语言。 基础设施人员在“信息技术基础设施库(ITIL)”中讲话。 花至少几天时间学习此ITIL术语。 [5]有些术语与开发人员的用法完全不同。

第二个重要的事情是,在基础架构中,人们比开发人员更加专业。 有时,开发人员只有一个问题,需要五个基础架构专家来回答。 ITIL的东西可能是基础设施之间人们之间的粘合剂。

进一步阅读

  • http://en.wikipedia.org/wiki/Emotional_intelligence
  • http://en.wikipedia.org/wiki/Categorical_list_of_programming_languages
  • http://www.leepoint.net/notes-java/algorithms/big-oh/bigoh.html
  • http://www.virtualmachinery.com/sidebar4.htm
  • http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

参考:在Software Engineering Candies博客上, 每个软件工程师都应从我们的JCG合作伙伴 Markus Sprunck了解到的十件事 。

翻译自: https://www.javacodegeeks.com/2012/05/top-10-things-every-software-engineer.html