最近遇到了一个怪圈，经师兄点拨后发现：
一个项目使用框架势必会损失一部分灵活性，毕竟框架是按照通用思路设计的，而每个项目的难点往往都不一样，盲目套用框架虽然能够拥有框架天然的设计模式、可扩展性、可重用性等诸多好处，但是无论是大而全的框架还是小而精的框架，都无法完全的适用于一个完整的项目，项目中一定会有一部分需求为了顺利使用框架而做出牺牲；
而使用原生方法/语言/库又会损失重用性、扩展性以及设计模式的优势，由需求点驱动编程，需要什么才解决什么，比较灵活，但是这样写出来的模块总是比较繁杂，逻辑不清晰，好像也不太利于团队共同完成一份代码。
我之前用了半个月思考怎么把基于jQuery的epub解析器（2012）套用到React技术栈中，让它也能应用上虚拟DOM技术以及清晰的代码结构，而不是对每个DOM节点进行复杂的命令式操作，但最后还是用了jQuery单独开一个页面展示依赖epub解析器的内容，没有完全的做成单页应用。因为要把它套用进框架（或者叫另一种设计模式）的成本，好像比整个项目的成本还大。
现在整个项目有个初步的样子了，感觉这样兵分两路去完成一个项目也不错，一是需求都能合理的落实了，二是开发成本控制的也比较合理，没有陷入到某一个技术点不能自拔，最后耽误项目进度的情况。
想到设计模式是因为，最近在学一门敏捷软件开发的课程，老师要求对一个购物管理程序进行设计，同学们提了很多不同的设计模式，但另一位同学认为对这种程序进行设计是过度设计，一个简单的对API进行实现和扩展的Java程序，需要使用高级的设计模式吗？我觉得不需要，无论采用哪种设计模式，最后的代码量也不会超过200行，内容可能还没有设计模式的示例程序丰富......那又何必让它符合一个似乎合理的设计模式呢？在功能很少的时候，实现这些功能需要花费20%的时间，让程序符合某种设计模式需要花费80%时间，期间也少不了让功能做一些牺牲，以换来代码上的清洁。在功能很多的时候，上万行代码需要团队多人协作，这样的程序实现功能需要花费80%的时间，让它符合某种设计模式需要花费20%时间，我觉得这样的分配是合理的，牺牲一小部分实现功能的时间，让整个团队效率提升，是值得的。