标签: EnterpriseArchitecture
企业架构故障管理
故障永远只是表面现象，其背后技术和管理上的问题才是根因。技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒。在日常运营中，无论什么原因，产品出现服务中断、服务品质下降，导致用户体验下降的情况，都称为故障（故障不包括用户方环境引发的场景）。
- 在日常运营中，无论什么原因，产品出现服务中断、服务品质下降，导致用户体验下降的情况，都称为故障（故障不包括用户方环境引发的场景）。
- 为什么会频繁出故障？
- 为什么一个小问题或者某个部件失效，会导致全站宕机or服务不可用？
- 为什么发生了故障没法快速知道并且快速恢复？
企业架构开发债务
近期在处理公司项目历史债务问题，由于客观历史原因导致。为了快速收益初期不知情况下产生。定期不清理债务导致。
综合债务偿还规划
根据当前情况，除重写策略以外，其他策略同时进行。按阶段将债务问题逐步偿还。根据阶段性成果适当调整下个阶段的重点工作。
- 达成共识 > 债务可见 > 及时止损 > 不断改善。
债务的体现
- 代码在不同项目中复制迁移，并随着时间增加。
- 代码虽然运行稳定，但是回归测试成本在增加。
- 迭代维护越来越困难。
- 新的feature开发周期越来越长，ROI降低。
- 影响开发人员心态。
编程式权限设计
背景
权限管理是一个几乎所有大中型 B 端系统都会涉及的重要组成部分，其目的是对整个系统进行权限控制，避免造成误操作及数据泄露等风险问题。
权限与权限管理
名词定义
权限相关的基本概念：
- 权限：用户可操作行为的最小单位。
- 用户：每个用户都有唯一标识，并被授予一个或多个角色。
- 角色：由不同的权限组合而成，最终分配给具体用户。
- 权限管理：控制用户的权限，只能访问授权内容。
编程式代码风格
好久没更新博客，最近公司让我出一个代码规范，我吓了一跳。赶忙翻出阿里《 码出高效》，不敢造次，我就补充点个人的想法吧。代码是给人看的。代码风格应该遵循
极简主义
写好代码
- 可维护性（maintainability）
- 所谓的“维护”无外乎就是修改 bug、修改老的代码、添加新的代码之类的工作。所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。
- 可读性（readability）
- 我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响代码的可维护性。
- 可扩展性（extensibility）
- 我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。说直白点就是，代码预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上，而不需要因为要添加一个功能而大动干戈，改动大量的原始代码。
- 灵活性（flexibility）
- 灵活性是一个挺抽象的评价标准。如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。
- 简洁性（simplicity）
- KISS 原则：“Keep It Simple，Stupid”。这个原则说的意思就是，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。
- 可复用性（reusability）
- 代码的可复用性可以简单地理解为，尽量减少重复代码的编写，复用已有的代码。在后面的很多章节中，我们都会经常提到“可复用性”这一代码评价标准。
- 可测试性（testability）
- 代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。