引子
这是一个我想对修真院，将近100个在学弟子要说的话，公司内部的Wiki会放一下，公众号会发一篇，也愿意开放出来给其他人。
但是知乎的机制并不能保证每一个收到推送的人都喜欢，所以如果你的TimeLine上出现到了这一篇文章，埋怨我没有用处。直接拉黑所有关注修真院的人，可能会有效。
这篇文章关于拍砖，但是并不是去讨论拍砖的技巧，反而是提醒一下，在拍砖的时候应该有的心态。
上册
第一 不了解的事情，不要轻易下结论
第二 学习框架，最重要的是学习框架解决问题的思路，而不是如何去使用
第三 技术范围的讨论，就在技术范围内解决
第四 不要盲目站队
下册
第五 所有的框架都是不完善的，以及都会不断的去完善
第六 在考虑学习门槛的时候，还是要考虑他们要解决的问题是不是一样的
第七 别局限于自己是什么框架，什么语言
第八 技术好，未必人品好
第九 别总去找他说的不对的地方，去寻找他说的有价值的点
第一 不了解的事情，不要轻易下结论
这是很常见的事情，大部分人在真正了解，比较一些框架之前，就往往已经有了自己的喜好。
这种喜好，在新人刚入行的时候，就已经有了苗头。
比如说，为什么写CSS不让用Table，我就是喜欢用Table。这是关于Table的争论。
比如说，为什么要用Spring，可不可以不用Spring直接写。这是关于Spring的争论。
这些争论有时候是有意义的，见的越多，你会发现，只要是可以滥用的东西，就会被滥用。
“只要存在，就有价值”，这句话是要放到长远的历史长河里去看，在证明存在的延续性之前，最好不要用这个观点去解释事情。
很多框架，协议，语言被设计出来的一些功能，原意是用作解决特定场景的问题，但是一旦被开放出去，就有可能被滥用。
Rest就是最好的证明，http协议在REST之前的十几年中，压根没有按照预计的目标去运转，到现在为止，还是有很多人不明白为什么要用Rest。
这并不是“存在即合理”，也不是产品设计和用户需求之间的差异，纯粹就是认知体系的问题。
适当的约束，反而会让你更强大。这一点在很多地方都被得到的证明，从混乱无序到井然有序，协作和规范变的更重要。
没有任何一种语言，规定了你不可以用a,b,c来命名变量，但是所有的语言都在提到命名规范这件事情。
而往往很多向往自由的人，并不能在一定的框架范围内去获得自由。
说这些是为了讲明白一件事情，有纷争，大概很大程度上就是人们总是在错误的使用正确的工具。
而在这个时候，并没有人愿意承认是自己错了，反而会对于改进自己工作方式，思维理念上有强烈的逆反心理。
我已经用我习惯的工具做的很好了，我为什么还要去接触和学习新的东西？
修真院里不止一个人跟我讲过，我用了一个我熟悉的语言或者是框架，原因就是老大你 推荐给我的东西，我不会，我怕浪费时间。
而我经常说的一句话就是：人有自己不会的东西，不是很正常吗。为什么要害怕去学习，而且既然我说了，你可以用新的东西，就代表着这部分的时间我愿意给你预留出来。
学习新知识的能力本身，也是修真院试图展示，引导和训练出来的。
所以绕了这一大圈，就会发现，人往往在做选择，或者是说出自己的喜好之前，说出来自己的结论。
比如说，在大多数人还未了解到Angular倒底解决了什么问题的时候，就已经有人声明自己喜欢Vue，或者是React了。
这本来无可厚非，人不可能对所有的框架都做出准确的判断，也不可能有大量的时间和精力去把所有的框架都了解，很多的时候，就是我们自己知道了一点点，就立刻给出一个判断：我喜欢，我不喜欢。
可是关键点就在于，你要知道，你自己的判断是不准确的。不要让自己阻碍了自己往前走的脚步。
如果JQuery，Angular，React，Vue你都有了比较不错的项目经验，在每一个项目上都踩过很多坑，都做到了自己能做到的程度，我想你才可以有了初步的资格去做一个相对客观的评价，否则就请记着，你所说的大部分都是自己的推测。
这是一个很重要，对程序员来说，很重要的理念，“只有你吃了那只苍蝇，你才能说吃苍蝇到底有多恶心。”
我不知道我表述的是否准确，也没自己的去考虑是否严谨，但是，在不了解一件事情之前，不轻易下结论，这是我希望修真院的弟子们都能认真去做到的。
第二 学习框架，最重要的是学习框架解决问题的思路，而不是如何去使用
修真院的CSS任务，有一个环节是这么设计的。先用Bootstrap去实现响应式和自适应，下一个任务中再用手写的方式重新实现一遍。
这么设计的重点就在于是，很多人不太了解为什么要用Bootstrap去做，觉得会受到很多限制。
这些话不是我猜的，而是修真院在引导这些0基础的新人的时候，经常会被问题到的问题。
也有一些人特别喜欢Bootstrap。但是重点就在于是，无论你是喜欢，或者不喜欢。
第一，你的目标就应该是先学会Bootstrap的使用。
第二，是要弄明白Bootstrap的实现原理。
第三，是要弄明白Bootstrap是要解决什么问题。
但是，这是对新人来说。对于一个已经有一定工作经验的人程序员来说，我恰恰推荐的一个反过来的顺序。
第一，你要弄明白Bootstrap要解决什么问题。
第二，Boostrap的解决方案是什么。
第三，Bootstrap该怎么使用。
修真院的任务隐藏的目标，就是希望能够在亲测Bootstrap之后，至少要明白，怎么用，解决了什么问题。怎么解决的，这是你在后续的时间里，自己找时间去完成的。
这样才是你学习一个框架的真正的意义。
Spring是解决什么问题的？Spring起步就在于是依赖注入，以及非侵入式这两个核心的理念或者是原则。他在背后隐藏的思想，是如何写出更优雅的代码，或者说人话就是怎么样能保证PM持续提出需求之后我该怎么减少系统维护的复杂度。
“凡是有重复劳动地方，都可以抽象，封装，复用。”这是诠释“懒是程序员第一动力”的关键点。
但是，现在慢慢演变出来了第二动力，“凡是有最佳实践的地方，都应该约束，规范，推广”。
所以，对于框架的学习本身，压根就不是学API，也不是去学习内部实现，而是去思考，他要解决的场景是什么，这个场景 原有的解决方案是什么，这些方案有哪些需要改进的地方，有哪些合理的地方，如果让我来重新解决，我会用什么方案，我要学习的框架是怎么解决这些问题的，现有的框架是否还存在哪些问题，如果要做改进，该怎么去做？
加上第一条，有了大量的工程实践，又明白了这些框架要解决的问题，我想这样才是保证自己有发言权的自我约束的前提。
否则请时刻提醒自己，“我所说的一切，都有可能是错误的。”
第三 技术范围的讨论，就在技术范围内解决
技术范围的讨论，也会很难限定一上明确的边界。但是我们也很容易判断出来，哪些攻击是不在技术讨论范围内的。
人往往会因为观点和立场的不同，而去讨厌一个人，也更愿意去和自己思维模式相近，理念相近，有共同语言的人在一起。
因为立场不同，思维方式不同去攻击一个人本身，我以前就经常这么做。在KB，玩杀人游戏的时候，在论坛拍砖是常事，知乎这种藏着掖着，写个小说还是照搬鲁迅的小Case，实在是小巫见大巫。但是我的战斗力一向都很渣，经常被人说是最好欺负的人，好在我虽然渣，但是不怎么生气，吵架不伤身，拍砖不上火，这是一直在提醒自己的事儿。
但是偶尔也有被惹急了，恨不得见面一巴掌拍死的阴暗心理，咒他们死全家的时候也有。
直到有一天，我问一个朋友，你见到了花椒鱼怎么办？当年跟他在论坛吵的那么凶。
他说：那还能怎么办，请他喝酒呗。
这大概是我这些年，最有价值的收获。我是一个性格暴燥，心理极度阴暗的人，对于生命和生活已经很早就没有充满热爱了，一直在盼着自己被惹急了的那天。
所以我可以在贴吧和Java吧的吧主骂两年，而且也准备一直持续下去，直到七老八十，或者是飞来横祸的那天。
在某种程度上，知乎的友善度，也确实帮助了我不少，很多评论的回复，被举报后删除了，确实净化了知乎的环境，也提醒我自己是要遵守游戏规则。
正是我了解自己一个，了解一个人暴戾的时候会做出什么事情，所以我才提醒大家，“技术范围的讨论。就在技术范围内结束。”
我不保证自己能做到，但是我期望新人们能做到。
就算是有观点的争论，即使是有不喜欢的人，也不要去做恶意的揣测，无中的生有。
第四 不要盲目站队
人有一种很奇怪的思维方式， 总是在为自己的选择争辩。就拿Vue和Angular的争执来说，有多少人可以决定自己公司里用哪一种框架？
如果你在公司有这个权利，你就去用你的好了。
如果你在公司没有这个权利，你说你说选择Vue或者是选择Angular有什么意义。
键盘敲的再响，都比不上招聘岗位的任职要求。
如果你本身就处在选择使用哪种框架的纠结点上，更没必要为争吵而站队，难道问题的关键不在于是听从有开发过框架经验的人去讲遇到的坑或者是经验，或者是错误的使用正确的工具的场景么？
你听就好，站毛的队，骂毛的人。
约束你自己向前走的，就是你自己给自己定位的位置，一旦你把自己定位成了某种理论的支持者，你就会受自己思维方式的限制。
不写了。先与这么多，本来打算一口气写完的，但是最近总睡不好，脑子转的慢。
剩下的等哪天有心情了再说。
其他人我不管，修真院里还在学习的人，你们必须在学习期间内认真去思考一下这些问题，修真院要教导的，并不仅仅是技术，更是工程师理念的传达。
你听了不认可没关系，但是我必须要讲出来。
