软件开发公司关键词
在软件开发中，有几个术语使用不当或不正确。 在这篇文章中，我研究了其中一些术语以及滥用这些术语带来的负面影响。
“敏捷”
敏捷宣言发起了一场运动，引起了许多软件开发人员的共鸣，这些开发人员对普遍的软件开发方法的效率低下和不足感到沮丧。 不幸的是，敏捷宣言的相对简单的概念以许多不同的方式被解释，改变，传福音，商业化和出售，以致于难以唯一地描述敏捷。 对某些人而言，敏捷成为“无文档”的代名词，而对另一些人而言，敏捷则意味着无需任何处理即可直接进行编码。 现在，敏捷已经出售了许多不同的方法和实践，以至于很难描述什么使敏捷变得与否。
敏捷含义的多种解释产生了一些负面影响。 在不了解敏捷的情况下实施所谓的敏捷实践可能会导致失败，这些失败归咎于敏捷，但是哪些失败与敏捷几乎没有关系。 对敏捷的不切实际的期望及其对发展的影响会导致不可避免的失望，因为仍然没有灵丹妙药 。 很难通过多种不同的解释来帮助新开发人员，刚接触敏捷的开发人员，经理，客户和其他利益相关者理解敏捷是什么以及敏捷对他们是否合适。 几年前，当我在一个敏捷狂热者的一次演讲中，他认为敏捷是成功的一切，而不是不成功的一切。
对我而言，“敏捷”是指与敏捷宣言中概述的价值观（个人和互动，工作软件，客户协作以及对变化的响应）紧密匹配的过程和方法。 还有其他方法和方法可能是有用且积极的，但是如果它们不受这些价值观的启发，那么我很难听到它们被称为“敏捷”的意思。
“休息”
罗伊·菲尔丁 （ Roy Fielding ）的论文《 建筑风格》和《基于网络的软件体系结构设计》普及了“ 代表性状态转移 （REST）”一词。 不幸的是，许多人已经交替使用REST和HTTP，并且在此过程中使有关REST体系结构样式和超文本传输协议 （HTTP）的讨论变得混乱 。
从历史的角度很容易看出为什么经常将REST和HTTP互换使用 。 REST将HTTP已经提供的功能作为其体系结构样式的重要部分，而其他流行的体系结构样式和框架正在尽一切可能隐藏或抽象HTTP细节。 REST利用HTTP的无状态特性，而其他人则尝试使用状态包装HTTP。 尽管REST当然在提高对HTTP的认识方面发挥了主要作用，但REST不仅限于HTTP。 我发现许多人将REST和HTTP视为一体，却不理解REST中的HATEOAS概念。 HATEOAS代表超媒体，它是应用程序状态的引擎，指的是应用程序状态的概念体现在服务器与客户端之间而不是客户端之间交换的超媒体中。
“重构”
我已经知道，当客户和经理听到开发人员指出他或她将“重构”某些东西时，他们都感到恐惧。 原因是“重构”通常意味着开发人员计划更改代码结构，并在此过程中“改善”或“修复”行为。 重构被认为是对代码的改进，不会影响软件的结果，但会导致更易于维护的代码。 太多的开发人员被诱使“在代码中时”进行其他更改以更改结果。 即使当情况变得更好时，这些更改也不符合重构的精神，因此，当这些更改导致现有功能的中断时，就会导致从不好的角度看待“重构”。
全面的单元测试和其他测试可以帮助确保重构不会改变任何预期的行为，但是开发人员还应该清楚地了解目标是使用改进的代码结构（重构）来维护当前功能还是实际更改/改进功能，并且仅使用术语适当时进行“重构”以避免混淆。
“过早的优化”
我通常同意现在著名的报价单背后的原则：“过早的优化是万恶之源。” 但是，我对此的解释是，不应尝试编写较少可维护性或可读性较低的代码，以期获得较小的预期性能提升。 但是，正如我在《 过早的优化不是这样》中所发表的那样 ，有时仅由于不具有良好的体系结构和高级设计决策，而因为它们具有相关的性能优势，才将该术语用作理由。 某些架构决策很难在以后进行更改，并且确实需要考虑性能。 类似地，即使在实现级别，有时性能更好的代码与性能较低的代码一样易读易写，因此没有充分的理由不编写性能较好的代码。
NoSQL
NoSQL一词对于一类数据库可能是一个不幸的词，可能最好用“ Not Relational”来标记。 由于许多“ NoSQL数据库”都采用了SQL（不采用关系模型），因此尝试了诸如“不仅仅是SQL”之类的替代术语。
“开源”
“开源”一词经常引起人们对所涉及软件在“自由”（自由/ 言论自由 ）方面是否“免费”和/或在没有货币价格的情况下（免费/ 免费啤酒 ）是否“自由”感到困惑）。 关于 “开源”和“自由软件”之间的细微差异 ，甚至可能会感到困惑 。 对我来说，“开源”是指我可以查看并根据需要进行修改的源代码。
JavaScript
随着JavaScript的日益普及，其名称选择不当似乎并没有像以前那样使许多人感到困惑。 但是，我仍然偶尔听到有人认为JavaScript必须与Java有某种关系，因为“ Java”是两种语言的名称。
SLOC
我通常鄙视关于源代码行的想法的所有内容。 SLOC的吸引力在于，它可以伪装成某种形式的代码行与Bean和小部件一样。 并非所有代码行都是相同的，并且不同语言，不同开发人员和不同功能之间的代码行也有所不同。 有些人甚至认为，更多的SLOC总是好事，而我发现，使用更少的代码行来编写更简洁的代码通常是可取的。 我以前在博客上写过代码行和意想不到的后果 。
肥皂
就误用而言，这并不是什么大问题，但值得注意的是，SOAP不再代表简单对象访问协议。
JDBC
尽管从技术上讲它从未代表过Java Database Connectivity，而且甚至不是首字母缩略词，但它实际上并不会导致任何问题。 它确实确实与连接数据库有关，并且与Java有关，并且被广泛认为代表Java数据库连接这一事实，这意味着对JDBC这一术语的滥用没有明显的负面影响。 实际上，我怀疑Sun Microsystems的人们有意让人们将其视为Java Database Connectivity的首字母缩写，同时明确指出它不是首字母缩写，因为它使人们可以通过对ODBC的了解快速理解JDBC的含义。
结论
这篇文章中讨论的许多术语的错误使用可能被描述为过于花哨 ，但是滥用其中的一些术语可能会导致沟通不畅和普遍混乱。 在某些情况下（例如“敏捷”和“重构”），滥用术语会导致负面体验，并损害这些术语的声誉。 在其他情况下（例如在实际上不是缩写的情况下使用JDBC和SOAP作为缩写），这种混淆似乎很小且无害，因为每个讨论虚假广告“缩写”的人都似乎理解了它的含义。
软件开发公司关键词
扫一扫
139
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
