数据建模名称规范
综合 NV + DiDi + Ali 的各种命名规范。 DO（ Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。 DTO（ Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。 BO（ Business Object）：业务对象。 由Service层输出的封装业务逻辑的对象。 AO（ Application Object）：应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。 VO（ View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。 POJO（ Plain Ordinary Java Object）：POJO专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。 Query：数据查询对象，各层接收上层的查询请求。 注意超过2个参数的查询封装，禁止使用Map类来传输。 Entity：JPA 规范下从数据持久层存储里取出来的对等对象。其实相当于 DO 。 Request：RESTful 接...
业务分析方法
背景 从 prd 出发，分析业务需求，寻找可以创造价值的方案。 业务分析的价值 全面分析用户的各项需求 告诉我们“做什么” 业务分析的目的 理解产品需求，识别业务范围 分析业务模块的重要程度、优先级 发现产品设计的不足 为后后续测试分析做准备 业务分析方法-整体过程 用不同的动作达到不同的产出。 理解 需求背景（必须） 举例：阿里巴巴账户体系 要初步阐述：1. 产生什么价值。 2. 需要解决什么问题。3. 甚至要阐明要达到什么目标（比如，基于支付宝账户体系统一账户id）。 现状分析（必须） 产品定位 现有业务架构 产品业务范围 规划业务架构**（1. 要有分期的意识，识别产品形态。 2. 要有清洗数据的方案，预测安全风险）** 识别（抽象分析建模） 业务角色（实际上就是系统交互的输入方，有多少个角色，就需要关注多少个东西） 自然人 其他系统 业务串联（为了找业务用例。业务串联就是把一堆文字描述串在一起） 业务用例（建模-业务用例图 用例是对场景的概括） 分析业务用例（建模-活动图 活动图是对用例的拆解） 提炼（进一步建模） 关键流程 由活动图的 ...
系分方法论交流笔记
分析、设计和架构的区别 系分 = 业务分析 + 系统设计 系分其实就是 Analysis + Design 业务分析才是最重要的大头 要理解： 架构约束 项目约束 要有： 权衡 选择 的过程 理解业务，要理解业务背后的东西，产出的是模型。 一步一步走，推演出来解决方案，要有方法论。 系统设计是很明确的工作了 应用设计 + 数据设计 + 技术设计 = 系统方案 要考虑的额外问题： 非功能设计：运行关注点、运维关注点、开发关注点、测试关注点。 项目约束 常见方法论 用例驱动设计 SOAD 面向服务的分析和设计 OOAD 面向对象分析和设计 DDD 领域驱动设计 DDD特别适合复杂系统。有一个以不变应万变的对象，才可以在未来承载复杂的业务演进过程。 这几种方法论可以混合使用。 需求分析与业务建模 把 prd 从薄读到厚，把文档中缺失的部分补全。 系分做 PRD 评审的时候，影响比较大的点一定要尽早确认。一些对系统变化可控，可预测的变化，可以暂时放过，后续在补充。 面向服务的业务建模 分析主业务服务，设计业务功能域，设计业务功能域边界。这个过程可能不断地螺旋式地重构。 如果用...
日期与时间
JSR 310 Java Date与Time API 新旧 API 的更迭 旧的 Java API 主要包括java.util.Date和java.util.Calendar 两个包的内容。这两个包的时间类型是可变的。如 Date 的实例可以通过 setYear 来产生变化。 JSR 310 中包括的日期类型主要有： 计算机时间：Instant，对应 java.util.Date，它代表了一个确定的时间点，即相对于标准Java纪元（1970年1月1日）的偏移量；但与java.util.Date类不同的是其精确到了纳秒级别。 人类时间：对应于人类自身的观念，比如LocalDate和LocalTime。他们代表了一般的时区概念，要么是日期（不包含时间），要么是时间（不包含日期），类似于java.sql的表示方式。此外，还有一个MonthDay，它可以存储某人的生日（不包含年份）。每个类都在内部存储正确的数据而不是像java.util.Date那样利用午夜12点来区分日期，利用1970-01-01来表示时间。这些类型的实例是 immutable 的，而且只能通过工厂方法创建。 时区...
使用 Truffle 来编译、安装智能合约(旧文一篇)
因为官定版本的 solidity 实在编译安装太费力了，放弃，改用 Truffle。 直接用 npm 安装： 1npm install -g truffle 创建新目录，初始化新目录： 123mkdir myprojectcd myprojecttruffle init 修改配置文件 truffle.js: 12345678910 module.exports = { networks: { development: { host: "localhost", port: 8545, network_id: "*", // Match any network id gas: 500000 } }}; 生成必须的智能合约源码和迁移脚本： 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253...
以太坊深度研究合集（2017-2018 旧文整合）
本文整合了 2017 年 10 月到 2018 年 8 月间一系列以太坊学习与实战笔记，包括工作机制、Gas 系统、事务与消息调用、随机数问题、硬分叉、谢灵点应用、为什么以太坊不适合做联盟链，以及 CentOS 6.7 上 geth 私链搭建、web3 安装、solidity 智能合约部署等实战。三篇 2018-08-29 的"旧文一篇"已统一收录于第五至第七章，作者当时的"旧文回顾"语气一并保留。 一、概述 以太坊（Ethereum）是一台 transactional singleton machine with shared-state——事务性状态共享的单例机器。实际上就是逻辑上唯一，但物理上由多个节点维护的共识中的 world computer。这台机器的状态是由事务变迁驱动的： 以太坊的核心区别于比特币的设计点： 引入 EVM 与图灵完备的智能合约 账户模型而非 UTXO 用 Gas 系统作为算力定价与防滥用机制 默克尔帕特里夏树存储状态、事务和收据 “幽灵协议”（GHOST = Greedy Heaviest Observe...
如何做性能测试的问题下的答案
试着回答一下这个问题。 首先要划分系统类型：有状态还是无状态，业务系统还是存储系统。根据不同的业务场景，设立性能测试的目标：是要测 QPS，还是 TPS 还是 TPS，还是任何其他【性能】-从广义来讲，一个存储系统到底能够以多高的平均时延来管理大多的存储空间，可能也是性能的一种。 有了性能测试的目标，接下来就是拆解用例。如果把性能测试归为测试的话，测试就需要测试用例，测试用例只是用例的形式化表达。把用户的使用场景勾勒出来，把每一步拆解成的流程图或者时序图–我们已经得到了一个纸上的集成测试计划，只是没有跟性能挂上钩。 接下来就进入真正写测试用例的环节了。 我们的测试报告如果要涵盖足够立体的信息，则既要了解每一个环节/接口/API 的性能指标，又要了解整体的性能指标。 这个时候测试工具的覆盖面就很重要了。如果我们选择偏黑盒的测试工具，apache ab /JMeter，则我们的测试用例就要围绕着对外交互的 API写，也只能测到外围接口的性能。这样的测试用例写起来最简单，无需侵入任何内部代码中。 如果我们使用了 JMH 一类的工具，则可以自由编写对任何方法的测试用例。但需要对系统有非常...
log 的历史
Log：一种被低估的计算机科学基础抽象 在计算机科学中，log（日志）远不止是"打印调试信息"那么简单。从数据库的 WAL 到分布式系统的共识协议，从版本控制系统到区块链，log 作为一种 append-only 的有序记录序列，是贯穿整个计算机科学发展史的核心抽象之一。 LinkedIn 的前首席工程师 Jay Kreps 在其著名文章 “The Log: What every software engineer should know about real-time data’s unifying abstraction” 中指出：log 是一种比消息队列、数据库、文件系统更基础的抽象——后者都可以建立在 log 之上。 本文尝试梳理 log 这一抽象在不同技术领域中的演化脉络。 数据库中的 Log：WAL 与 Binlog WAL（Write-Ahead Logging） WAL 是数据库实现 ACID 特性的基石。其核心思想是：在修改数据页之前，先将修改操作写入日志。 WAL 的工作流程： 事务开始时，将修改操作（redo log entry）追加写...
JPA 的 id 生成策略
JPA 有一个@GeneratedValue注解，有一个strategy attribute，如 @GeneratedValue(strategy = GenerationType.IDENTITY)。 常见的可选策略主要有IDENTITY和SEQUENCE。 GenerationType.IDENTITY 要求底层有一个 integer 或者 bigint 类型的自增列（ auto-incremented column)。自增列的赋值必须在插入操作之后发生，因为这个原因，Hibernate 无法进行各种优化（特别是 JDBC 的 batch 处理，一次 flush 操作会产生很多条insert 语句，分别执行）。如果事务回滚，自增列的值就会被丢弃。数据库在这个自增操作上有个高度优化的轻量级锁机制，性能非常棒。 MySQL 支持这种 id 生成策略， 使用 MySQL 应该尽量使用这个策略，即使它无法优化。 JPA 用它生成 id，会一条一条地插入新的 entity。 GenerationType.SEQUENCE 数据库有一个所谓的 sequence 对象，可以通过 selec...
Convention over Configuration over Programming
什么是 Convention over Configuration over Programming 在软件工程中，有一条重要的设计哲学层级： Convention over Configuration over Programming 约定优于配置，配置优于编程。 这条原则的核心思想是：能用约定解决的问题，就不要引入配置；能用配置解决的问题，就不要写代码。 它反映了软件设计中对复杂度管理的追求——越是高层次的抽象，使用成本越低，出错概率也越小。 三个层次的含义 Programming（编程） 编程是最灵活但成本最高的方式。开发者需要编写具体的代码逻辑来实现功能。每一行代码都是潜在的 bug 来源，都需要测试、维护和 review。编程适合处理那些真正需要定制化逻辑的场景。 Configuration（配置） 配置是介于约定和编程之间的中间层。通过外部化的配置文件（如 XML、YAML、properties 等），开发者可以在不修改代码的情况下改变程序行为。配置降低了修改成本，但引入了配置管理的复杂度——配置项越多，理解和维护系统的难度就越大。 Convention（约定） ...
