降低软件复杂性一般原则和方法
首先，互联网行业的软件系统，很难一开始就做出完美的设计，通过一个个功能模块衍生迭代，系统才会逐步成型；对于现存的系统，也很难通过一个大动作，一劳永逸地解决所有问题。系统设计是需要持续投入的工作，通过细节的积累，最终得到一个完善的系统。因此，好的设计是日拱一卒的结果，在日常工作中要重视设计和细节的改进。
其次，专业化分工和代码复用促成了软件生产率的提升。比如硬件工程师、软件工程师（底层、应用、不同编程语言）可以在无需了解对方技术背景的情况下进行合作开发；同一领域服务可以支撑不同的上层应用逻辑等等。其背后的思想，无非是通过将系统分成若干个水平层、明确每一层的角色和分工，来降低单个层次的复杂性。同时，每个层次只要给相邻层提供一致的接口，可以用不同的方法实现，这就为软件重用提供了支持。分层是解决复杂性问题的重要原则。
第三，与分层类似，分模块是从垂直方向来分解系统。分模块最常见的应用场景，是如今广泛流行的微服务。分模块降低了单模块的复杂性，但是也会引入新的复杂性，例如模块与模块的交互，后面的章节会讨论这个问题。这里，我们将第三个原则确定为分模块。
最后，代码能够描述程序的工作流程和结果，却很难描述开发人员的思路，而注释和文档可以。此外，通过注释和文档，开发人员在不阅读实现代码的情况下，就可以理解程序的功能，注释间接促成了代码抽象。好的注释能够帮助解决软件复杂性问题，尤其是认知负担和不可知问题（Unknown Unknowns）。
提升代码质量的方法：领域模型、设计原则、设计模式
一名合格前端工程师必备素质：代码整洁之道
内容出自《代码整洁之道》、Alex Kondov的博文tao-of-react和《Clean Code of Javascript》
编写高质量可维护的代码：优雅命名
俗话说得好，万事开头难。而对于前端 coder 来说，每次新项目、新需求来的时候，我想大家最苦恼的往往就是如何去命名，无论是项目名称、页面的文件名称亦或是代码中的方法名称，对于我来说，但凡名字想好了以后，我觉得需求就已经写完一半了。
这可能是大型复杂项目下数据流的最佳实践
分层。解耦，提高复用性。 分 UI 层，Store层， API层。Store 层: 存数据和数据的操作。 API 层: 与接口交互和做数据的格式化。接口字段发生变化，可以在抹平变化。
Store 的粒度的设计。分为：全局 Store，页面 Store，业务模型 Store。
设计 Store。根据领域设计(DDD) Store，而不是根据设计稿。 根据设计稿设计的缺点：成员都根据各自手里的设计稿设计 Store 会导致 重复代码会越来越多。 DDD 的优点：采用 DDD ，我们去抽象领域模型。视图层只需要实现视觉稿和组装业务逻辑，具备很强的灵活性，就好像搭积木一样，底层的领域模型不需要变动，只需要改动交互变更或视图。极大提升了开发效率和维护性。
Store 库的选择：选择 Mobx。原因：无很多模板代码，支持多 Store，对 ts 兼容好。
编写可维护的前端代码
基本约定（项目结构，代码风格统一）；类型安全(用 TS，禁用 any)；删除不必要的注释;配置分离；状态管理；性能优化；版本管理(版本锁定和向下兼容)；适度封装；组件设计（组件的边界）；防御式编程。
使用事件驱动编程解耦 JavaScript 代码
应用事件驱动模型重写 bulletz.io 得到了高度解耦的逻辑。重构后代码明显更简单、更容易理解，顺便也修复了一些用户界面的 bug。用户界面更新和状态更新都写成了自包含的模块，响应其他地方发出的数据。
如果你最近打算脱离框架编写网页，我建议了解下事件驱动编程！我为了解决这一问题写的库叫做 tiny-pubsub，GitHub 链接是 LukeWood/tiny-pubsub。
设计原则 & 设计模式
图解23种设计模式（TypeScript版）
6大设计与原则，23个设计模式。
面试官:你不懂六大设计原则,回去等通知吧!
单一职责原则：类，函数，职责单一； 开放封闭原则：对拓展开发，对修改关闭； 里氏替换原则：引用父类的地方，都能被子类替代； 依赖倒置原则：面向接口而不是面向具体实现编程； 接口隔离原则；使用多个专门的接口比使用单一的总接口要好，即接口应该是相互隔离的小接口，而不是一个臃肿且庞杂的大接口； 迪米特法则：又叫最少知识原则，它是指一个类对于其他类知道的越少越好。能降低耦合。
Design Patterns Game
设计模式在线练习题。
其他
验收标准到底是不是测试用例？
一文解决AC/TC傻傻分不清的小困惑。
敏捷质量实践中提倡测试左移，测试人员要尽早介入需求阶段，越早越好。测试人员需要关注需求的有效性，以及在需求产生和传递的过程中，交付价值是否被准确的描述、理解和对齐。在这个过程中很容易遇到一个常见问题：验收标准是验收测试要测的吗？验收标准到底是不是测试用例？这两者之间有什么区别和联系？本文主要想解决的就是这个具体的困惑。
若有收获，就点个赞吧
0 人点赞
