有很多专业人士可供个人选择，我相信e应该跟随他最喜欢或最讨厌的专业。 这样，成功的机会和生活质量都会好得多。 因此，如果您问我为什么选择软件开发作为职业，我可以向您保证编程是一项有趣的职业。 当然，不用坐在显示器前并不断在键盘上打字，这很有趣。 这很有趣，因为我们可以控制编写的内容，并且可以让我们的创新狂奔。
在本文中，我想分享一些我尝试过的想法，如果有任何想法适合您的工作，请您亲自看看。
工具类
对Eclipse使用OpenExtern和AnyEdit插件
在我尝试过的所有插件中，这两个插件是我最喜欢的两个插件。 它们体积小，速度快且稳定。
OpenExtern为您提供打开任何Eclipse资源的文件浏览器或控制台的快捷方式。 在使用Eclipse的第一天，我经常发现自己打开项目属性只是为了复制项目文件夹以打开控制台或文件资源管理器。 OpenExtern插件使繁琐的5到10秒的过程成为1秒的鼠标单击。 这个简单的工具实际上有很大帮助，因为我们许多人都从控制台运行Maven或Git命令。
我认为有用的另一个插件是AnyEdit 。 它向Eclipse编辑器添加了一些转换，比较和排序工具。 它消除了对Eclipse使用外部编辑器或比较工具的需要。 我还喜欢在保存时打开自动格式设置并删除尾随空格。 如果我们所有人都具有相同的格式化程序配置（换行，缩进等），这将非常有效。 在我们标准化代码格式化程序之前，我们很难在每次签入之后比较和合并源代码。
除了这两个以外，过去，我经常安装Decompiler和Json Editor插件。 但是，由于每天大多数Maven工件都是通过源代码上传的，并且可以使用Chrome Json插件轻松查看Json内容，所以我发现这些插件不再有用。
使用JArchitect监视代码质量
过去，我们用眼球来监视项目的代码质量。 当您有时间照顾所有模块时，这似乎已经足够了。 当团队不断壮大或多个团队从事同一项目时，事情变得更加复杂。 最终，仍然需要对代码进行审查，如果出现问题，我们需要提醒我们。
幸运的是，我得到了JArchitect的报价来试用他们的最新产品。 首先，这是一个独立的产品，而不是传统的集成到IDE的方法。 对我来说，这是一个优势，因为您可能不想使您的IDE变得过于沉重。 第二个好处是JArchitect可以了解Maven，这是市场上罕见的功能。 第三个好处是JArchitect在自己的工作区中创建了自己的项目文件，这对原始Java项目无害。 当前，该产品是商业产品，但您可能需要看看该收益是否合理。
设置项目
众所周知，Java Web项目具有单元测试和功能测试。 对于功能测试，如果使用像Spring MVC这样的框架，则可以在不启动服务器的情况下为控制器创建测试。 否则，开发人员需要启动服务器，运行功能测试然后关闭服务器是很正常的。 考虑到该项目可能是由其他人创建的，而我们之前从未进行过交流，因此此过程有些繁琐。 因此，我们试图以一种人们可以直接下载并轻松运行的方式来设置项目。
服务器
过去，我们为每个本地开发箱和集成服务器（Cruise Control或Hudson）手动设置服务器。 逐渐地，我们的常规做法转向将服务器检入到每个项目中。 此举背后的动机是节省了签出后建立新项目的精力。 由于服务器是嵌入在项目内部的，因此无需为每个盒子下载或设置服务器。 此外，这种做法不鼓励项目之间的共享服务器，因此不易出错。
除服务器外，项目中还有两个与服务器有关的元素。 它们是属性文件和数据库。 对于每个元素，我们都会根据情况采用稍有不同的做法。
属性文件
签入属性模板而不是属性文件
每个开发人员都需要克隆模板文件并在必要时进行编辑。 对于连续集成服务器，这有点棘手。 开发人员可以在工作区中手动创建文件，也可以将构建服务器属性文件检入到项目中。
不再使用以前的做法，因为它很容易出错。 任何清理工作空间的尝试都会删除属性文件，我们无法追溯文件中属性的修改。 而且，由于我们像过去那样将Jenkins设置为集群而不是单个节点，因此不再适用。
对于第二次练习，而不是在my-project.properties检查，我宁愿签我，project.properties模板和我-project.properties -詹金斯 。 第一个文件可用作设置本地属性文件的指南，而第二个文件可重命名并用于Jenkins。
使用主机名定义外部网络连接
如果我们需要为各种项目设置类似的网络连接，则有时这种做法可能会更好。 假设我们需要为大约10个指向相同数据库的类似项目配置数据库。 在这种情况下，我们可以在属性文件中对数据库服务器进行硬编码，并在每个构建节点中手动设置主机文件，以指向数据库的预定义域。
对于非必要属性，请提供尽可能多的默认值
关于这种做法，没有什么可说的。 我们只需要提醒自己不要偷懒，这样其他人可能会喜欢处理我们的项目。
使用LandLord服务
这是一种非常新的做法，我们仅从去年开始应用。 根据我们办公室的规定，Web Service是唯一管理和访问UAT和PRODUCTION服务器的团队。 这就是为什么我们需要引导他们，他们需要对至少两个环境进行重复设置的原因，而这两个环境通常都需要集群。 在我们整合所有环境的属性，将所有项目都投影到单个房东服务之前，对他们而言，这非常繁琐。
从那时起，每个项目都将启动并使用环境ID和应用程序ID连接到房东服务。 房东会很乐意为他们提供所需的所有信息。
数据库
使用DBUnit一次设置数据库，并让每个测试用例自动回滚事务
这是传统的做法，如今仍然很有效。 但是，它仍然需要开发人员为DBUnit创建一个空模式来连接。 为了使其正常工作，项目必须具有支持在测试环境中自动回滚的事务管理框架。 它还要求数据库操作在测试环境中进行。 例如，如果在功能测试中，我们尝试将HTTP请求发送到服务器。 在这种情况下，数据库操作发生在服务器本身中，而不是在测试环境中发生，因此无法执行任何操作来回滚它。
在内存中运行数据库
这是Play框架的内置功能。 开发人员将在开发模式下使用内存数据库，而在生产模式下使用外部数据库。 只要开发人员仅使用JPA实体并且不了解基础数据库系统，这就是可行的。
数据库演变
这是Ror借来的想法。 与其从头开始设置数据库，不如简单地检查当前版本并顺序运行delta脚本，以便数据库获得所需的架构。 与上述类似，除非Ror或Play之类的框架提供本机支持，否则要自己做是昂贵的。
编码
我从事该行业已有10年了，可以告诉您软件开发就像时尚一样。 好的做法和坏的做法之间没有明确的区分。 凡是被归类为不良做法的东西，都有可能在新的最佳做法之后再出现。 让我们总结一下我们的一些激烈辩论。
类属性的访问修饰符
我们大多数人都被教导应该从外部访问中隐藏类属性。 相反，我们假设为每个属性创建getter和setter。 即使我不知道大多数IDE都能自动生成getter和setter，我还是严格遵循这一规则。
但是，后来，我被介绍给另一种认为二传手很危险的想法。 它允许其他开发人员破坏您的对象并弄乱系统。 在这种情况下，您应该创建不可变对象，并且不提供属性设置器。
面临的挑战是，如果我们隐藏类属性的设置器，我们应该如何编写单元测试。 有时，使用Spring之类的IOC框架将属性插入到对象中。 如果周围没有框架，我们可能需要使用反射工具将模拟依赖项插入测试对象。
我已经看到许多开发人员以这种方式解决问题，但是我认为这是过度设计。 如果我们做出了一些妥协，则将package修饰符用于该属性会更加方便。 作为最佳实践，测试案例将始终与实现放在同一个程序包中，并且注入模拟依赖项应该没有问题。 一揽子计划通常由同一个人或团队控制和贡献； 因此，损坏物体的机会很小。 最后，由于包修饰符是默认修饰符，因此它节省了代码的几个字节。
整体应用程序与微服务架构
当我加入行业时，“企业”一词意味着大量的xml，大量的部署步骤，庞大的应用程序，许多层，并且代码非常面向领域。 随着事情的发展，我们采用了ORM，学会了将业务逻辑与表示逻辑分开，学习如何使用AOP简化和丰富我们的应用程序。 一切顺利，直到我再次被告知前进的方法是Micro Service Architect，它使Java Enterprise应用程序的功能类似于Php应用程序。 我们现在使用Java的最大好处可能是Java Vitual Machine的性能优势。
当采用微服务架构时，很明显我们的应用程序将面向数据库。 通过去除这些层，它也使AOP的好处最小化。 代码库肯定会缩小，但是编写单元测试将更加困难。
翻译自: https://www.javacodegeeks.com/2014/11/exploration-of-ideas.html