yclfdn2004的专栏

hi,all      为减少客户端BUG数量，提高完全解决BUG的效率，现做提出如下规定:      1、需求理解到位:每次需求发布后，客户端会组织会议共同讨论需求点(包括任务task\排期\实现方案\可行性\流程)，保证精准达到需求。      2、大的需求功能，负责开发的人员需要说明技术方案。团队要做方案的review，以防止做完以后可能出现的坑。      3、自测的问题是

hi,android组：            大家在解决友盟日志的时候，找到了原因，要看一下我们的程序在其他地方是否有过类似的处理，触类旁通，一并改掉。            解决友盟日志的操作步骤：            1、根据crash日志、终端设备状况，分析原因。            2、修复问题并根据发生crash终端设备机型进行自行测试。           

1、Make Computer Science fundamentals very strong ,mainly Data Structure & Algorithm.　　拥有非常扎实的计算机科学知识基础，尤其是数据结构和算法。      2、Make a habit of solving at least 3-4 code snippets/Week, check

系统结构友盟自动更新系统的示意图如下：图中手机代表客户端。服务端的各个模块描述如下：WebConsole:提供上传更新包的网站操作界面。FS：文件系统，存储apk文件和增量更新包，增量更新的原理后文会提到。DB：用于存储文件的属性，例如版本号，更新描述，文件的md5等。Server: 接收客户端请求，返回文件下载链接。CDN：提供

一. 需求阶段1. 初期由leader或者项目责任人和PM沟通下阶段开发计划，确认需求的可行性和优先级等初步达成共识2. 接下来PM提供详细UE文档（需求颗粒感尽可能小）发起三方会议，由产品、开发和QA确认需求并达成一致，开发和QA可以对产品任意方面，提出看法和建议3. 最终的需求定稿，周知开发和QA，由QA开始编写测试案例4. PM容易忽略的需求：打点统计，新

经过这么多年的摸索与实践，初步总结一下：无论多好的系统架构，只有适合自己当前公司和自己公司目前人员架构的才是好的解决方案我选择了SSM（Spring SpringMVC Mybatis）作为最初的Server开发框架，绝大部分的工作也都是让阿里云帮助我们完成，结构如下图所示：前期可以用上面简单的，适合A轮前的。后期如果后面业务拓展起来，上面的架构，还可以继续的细

0：以RP为准看流程1、让产品过一遍2、让UI过一遍，让他们好好看一下3、两端对一遍4、对测有问题都相互提醒一下。