JimmyLv_吕立青
JimmyLv_吕立青
> PDCA 里面plan就是tasking产出test case，do就是写代码，check就是bad smell，然后action当然就是重构！ 但是 🐻 叔说 PDCA 太老了，大家都知道。 所以改用精益模型… 缩短build measure learn的反馈周期。 ## 其他几个模型： PDCA: Plan--Do--Check--Adjust Ray Dalio 的五步流程法GPDDD: Goal--Problems--Diagnosis--Design--Doing Eric Rise的精益创业理论DBML: Define--Build---Measure--Learn 孙陶然的16字方法论： 先问目的、再做推演、亲手打样、及时复盘 https://mp.weixin.qq.com/s/VUHRvx-Ny5mnlO5GkJjPLA
## 项目纵向拆分  工程化+创新+定制化+平台（自主权） 定制化软件服务（咨询、创新、平台） 数据可视化（业务、图表、设计、视觉、insights） 面对未来的创新化架构师（搞定沟通、快速学习） 个人DPS，数字平台战略（基础设施、量化自我） （via 智能创新服务领域工程创新能力最强的团队） ### ⓵ 定义目标和原则 ### ⓶ 展望结果（OKRs） ### ⓷ 头脑风暴（发散） ### ⓸ 组织整理（收敛） ### ⓹ 明确「下一步行动」 ## References - #200 -...
## 项目纵向拆分 ### ⓵ 定义目标和原则 - 技术牛逼（编程、架构、工程） - 构建影响力 ### ⓶ 展望结果（OKRs） - 发布一篇博客文章（同步至「前端的逆袭」知乎专栏） ### ⓷ 头脑风暴（发散） ### ⓸ 组织整理（收敛） ### ⓹ 明确「下一步行动」 - 总结工程实践的缘由和好处（有时候 benefit 这样的词还真找不到一个好的中文词） - 代码实践与示例 #277
## 项目纵向拆分 > “普元选择的对 API 契约的描述方式，是参考 swagger spec 规范，使用 yaml 语言来描述。当然，swagger 的描述是针对 restful 接口的，我们可以针对自己接口定义的需要，自定义自己的描述属性。” 深入浅出聊聊企业级API网关：http://mp.weixin.qq.com/s/j6OuJ8KwClWaJokofiN8wQ ### ⓵ 定义目标和原则 ### ⓶ 展望结果 ### ⓷ 头脑风暴 ### ⓸ 组织整理 ### ⓹ 明确「下一步行动」...
## 项目纵向拆分 举个 🌰 写个什么 Redux 的姊妹篇： 写完 Redux 核心概念和基本原理之后，然后分分钟写 3 篇： - Redux 与 React - Redux 与 vue -> vuex - Redux 与 ng 1.x & ng 2+...
 > 只要业务在发展，系统调整就是必然，因为处理不同量级的系统本质上就不是一个物种。真正挑战的是，怎么在高速行驶中，把奥拓改成奥迪。 似乎这也是TDD的痛，tdd更适合从无到有0到1，那1->better 1怎么做呢？ 先给遗留代码写测试，然后再放心大概重构吗？ 1. 根据业务功能写一个测试(AT) 2. 运行测试，测试通过，绿 3. 快速写一个新的实现(通常可以复制)，测试通过，绿 4. 重构新的实现，做进一步改进 5. 替换原有的实现，运行测试，绿 但是， > 补测试是个无底洞，因为一直在开发新功能。就好比今天吃昨天的剩饭，明天吃今天的剩饭 因为之前的代码在编写时没有考虑可测试性，没有合理抽象和分离关注点，导致后期添加单元测试的成本较高 在已经手工测试过证明没有问题的代码上添加单元测试，也让人有画蛇添足的感觉 并且按照以前的习惯，在需求变更或修复Bug后会进行手动测试，现在还要修改单元测试代码，更会造成一种「单元测试维护成本很高」的误解 如果能保证新增的代码都有测试覆盖，整体测试覆盖率就会持续上升 利用TDD（测试驱动开发）的方式，在开发新功能，修复Bug，做需求变更前，先新增或修改单元测试，再修改实现代码，单元测试通过即代表工作完成，减少了大量的手工测试和 Debug时间，在完善的单元测试覆盖下还可以进行大胆重构，这样将极大提高开发效率和代码质量 ＠小波老嬉 Sent...
via 《跃迁》 - 什么是问题树？ - 问题树跟知识树的区别 - 定义什么是有用？ - 如何使用问题树？ - 迁移成本（转化GitHub issues） Sent with GitHawk
ref: 移动 web 适配利器 - rem | AlloyTeam rem 数值计算 如果利用 rem 来设置 css 的值，一般要通过一层计算才行，比如如果要设置一个长宽为 100px 的 div，那么就需要计算出 100px 对应的 rem 值是 100 / 16 =6.25rem 对于使用 sass 的工程： 前端构建中，完全可以利用...
- define-build-measure-learn 中的measure - 如何埋点？ - 常用统计工具？ - 何种埋点有价值？ - 缩短验证周期？ - 时间维度上的潜在影响 - 对博客分析的作用 Sent with GitHawk
via [单页应用的HATEOAS实战 | 洞见](https://mp.weixin.qq.com/s/oeTs3qwRrpzmFdrjjhnGkw) **更容易让团队找到消除重复的“套路”。** 那么HATOEAS带来了什么优势？ 1. 只要客户端总是使用Link Rel来获取URI，那么服务端可以在不破坏客户端实现的情况下实现URI的修改，从而进一步解耦客户端和服务端。 2. 帮助客户端开发者探索API，Links实际上提示了开发者接下来可以进行何种业务操作，开发者虽然精通技术，但往往对于业务不甚了解，这些提示可以帮助他们理解业务，至少是一个查询API文档的好起点。 想象一下，如果某个API的响应中多了一个新的Link，敏感的开发者可能就会询问这个Link是用来做什么的，是一个新的特性吗？虽然看起不起眼，但这往往使两个团队的成员沟通起来更容易。 ## 在摸索中前进，自由地重命名你的资源 在项目初始阶段，团队对业务的理解还不深入，很有可能会得出错误的业务术语命名，或者业务对象的建模也不完全合适。 反映在API上，可能你希望能够修正API的URI 采用了HATEOAS的项目中，这很容易，因为客户端是通过Link来查找API的URI，所以你可以在不破坏API Scheme的情况下修改它的URI。 ```json HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: application/hal+json;charset=UTF-8 Transfer-Encoding: chunked Date: Fri,...