获得徽章 25
- 几乎所有程序员都会拥有在屎山中作业的经历，并且所有有此经历的人基本上都会关切地问候一下写下这些代码的人
我曾经和很多人一样，一边骂一边暗自笃定，我是绝不可能写出这种代码的，但随着接触的项目多了之后，我终于明白，每个人都极可能是屎山的贡献者
业务屎山的存在是不可避免的，这跟写代码的人的水平和修养无关，大部分人都觉得自己是不会写出屎山的，并且可能也真的在努力写好代码，但实际上到了最后，终将变成自己讨厌的人
在项目初始阶段，还可以凭借着强硬的技术水平，保证整个系统处于所谓的“优雅”状态，但随着业务的快速迭代，参与的人数越来越多，这种初期建构起来的壁垒不堪一击
可能你认为你自己的水平很高，但你无法保证团队内所有人的水平都和你不相上下，参差不齐的团队水平是一件非常常见的事情
退一步，就算你拼尽全力保证进来的人都具备很高的技术水准，结果可能会更麻烦，因为技术是没有统一答案的，你觉得你的设计、架构好，但你怎么保证别人也觉得你的好，他完全可能觉得另外一种好，并且水平越高的人就越会有一种固执的自视清高，他不认可你，自然就不会遵守你的规则
再退一步，你拼劲全力保证团队内的人都具备很好的技术水平和修养，并且说服了所有人都认可你的思想，但这个时候业务方来了一个需求，众所周知，发展中的业务不可能是一成不变的，可以说是五花八门，甚至做着做着自己否定自己， 很可能有一个需求只要做了，就会对你的架构造成破坏，你做不做？
一个不做，两个三个五个呢？你都不做，那你的价值是什么，业务要你干什么？
技术是为业务所服务的，而不是用来体现你自身代码水平的，这种天然存在的优先级就决定了技术在绝大多数情况下需要向业务妥协
所以你不得不做，但只要你做了，根据破窗理论，你的所谓设计自此将不可避免地开始加速“堕落”，最终变成传说中的屎山，而 git 忠实地记录下了你对这座屎山所有的贡献
绝大部分的项目都避免不了成为屎山的结局（除非创业未半而中道崩殂，但这种更惨），但并不代表我们就应当自暴自弃顺其自然了，我们要做不是避免屎山的出现，因为大概率是避免不了的，我们应当为它们的出现提前做好规划，预留充足的空间，让屎山的艰难险阻仅流于表面，而保证内核的一如初心
屎山是不优雅的，但可以是可维护的，可以存在大量的反设计业务逻辑和 hack 代码，但不应当在里面尽情地挖坑，可以让人全神应对，但不应当让人头破血流展开等人赞过
421 - 每次360评估都像是一场对全体字节人自我反省能力、长期回忆能力、作文表达能力的考验
这半/一年来，我做了什么，有什么重要产出？翻看以往的需求文档或排期，通篇看下来终于总结好了，我确实挺忙的，为公司做出了应尽的贡献，但当下笔想写下来的时候却发现太多的东西不知道该怎么写，改个字段算重要工作吗？修改了某个配置呢？充当oncall为业务方解疑答惑呢？
要说算，可是这些事情也太小了，要说不算，有的事情尽管简单但依旧需要有人去做，依旧耗费了大量精力，能够称得上是大且复杂的重点工作半年下来可能就那么一两件，但只写这么一两件的话，是不是太难看了？
这半/一年来，他做了什么，有什么重要产出？翻看以往的需求文档或排期，通篇看下来终于总结好了，我和他确实合作挺多的，但至于说他有什么优点，好像也就是一个正常人吧，实在想写，优点还是可以写出几个的，但是哪些地方待改进呢，就是一个正常人，没什么毛病，绞尽脑汁，最后写了一个不痛不痒的待改进点
有些人确实很典型，优点、缺点、做了哪些事情一想就想到了，但是大多数人都是普通人，并没有那么明显的影响力，导致半/一年内的长期记忆很模糊，想了半天终于想到了一件关于对方的事情，但他半/一年内就做了那么一次值得称道的事情，算是优点吗？他某次不小心犯了一个错误，算是缺点吗？他参与了某个重要的项目，但他在其中扮演着怎样的角色、表现得怎么样？大概率是记不清的
苦思冥想终于写完一个，然而后面还有五六七八九十个在等着，每一个都是一场轮回
对于字节人来说，360评估是逃不掉的劫难，与其每半年刷新一次痛苦，不如想想如何不痛苦
写评估最难的事情无非是要在短期内对长期模糊的记忆进行提炼总结，如果把这件事情放到整个半/一年评估的周期里分散完成呢？
平时就有意识地进行总结和规划，在一段时间内，对做了的事情进行提炼记录，与人合作时，遇到一些能够让你关注的点也及时总结，下次再写360评估，无非就是复制粘贴的事情了
格局放大点，不仅是360评估，生活或工作中一些需要周期性回顾总结的事情，都可以分散在周期过程内进行积累，最终顺滑优雅地完成结果，而不是在 Dealine 前通宵达旦手忙脚乱
唯一的问题是，对于很多这种周期性的事情而言，实际上可能就是一种形式、一种流程，只是为了最后更好一点的效果就持续占用周期时间段的精力，会导致 roi 很低，积极性自然不够，很难坚持展开等人赞过 25 - 坦诚清晰：敢当面表达真实想法；能承认错误，不装不爱面子；实事求是，暴露问题，反对“向上管理”；准确、简洁、直接，有条理有重点
这是对坦诚清晰的官方描述
作为员工，理应贯彻落实公司正面的规章制度，但制度是死的而人是活的，让一个交叉于各种利益、情感节点下的人去执行一条固定的规则，必然需要“本地化”才能更好地被执行
规则为主，”人情世故”为辅，应该当面表达真实想法，但在表达的同时要语气委婉照顾彼此的面子；应该实事求是暴露问题，但同时也要给人台阶下，应该反对“向上管理”，但也可以考虑一下其正面的思想
在不违反法律和道德的前提下，只要能达到目标，过程是可以变通的，既达到了目标，又不会伤害到他人或者自己
坦诚清晰应当是“人间”的坦诚清晰展开1点赞 - 对于研发人员，特别是前端来说，似乎 Chrome 浏览器已经成为了唯一标配浏览器，无论是开发调试还是线上验证都首选Chrome，甚至都懒得用其他浏览器验证一下样式
但截止目前，Chrome内核的浏览器也只是占到了国内市场的一半，这一半之中还有相当一部分是以 chromium 为内核的国产浏览器，这些国产浏览器在一些表现上跟 Chrome并不完全一致，绝大部分非互联网从业者的浏览器都是这部分以 chromium 为内核的国产浏览器（例如360浏览器）
作为前端，是否应该对于这部分体量无法被忽视的浏览器保有一定的关注度呢？
今天因为Chrome被占用干其他事情，所以破天荒地使用FireFox打开一个内部网站，结果网页上却告诉我我在用不安全的浏览器，并给了我一个Chrome的下载链接
讽刺的是，Firefox 是目前主流浏览器中最安全的那一个展开4点赞 - 因为要对上线保持敬畏，所以要有Code Review，在严谨的氛围和规则内，团队内每个人都可以做到服从每个上线环节的要求，形式是可以保证的，但如何保证效果？
就算一个人有着好几年的工作经验，也在团队内待了足够长的时间，这也并不意味着他对所有的经手项目都一清二楚，特别是对于那些有着深厚历史包袱的项目，存在着各种所谓的设计模式和业务上的妥协，不深入了解或者是在上面栽个跟头其实是很难搞明白那些逻辑到底代表着什么
那么在 Code Review 的时候我作为一个 reviewer 就算是想好好给代码把一下关也是有心无力，最多看一下局部的代码逻辑写得对不对，写得好不好，而实际上大部分的 bug 都是业务bug，光看局部代码是无法发现的，局部的代码可能都是对的，但组合在一起形成了整体逻辑可能就是错的
作为众多reviewer中的一员，我可能存在侥幸心理，想着其他人可能会发现的吧？而事实是，可能所有的reviewer都是这么想的，大家都对本次 review负有责任，但大家都不是主要负责的人，旁观者效应导致责任分散，所以就没有真的负责的人了
那么就需要指定一个主要负责的人，肯定不能随便指定，让一个并不熟悉这个项目的人来当负责人，只会平白给这个人造成压力而对真正想达到的结果毫无帮助
所以，谁最熟悉这个项目那么谁就是这个项目的负责人，他是这个项目所有code review的主要负责人
但个人精力是有限的，所以不可能让一个人当多个项目的负责人，那么就需要进行分工，而为了帮助其他人都有各自最熟悉的项目，那么就需要在平时做需求的时候明确分工，在人手平衡的情况下，尽量将所有的A项目分给小张，将所有的B项目分给小王，培养具体个人对具体项目的 Owner 意识展开赞过 33 - 在团队协作开发下，代码的破窗效应非常易得与常见，只要团队中有一个人打破窗户，那么将会导致其他所有人坚持构建起来的良好开发体验崩溃，进而逐渐影响到越来越多的人放弃对可维护代码的追求
破坏是很容易的，并且重建几乎是不存在的，几乎没有人愿意耗费力气将项目代码挽回可维护的正轨，这是一件在可见的时间范围内，对业务毫无帮助且可能导致未知级别bug的事情，更别提还可能会被一次又一次地破坏掉
相比于坚持了一段时间才被破坏掉的开发体验，有的项目可能从一开始就没有体验可言，日常的迭代开发中，至少要拿出一小部分甚至更多的时间来堵住以前埋下的坑
而解决这一困境的唯一方法就是重构，但重构之后又如何保证后续不会再次崩溃？
项目的架构与设计至关重要（需要具备一定的能力），最起码可以保证底层是美好的，然后需要辅以强力的约束（比如严格的eslint 和 typescript），让坏代码写得不是那么容易，这在初始阶段可能会导致相当一部分的抵制，但最起码整体的未来是更加光明了一些
足够长的时空里，一切事物最终都该是平衡的，想要保证整体的和谐，必然会更多地压制具体个人的表达展开赞过 评论3 - 规范的流程固然能给日常工作带来便利，但在持续化的需求迭代之下，一个完整的流程规范在建立起来之前必然存需要一定的时间，并且建立起来之后，可能还需要很长时间的修修补补才能真正完善
除此之外，很多实际的工作场景可能都是一次性的，没有建立规范的必要，或者是一直处于建立规范的过程中，那么势必会导致部分工作是处于无序状态的，比如在正常推进自己工作的过程中，被拉去oncall、配合接入、测试、排查问题等，存在很多计划之外的事情
这是比较让人厌烦的，但既然被拉过去了说明必然负有相关责任，那么就得一一解决，如何平衡这种工作状态呢？
我认为应当保持一个客观的心态，即，不以物喜不以己悲
遇到可能会导致自己情绪变坏的事情，应该及时放下主观情绪，不被主观情绪所左右，客观地站在自己所应当负责的角度解决问题，负责好自己应当负责的事情，解决好自己应当解决的事情
当然，以上只是针对主观上不好的一方面，对于主观上好的方面，例如解决了关键问题，获得了某项荣誉，还是值得主观满足的，正面激励触发持续的主观能动性展开赞过 12