代码评审

软件生命周期 软件测试要经过一个什么样的过程呢，这就要从软件的生命周期开始说起了。 软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到报废的生命周期。 整个生命周期包括问题定义与规划、需求分析、系统设计、软件编程、软件测试、软件运维等阶段。 在周期内，无论是开发还是测试都依赖于某个模型进行作为依据，有效地提高开发、测试效率。 软件开发模型 在软件开发的实践中，总结了很多软件的开发模型来描述和表示一个复杂的开发过程，如果瀑布模型、快速原型模型、螺旋模型等。 软件测试与软件开发模式有着紧密的关系，作为一名测试人员，应该充分理解软件的开发模式，尽快的找准自己的位置，从而尽快的发挥自己的价值。 瀑布模型 瀑布模型是线性模型的一种，在所有的模型中占有重要的地位，是所有其他模型的一个基础。 瀑布模型如同工地里的建造盖房流程，使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。 测试的切入点，开发完成后，必须留给测试足够的时间给测试人员，否则可能会导致测试不充分，导致很多问题到项目的后期才体现出来。 优点 明确划分了软件生命周期的各个环节。 强调早期软件计划，需求分析比较重要。 清晰的工作流程，便于分工协作。 适合需求稳定的产品开发。 每个阶段都有一个检查点。 缺点 线性的开发流程，存在巨大的风险。 依赖于早期的需求调查

一、环境介绍 随着软件开发需求及复杂度的不断提高,团队开发成员之间如何更好地协同工作以确保软件开发的质量已经慢慢成为开发过程中不可回避的问题。Jenkins自动化部署可以解决集成、测试、部署等重复性的工作,工具集成的效率明显高于人工操作;并且持续集成可以更早的获取代码变更的信息,从而更早的进入测试阶段,更早的发现问题,这样解决问题的成本就会显著下降;持续集成缩短了从开发、集成、测试、部署各个环节的时间,从而也就缩短了中间出现的等待时间;持续集成也意味着开发、集成、测试、部署得以持续。所以,当配置完Jenkins持续集成持续交付环境后,就可以把发布的任务交给集成服务器去打理了。使用Maven(Ant)等来实现Java项目自动化构建发布部署。这些工具可以帮助在构建过程中实现自动化发布、回滚等动作。 二、jenkins简介 Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后,项目从 Hudson项目独立。 官方网站: https://jenkins.io/ lenkins提供了软件开发的持续集成服务。 它运行在Servlet容器中(例如Apache Tomcat)它支持软件配置管理(SCM)工具(包括AccuRev SCM, CVS, Subversion,Git, Perforce.Clearcase和RTC),可以执行基于Apache

转载： https://blinkfox.github.io/2018/11/24/ruan-jian-she-ji/ruan-jian-cheng-xu-she-ji-yuan-ze/ （原文更漂亮，转载此处，仅为了方便自己阅读） 一、前言 软件也像人一样，具有生命力，从出生到死亡，会经历多种变化。软件架构设计也不是一蹴而就的，是不断地演进发展。每个程序员都可以从理解编程原则和模式中受益。 软件设计原则是一组帮助我们避开不良设计的指导方针。根据 Robert Martin 的理论，应该避免不良设计的以下三个重要特点： 僵化 ：很难做改动，因为每一个细微的改动都会影响到系统大量的其他功能 脆弱 ：每当你做一次改动，总会引起系统中预期之外的部分出现故障 死板 ：代码很难在其他应用中重用，因其不能从当前应用中单独抽离出来 下面这些软件设计原则是我从一些书籍和网络中收集而来，并不完整，而且你也需要在一些有“冲突的原则”之间进行权衡和取舍。本文或许会对你的编程、程序设计、讨论或评审工作有所帮助。 二、通用设计原则 1. KISS 所谓 KISS 原则，即： Keep It Simple,Stupid ，指 设计时要坚持简约原则，避免不必要的复杂化，并且易于修改 。 Everything should be made as simple as possible, but not

教材学习内容总结 这一周学习了各种指令格式，并在Pep/8上运行了小程序。知道了汇编语言。认识了伪代码，知道了如何测试程序 教材学习中的问题和解决过程 问题1：想多了解一下汇编语言及各种语言进化过程 解决方案：通过查资料我知道了早期的程序设计均使用机器语言。程序员们将用0, 1数字编成的程序代码打在纸带或卡片上，1打孔，0不打孔，再将程序通过纸带机或卡片机输入计算机，进行运算。但由于用机器语言编写程序，编程人员要首先熟记所用计算机的全部指令代码和代码的涵义。手编程序时，程序员得自己处理每条指令和每一数据的存储分配和输入输出，还得记住编程过程中每步所使用的工作单元处在何种状态。这是一件十分繁琐的工作。编写程序花费的时间往往是实际运行时间的几十倍或几百倍，而且，编出的程序全是些0和1的指令代码，直观性差，如果有错写也很难查找。所以汇编语言诞生了。汇编语言的主体是汇编指令。汇编指令和机器指令的差别在于指令的表示方法上，汇编指令是机器指令便于记忆的书写格式。我们用汇编语言编写程序，但计算机只认识机器指令，这时候就需要一个能将汇编语言转换成机器指令的工具，就是编译器。程序员用汇编语言写出源代码，再用汇编编译器将其编译为机器码，最后由计算机执行。 汇编语言是直接面向处理器（Processor）的程序设计语言。处理器是在指令的控制下工作的，处理器可以识别的每一条指令称为机器指令

背景 随着公司业务量的飞速发展，平台面临的挑战已经远远大于业务，需求量不断增加，技术人员数量增加，面临的复杂度也大大增加。在这个背景下，平台的技术架构也完成了从传统的单体应用到微服务化的演进。 系统架构的演进过程 单一应用架构（第一代架构） 这是平台最开始的情况，当时流量小，为了节约成本,并将所有应用都打包放到一个应用里面，采用的架构为.net+sqlserver: 位于最外层（最上层），最接近用户。用于显示数据和接收用户输入的数 据，为用户提供一种交互式操作的界面，平台所使用的是基于.net的web形式。 业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。 业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。 如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。 数据访问层：有时候也称为是持久层

持续集成（Continuous integrationI） 是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。 目的就是让产品可以快速迭代，同时还能保持高质量。 核心措施是代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。 持续交付 (Continuous delivery) 频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 可以看作是持续集成的下一步，它强调的是不管版本怎么更新，软件是随时随地可以交付的。 持续部署(continuous deployment) 是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 目标是代码在任何时刻都是可部署的，可以进入生产阶段。 前提是能自动化完成测试、构建、部署等步骤。 来源：博客园 作者： tongyishu 链接：https://www.cnblogs.com/tongyishu/p/11682104.html

本章从微观上关注编程过程――也就是关注创建单独的类及其子程序的特定步骤。本章还将讲述伪代码编程过程，这种编程有助于减少设计和编写文档所需的工作量，同时提高这两项的工作质量。 先对一个类做总体设计，列出这个类内部的特定子程序，创建这些子程序，然后从整体上复查这个类的创建结果。 创建一个类的关键步骤如下： 创建类的总体设计； 创建类中的子程序； 复审并测试整个类。 创建子程序涉及到的活动： 设计子程序； 检查设计； 编写子程序的代码； 检查代码。 有效使用伪代码的指导原则： 用类似英语的语句来精确描述特定的步骤； 避免使用目标编程语言中的语法元素； 在本意层面上编写伪代码； 在一个足够低的层次上编写伪代码，以便可以近乎自动地从它生成代码。 一段不好的伪代码示例 increment resource number by 1 allocate a dlg struct using malloc if malloc() returns NULL then return 1 invoke OSrsrc_init to initialize a resource for the operating system *hRsrePtr = resource number return 0 一段好的伪代码 keep track of current number of resource in use

Git 协作流程5 Git 作为一个源码管理系统，不可避免涉及到多人协作。 协作必须有一个规范的流程，让大家有效地合作，使得项目井井有条地发展下去。"协作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 本文介绍三种广泛使用的协作流程： Git flow Github flow Gitlab flow 如果你对Git还不是很熟悉，可以先阅读下面的文章。 《Git 使用规范流程》 《常用 Git 命令清单》 《Git 远程操作详解》 全部回复 实验楼管理员 L64 一、功能驱动 本文的三种协作流程，有一个共同点：都采用 "功能驱动式开发" （Feature-driven development，简称FDD）。 它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。 二、Git flow 最早诞生、并得到广泛采用的一种协作流程，就是 Git flow 。 2.1 特点 它最主要的特点有两个。 首先，项目存在两个长期分支。 主分支master 开发分支develop 前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。 其次

安全注意事项 虽然它通常是很容易建立一个运行正常的软件，它是更难检查，没有人能在这是一个方式来使用它没有预料到的。 在Solidity中，这更为重要，因为您可以使用智能合约来处理令牌，或者甚至可能使用更有价值的东西。此外，智能合约的每次执行都是在公共场合进行的，除此之外，源代码通常也是可用的。 当然，你总是要考虑有多大危险：你可以将智能合约与对公众开放的网络服务（以及对恶意行为者）甚至是开源的网络服务进行比较。如果您只将购物清单存储在该网络服务上，则可能不必太在意，但如果您使用该网络服务管理您的银行帐户，则应该更加小心。 本节将列出一些陷阱和一般安全建议，但当然可以永远不完整。另外，请记住，即使您的智能合约代码没有错误，编译器或平台本身也可能存在错误。可以在已知错误列表中找到编译器的一些公知的安全相关错误的 列表，这些错误也是机器可读的。请注意，有一个bug bounty程序，它涵盖了Solidity编译器的代码生成器。 与往常一样，使用开源文档，请帮助我们扩展此部分（特别是，一些示例不会受到伤害）！ 陷阱 私人信息和随机性 您在智能合约中使用的所有内容都是公开可见的，甚至是标记的局部变量和状态变量private。 如果你不希望矿工能够作弊，在智能合约中使用随机数是非常棘手的。 重入 合约（A）与另一合约（B）之间的任何互动以及任何以太方移交控制权转移到该合约（B）

本文转载于: 猿2048 网站➫ https://www.mk2048.com/blog/blog.php?id=ckik00kib 对于中大型前端项目，项目规范与代码质量尤为重要。当功能需求变更或需要重构时，随心所欲的(糟糕的)代码可能带来比重新开发还麻烦的问题。 1 前端项目代码中的常见问题 1.1 凌乱的书写风格，阅读体验差 这个问题不用作过多阐述，想必接手过他人代码的同学，多少都有些体会。简单来说，太过随意的代码会让强迫症患者难以容忍，难以阅读理解的代码有时甚至不如推倒重来。 1.2 低质量的编码，bug 不断 什么样的代码是低质量或高质量的？好的代码可能会让你如读小说一般被吸引，糟糕的代码会让你看一眼就不想继续、甚至看半天而不知所云。 有人可能认为初级程序员才会有这种问题，其实不然，一些工作经验两三年的同学写的代码依然如此。对于一些个人自学意识不够积极、没有团队规范性指引的同学，很容易习惯成“学习半年、然后重复三年无长进”的情况。 拿出来你可能不太愿意相信，下面这些例子即来源于真实项目。你能尽可能地找出其中存在的各种问题吗？ 图1 图2 图3 图4 图5 图6 图7 以上只是截取的一些很简短的列子，那么涉及大块复杂逻辑的地方会是怎样的，试试发挥一下你的想象力。 1.3 功能不分离，逻辑糅合，难以阅读和理解 这种问题其实是非常普遍的。 一个函数几百行、一个文件数千行