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