从刚毕业，到找到工作，开始接收任务，有导师带的做事，再到主动提出问题，确定解决方案，带着团队一起实现这个功能。工作的方式在变化，所处的角色在变化。几年的架构优化工作下来，横向的对比来看，架构优化的工作要比正常的版本需求迭代的研发还是有一些区别，主要在于以下几个方面1. 架构优化的工作，是提前为业务的将来做准备，等业务需要时再进行技术架构的搭建时间就来不及了。可是在当下，对于业务的现有的架构是合理的
研发质量和研发效率都是研发过程中，追求的目标，高质高效的产出最终决定了研发产出的有效性。也是持续的，对当下，对长期影响最小的交付方式。但当质量和效率只能二选一时，是优先选择效率，还是说选择质量？这个问题貌似不应该存在，效率高事做的再快，质量不好也不上了线；质量高无bug，事干不完同样也上不了线。为啥我还在这碎碎念，质量高于效率呢，这个得从影响面来看。当一位研发人员，负责的一件事，质量不好，影响的是
在架构优化的早期，还处于研发或方案设计的阶段时，当研优化相关的需求还没有完成能力的构建，对于技术方案的影响比如，核心指标的变化，用户体验的变化，资源消耗的变化等还处于一个理论的状态，在真实的使用场景的数据是什么样，用户使用的真实体验如何还是未知，如果技术方案可能存在对业务指标产生影响，关于指标变化的摸底还是有必要放在技术方案中一起推进落地的。评估主要分为两类，一类为线下评估，一类为线上评估。线上评
把一个App作为一个整体来看，架构的优化会涉及到这个App当中的任意一个模块。优化的工作也必然涉及到了人力的问题和资源的协同。架构的优化工作在人力的安排上主要有两种方式，1）一种是有专门的团队来对接架构优化的工作，2）另外一种呢，是有几个人明确架构，优化方案和目标，推进在团队当中不同的方向进行落地。第一种方式通常使用专项的方式来推进架构的优化，在这个过程当中不同的角色都有相关的人员参与，并提前确认
计划的设定影响着团队资源的投入产出，如何设定站在不同的角度都有着不同的思考，计划的设定的过程就是提前基于目标和方案，划分为不同的实施路径的过程，如实的讲，没有完美的计划，只有最适合的计划，结合架构优化过程的需要，以下七个因素影响计划的设定的关键。目标：目标是计划设定的基础，以完成目标为根本，对达成目标的相关信息进行计算和划分；一般来讲计划的目标和技术方案的目标是同一个目标，基于同一个目标中的技术方
问题是在我们日常的工作当中经常使用的词语，部分同学对于这个词比较敏感，不愿意主动提出问题，也不愿意正视问题的存在。客观的讲，问题已经存在了，不会因为没有人提就变成不存在，反而因为有人关注问题，关于问题的产生带来的影响可以较快的感知，及时对于问题进行修正，可以有效的避免问题带来的影响累加，和规避问题的性质改变的可能。如实的讲在工作中，团队/产品中当下的或将来潜在问题的解决过程实际上就是机会，以系统架
在系统的生命周期内，架构问题的发现主要有两种，一种为主动发现，一种为被动发现。一般在团队中成长起来的高阶工程师，对团队的技术及业务都会有一定的了解，对现有的技术架构存在的问题也会有着一定的了解，结合业务的需要及将来的趋势，主动的提出问题，并解决问题是架构的持续优化之道。大部分研发人员不愿主动提出问题，主要的原因有一个就是惧怕冲突，如果这个问题自己能够做到很客观地去评估和针对具体的事情去解决，这件事
在每一个产品（本文中以系统代替）的生命周期中，系统的技术架构，都会经过从无到有的构建，也会根据需要而进行重构，那么每次架构优化工作的目标是什么？倒底优化的是什么呢？有一段时间，一直困扰着我，架构优化的价值何在？倒底有多么的重要？经过长时间的思考之后，得出来的一个关键词就是“赋能”，直接的讲，就是给系统赋予新的能力，可以基于新的架构实现更多的事情，实现当下不可实现的能力，赋予系统更多的可能性，这些可
技术架构的优化有一个重要目标就是为业务赋能，技术架构支持业务实现更多的能力，可以高效的支撑业务的扩展，服务于用户，最终间接的提升产品的价值。要作技术架构的优化，首先理解业务，业务理解不足，技术架构与业务的融合成本就会提升，甚至会因为架构优化的工作无法保证优化前后的业务一致性，而无法上线。对于业务的深度理解是架构优化是一个前置的，必要的工作。在业务理解的目标，对于技术架构优化的过程可以产生以下几个帮
在软件的研发生命周期中，一部分工作是显性的，可以明确资源的投入；也有一部分工作是隐性，资源的投入是后知的不可明确的。对于显性的资源投入，团队可达成共识，每位参与研发过程的人员基本上都要有在对应的节点投入精力。在时间的评估时较容易想到并提前预留时间而进行相关工作的开展，常见的如需求理解、方案设计及评审，规划及计划、研发及测试等工作。对于隐性的资源投入，在团队中与具体的研发人员所处的业务方向，研发方式
技术决策，这个一个与选择有关的话题，当一个研发人员，成为团队的高阶研发人员/架构师，意谓着有较多的资源可以影响。同时也会存在，一些错误的决定，没有正向的反馈，也会被执行的情况。架构师在技术方案的错误决策主要原因有三种识知不足：技术决策的内容，超出个人的当下认知范围，比如新技术，新领域，新业务，评审过程对于相关的内容不清楚，很难发现方案中的潜在的风险。私心驱动：技术方案对于个人（或相关）是最优的，但
一般来说，一个客户端产品会在不同的平台均有发布及为用户提供服务，在技术方案设计的过程中，多个平台的系统提供的API架构不同，对于特定的能力实现的流程和机制也有不同，一些开源的能力实现风格也有所不同，技术方案的设定就会存在多端的方案不对齐的情况。基于同一个功能点，确定相关的技术点都是需要实现的，如果多端的技术方案没有对齐，会存在以下5个直接或间接的影响。技术实现不统一：因平台特性不同，能力也有所不同
评审工作是研发过程中经常性的工作，在研发工作过程中研发人员会评审其他人员的相关事项，也会邀请其他人员评审自己的相关的事项。常见的评审如：需求评审、方案评审、计划评审、代码评审、规范评审、配置更新评审及bug修复评审等等。为什么需要评审呢？是否有评审的必要呢？不评审是不是事情就做不了呢？答案是需要的。参考百度百科中的定义，评审，指评议和审查；审议。一般是比赛的时候需要评审来决定选手的比赛结果。抽象
在日常的研发工作中，CodeReview（以下简写为CR）是代码交付的一个重要环节，通过CR可以提前发现代码潜在风险与BUG，提升系统的可维护性，降低事故的概率及修复成本。长期来看CR促进了团队内部知识共享，提高团队整体水平。CR过程对于研发人员来说，也是一种思路重构的过程，也可以帮助更多的人理解系统。研发人员的时间有限的，CR过程是一个研发人员自我要求较高的事情。作为CR的发起人，需要想清楚，希
在日常的研发过程产品质量的产生本身内部代码逻辑，导致的异常的占比较高，而因为数据产生的一异常比例较低，常见于客户端与服务端的通讯产生的数据和客户端本地存储的数据产生的异常，这类异常复现的成本也相对的高一些，比如需要产生数据交互的行为，或产生数据的存/取的行为，甚至还是版本兼容问题导致，复现的周期比较长。一般来讲，常见的异常的产生有以下几种情况空数据：下发的数据中部分的节点数据为空，解析出来的数据和
51CTO博客开发
图像识别过种中，由于图片的来源不确定，文字信息在图片中的大小比例也不确定。所有的工作都交给识别模块来处理，工作量是不是会很大？如果需要云端介入，网络的传输数据量会不会影响应时长？
移动设备的产品的网络状态取决于用户所处的网络环境。这个网络环境也会根随的用户的位置进行改变。这篇是关于移动APP中的网络请求超时时长设定的思考及方案。保证了不同网络下，不同的数据量的请求有效性并在网络状态不佳时及时的通知用户。
1．“博”与“专”上的迷失 假设说一个人的学习已经聚焦，并且学习的内容和自己实际参与的项目也相吻合，那么是不是就没有问题了？很不幸，答案仍然是否定的，在任何一个子领域里，仍然需要进一步去考虑“博”与“专”的均衡。 对于软件开发而言，设计是再常见不过，再简单不过的一个词了。可如果把视角拔高一点就会发现，单以设计而论仍然是一个不可穷尽的领域，我们可以快速扫描一下和设计相关的部分概念
（via:破船之家，原文：Provision iOS IPA App for In-House Enterprise Distribution） 在企业内部分发 iOS 应用程序非常复杂。经过努力，我成功实现了在企业内部的应用程序分发。我决定用此文来记录我的最佳实践方法，以供将来参考。 如果你希望通过 Safari 能在任意的 iOS 设备上安装应用程序 (不需要发布到 App
1. 概述大部分APP设置项都通过Cocoa preferences system：userdefaults system完成。 2. 关于user defaults system2.1 创建一个正确的preference使用简单的数据值、数据类型支持string、number、dat
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
