2019-12-18很好奇这三个方法运行效率的高低。测了一下争哥给的代码的执行效率，结果正如争哥文章说，第三个是最快的。
方法一（正则）< 方法二 < 方法三
正则就真的这么不堪么？效率如此之低？其实不然。
Java中正则的最佳实践是：
用于校验和匹配的正则表达式使用时需要预先compile，在类中写做静态变量（经常会重用），这样可以提高效率。Pattern.compile(IP_REGEXP)
优化正则后的效率如何呢？
方法一（正则）< 方法二 < 方法一（正则改进后）< 方法三
测试参数设置：每个方法执行100万次。
实验结果：
方法一：2.057s
方法一优化：0.296s 提前编译正则
方法二：0.622s
方法三：0.019s
有兴趣的小伙伴看看代码，欢迎一起讨论！https://github.com/gdhucoder/Algorithms4/blob/master/designpattern/u20/TestPerformance.java
参考：
https://stackoverflow.com/questions/1720191/java-util-regex-importance-of-pattern-compile展开 9 86
2019-12-18开发中的重复造轮子，这东西怎么说呢。我认为这句话是对公司来说的，但是对自己来说，重复造轮子是有必要的。就好比之前的数据结构和算法，那也是所有轮子都有啊，为什么还要自己写响应代码。这个问题在另一个专栏都说烂了，这里也不再赘述了。
光说不练假把式，轮子用不用的好，自己了解的深入才知道。我们读书的时候，用数学定理去解题，也是在一些已知条件下才能用这个定理。不能上来就套定理，而是要分析是否满足使用情况。只有吃透定义和原理，才能更好的使用轮子。
开发中也一样，我们要排查各种各样的问题，如果轮子内部出了问题，对轮子原理实现都不了解的，怎么排查问题。怎么知道用那种轮子是最好的呢。而且还会存在改造轮子的情况，轮子不满足我们特定的需求，那也是吃透了才能改的动。
总之，轮子这东西，对公司来说，不要重复，对自己来说，要多去理解，多动手。总不希望自己就是个调包侠吧展开 1 52
2019-12-18设计模式_19
今天的内容有一些哲学味道，让我联想到奥卡姆剃刀原理：
如无必要，勿增实体。
用同事不懂的技术，增加了整个团队的理解成本；重复造轮子和过度优化，大多数情况下带来的便利小于增加的成本；
不要写炫技的代码，就像杜峰(CBA广东队教练)说的：“如果没有目的，就不要运球。(因为运球就可能丢球)”，降低出错的概率是一个数学问题，它能够真实得提高软件质量。
回到作业，同上：
只有必须造轮子时，才要造轮子。
那什么又是必须呢？
- Vim如果不用KMP，恐怕就没有人用了。
- MySql的性能(即将)已经不能满足阿里的业务量
- 微信作为国民应用，需要解决各种弱网络下尽可能收发消息。
...展开 2 12
2019-12-18你怎么看待在开发中重复造轮子这件事情？
轮子:供上层业务应用使用的基础组件.
造轮子:设计并实现基础组件.
重复造轮子:重新设计实现一套新的组件.
开发中重复造轮子:
对于个人可以有深度度地提升对业务与技术认知的理解,还可以提升设计与动手能力,由于掌握了更多细节的知识,以后对于这类问题的排查定位及处理是有益处的.
对于技术团队,重复造出的轮子多了日后就需要有更多的人手和精力维护各个轮子,使轮子的维护成本变高;在使用方面,团队的每个成员为了能够正确的使用轮子就需要花费精力去熟悉各个轮子的特征.
什么时候要重复造轮子？
新的业务场景中原来的轮子不再合用,并且改造的成本高于重新建造的成本.比如原有业务量不大对于性能要求一般时,旧轮子足够满足;但随着业务的迅猛增长,对于性能提出明确苛刻的要求,就可以考虑重新建造新轮子了.
什么时候应该使用现成的工具类库、开源框架？
业务发展的初中期阶段时应该使用.这个阶段业务需求一般比较通用且对性能要求也不高,这时的业务与技术的特点就是要快,快速响应业务占领市场.
但发展到一定规模,性能成为了制约业务发展的瓶颈,拿来主义已经不能满足业务的更高要求了,就必须要动手建造适合自身业务需求的特定轮子.展开 9- 2019-12-18“不要使用同事可能不懂的技术来实现代码”这一条我觉得是可以值得商榷的~ 比如在项目中引入新技术就可能会违反这一条，我觉得关键点在于这个新技术是否值得引入？新技术是否可以在团队中得到推广？
有时候，在code review看到不理解的新技术时，其实刚好也是可以触发讨论和学习，如果只是单纯的不去使用，很容易造成整个技术团队停滞不前。作者回复: 嗯嗯 我的意思不能为了用新技术而引入新技术 不过也没那么绝对 设计问题本来就没有绝对的对重庆更多的是弄明白道理之后 根据实际场景自己去权衡
7 
2019-12-18一.什么时候要重复造轮子？
1. 想学习轮子原理(有轮子但是不意味着你不要了解其原理)
2. 现有轮子不满足性能需求(轮子一般会考虑大而全的容错处理和前置判断，这些对性能都有损耗)
3. 小而简的场景(比如设计一个sdk,最好不宜过大，里面轮子太多不易三方集成)
4.定制化需求
二.什么时候应该使用现成的工具类库、开源框架？
1.第一条中提到的反面情况
2. 敏捷开发，快速迭代，需求急的场景
3. 轮子比自己写的好，BUG少，设计好
4. KISS原则展开 4
2019-12-18很早就知道 kiss 原则了，以前的理解是代码行数少，逻辑简单，不要过度设计这样就符合 kiss 原则。虽然知道这个原则，但是却没有好好在实践中注意到，导致写的代码有时候晦涩难懂，有时候层层调用，跟踪起来很繁琐。看完今天的文章，理解更深了，代码不仅是给自己看的，也是给同事看的，并且尽量不自己造轮子，使用大家普遍知道的技术或方法会比炫技好很多。
至于另一个原则，你不需要它这个实际上做的还是不错的。 4
2019-12-19争哥好，想请问一个问题，文中说到不要写同事可能不懂的技术实现，这该如何权衡呢；
对于 Java 8 的 lambda 表达式，我认为这样的代码会更为直观；可是由于同事都习惯使用存储过程，Java 7 的语法糖；
是否因为团队大部分人都不使用 lambda，就应该在项目中放弃使用呢？作者回复: 应该暂时放弃 等团队慢慢学习接受
4 3- 2019-12-18提个疑问:
文中"所以，评判代码是否简单，还有一个很有效的间接方法，那就是 code review。",这里的code review有个前提该是团队成员的技术要有一定的水平,如果全是些初级人员,不按照面条式写代码就看起来费劲,这种代码评审就没意义了,所以前提是评审必须要有一定的内功修为.作者回复: 你说的没错 要有大牛 不然code review就流于形式 大眼瞪小眼
3 
2019-12-18我觉得如果开源类库完全能满足需求的话，那完全没必要造轮子，如果对性能有要求，比如类库太复杂，想要简单高效的，那可以造个轮子，比如我认为shiro也是spring security的轮子，他简化了很多东西，小巧灵活。还有就是觉得类库能满足需求但是相对于当前需求来讲不够可扩展，那也可以采取类库思想造一个全新的轮子来用。 3 3
2019-12-19那请问像正则表达式这样的东西是不是就没有用武之地？作者回复: 当然不是 简单的正则表达式 大部分人都能看懂 就可以用 别整那种极端难看懂的就行 凡事都有个度 合理把握
2
2019-12-18要不这样吧，如果编程语言里有个地方你弄不明白，而正好又有个人用了这个功能，那就开枪把他打死。这比学习新特性要容易些，然后过不了多久，那些活下来的程序员就会开始用0.9.6版的Python，而且他们只需要使用这个版本中易于理解的那一小部分就好了（眨眼）。
——Tim Peters 传奇的核心开发者，“Python之禅”作者 2
2019-12-18对工作上重复造轮子，没有必要，因为讲究效率问题，别人不会管你实现的功能是复制粘贴的，还是自己实现的，能正常使用就ok，对于自己来说也没必要盲目造轮子，不要造大轮子，除非你觉得你造的轮子可以碾压现有的，造一些小轮子，使用别的轮子的思想和设计还是有些用处的。 2
2020-02-05可能大家会说KISS、YAGNI这些原则听起来容易，做起来难。其实我认为不是做起来难，而是难在为什么要做和为什么不做。回到写代码这份职业来说，我觉出三个不同的问题：
1. 你为什么要写可用代码代码？ -- 赢得公司的信任，让自己能够活下来
2. 你为什么要写简洁可用的代码？ -- 解放自己的生产力，创造更多价值，升职加薪
3. 你为什么要写简洁可用，并影响其他人？ -- 赢得别人尊重，获得职业成就感
我觉得程序员首先要思考上面三个事情为什么要做，而且要回答上这些问题，需要自己持续精进，比如提升编码Sense、设计思维、提升系统思考能力。
在探索上面三个问题的道路上，很多开发人员可能有如下内心小九九：
1. “我要用炫酷的方式Show技能。看，正则，你看得懂吗，哈哈。小样”
2. “我要用最少的代码写出这个而功能。看，我的代码就是比你少”
3. “我要用极致的性能来写这个功能。来，测一测，谁的用时最短，我开始用了快速排序法的”
4. “我要用上5个设计模式。你瞧瞧，这里有5个设计模式的精髓，健壮无比的代码”
5. ....
以上这些内心小九九是我们要去尽量克制的，尽量少做、甚至不做，而为什么不做这些事情，去思考这个问题的答案更重要。
道理可能都懂，缺的是刻意练习，推荐一些实操落的方法论和实践：
1. 简单设计（4原则和优先级）
2. 测试驱动开发（Tasking + TDD）
3. 重构（作者后面会提到）展开 1
2020-01-02KISS用于设计之初的理念，是规划；YAGNI用于设计之后的优化，是减法。 1
2019-12-20Ken Thompson :拿不准，用穷举 1
2019-12-19打卡～
我觉得做项目中是不需要去重复造轮子的，但如果一个轮子特别大，但我只需要这个轮子很小的一部分内容，那是不是考虑借鉴它的思想去造个轮子呢？作者回复: 是的 这是重复造轮子吗一个比较重要的理由
1 1
2019-12-19老师，以java为例，什么样的写法可以被称为不建议使用的过于高级的语法呢作者回复: 比如一些函数式编程语法 有人就不了解
1
2019-12-18想请问一下老师对于使用正则匹配的看法，因为在平时的工作中还是会时不时看见，而且感觉确实可以省掉一些代码。作者回复: 简单的正则表达式可以用的 不要太极端就好
1
2020-02-07关于重复造轮子这件事，我觉得当一段逻辑或者业务趋于稳定后才能考虑讲一些逻辑抽象成轮子供以后得代码使用，一开始就想着造轮子使用，有点过度设计了，可能还会违背KISS和YAGNI原则