敏捷开发

建议先阅： https://blog.csdn.net/Su_Levi_Wei/article/details/89313778 建议先阅： https://blog.csdn.net/Su_Levi_Wei/article/details/94206222 无数疑问 在互联网行业中，我们常常会听到敏捷开发这个词，但敏捷开发是什么，我们是否真的需要敏捷开发这个东西？即便真的需要敏捷开发这东西，要怎么去用好这个东西？用这个东西之前有没有条件？和以前的瀑布流开发有什么区别？ 最重要的是这东西是否真的适合当前的团队？ …… 瀑布流开发（传统） 在这种管理方式中，可以发现，就跟工厂的流水线那样，一环扣一环，因此我更喜欢称为流水线。 在这种管理方式中，可以发现有着很严重的问题。后面的人要等待前面的人做完，在前面的人没有做完时，后面的人就会一直空闲着，前面的人做完了，后面的人就会很忙碌，这时就变成前面的人很空闲。 有人会想，这个问题很好解决。 前面的人做完了，就给下一个项目的任务给他，或者是给别的任务给他，问题在于这个人做完了，空闲下来了，此时你分配别的任务给这个人时，测试刚好测出了问题，这时又问题，刚分配的这个新的任务如果没有做完，后面的人又要等待。如果测试测出的问题不去解决，在这个问题涉及的流程中就要停下来了，因为测不了了…… 就这样一直循环时，就会造成测试很累、开发很累。

现在我们有一个大坑，缺少软件设计、质量保障，项目leader常常盲目强调快速迭代，项目最终会陷入到质量腐化、Bug百出、交付失控的悲惨境地。 对这种空谈快速响应变化的“敏捷”，我更喜欢叫他“中华田园敏捷”。 你真的知道敏捷开发的根本原理吗： 缺少可重构性的软件，不可能快速响应变化。 没有高覆盖率、快速运行的单元测试，重构就不可能落地。 测试驱动开发是获得高质量单元测试集的唯一有效方法。 建立在充分覆盖且运行快速的自动化测试基础上的持续集成是迭代式开发的必要条件。 我们发现：极限编程是唯一将开发技术实践提到核心地位、构建完整软件交付流程的敏捷方法论。 刻意训练、实践极限编程，是提高开发效率、实践敏捷开发的必要环节。 如何避开猪队友，抛弃田园敏捷开发，实践真正的TDD？ 有没有想过一个场景，和一线开发者结对编程，在【教练】带领下用半天时间，完成敏捷开发核心项目，输出优质代码。 12月21日，周六下午1点30分，「极客练功房」欢迎你免费参加。 参与人数：免费 每场限30人 首期主题：TDD敏捷开发实践 面向人群： 具备初级开发基础，无论从事前端还是后端均可，没有语言限制； 追求卓越技术，希望实践极限编程的一线开发者； 经验不限，想突破技术瓶颈，跳槽一线大厂的进阶程序员； 技术leader，想整体提高团队效率，完成质的飞跃。 什么是「极客练功房」？ 「极客练功房」是工作坊、是训练营

个人回顾总结 一、开课提出问题 第一次博客地址： https://www.cnblogs.com/Slow-Walker/p/11513179.html 二、问题回答 2.1问题1：针对单元测试 怎么保持单元测试的孤立性呢，假如测试方法中的参数过多就会造成在被测试方法业务逻辑复杂，而且会频繁调用其它接口，他的优缺点具体有哪些呢？ 课程学习回答：通过本次的课程的学习以及后面的单元测试项目实践、以及最后的团队项目实践都用到了单元测试，也较为深刻的掌握了单元测试的方法以及他的测试，也深刻的体会到了他的优点缺点；首先是采用自顶向下的单元测试策略，解决单元测试孤立性问题，实践的步骤如下： （1）以单元组件的层次及调用关系为依据，从最顶层开始，把被顶层调用的单元做成桩模块。 （2）对第二层单元组件进行测试，如果第二层单元组件又被其上层调用，以上层已测试的单元代码为依据开发驱动模块来测试第二层单元组件。同时，如果有第二层单元组件调用的下一层单元组件，则还需要依据其下一层单元组件开发桩，桩的数量可以有多个。 （3）依此类推，直到全部单元组件测试结束。 项目中体会到它真正具备的优点个人总结如下： 因为单元测试是直接或间接地以单元组件的层次及调用关系为依据，所以可以在集成测试之前为系统提供早期的集成途径。由于详细设计一般都是自顶向下进行设计的，这样自顶向下的单元测试策略在顺序上同详细设计一致

课后总结： 回望课程初期，对这门课程是感到迷茫的，并不清楚这门课程会为我们带来什么有价值有意义的东西，记得在第一次博客作业的时候，根据博客要求提出了一些相对迷惑的问题，那经过几个月的学习，让我对当初的问题有了见解和答案。 https://www.cnblogs.com/YMIng123/p/11490235.html 当初所提的问题篇幅可能有点长，因此当我解答问题时对题目只进行简单的阐述。 问题1：团队模式中的最优模式时什么？ 阐述：书中向我们举例了很多的团队模式，如明星模式，秘密团队等等，同样也例举了瀑布模型，敏捷开发模型等团队开发模型，那面对如此多的团队模式模型，我们或许会苦恼哪一种的结合时最优的模型模式，起初我以为秘密团队时最优模型，但是经历了这几个月的敏捷开发模型，又感觉出敏捷开发更适合我们。我网上查阅了相关资料，并没有哪一个说出x是最优模式，针对于不同的开发环境及规模吧，也就是因地制宜，不同的场景适合不同的模式。 问题2：没有风险就是最大的风险，作者为什么会这么说？ 阐述：风险是较广义的词，不仅仅标识者我们所说的Bug，也有可能是其他非客观因素，如资金，人员，技术等，作为开发人员，我们总是希望避免Bug的产生，但是，没有风险就是最大的风险，我认为它暗示着一些隐含的因素，也就是在开发过程中包括测试过程种尚未发现的问题。一旦由用户发现或者是由黑客发现，可能会直接导致软件崩溃

提到DevOps这个词，我相信很多人一定不会陌生。 作为一个热门的概念，DevOps近年来频频出现在各大技术社区和媒体的文章中，备受行业大咖的追捧，也吸引了很多吃瓜群众的围观。 那么，DevOps是什么呢？ 有人说它是一种方法，也有人说它是一种工具，还有人说它是一种思想。更有甚者，说它是一种哲学。 越说越玄乎，感觉都要封神啦！DevOps这玩意真的有那么夸张吗？它到底是干嘛用的？为什么行业里都会对它趋之如骛呢？ 今天这篇文章，小枣君就和大家好好聊一聊这个DevOps。 DevOps的起源 这个故事有点长，从头开始讲起吧。 上个世纪40年代，世界上第一台计算机诞生。从诞生之日起，它就离不开程序（Program）的驱动。而负责编写程序的人，就被称为“程序员”（Programmer）。 程序员是计算机的驾驭者，也是极其稀缺的人才。那个时候，只有高学历、名校出身的人，才有资格成为程序员，操控计算机。 随着人类科技的不断发展，PC和Internet陆续问世，我们进入了全民拥抱信息化的时代。越来越多的企业开始将计算机作为办公用的工具，用以提升生产力。而普通个人用户也开始将计算机作为娱乐工具，用以改善生活品质。 于是，计算机的程序，开始变成了一门生意。程序，逐步演进为“软件（software）”，变成了最赚钱的产品之一。 在软件产业里，程序员有了更专业的称谓，叫做“软件开发工程师

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 1. 编写产品backlog 参与人：po+测试负责人 主要责任人：Product owner 形式：excel 内容：ID,Name,importance,Initial estimate,How to demo,Notes 输出物：输出上述内容的excel，输出原型图、功能说明，复杂流程需要流程图 2. 准备sprint计划 责任人：scrum master 形式：无 内容：确认产品backlog井然有序 输出物：无 3. 制定sprint计划 参与人：all 主持人：scrum master 形式：wiki、邮件、白板等 内容： 1. sprint目标 2. 团队成员名单 3. Sprint backlog 4. Sprint演示时间 5. 确定scrum每日会议的时间地点 日程： 13:00-13:30 po介绍sprint目标，概括产品backlog，定下演示时间 13:30-15:00 估算时间，必要情况下按照索引卡的方式拆分backlog条目成任务 15:00-16:00 团队选择放入sprint中的故事，计算生产率 16:00-17：00 进一步拆分故事 输出物：1.确定演示时间 2.确定sprint目标 3.决定sprint要包含的故事 4.拆分故事成任务，并估算时间 5

任何一个领域都遵循从新人到熟手，从熟手到专家的路径。在成长过程中，DevOps人经常会陷入没人带，没人管，找不到职业方向的迷茫。 DevOps是在商业演进与企业协作的进化过程中诞生的一个全新职业，被很多人看成是一个“全栈”岗位，是能开发、会运维的复合型人才，但想要从事DevOps工作要从哪学起？如何入门？又该如何精进？ 我们对101名DevOps专家进行调研，问题只有一个：从入门到熟手，再从熟手到专家的成长路径中都看了哪些书？最终选出了39本推荐度最高的书籍，分成基础敏捷实战、敏捷测试、精益系列、技术工程、DevOps、教练、引导、大规模敏捷这8大部分，建议每一个DevOps从业者收藏阅读。 基础敏捷实战 《Scrum要素》 本书以一种轻松易懂、简洁精练的方式，介绍了Scrum 方法的核心要素。Scrum 入门级读物，内容精练，轻松易读，是帮助软件开发人员认识、初步了解Scrum 方法的佳作。通过阅读本书，可以厘清Scrum的相关知识和概念，为采用和实践Scrum 方法做好充分准备。 《敏捷革命：提升个人创造力与企业效率的全新协作模式》 本书由Scrum创始人写就，以讲故事的方式，讲述Scrum的由来，并逐步推进的过程。同样是入门级读物。 《Scrum精髓：敏捷转型指南》 如果想用Scrum来开发足以引爆流行的产品和服务，本书就是你梦寐以求的完全参考。

1.1 App后台的功能 远程存储数据 消息中转 1.2 App后台架构 如何快速提炼架构核心点，掌握架构的精髓？ 是在什么业务逻辑遇到哪些问题； 采用了哪些技术解决方案。 架构设计有哪些特点？ 架构是和业务紧密相关 架构的演变是由业务驱动 架构不是为了炫耀技术 1.3 App和App后台的通信 一般情况下，选择 HTTP协议 足够了；除非对App的安全性和性能要求极高，而选择私有协议。 App和服务器通信使用 短连接 ，除手游和聊天推送服务外，使用长连接。 App后台以 API的形式 提供给App使用。 App后台API以 JSON作为返回数据的格式 ，它比XML格式更省流量 。 1.4 App后台和Web后端的区别 App后台要慎重考虑网络传输的流量，主要在API设计、图片处理上 移动手机弱网络环境 手机电量有限 1.5 选择服务器 App产品经常会出现在毫无征兆的App访问量爆发的情况，解决访问的压力最快、最有效的方法是升级服务器的硬件，如升级CPU，升级内存容量或者升级带宽。 传统的IDC要升级CPU或升级内存容量的流程如下。 和客户经理商谈所需硬件的价格或在线选择具体的配置。 在线支付或银行转账。 确认钱到帐后，等待IDC安排工作人员升级硬件。 这个流程由于需要人工介入，很难做到几分钟内完成硬件升级。 而使用云服务器升级硬件就很简单，流程如下。

俗话说，文人相轻。我总觉得，技术人，也相轻。 从2018年8月换到现在的公司。 起初是表现过度，然后莽撞，到抱怨，到轻视别人，到现在的平复。 有时必须看清自己，更要承认别人。 表现过度 以为自己有点经验就了不起，入职后，对一些事情总是过度表现自己的看法。 还有种，我的看法天下第一的既视感。只有我对你们错的优越感。 一切都是虚荣心，这些过度的表现导致我没有看清周边同事的发光点。很长时间自己都在自己设的一个局里，无法自拔。 莽撞 有个系统正巧交接到我这，这个系统对外写了32个接口，花费了1个月。 你想知道我接到这个系统的第一件事是什么吗？ --重构 想在想想都难以想象啊，刚刚重构的系统，我竟然还想重构？ 对，我就是这样给领导说的：“薛哥，我想把这32个接口都放到类似一个回收站的文件夹里，有对接的系统使用接口，我就重构一个” 领导让我回去先一等，等有对接再说。就这样，我这根弦算是稍微冷却了一下。 听说公司要来一个大牛，姓杨，仓储物流领域算是经验丰富。我心想：我倒是看看有啥厉害的。正巧要开一个中台会，第一次参加。 没错，大牛会上对建设中台提出了10条疑问和建议。我认真记录了下来，完成了反怼。 现在再一想，我当初为了什么？就为了能够气势上压住所有人，工作上突出表现，升职加薪？ 抱怨 伴随着激进和莽撞，我又陷入了抱怨的深坑。 记得上面新重构的系统么。32个接口。有业务系统开始对接了。 此时

开篇 我们都知道开发一个软件必须要有开发的背景和特殊的需求等等，我们就来分析我们开发该系统的项目背景和开发该项目的目的。下面我们来分析下开发药店系统的目的 及可行性研究分析，对现有平台构建该项目的风险性等进行分析，可行性方案的分析。其他方面的因素分析。 大纲 1、总论 2、项目建设的背景和必要性 3、项目的方案设计 总论 我们既然要开发药店系统，那么我们必须知道开发这个项目的意义和目的，药店系统主要解决很多的药店的信息化管理，从采购到销售到财务管理等一体化的信息化系统 解决方案。该系统包含药品采购管理，药品库存管理，药店销售管理等子模块，药店信息管理软件针对我国医药企业药品经营管理特点（尤其是中小型药店销售商）而特别设 计，符合GSP管理规范，软件界面设计简洁，美观，其人性化的软件流程，使普通用户不需培训也能很快掌握软件操作使用方法，上手极易。药店信息管理软件广泛适用于医 药批发零售企业、药店、医院药房等用于药品进销存管理, 医药财务管理等场合，是您医药企业进行信息化管理的强大工具。 本药店系统结合AgileEAS.NET敏捷开发平台的完美实践，能够做到良好的扩展性和快速开发，我在现有的基础上通过1星期的时间完成了药店的所有功能，从需求-设计- 编码-测试等过程。可以充分体现AgileEAS.NET敏捷开发平台提供的工具的强大性。 项目建设的背景和必要性