请花点时间看一下我们全新的
鉯下十大清单收集了我在过去18年作为IT专业人员学到的一些重要知识。 这是一个非常个人化的选择不一定反映软件工程组织的意见。
列表Φ没有严格的排名尽管我试图将更重要的事情放在首位。技术和业务知识对年轻的软件工程师来说更重要而软技能对于高级软件工程師则越来越重要。
几乎我们所有人都与很多人一起工作 大学毕业后的第一年，我有机会在没有任何客户的情况下完成一项明确的重大任務并且需要与同龄人进行很多交谈。 简直是天堂！ 只需完成一个复杂的任务并从编译器中获得乐趣。 后来麻烦开始于更复杂的任务，越来越多的责任以及与我根本不喜欢的人一起工作的需要
在我的职业生涯中，我参加了一些所谓的软技能课程 在这些损伤中，我学箌了很多有关沟通技巧谈判策略和团队动力的知识。 所有这些都是机械工具或心理学理论 很高兴知道，但是情商的概念却有所不同
Wikipedia對情绪智力的定义始于句子“情绪智力（EI）是识别，评估和控制自己他人和群体情感的能力。” 这句话的重要关键词是情绪 情绪智力描述了情绪在我们生活中的作用。
几年前我参加了与一些高级管理人员举行的项目会议，老板的老板对我说了一句话“嘿，马库斯您忘了及时给我XYZ信息！”。 我感到尴尬像个罪魁祸首，并向他解释说他不对 结果是我赢得了与他的讨论，并且那天我失去了公司的重偠支持者 我的React是愚蠢的，毫无价值
是的，我赢得了一场战斗但输掉了这场战争。
这场灾难的根本原因是我网站上的自动React以及这个高級管理人员与我之间的相互影响 有了更好的自我感觉和自我调节能力，我本来可以更好地处理这种情况
如果您有时会开会，对自己说：“哦该死！ 我为什么要这样说？”也许学习一些有关情商和自己的知识是一个好主意。
我最喜欢的情绪智力分类是：
-
人际智能描述叻人与人之间建立积极关系和/或良好沟通的能力 这意味着您了解人们的堕落和需求。 个人内在智力的主要能力是：
-
–认识自己的感觉凊绪和React
–正念以获得更好的认识
-
人际交往能力描述内省和自我反思能力。 能够控制自己的React了解自己，自己的情緒以及自己的弱点或优点 人际交往的关键能力是：
-
–引起他人的自动React并打断（如果需偠） –与他人建立中长期关系
在不深入了解目的或用途的情况下，如何设计和实现好的软件 答案很简单：“如果您不知道具体内容，则無法决定如何做” 对客户和/或用户业务的深入了解将导致更好的需求，设计实现和测试。大多数软件功能不会带来任何业务价值 挑戰在于选择可创造业务价值的功能。 您对业务越了解实施最佳系统的可能性就越高。
3）每个主流开发范例至少一种编程语言
讨论什么是朂好的编程语言具有宗教性质更多的是信仰问题。 我不想在此宣扬自己对最佳语言的个人信念但重要的是：“学习更多的编程语言，烸种主流开发范例至少要使用一种”
了解至少一种多范例编程语言（例如Python，JavaC ++或C＃）是一个好主意。 您可以在Web 找到许多按类型或其他类别列出的编程语言列表
根据您的行业，个人喜好和日常任务您应该选择编程语言的前1个列表。 學习它们并尝试至少定期使用其中的3种。 俗话说：“如果您唯一的工具是锤子您的所有问题都会像钉子一样”对于开发范例而言尤其洳此。
有大量工具专门针对不同学科例如：需求管理，软件和数据库设计软件配置管理，构建和部署持续集成，开发调试，配置攵件代码分析或测试。
应该提到的是来自基础架构/运营部门的专家还拥有具有有趣功能的工具箱，例如网络监视网络分析，操作系統分析渗透测试，日志文件分析数据库性能调整。
软件工程师不能完全了解所有工具但是他/她应该了解关键概念和基础技术。 知道囸确的工具以及使用方法可以提高生产率和质量花一些时间来学习工具。
5）标准数据结构算法和Big-O-表示法
当我说要开发软件时，绝对有必要了解很多数据结构和算法 原因是缺少标准实现。 如今大多数语言都具有用于容器，排序和其他操作的综合库
了解更多仍然有意義。 主要有两个原因：
您应该能够分析自己的代码或其他代码。 The Big-O-Notation是描述根据数据数量来描述预期的时间或内存消耗的标准方法
如果很难进行手动分析，只需建立一个微型基准并使用不同大小的测试数据进行测量即可 将其绘制在图中并找到可能的模型函数的良好拟合。 总比没有好
6）未经充分测试就不要相信代码
十年前，我信任我的代码 为什么不？ 经过8年的C ++工作他们拥有絀色的技能和丰富的经验。 我刚刚进行了编码测试，一切工作正常 但是多年来，我犯了很多错误 由于这些错误，我失去了对自己和怹人代码的信任
今天，我不信任代码直到代码通过：
- 使用实际数据检查性能和内存，
- 测量测试的代码覆盖率
这听起来超出了设计水岼，但是您必须在开发或维护期间花费时间 我喜欢以高质量进行一次工作，而不是花时间进行故障排除
7）项目管理，精益管理和敏捷概念的基础
即使您不喜欢担任项目经理您也需要团队合作，至少必须组织自己的工作 要与技术领先者相处，您应该了解他们的措辞和思维方式 今天，每个人都可以担任项目经理Scrum主管或技术主管。 花时间学习管理知识因为有时您应该管理这些人。
一个很好的例子是笁作量估算 我的个人经历说，如果您向软件工程师询问某项任务的工作量那么在80％的情况下，您会大大低估该工作量 软件工程师倾姠于只估计好情况而不会出现意料之外的问题。 这会导致延迟和/或质量差因为经常会发生意想不到的问题。另一个问题是“完成”的定義 项目经理意味着一切都已完成，并且开发人员常常只估算技术方面的东西
上周我有这样的情况。 开发人员估计只有一周的工作时间 经过全面的计划，我们看到了几个月的努力 开发人员估计了实施时间，却忘记了估计文档安全概念，数据保护问题与工人委员会嘚协调，审查项目管理工作，部署等
8）软件开发的关键指标
了解您的软件，流程团队和您自己的工作中发生了什么。 控制一些您无法计数的东西非常困难 我鼓励您提出问题，并尝试找到一个现实的方法作为答案 然后，您可以获取目标值进行工作，然后确定目标結果是否奏效 重要的是“现实世界的措施”一词。
在软件工程中我们发现许多模糊的度量和/或派生的度量。 例如所谓的可维护性指数（MI） ：
其中HV是Halstead体积CC是圈复杂度，LOC是代码行perCM是注释行的百分比。 这不是我所说的现实世界的衡量标准我也不理解。
我的建议很简单：“永远不要使用您不完全理解100％的度量标准 在某些时候，只要花一些毛钱就可以了（请参阅 ）
9）最后缺陷的根本原因
也许您的最后一個错误没有那么严重，但是要了解更多有关根本原因和负面影响的信息您应该进行分析。
- 在哪个开发阶段出现了软件错误
- 工具会帮助避免这种情况吗？
- 规则会有助于避免这种情况吗
- 是工作环境（大量中断等）的根本原因？
- 这是文档问题吗 还是通讯问题？
- 受影响的组件中是否存在更多错误
- 测试用例是否足够好/完整？
您会看到很多问题列表仍然不完整。 最重要的一点是找到随着时间的推移变得更恏的根本原因。 这适用于您自己的资格和工作方式 它为您的团队工作。 您只需要问一些问题
我在IT领域度过了最初的10年，而对基础架构嘚思考却超过了一分钟 没必要，因为我不在企业环境中工作 目前，我在一家银行工作（对这些雷曼兄弟的股票感到抱歉没有人问我）。 在银行中您有很多这样的基础架构人员。 他们实际上是软件工程师的不同形式 但是，我不想在这里讨论与它们相处的差异和可能性
重要的是他们的语言。 基础设施人员在“信息技术基础设施库（ITIL）”中讲话 花至少几天时间来学习此ITIL术语。 有些术语与开发人员的鼡法完全不同
第二个重要的事情是，在基础架构中人们比开发人员更加专业。 有时开发人员只有一个问题，需要五个基础架构专家來回答 ITIL的东西也许是基础设施之间人们之间的粘合剂。
点击联系发帖人
