持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情
最近的工作中发现了这样一个问题，有的公司发展了几年、有的甚至是十几年的公司，基本上连一套属于自己的js库都没有。这就让人很无奈了。
这种情况下我们可能会发现，公司中不同的水平的程序员写的代码，做的业务和逻辑真的是到处都是，乱码七糟。
看看你的公司有没有这种现象：
①为了攒产品，快速发布上线，很多人怼一个项目，然后要求在有限的几天内完成
②不同的人负责不同的模块，单模块的业务实现过程中到处任意复制，我也不明白为什么这种情况下不做公共js库
③在项目完成后人手立即抽出，各自忙其他的，继续做着复制代码的工作
说到这里，其实也能够应验，为什么很多人道听途说的传言：程序员过了30岁「有的说35岁」基本上就干不动了。
如果一直搬砖，一直复制别人的代码，一直到处粘贴网上各种现成的案例。那肯定到了30岁你搬不过年轻人。因为年轻人眼疾手快，而且熬夜还不困。
那么如果你从毕业24岁左右开始做程序员，搬到30岁，还在做着重复的搬砖的工作。那你就肯定30岁以后凉凉了。就算不失业，也是在边缘部门工作，干的可能也是一些很少会让人想起的边边角角的碎活。
但是不论什么工作方式，咱们可能都要尽可能的在最短的时间内真正干好，干精一门手艺。有的人毕业两年兴许工资翻番，有的人毕业5年，10年，可能还在抱怨职场的人情冷暖。
可是抱怨又有什么用呢？
还不如去找一本HTTP图解，没事看看上面的图画，还能掌握两个知识点呢。
举个实际的例子吧。多个产品，多个项目，多个项目组，单个产品中的不同部分，这个部分可以理解为分视图，也可以理解为vue中的组件，它们之间肯定是有共性，有特性的。
就前段时间，我们有个同学，一个freemarker的页面，同样的模块基本上能够占据百分之七十的布局。
这个时候如果工期比较赶忙的话，你是选择直接按照提供的死数据写一大堆html，还是直接利用macro定义一个宏，通过递归，或者用for循环遍历呢？
相信你写死的代码摞完可能花上1个小时，用macro可能也是花上一个小时，但是当数据追加或者产品部门需要调整样式的时候，前者你可能修改要再花上1个小时。后者可能30秒钟就解决战斗。
这就是好程序员和普通程序员的区别。
同样是程序员，有的人认为30岁以后就没法干了。实际上50岁以上的程序员也大有人在。我曾经在微软参加过一次 《CLR via C#》的作者Jeffrey Richter的分享会，这哥们现在不知道还在没在写代码了。要是写的话估计年龄也该不小了。哈哈。
其实，有时候有些工作，也就是思考上那么半个小时，两个小时的问题，养成习惯以后就会慢慢积累。
逐渐成长，当然这样就和墨守成规的干法逐渐拉开差距。
当你初入职场的时候，老人可能会告诉你不要死磕一个问题，不懂的就抓紧时间问。这是一个很关键的点。
在开始的时候，我们要知道，你遇到的问题，尤其在第一阶段，刚进门槛的时候遇到的问题，基本上是别人在项目的进展过程中都已经遇到过，并且踩过千八百便的坑。对你来说还是坑，对别人来说，它已经变成了踩平的平地了。
这也就是让抓紧时间问的原因。抓紧时间问的前提是你首先要动脑子想一遍，思考一遍问题的前前吼吼，问题的上下文环境，问题的出发点和回归点。
如果遇到问题就问，遇到问题就问，那我相信被你问的那个人，只要他还是人类，他就一定会烦的。没有一个人喜欢一个不动脑子，并且怎么教都教不会的新人。
当你看了一个小时没有思路，看了两个小时不知道怎么下手，查了半天还是不知道云里雾里的时候。麻烦打住，去找人问，就是人家骂你你也得去问。
因为负责人是有工期的，负责人是要做阶段性汇报的，负责人是要对他的上级负责，对公司的产出负责的，负责人有的可能是要做经营预算的。
简单来说，你1个小时的工作，花了两天的时间做出来，那么就相当于白白浪费了1天零7个小时的工时，转换过来这就是浪费的人力成本。所以这些可能是负责人考虑的问题。有时候，即使挨骂了，被骂上两三次，问题解决了，你学会了，这种其实对新人来说是最好的状态。
当然，其实一般不忙的时候，大部分人还是比较乐意帮助你的。除非你遇到的领导真的很让人崩溃。这种情况下，相信你也忍不了多久，就要跳槽走人的。因为谁也不想伺候这样的大爷。
怎么才能形成，写成自己的js库。
就像上面说的，你写的多了会发现，它有一些常用的，比如从url中获取参数的键值对，参数名称，参数对应的值。比如，你可能要验证email的格式是否正确，要验证电话号码的位数是否是11位，要验证url是http的还是https的，等等这些都是我们常用的。
如果你有心积累了下来，放在了一个公共的js文件，当这个文件越变越大的时候，它就是你的js库，它甚至可能会成为你们部门，你们公司的js库。
这个是基于功能性的，还有一些是基于业务的。这些都是有章可循的，比如bootstrap，或者layui，或者aui，或者jquery，或者jquery-ui，或者viewerjs，等等等等。
这些公共的开源组件。它就是我们的快乐源泉。并不是因为，它拿过来就能用。而是因为，它可以为我们的前端工作指明方向。
比如，拿layui「尽管layui现在已经不维护了」来举例子：
（1）它是如何控制样式的
（2）它是如何划分table、form、laydate、等等组件的
（3）对于laydate中的输入框和弹出的时间，它是如何渲染的
（4）事件是如何绑定的
（5）为什么没有过多的冗余业务，一样可以实现简单的，高可操作性，强复用，低耦合的功能的
（6）不同的模块是如何压缩成一个代码文件的
（7）table的异步数据加载是如何做到的
（8）不同的原型，也就是 prototype 是如何实现的
（9）JavaScript中的constructor是什么东西
（10）原型链是个什么鬼
（11）在JavaScript中如何实现继承
（12）闭包到底是个什么玩意
（13）JavaScript如何与html标签分离（这一点很重要，很多人习惯在页面中，写一大堆JavaScript、和html、css，看起来真的是要命）
（14）去掉上面的这些知识点，还有一些技巧，真是说到这，有的朋友都代码写了3年5年了，可能chrome的调试控制台还不会用
- chrome的debugger模式
- JavaScript中的debugger的用法
- chrome的断点的用法
- chrome的单步执行
- chrome的application的内容
- chrome的请求
- chrome的请求头
- chrome的响应
- chrome的响应内容
- 请求耗费的时间
- 请求资源的大小
- 请求资源的分类
- console.log打印的方法
- chrome控制台的监控
- chrome文件目录的查看
还有别的一些点，想起来再说吧。
你们在工作的过程中有遇到过什么问题吗？可以分享一下。
其实JavaScript也不难，css也不麻烦，java也没有那么想象的恐怖。只要大门打开，有趣的事物有很多都等着去寻找。
当成任务，就很难找到乐趣，打开一扇门，自己走进去，就能够发现很多有意思的知识点。跟老人学习一下，跟新人分享一下。共同进步，共同努力。还挺好。
有时候英文真的能帮你打开新世界的大门。当你在国内的各大网站，各大博客找不到解决方案，又不好意思问别人的时候，你可能会在stackoverflow那儿找到一点有用的信息，甚至直接帮你解决问题。这种案例屡见不鲜。经常会遇到这种情况。不过有时候stackoverflow也不灵。
还有一个经验，有时候百度检索出来的结果不是你想要的时候，翻个两三页还没有想要的东西的时候，就别翻了，翻译一下试试看英文文本的检索。或者在必应的国际版搜索一下。如果你在可访问Google的国家，可以再试试用Google得到的检索结果。对比一下看看有没有能用的。
到点了，就到这吧。谢谢支持。有空再聊。
