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