获得徽章 25
- 发现一个有意思的地方，很多英文技术库包的网站，会将库实例放到全局变量上，打开控制台就能对包的api进行验证，例如 [lodash](
lodash.com)，打开网站控制台，全局上就挂着 `_` 变量，直接可以执行 _.debounce 等api，类似的还有 [dayjs](day.js.org)，全局变量就是 dayjs
反观中文技术库包的网站，我至今没看到一个这么做的（也可能是我见识短浅吧），这个功能虽然没啥技术难度，但确实也反映出了一个开源技术的细节做得是否到位
文档写得再全，不亲自试一下总感觉不太放心，但如果只是为了测试一个 api 就要专门新建个本地项目或者在codepen等上建个在线实例，未免有些大张旗鼓，相比之下，在看文档的时候顺手打开文档的控制台就能测试，就优雅很多了展开等人赞过
评论16 - 业务代码与竞赛代码是存在着本质差别的，竞赛代码追求的是更快更好，其余的例如可维护性等不值一提，所以你尽可以定义变量为a、b、c，尽可以一个方法写几百行，尽可以追求奇技淫巧，而业务代码追求的则是业务实现和团队协作
业务团队第一要义是保障业务的实现，例如为了应对千变万化的业务需求，代码必然需要保证一定的灵活度，说的具体点，相比于引入一套有着各种条条框框限制的模式，多写点 if...else 并不一定就真的不好。
团队协作是把团队放在第一位，那么必然需要放弃个人的一些习惯，例如编程风格、技术选型等，必须要考虑到你写的代码不仅是你自己看更可能是要给别人看，要考虑ROI是否值得
或许你比较新潮，知道很多前沿技术，但不代表你就要把这些很酷的东西一股脑引入到团队代码中来，要考虑到这些东西对于其他人来说是不是可接受的，相比于用二进制运算替换四则运算带来的那点性能提升，代码可读性才是更重要的，相比于写复杂的类型体操，老老实实地给每个变量、每个函数入参出参写好类型才是更有用的
当然了，如果能把代码写得优雅点那自然最好不过，但优先级必须要放到业务之后，如果可能妨碍到业务，那么这个优雅不要也罢展开等人赞过 46 - 平时的认真工作负责踏实，只是一个决定结果的基调，但无法给予你更多，在认真工作负责踏实这个选项上，60分和90分比较起来，给人的感觉其实差别并不大，因为这是无法具体衡量的主观性事务，只要让别人对你的印象是好的，至于这个好，是60分的好还是90分的好，并没有什么差距
但是你想在一件由主观决定的事情上从60分的好，努力变成90分的好，却需要付出更多，至于100分，几乎是不可能的事情，所以从60分开始，你越努力往更高分前进，你的ROI就越低
归根到底，是努力错了方向，在基调确定的情况下，就该去做其他更有决定性的事情
比如你想取得一个好的绩效，那么在得到了团队的正面印象后，下一步不是继续努力让这种正面印象继续加深，这是无意义的，不论是对于你自己还是对于团队都是无意义的，而是要转变方向去做一些能突出自我的事情来，做一些能让领导在给你打绩效的事情想到的事情来展开等人赞过 45 - 以前我非常鄙视向上汇报，并认为这属于老油条行为，只有能力不行的人才会整天想着向上汇报，有真材实料的人都是凭实际可见的产出说话
但随着见过的事情越来越多，我逐渐认识到向上汇报是必不可少的，其重要程度或许比干实事还要重要
作为混口饭吃的打工人，产出当然是体现在绩效上，绩效是领导给打的，一般而言，在规模稍大的公司，有打绩效权力的领导，其级别不会太低，最起码是个中层管理者，底下可能会有几十号到上百人
在流动性较高的互联网行业，领导能记住底下每个员工的名字就不错了，指望他还能记住每个人平时都做了什么、态度怎么样、评价怎么样、产出怎么样，客观上很难实现
那么如何让领导记住你呢？向上汇报的重要性就体现出来了
不仅是汇报你做成功了什么，还要汇报某件事情你为什么没达到预期，有时候一个坏印象就可以抹杀以往所有的努力
只不过在这个过程中，作为一个做实事的人，不能为了汇报而汇报，汇报只是一个保证绩效可以匹配产出成果的手段而非原因展开赞过 22 - 代码的奠基者至关重要，在第一次写下代码的时候，就要充分考虑到可维护性，一般而言，在代码首次被写下的时候，可能是没有太多的逻辑的，所以一些可以优化的点就显得不是那么重要，例如函数、组件抽离，因为代码量和逻辑比较少，抽不抽也无所谓
但随着项目的持续迭代，初版代码会被多次修改，更多的逻辑堆积上来，原先优化与否的逻辑就变得急需优化了，但通常情况下，除非是实在堆不下去了，否则是不会有人主动优化的
惯性和方便使然，前人怎么写我就怎么写，初版代码编写者预期之内的代码优化永远不会发生
所以，优化要从一开始就进行，在实际场景下，没有所谓的过度优化，所有的优化都是需要的，奠基者的作用至关重要，代码风格的惯性会持续相当长的时间展开赞过 32 - 面试造火箭，入职拧螺丝
很多人可能对这种现象存在的原因理解有偏差，所以导致对此很反感，实际上面试造火箭根本就不是真的想招个能写出多好的代码的人来，而是为了保证招进来的人不写出太烂的代码
技术能力强的人，给他宽松的时间和思考，确实可以写出不错的代码，但在996的工作环境下，光是按时写完需求不拖后腿就已经够累了，哪有精力去思考怎么写出好代码来，更何况按照业务屎山理论（参见我的上条沸点），想把业务代码写得多好就是笑话
不同的是，能够在面试造火箭的人，在面对不得不从两份坏代码中选择一个的情况下，能够选择出一个更好的，所以造出来的屎山能够堆得更高撑得更久，而这恰好也是业务所看重的，业务不会管你代码写得到底怎么样，只关心业务本身是否持续稳定不要总是出乱子展开赞过 33
lodash.com