no-nested-ternary
三元表达式在简单的判断取值中使用，还是很简洁的，但是当遇到嵌套逻辑时，可读性就变得很差，实际项目中，我是这么要求团队=》禁用。
1 | var foo = bar ? baz : qux === quxx ? bing : bam; |
no-nested-ternary
为了约束这类代码的存在，eslint中会增加no-nested-ternary。
规则介绍戳这里
阿里巴巴Java开发手册阅读
发表于
更新于
本文字数：
1.4k
阅读时长 ≈
2 分钟
本文介绍关于阿里巴巴Java开发手册阅读，包括使用场景、实现细节等，以提高关于阿里巴巴Java开发手册阅读的效率。
最近阿里发布了
阿里巴巴Java开发手册（泰山版），花了点时间阅读下，这里MARK下个人感受
无规矩不成方圆
- 有些人觉得没规矩不挺好？但假如项目中10个人，10个风格，10个规矩或者没规矩，代码又存在交集，这样的代码能维护吗？能不出问题吗？impossible！
- 规矩，标准是为了提升协作性，降低门槛儿，代码差异化一定程度降低，每个人都这么做，熟悉了规矩，无论是自己coding还是看别的人code，自然就快，那么bug率自然也就降低了
- 假如我是个独立开发，只有我一个人，我就不需要规矩了？我之前也这么认识，但逐步我改变了这个认识，就是个人也需要有自己的规矩，风格，因为这会让你效率越来越高，规矩的背后是标准化，统一化。
- 这些规约的背后是前辈们，或者同行们从无数的坑，无数的雷中总结出来的，不一定恒对，但值得学习，值得参考，值得借鉴。
so，没规约，不见得单个问题解决不好，但不久的将来，一定出问题，害人害己。
架构决策记录-ADR
发表于
更新于
本文字数：
730
阅读时长 ≈
1 分钟
本文介绍关于架构决策记录-ADR，包括使用场景、实现细节等，以提高关于架构决策记录-ADR的效率。
之前年终Review时，与同事探讨一个项目总是会面临各种情况，而项目底层的架构，也是一直在发展，架构背后的人也是在发展，面对这种发展，我们需要系统反思、调整、分享。只有这样才能校正，才能统一整个team的认知等。
在交流中同事推荐我去了解
Architecture Decision Records (ADRs)，这个概念之前只是喵了一眼，毫无印象，答应要学也一直没有去学=》惭愧。于是今天还债。
ADR
ADR全称Architecture Decision Records,汉化后就是架构决策记录，之所以有这样一个概念，其背景正如上述我所提到的，项目是一个变量，在发展，而在这变化中，我们需要去系统记录梳理这些变化点。对于所有的成员也需要一种形式可以了解这些，而最合适的就是文档化。
当前我们是如何做的
- 博客，我喜欢博客去总结一些变化
- 公司文档-Confluence
- 个人脑中
TypeScript装饰器实践
发表于
更新于
本文字数：
2.2k
阅读时长 ≈
4 分钟
本文是作者对TypeScript装饰器实践的介绍，包括TypeScript装饰器实践的优势、实现细节、相关资料等，这些步骤可以帮助作者提高TypeScript装饰器实践的效率。
当前装饰器还只是ES提案[Stage 2]，在过去，还没定下来的东西，我们无话可说。但今天，项目中使用的是TypeScript，Babel，本身存在转译，所以我们往往可以用些超越当前的特性。比如Angular2框架中就有装饰器的大量存在。
这块之前我也只是在NG中较多的使用，并不算熟悉，于是冲下电。
装饰器
装饰器模式，顾名思义，就是将某个类重新装扮下，使它在功能上更强
大，但是作为原来的这个类，使用者不应该感受到装饰前与装饰后有什么
不同，否则就破坏了原有类的结构，所以装饰器模式要做到对装饰类的使
用者透明
类别
谷歌工程实践-CR，MR
发表于
更新于
本文字数：
683
阅读时长 ≈
1 分钟
本文介绍关于谷歌工程实践-CR，MR，包括使用场景、实现细节等，以提高关于谷歌工程实践-CR，MR的效率。