java开发遵循的原则

在1990年代，当Java开始出现在开发人员场景中时，它就迎来了来自微软的竞争，因为它努力在国际开发社区中赢得一席之地。 但是，多年来，Java似乎已经达到了比Microsoft现在提供的更稳定的基础结构和开发标准集。 这是两个社区都采用了彼此完全相反的成熟轨迹的结果。 当时，微软正在提供成熟的技术，而Java是“新手”。 双方对产品开发也提出了完全不同的观点。 微软提供的产品以“易用性”为根本因素，从而使开发人员能够比竞争对手的解决方案更快地创建桌面和Web应用程序。 与新的Java工具相比，尤其如此。 但是，Java在学术和科学领域都有其创立基础。

通过许多Java文章可以轻松地看到这一点，这些文章拆解了我们在Microsoft社区中视各种接口控件而已，而第三方控件开发人员除外。

Java社区确实很难在一个公认的开发形式中占有一席之地，直到它在大型企业开发区域中提出了Microsoft产品的替代产品为止，这是Microsoft的弱点，因为当时Microsoft产品面向部门和部门级别。应用程序。 一旦Java工具对开发人员变得更有用，大型企业领域就会通过其更适合的企业产品（即J2EE，以及后来的Spring Framework）看到Java开发的优势。

今天，我们发现一个Java社区似乎比Microsoft社区更加稳定，尽管人们对其周围的报告不了解也不知道。 几年前，由于两个社区为了开发人员的优势而相互竞争，所以这种报道是完全不同的。今天阅读诸如jaxEnter.com之类的在线杂志，大多数文章似乎都集中在现有技术及其改进上。 对于微软而言，情况恰恰相反，微软似乎是在以美国五角大楼的方式采购新武器的同时，对产品进行改进。 两者都抛出了完美的技术，并从全新的，未经测试的概念重新开始。

在此作者看来，作为自1989年左右离开大型机领域以来一直使用Microsoft技术工作的人，Microsoft不仅在他们提供的产品以及开发应用程序的方式上发生了一些严重错误。年份。 在史蒂夫·鲍尔默（Steve Ballmer）任职期间，微软的最新首席执行官萨蒂亚·纳拉亚娜·纳德拉（Satya Narayana Nadella）似乎最令人发指。 尽管微软声誉极差，但在这方面似乎更加稳定。

借助桌面应用程序，Microsoft现在拥有两种类型的开发产品，即原始的“ Windows窗体”模型和更新和推荐的“ Windows Presentation Foundation（WPF）”，后者在样式和设计复杂的界面方面要困难得多。 WPF背后的总体概念之一是使其开发类似于Web开发，并且在这方面已经非常成功。 但是，复杂性和相当分散的文档使许多开发人员难以进行这种开发。

Web开发与Microsoft的故事有些不同，对于那些阅读过我的文章的人来说，你们都知道我对Web的看法是负面的，因为它的发展方向太多。 最初使用“ Web表单”模型设计，无疑具有其自身的缺点，尽管内部设计存在固有缺陷，但该模型非常容易创建相当复杂的Web应用程序。 仍然是。

沿途某个地方，一些高级技术人员突然想到整个Microsoft社区都希望Java社区在这方面拥有MVC模式。 也可能是有关Microsoft产品组的可怕内f的结果。 当时，作为使用Microsoft产品的软件工程师，我充分了解了开发人员社区面临的问题。 有趣的是，我从未发现其成员有任何此类需求。 实际上，当ASP.NET MVC首次发布时，我反而对它产生了相当大的负面React。

尽管如此，我仍然没有发现这种产品开发有什么问题。 但是，绝对没有必要颠倒整个社区来提供这种新范例，因为那些确实想使用它的开发人员已经有了Castle Project的“ Monorails”提供的开源替代方案。 这一独特而强大的产品完全按照Microsoft推出其第一版ASP.NET MVC的方式为Microsoft的Web开发提供了MVC开发。 实际上，如果您对安装进行了比较，您会发现创建的解决方案是彼此的精确副本，这使人们想知道微软是否首次引入MVC实际上是Castle Project的“ Monorails”的分叉版本。 。

但是，与Java社区维护其初始工具集并使用它们成功进入企业不同，Microsoft尽管提供了很多质量工具，却没有提供可用于所有级别开发的类似规模的构造。 尽管如此，通过引入.NET开发环境（这将成为Java的最大竞争对手），Microsoft确实提供了诸如Remoting Framework（后来称为“ Windows Communication Foundation（WCF）”）之类的分布式计算功能，这应该是Java更成熟的J2EE实现的答案（由于J2EE的初始性能和配置问题，Java将提供Spring框架的替代方案）。 尽管Remoting的功能在当时相当广泛，但其使用心理学并未反映出Java社区中类似的思想压力。 因此，尽管Java社区的企业级工具都与开发Java桌面和Web应用程序的能力交织在一起，但Microsoft的产品却相形见too，无法提供如此高的心理凝聚力。

自.NET以来，这对Microsoft而言是不幸的失败，即使在最早的配置中，它也为寻求现代快速应用程序开发技术的开发人员和组织都提供了很多东西，而Java社区并没有提供这些东西。 尽管如此，.NET的易用性开发功能与Java更广泛的企业产品一样精心设计。 他们不仅为开发人员提供了一种创建应用程序的好方法，而且还为希望修改其工具产品的第三方公司保持了一致性。

随着时间的流逝，两个社区开始在一定程度上反映彼此的能力。

借助“ Windows窗体”和更新的“ Windows Presentation Foundation”，Microsoft通过使用Java，AWT和其他工具，远远超过了Java在桌面应用程序开发方面的能力。 对于Web应用程序，Microsoft提供了“ Internet Information Server”作为其标准应用程序服务器，而Java Community则依赖于“ Apache”，后来又使用了“ GlassFish”，这两个都是出色的服务器。 对于实际的Web开发，我们拥有ASP.NET WebForms，而Java具有“ Java Servlets”及其MVC开发范例。 前者提供一对一页面处理（网页到代码隐藏），而后者提供一对多页面处理（网页到多个控制器）。 随着时间的流逝，两家公司都成为其开发者社区公认的开发方法。 尽管Microsoft社区中的许多人抱怨“ WebForms”存在某些困难，但据我所知，没有人提出任何建议将其与沐浴水一起丢弃。 不幸的是，微软因停止生产非常坚固的产品而在声誉上相当差。 尽管它尚未宣布任何计划停止“ Web窗体”支持，但可以轻易看出，重点越来越放在ASP.NET MVC平台上。 在较旧的“ Windows Forms”平台和较新的“ Windows Presentation Foundation”之间，也是如此，尽管它们都不是人们对使用ASP.NET MVC及其相关工具所能发现的近乎歇斯底里的原因负责。

作为停止提供优质产品的一个示例，Microsoft开发了桌面“ SQL Server CE”桌面数据库引擎。 它的占用空间约为2兆字节，对于SQL Server开发人员来说是一个非常易于使用的引擎，并且支持32位和64位计算机。 随着主要SQL Server开发的继续，Microsoft决定停止使用这种高度通用的数据库引擎，转而使用“ LocalDB”，该引擎在桌面上的存储空间约为14兆字节。 不用说，这个数据库引擎几乎不受任何人的关注，因为许多人选择使用SQLite或Firebird。

随着Microsoft继续对“ Web窗体”和“ Windows Presentation Foundation”环境进行自己的改进，这些模型已经走了很长一段路，并且已经发展成为非常可靠的软件开发形式。 它们既稳定又为需要快速，高效并使用现代样式界面开发桌面和Web应用程序的组织提供了极大的灵活性。 在这个关头，微软或多或少提供了与Java社区一样稳定的平台。 为确保两个社区提供不同的开发风格，但两种风格都已经成熟，并且可以产生业务组织可能需要的任何应用程序。 随着Microsoft对“数据中心”服务器的日益关注，企业级开发也为Microsoft找到了一个很好的家。

尽管如此，在两个阵营中都取得了如此成功，微软方面还是出了点问题。 对于开放使用开源软件的Java社区而言，令人惊讶的是，软件开发的基本原则从未真正绕过重新定义Microsoft开发社区的宣传和鼓掌。 绕道而行的大部分原因是ASP.NET MVC范例的结果。 在Microsoft社区中，通过“ Web窗体”通过MVC或通过“ Windows窗体”通过WPF提倡的原因在大多数情况下都是胡说八道，因为所有这些开发模型都做的完全相同。 他们要么创建Web应用程序，要么创建桌面应用程序。 有人可能会说，随着移动计算的出现，ASP.NET MVC是一种更好的解决方案，但是到目前为止，在Microsoft的开发方面还没有任何证据。

问题在于，对于作为一家软件销售商的营销公司的微软公司来说，从未认识到一个简单的事实，即业务应用程序的开发已经成熟到某种程度，在这种情况下，可以完成的工作很少。这个领域涉及新工具的开发，它将提供一些实质性的独特功能，从而可以促进一种新的开发方式。 除非基础发生重大变化，否则我们的硬件和设备是在如此重大变化的基础上创造的。

微软根本无法理解他们所开发的软件对开发人员而言是完美的，而成熟度与Java社区相当。 而且由于微软从营销组织的角度看待事物（为什么比尔·盖茨离开时，他们为什么还要让史蒂夫·鲍尔默（Steve Ballmer）成为公司的销售员？），他们似乎需要“下一个新事物”，这可能会使Java开发人员转换为Microsoft产品线，或鼓励青少年，青少年和大学生使用他们的工具。 不幸的是，尽管做出了所有努力，但Microsoft似乎在这些方面都失败了，因为与其他方法相比，我看到更多的开发人员对他们离开Microsoft社区的方式发表了评论。 这么小的外流可能是微软提供的开发选择越来越模糊的结果。 至于教年轻人编码； 我从未听说过如此荒谬的事情。 像任何技术专业一样，首先必须要有一定水平的才能才能发挥作用。 此外，微软始终隐藏着议程，在这种情况下，是要发展新水平的廉价劳动力，而不是发展“批判性思维”技能。

由于实际上没有开发效率之类的东西，因此所有范例都有效地工作，并且各有优点和缺点。 对于实施的每种技术，都必须克服一个缺点。 因此，开发决策主要基于开发人员最满意的知识以及他们所知道的知识。 尽管具有技术属性和背后的科学知识，但大多数情况下，此类决策本质上是主观的。 并且考虑到大多数技术经理可能会在乎，除了他们的技术选择不会使他们被解雇外，我怀疑对于任何特定开发技术的优点，他们是否存在严重的担忧。

我喜欢在VB.NET中工作； 所以射杀我！  我可以像在C＃中一样高效地工作，但是我在1980年代末从DBase领域来到，对 语法的 ^第 4 代 感到最满意 。 那时，我们在DBase环境中做过一些很棒的事情，可惜他们沦落到历史的垃圾箱里，这真是令人遗憾。

今天，在Microsoft社区中，我们发现我们正在使用他们的工具来体验Java社区在业界首次出现时所经历的一切。 专注于工具，技术和头，而不是在不考虑所使用工具的情况下进行高质量的应用程序开发。

但是，不容易丢弃成熟的可靠软件开发工具。 一个很好的例子是 Visual Basic，C＃，Java和C ++的 ^第三 代 主要 语言 的寿命 。 他们都做了开发人员完成工作所需要的一切，并且已经做了相当长的一段时间了。 就所有意图和目的而言，其他一切都只是分散注意力和虚张声势。 确实，已经为特定目的开发了某些语言，例如Modula III，Prolog，以及一些其他最新的动态语言，但在大多数情况下，主要的开发语言多年来一直是软件工程中的力量大型机已经消亡，并且可能会持续很长时间。

Microsoft应用程序开发-原始成熟的开发风格

微软在2008年发布“ Windows Presentation Foundation”后，它就可以促进桌面和Web应用程序的单一样式开发。 如果他们提倡这样一个统一的环境，同时对其进行完善以支持新兴的移动环境，则由于我们的知识基础将更加深入，因此在发展问题方面，我们这边的围栏将会更加稳定。

考虑到这些环境，使用MVC（网络），MVVM（桌面）等具有许多“技术”优势，但最终这些优势都无法为大多数需要应用程序的组织带来很多好处发展。

例如，许多开发人员都支持使用这样的范例可以大大提高测试效率的想法，因为开发人员可以使用各种测试框架并将组件彼此分开进行测试。

但是，没有证据表明使用好的传统测试技术和使用最新的测试技术会导致后续质量的差异。 自战斗机问世以来，所有战斗机飞行员都学过一种公理。 成功参与的因素是操纵杆后面的飞行员，而不是飞机。

在两种测试方式中，必须花一些时间进行正确的测试。 传统测试可能更多是手动工作，但是在较新形式的测试（“测试驱动开发（TDD）”）中所花费的额外时间将用于测试代码的其他开发。 在这两种测试模型中都可能发生不良测试。

实际上，使用传统测试不允许将缺陷引入生产环境，因为这是这种质量控制的目的。 但是，我无法数出我已经读过的文章数量，因为现在有很多理由可以很快找到并可以通过自动部署流程纠正，所以现在很常见的是讨论使用TDD / Agile在生产过程中允许使用缺陷的情况。 。 当出现令人讨厌的错误时，请告知此类应用程序的最终用户。

使用不带MVC和MVVM范例的Microsoft工具开发应用程序的样式仍然基于捕获和响应用户请求的单个中间层模块。 在标准的“ Web窗体”（ASP.NET）中，该模块被称为“代码隐藏”，并且与更新的“ Windows Presentation Foundation”（WPF）桌面应用程序大致相同。 令人惊讶的是，在这种环境下，Microsoft似乎并没有为此模块提供首字母缩写词，但它或多或少是同一件事。 因此，在两种情况下，我们都可以从下图所示的角度看待这种类型的开发。

该图显示了它在大多数开发平台上的历来成就，但是Microsoft或多或少地将其编入了他们的产品。 只要您不不断地来回传递大量数据，网络上的这种模型绝对没有错。 如果是这样，性能将明显受到影响。

为了使Web的性能更加高效，开发人员和供应商都想出了避免用户完全“回发”此类请求的技术。 结果就是引入了AJAX，即使在今天，AJAX仍是所有此类后端调用的基础，而这些调用并不涉及完整提交Web表单。 Microsoft AJAX尽管有一些缺点，但实际上效果很好，并且仍在专业维护中。 您根本无法超越AJAX“ UpdatePanel”为开发人员提供的易用性。

对于桌面应用程序，这不是什么大问题，因为WPF或“ Windows窗体”的中间层模块（响应\请求）与接口以及使用该接口的用户位于同一台计算机上。

但是，对于Web而言，开发人员一直在追求某种“银弹”，以某种方式在其应用程序中产生最佳性能。 结果是，对新工具和框架的追求已成为Microsoft开发人员的技能和能力指南。 微软愚蠢地跟风，而不是专注于完善其核心产品。 显然对他们所取得的成就感到满意的Java社区几乎没有必要涌入像Microsoft世界这样的未知领域。

现实情况是，就像系统工程师几年前写的那样，在网络上，性能是硬件和配置的问题，而不是太多的代码，尽管您可以做一些事情来提高应用程序的响应速度。 此外，在诸如Web上的大型应用程序或台式机上的大型客户端服务器应用程序中，追求性能在很大程度上是一种幻想，因为两种类型的应用程序中最重要的问题是“并发”，这将排除在外。开发最高性能的能力。 当大量用户正在访问应用程序时，您想要的是可接受的性能。

在开发方面，许多Microsoft开发人员通过将每个接口表单所需的几乎所有必要处理都加载下来，继续弄乱他们如何处理“代码隐藏”模块。 “ Windows窗体”和WPF开发也是如此。 无疑，这种情况与Microsoft版本的MVC一样频繁发生。 这种类型的开发导致应用程序固有的瓶颈，因为此类模块实际上被用作其他模块的“分派器”，这些模块将处理实际的业务逻辑和后端流程。 因此，这种发展方式的实际结构如下所示……

然后，在这种情况下，流程模块代表我们用来调用中间层的模块，而接口和请求\响应（代码在后）模块代表前端层，其中请求\响应模块在应用服务器上实现Web应用程序或同一台计算机就桌面应用程序而言。

流程模块也称为业务对象，在该对象中，来回传递给客户端的数据将通过计算，文本转换以及其他类型的算法进行操作。 可以在流程模块的整个范围内共享的特定模块旨在实现特定但或多或少通用的处理形式，例如数据库访问，安全认证和常见的字符串操作功能等等。

最后，我们有一个后端层，它由数据库组成。

对于许多年长的开发人员来说，这应该是常识，而对于年轻的Microsoft专业人士来说，这应该是他们被教导开发高性能应用程序的正确方法。 就像“保时捷”一样，“没有替代品！”，无论您如何切片或切成薄片。

真正的N层开发； 基础架构比编码更重要

但是，即使高效，整洁地设置了此编码基础结构，访问量很大的站点也很可能不会带来人们期望的性能提升。 即使应用程序是使用ASP.NET MVC（而不是“ Web表单”）开发的，但从MVC框架的这一方面开始，路由一直是与MVC争用的历史点，因此来自路由器的许多控制器调用可能会带来严重的瓶颈。历史上一直基于“反射”，这不是地球上最快的过程。

由于我不是Java开发人员，所以我不知道该社区如何规避这些问题。 但是，作为一个比我们的Microsoft开发人员更复杂的背景发展起来的社区，我想下一个求助对象对于大型Java应用程序来说是相当普遍的。 但是，Java Community确实并入了servlet，它是一种微型服务，可以在中间层处理请求和响应。 它非常巧妙，仍然可以很好地工作。

早在1990年代，流行的宣言，MVC，JavaScript等兴起之前，实际的分布式计算思想是Web或客户端服务器应用程序中真正性能的基础。 实际上，关于此主题的最佳开发人员手册之一实际上是由化学家转变为程序员的，他为北达科他州开发了高性能的Web和客户端服务器系统（可能是南达科他州，我不记得了。）随时有超过1500个客户使用中央系统。

这位科学家为硬件\数据库配置制定了框架，即使在今天，对于大型应用程序也无法击败。 他采用了当今的标准并设计了整个框架，并测量了配置的每个级别的性能基准，直到他将每个级别精炼到最佳效率为止。

但是，随着速度越来越快的微处理器的兴起，这些基础很快就被预算所掩盖，因为预算也将由日益增加的外包狂潮所定义。

但是，正是这些基础提供了分布式计算的概念，而不是这些系统支持许多远程客户端。

回到上面的图形，要进行最佳处理的各种处理级别中的每一个都不能依靠一台机器来完成。 但是，这就是当今许多IT组织所做的事情。 但是，大型组织的确提供了非常强大的应用程序服务器，这鼓励使用单机部署。

尽管这样的部署可能会产生令人满意的结果，但是除非服务器非常强大（例如使用大型机或一组高性能UNIX计算机），否则此类配置的可伸缩性将是有限的。

为了解决这个问题，开发人员已将精力集中在其代码上，因为这是可能出现性能瓶颈的区域。 在某些情况下，可以通过优化编码来提高性能，但实际上并没有那么多。 这是因为真正的性能是基于硬件而不是软件。 因此，无论使他们的代码多么高效，它的运行速度都只会与部署它的计算机可以处理它的速度一样快。 一台机器拥有的客户越多，性能就会越慢，因为单台机器将不得不越来越努力地处理工作负载。

为了克服这种限制，开发人员开始在某些应用程序中实施线程操作，这再次主要基于可用的硬件。 早期的文档建议每个微处理器最多十个线程，而每个微处理器单个线程的最佳建议。 对于可能包含多个微处理器的机器，这似乎是一个实质性的想法。 但是，有多少组织为其应用程序提供32 \ 64核心计算机，并且为单个应用程序留出了多少计算机？ 我建议不多。

结果是线程通过为接口提供灵活性而找到了自己的优势，这一直是其预期目的之一。 正确实施后，线程确实可以很好地工作，您只需要谨慎对待即可。

在这种类型的实现中，我们还发现了异步编程的兴起。 但是，这种类型的处理仅在应用程序具有可以长期放置在后台线程中的长时间运行任务时才发光，因为不需要立即使用数据。 这种编程风格实际上与性能无关，而与灵活性有关。

再次回到上一张图片，我们需要从易于缩放的应用程序中获得最大性能，这也是很少有组织会选择的事情，因为设计，测试和实施都需要花费自己的时间。 。 尽管如此，我们还是要从如下所示的基本硬件配置开始……

在继续之前，请注意上图中的数据库部分。 您将看到两种类型的数据库引擎， 用于事务处理的 OLTP 和 用于查询处理的 OLAP 。 为什么对于一个应用程序我们需要两种不同类型的数据库引擎？ 对于相当小的应用程序，我们不需要，但对于现在和将来可能需要扩展的应用程序，这是设置后端层的标准。 OLTP数据库用于事务处理时效率最高，而OLAP数据库则针对查询进行了优化。 尽管OLAP数据库引擎是为商业智能系统而吹捧的，但这些系统的现实是，此类系统除了其数字功能外，还针对查询进行了优化。

为了确保每个数据库系统在其数据方面都是最新的，OLTP数据库引擎被设计为将任何更新传递给其OLAP兄弟。

通过以这种方式拆分数据库系统，您实际上可以通过允许每个数据库引擎尽其所能来将后端的性能提高50％以上。

最后，这证明了这种实现方式的成本增加，每个层由多台计算机组成，并且随着我们离前端层（接口）越来越近，计算机的数量也在增加。 在自己的设计中为每个层制定性能基准的科学家发现，随着过程进一步深入到此基础架构的层中，处理较低层所需的时间更少。 这是因为在响应用户请求方面，每层机器实际上都要做的很少。 结果，这种类型的基础架构看起来像下面的更新图形……

然后，此最新图形演示了用于高并发应用程序的大规模部署的正确配置。

该基础结构的每个级别都可以通过添加其他硬件组件来线性扩展，因为每个级别都将由计算机集群组成。

许多人对这种类型的基础结构的React是设计和实施成本太高且耗时。 他们是正确的。 但是，这是用于实施高性能系统的适当技术，几乎没有什么可以使人们克服这一问题。

今天的炒作，尤其是在Microsoft社区中，是可以使用脚本语言以及C＃或VB.NET的MVC范例来构建如此高性能的应用程序。 事实并非如此，这就是事实，但这可以促进良好的营销。 良好的应用程序开发不仅需要干净且高效的代码，还需要可以提供代码可以利用的功能的基础结构。

毫无疑问，大多数Microsoft组织由于通常的原因未遵循上述标准； 我之前提到了这两个方面，因此设计需要太多金钱和时间。 公司喜欢以便宜的价格工作，因此网络和硬件人们想到了将应用程序组合到现有硬件上的方法，一旦完成，它们就会大大降低频繁使用的应用程序的性能。 这样的应用程序组合对于低或什至是中等用途的应用程序来说是很好的，但是总的来说，就性能而言，这样的组合只会阻碍响应时间。

人们喜欢使用的最后一个借口组织是“完美世界综合症”。 “好吧，在一个完美的世界中，我们会拥有这个。” 问题是，除了技术精明的组织外，没有人会尝试接近任何类似于可信基础架构的东西。

The result of this derailing of actual n-tiered development has fostered the idea that applications can be made to perform very efficiently through refinement of code. For the most part this is utter nonsense but in the attempt to produce such performance technical managers have put terrible pressures on their developers to refine their code bases to the nth degree saving only milliseconds in time. This is not to say that you cannot find substantive performance enhancements in refining existing processes but it cannot be done simply through a refinement of existing code bases.

Years ago I worked with someone who thought he was the “gift to object oriented programming” and only he knew how to develop code properly. I am quite sure that everyone reading this piece has experienced a person of this nature at one point (or many) during their careers. There are plenty of these “fools” out there.

This fellow in particular just about cursed me out for a set of database queries I had written and placed as singular selects in a store procedure. This fellow promptly redid my stored procedure combining my queries into a joined set of queries. I accepted his work calmly and out of curiosity proceeded to run the performance benchmarks on the original stored procedure and the updated one that this fellow claimed was the proper way to write what I was doing. I never told him the results thinking he would just waste my time even more by trying to refine his own work. Nonetheless, his work took 35 milliseconds longer than my original code.

In either case, my faster stored procedure or his slightly slower one in the scheme of things would make little difference since Humans cannot interpret time at such levels. Yet, such attention to the coding of developers over the years has become near sacrosanct in many organizations to the detriment of all and everything else involved since for the most part it is a giant waste of time; especially if the infrastructure on which the application will run is not optimized properly. Any student of modern compiler theory and internals will be able to tell you this.

First and foremost, all of the compilers in today's business world whether they be for the source-code languages or the database systems are extremely well optimized. Even if your code is somewhat inefficient, these compilers will make up for it by providing the best optimal solution for what you are attempting to write. Does this mean you get to write sloppy code? No…

What it means is that the attention to such performance details in your coding is more esoteric in the endeavor than in actually yielding increased performance results. It means that good clean code will work well and will most likely still be optimized by the compiler. Bad code, will work… well badly but probably not as badly as one would expect since the compiler will most likely eliminate some of the issues.

Note that we are talking about working code in both situations here not code that simply is so poorly written it will not work or barely do so.

To the last, I did work on an application that had been completely coded by someone else. The coding was atrocious and many of it completely wasteful. In fact, after having been able to study and work with the application for some time I found that at a minimum at least 50% of the code was unnecessary and could be removed if the application were to be re-written. Though I never had the opportunity to do this, the application, for all its inherently poor design and coding, actually operated reasonably well in terms of user response and processing. And this included a very poorly designed database as well.

No matter what type of application you may design and implement as long as you write your code in a clean and legible manner it will work just fine under low loads of activity. If you refine your code as much as possible towards making it as high performing as possible it will still work to the same degree under low levels of load activity since the optimizations that both you and the compiler make to your work will not be able to be interpreted by Human users. If you apply the implementation to a situation where there is to be expected a high concurrency rate, no matter how well your code is written it will fail to perform properly without the proper infrastructure. It is that simple.

Despite these fairly simple engineering axioms, developers have still tried to optimize their applications in various ways that attempt to work around poor infrastructure implementations.

Today, the apparent standard on the web in the Microsoft world is what we used to call the “fat client” where as much as possible is placed within the client area of an application. The thinking is now that JavaScript reigns supreme and that as long as one implements all of the necessary libraries and dependencies on a web page everything will be highly efficient.

It is rather surprising to see developers praise a language that was never designed to do what it is being used for now while at the same time increasingly develop ever more tools that make use of the same language in a way that appears to make the whole sloppy mess in some way extremely recursive from a figurative sense.

JavaScript, like all languages of its type, falls within the domain of what we now call “dynamic” languages, which means that they are completely interpretive. In turn, this means that they are in general, inefficient no matter how fast the JIT compiler may be. Their primary advantage was for quick development times and not quick performance.

The use of such a technique encourages the building of applications that use individual data calls to the server, which will respond in kind. Some of this design came out of the mad rush to eliminate as many calls to the server as possible via post-backs, which entailed the passing of undesired amounts of data.

To some degree this concept made sense. However, it appears to have been lost on Microsoft developers especially that this form of data call was rectified rather early on with “Web Forms” through the use of the “web method”, which works quite nicely. It uses the same type of call within the popular “jQuery” framework (as well as others) that one would use if the call was made to a controller in an MVC application.

So does it matter where the method may be implemented; within a single-page code-behind or an MVC controller, which may be only one of several that will receive requests from a single web page? Most likely not…

It is true that sophisticated developers have made legitimate complaints about the way that Microsoft's ASP.NET “Web Forms” does its processing against a “one to one” web page and its corresponding code-behind module. However, many of these complaints have been addressed over the years through refinements that Microsoft has made to the “Web Forms” paradigm. And the same has been true of Microsoft's ASP.NET MVC implementation or there wouldn't have been so many version releases in the past 6 years. The issue is why did we ever need two divergent development paradigms for the web when the original and more mature model offers nearly identical performance power while being far more flexible to develop with?

While the move from “Windows Forms” to the “Windows Presentation Foundation (WPF)” has made a lot of sense in the way that now both web and desktop applications can now be developed in similar styles, the move from ASP.NET “Web Forms” to ASP.NET MVC has not had a similar level of credibility despite what the pundits may say. In fact, it is this move that has had a terrible effect on Microsoft development stunting the growth of more mature technologies that worked equally as well.

In some respects some of the thinking behind these evolutions has resulted from attempts to break out the tasks involved in application development to separate groups so that one group could design the interface while another would implement and test it. This makes sense but in most real world situations does not often happen in the Microsoft Development Community. Instead, developers tend to be responsible for most aspects of application development. This is why in job postings for Microsoft developers you often see a laundry list of skills requirements for the candidates; a list so long that no one could possibly be well skilled in all of the items. If the Java Community has found the same style of job offerings than it is familiar with this problem.

Nonetheless, one of the results of these changes in the Microsoft development environments has been to take advantage of the now many free software offerings from the Open Source Community to create new tools based upon inefficient language mechanisms not necessarily out of necessity but instead from wanting to try something new. There is nothing wrong with this endeavor but when a company attempts to mold all such activities into an existing development environment such as Visual Studio you land up with 6 gigabyte installations, most of which each developer will hardly use, taking advantage of only that which interests him or her.

Microsoft marketing consistently touts the advantages to creating great applications and modern user experiences with such new and “exciting” tools. However, if you have been in the industry as long as I have, you find that the marketing has become highly redundant by repeating the same mantras that began with the release of Windows 95. Nothing ever really changes…

Don't get me wrong, Microsoft has some great development environments and tools as does the Java Community. However, there is a limit to what can be effectively done with the development of business applications using current protocols and infrastructures in either case. The Java Community has refined its offerings around scalability from the beginning and has matured in that endeavor. Microsoft on the other hand got off to a good start with its own offerings and could have done much more with these initial environments if they had stuck to refining what were already decent foundations.

However, instead of doing this Microsoft will persist to ensure new offerings in some misguided attempt to remain relevant while making these offerings as bloated as the original ones were claimed to be seeking that multi-pronged “silver bullet” that will not only yield high performing applications but offer efficient development environments that will convince many in the Java Community to convert.

I believe this is a fool's errand but businesses are often run by people who are perceived to be intelligent but really aren't. Good developers understand what they need to create good applications and it would behoove Microsoft to stop throwing everything out with the bath water and start again filtering for the community what is necessary, makes sense, and defines what makes for good ease-of-use development environments. This would be a far superior approach than turning their entire section of the industry into a technical nightmare creating a future that is based upon quicksand…

This article first appeared on Tech Notes , Black Falcon Software's technical articles for .NET Development.

翻译自: https://jaxenter.com/windows-developers-should-follow-the-stable-infrastructure-and-development-environments-of-the-java-community-and-forget-the-hype-130054.html

java开发遵循的原则