具有清晰逻辑架构和思考的应用程序开发

app开发具有明确的逻辑架构和思维，开发人员的价值体现在技术和产品上。对于沈阳app开发，除了实现业务外，最重要的是开发的速度，质量和可维护性。速度决定了你是否可以支持公司抢占市场。质量决定了你是否能够站稳脚跟而不是迅速被踢掉。可维护性决定了您在继续前进时是否能保持快节奏。速度，质量和可维护性，速度，质量和可维护性要求实际上是快速，稳定和明确的要求。快速：快速实际上是最容易做到的，或者最简单的事情就是知道你是否可以做到。熟悉的Android开发朋友知道，如果您能够理解业务逻辑并在不受干扰的情况下投资开发，那么开发速度可以非常快。一般尺寸的应用程序可在一到两周内完成。稳定：它没有它那么快。您可以简单地利用时间进行实时定量评估。在我们知道它不稳定之前，我们必须等待很多错误。但是，当工作速度很快时，很容易出现很多错误。事实上，Android的常见问题无非是内存，异步，响应等。很容易消除和解决这些问题。困难的部分是如何确保不会发生这些问题。明确：Clear是最难实现的，可以通过时间量化，稳定性可以通过bug统计量化，但清晰度难以量化，代码审查和可扩展性是主观评估，而且相当滞后，在很多情况下，它通常是必须等到需要实现扩展，甚至当替换接管代码时，代码也不清楚。

对于开发人员，我如何快速，稳定和清晰地开发应用程序，并且我已经整理了一些我的经验。从职责分工有限参与业务设计，业务设计是运营部门和产品经理的工作，确实不应该负责研发，但我说参与，研发（包括测试）应该参与业务设计尽早，一方面提前发现问题另一方面，您可以指导和建议技术路线。研发参与设计可以避免许多问题，例如通信压力，加载速度，延迟时间，硬件负载和其他移动开发特定问题。我们不能指望运营和产品可以像专业研发一样全面。想想周翔。另一方面，研发参与设计也可以导致技术路线，例如使用本机App，混合App或ReactNative，单用户或多用户系统，以及使用何种形式的费用。实际上，您可能会在业务设计中发现漏洞，例如计费表单，异常提示甚至业务逻辑。当然，参与设计将不可避免地占用研发时间。有些人会觉得很委屈，觉得这是他们的产品。然而，事实上，研发参与设计并为自己节省时间，因为无论产品如何设计，它最终都需要技术。要开发和实现，如果设计中存在问题，您可以更改代码的输入，并且可以投入比产品修改文档更多的内容。当然，公司层面也应该有明确的定位。必须限制和指导对研发的投资。如果将大量的研究和开发用于设计工作，那么这是另一种形式的浪费。异常处理在实际的开发过程中，除了实际占用了相当一部分工作量的bug之外，有时还有一个很好的开发计划，因为一些奇怪的bug必须延迟很长时间，即所谓的“代码字5”分钟，两个小时的故障排除“也是。因此，能否尽快处理异常对发展效率具有很大影响。 处理异常时，我有一些事情：我提前考虑异常处理，在编写正常流程的业务代码之前，我首先考虑业务流程分支中的“不赢，先丢失”的异常，首先处理异常Off，例如，获取在线数据列表，首先考虑网络异常，服务器错误，数据故障等异常情况，然后给出相应的提示，最后处理数据的正常情况，你必须编写正常的业务代码和异常处理代码，你只需要改变工作的顺序，实际上你投入的开发时间并没有增加，但是你的效率有很大提高，因为一旦出现异常，我们可以快速确定异常的原因并节省大量时间。这也有好处。在您的思维陷入复杂的业务逻辑之前，您可以处理相对简单的钩子，这可以防止您在获得大脑缺氧时被业务逻辑忽略。写入错误或写入泄漏异常处理。要隔离背景前后的数据接口，最好不要直接使用背景提供的数据，并在中间添加一层映射。一方面，如果后台数据存在问题（数据异常，更改字段等），您可以在映射数据时找到它。和定位问题;另一方面，它还可以帮助您使用更适合App for data persistence的数据格式。另外，建议做一个界面入口和检查工具，不管形式如何，但要轻松维护前后界面，最好自动检测界面反馈是否正常（服务器过载，现场变化，第三 - 服务到期，等等）。异常信息的收集，摘要和数据持久性。如果发生异常，最重要的是收集异常代码行（例如MainActivity的第61行）和异常的原因（例如空指针异常），并将其记录为本地文件以进行上载和查看。有关详细信息，请参阅：使用框架进行结构分层是必须的，Model层，View层必须具有单一责任，至于使用MVP，MVVM或其他东西取决于个人偏好和项目需求。个人喜欢MVP，感兴趣的可以看看MVP框架的演变，当然，Rx链编程也不错。 个人在结构分层方面有多种经验：高内聚数据层，与数据读写相关的处理，网络读写，本地读写，缓存数据等，包括模拟数据，都集中在数据层。通过回调或链式调用将数据投掷到业务层，并通过多版本机制在模拟数据和实际数据之间切换。松耦合Activity，界面应该是与业务相关的最低层，主要是提供显示载体和触发生命周期处理，Activity应该很容易被替换。独立且易于测试的业务层，业务层应该能够实现自动化测试，这一点非常重要，即使你没有实现自动化测试，编写代码也可以进行自动化测试，也可以帮助你优化代码，抽象抽象，剥离剥离。必要时抽象特殊控制。如果需要重用控件，请不要让控件合并到Activity中，而是将其抽象为独立的显示控件，该控件可以解耦和重用。不要过度设计。敏捷开发中有一个实用的原则，即不要过度设计。开发的价值不是编写漂亮的代码，而是实现产品并支持其正常运行。在实现产品功能的前提下，代码逻辑实际上越多越简单越好，意味着高可靠性和低维护成本。如果将来需要扩展该功能，可以通过修改和重构来实现。当然，简约并不意味着随意。让事件变得复杂很容易，但很难做到。它可以在逻辑上清晰，线程安全，内存安全，易于修改和扩展。同时，它可以保持代码简洁，但它实际上测试了技能。实际上，不仅在开发新功能时，还要避免过度设计。在维护和扩展旧代码时，还应注意正常运行的代码是良好代码的事实。我认为在维护旧代码时，它也适用于开放和封闭的原则。必须更改但未更改的旧代码是打开的，可以修改;对于可以正常运行的代码，即使你觉得软件公司

它既丑陋又发痒，它也是封闭的，它无法修改。回到那句话，开发的价值不在于编写漂亮的代码，实现产品并支持其正常运行。一般图书馆的建立和维护我们知道项目管理有四个要素，时间，成本，范围和质量。这四个要素通常不兼容。如果需要时间，有必要削减一些项目目标并降低成本。牺牲质量很容易，等等，但是建立和维护一个公共库可以同时使所有四个元素受益。加快开发速度，专注于特定业务（时间），降低熟悉项目的团队成员的成本，为新业务开发提供基础，加快开发迭代，促进更快的版本发布，提高代码重用率，减少开发投资（成本）稳定的公共模块采用依赖组件库方法，提供给每个业务线进行协同使用，减少重复开发和升级维护工作量，提高开发效率，更容易实现项目目标（范围）为实施的功能/业务，抽象通用模块，具有类似要求，可以快速实施，更容易实现项目业务需求，提高产品质量，持续改进常用功能（质量）常用功能/业务模块使用组件重用，更有利于曝光缺陷，一种修改，多种好处，提高产品质量代码评论一般来说，程序员看一下他们一个月前写的代码，这是完全奇怪的，我是一样的，一个月后基本没什么印象，但是如果你想修改/扩展怎么办，这次，您必须查看代码注释。就个人经验而言，有很多地方你必须写评论：接口，特别是MVP的Contract接口，它基本上定义了你的主要业务行为，谁加载数据，谁显示数据，谁触发了它。下一步，内容写得清楚，稍后阅读代码，只需查看界面即可了解主要业务的进展情况。服务，广播等，服务和广播因为没有界面，容易脱离业务逻辑链，缺乏业务逻辑中的上下文，所以必须有详细的注释来解释其业务场景。 初始化，注入等。如果自定义某些扩展函数或控件，需要一些初始化函数或注入特定函数，则必须编写注释以提示调用者执行必要的操作。