💼 从工作中学到的
    此条为私密说说,仅发布者可见

    💼 从工作中学到的 职场中应该会有很多时候会受到挑战。比如工作流程(开发/需求流程等等)是否合规,技术方案是否合理,考虑全面,代码是否严谨等。要学会受到挑战的时候不要急的把自己择出去,这样的心态会让自己会急躁的为自己辩解。但事实上很多时候不需要辩解,只需要解释,所以要缓一缓,如果是通讯工具沟通,不要急于回复,理清思路再回。面对面沟通,也可以停顿、思考片刻后给出回答,切勿自乱阵脚,有理也说不清。

    📝 每日记录 今天北京下大雪了,这可真算得上是鹅毛大雪!下班的时候,走在路上,雪特别的厚,踩在上面还有咯吱咯吱的声音,非常治愈

    补充一则记录:春节前,第一次点这家的烤串,点了一个烤猪蹄,特别好吃,送过来的时候温度也不错,猪蹄也挺嫩的。复工回来的时候,又点了一次烤串,发现很一般了。相似的经历是之前的一家炸鸡店,第一次点手枪腿,真的是太好吃了,手枪腿里还有汁水,第二次点怎么这么一般。不太清楚是丧失了新鲜感,还是确实餐品质变差了!

    PS:已经高强度上班三天了!
    PSS:明早还要早起赶文档!!

    此条为私密说说,仅发布者可见

    📝 每日记录 从4月末开始,每天熬夜到1点半,身体每况愈下,以至于再也不能不重视了。

    身边新冠第二波的人也变多了。倒是一直没有发烧过,因此也不知道自己有没有阳过,不过其他的症状从1月放开后持续不断。 腰痛、咽喉不舒服,胸闷,呼吸不畅,口腔溃疡等等几乎不间断轮番上阵。

    这半个月来,从新需求启动忙到焦头烂额。但是身体永远是第一位,所以下班后不再想任何工作的事情了。

    💼 从工作中学到的 关于工作,从0启动了一个需求,所以涉及到大量的方案设计与评审的工作。在这里体会最深的一点是:过度设计是一切的根源。很多优秀的技术架构是需要演变的,而不是一步到位。

    在代码设计中,有很多不错的设计模式和设计原则,以便代码便于扩展,容易测试。但是在实际的设计中,很容易从一个具体的需求想要设计一种“极其通用”的设计方式。模块越通用带来的复杂度就越高,因为需要兼顾更多的场景。

    所以不如变成两个模块来做,而不是想要一个模块非常灵活、通用的完成所有需求。

    尤其是在刚刚接触一些设计原则的时候,我们想要在代码的所有地方去应用,比如单一职责,开闭原则、MVC等等。可能会让一个没有那么复杂的需求拆分成很多独立的模块,导致这些模块之间需要还需要通信,或者函数需要不断的通过层级来偷传,这无疑增加了复杂度。

    当然好的代码需要一定的设计,这其中的权衡是需要在不断的实践中掌握的。

    💼 从工作中学到的 「输出论据比论点更有价值」最近在写绩效评价相关的,有一个感受就是情绪或者主观评价都是比较虚的。所以才会有所谓的「夸夸宝典」,这些主观评价就像是一个结论或是论点,必须需要有论据支撑才有价值。当然这个场景下论据与论点结合更适合。

    这个观点同样适用于其他的事情上。比如与别人沟通上,即使你要和别人吵架,提出你的不满,你可以数落对方做的不好的地方,让你烦、讨厌的事情,但最好减少去输出主观的评价或情绪。比如直接人身攻击,大骂对方没素质等等。输出论据,大家也能心知肚明知道你的不满了。而情绪和观点是可能会变的,过几天你可能会因为一时冲动输出太多情绪而后悔,但是事实是不会变的,这不会让自己觉得“冲动了”。

    💼 从工作中学到的 写文档和设计代码有一些相似之处。一个比较复杂的话题想要展开,就好比设计一个复杂功能的类。全部代码写在一个文件中当然可以,就会导致单文件代码行数太多,阅读起来很费劲。如果我们能更好的封装与模块化代码,单个类的功能就会更清晰。

    同理,写一篇复杂话题的文章,也可以有类设计的思想,先介绍最基础的部分,然后基于这个基础会有多个分支展开(子类继承)。多篇文章之间环环相扣,而每篇文章也不会太长,阅读压力也不大。

    我也看到过有很长文章从头到尾讲一个复杂话题的,写的也特别的好,这个就好比仍然是多个类,只不过放到同一个文件里面而已。

    此条为私密说说,仅发布者可见

    💼 从工作中学到的 当我们CR代码的时候,我们在review什么。 其实很难和代码作者本身理解程度来review代码逻辑的正确性,而是应该review一些常见的代码写法的问题。比如指针是否有空指针风险,函数本身的设计(如输入参数在输出参数前面)等等代码规范的问题。

    除此之外,如果对代码需求的细节了解更多,可以review 一些代码的逻辑,比如改动代码是否会影响之前的调用流程。

    CR中几乎做不到的是判断每个变量计算的值是否符合预期,这个需要代码作者本身来保证。

    正常来说,别人给你CR的意见都是你自己每次自己CR的时候应该发现的,所以提高代码质量的一个好方法就是记下每次别人给自己的评论,并反思为什么自己在检查代码的时候没有发现(还是自己并没有检查代码)?

    📝 每日记录 工作如果获取不到持续的成就感和进步,是很容易陷入一种痛苦、迷茫、虚无的感受的。尤其是如果一直工作没办法按照排期完成,一直后延、后延、后延,只是无尽的麻烦... 💼 从工作中学到的

    💼 从工作中学到的 因为国庆大部分时间都在忙工作,节后的几天又继续加班到挺晚才回来,快晚上十点回来后,因为天气变冷,挑选一些过冬东西,然后就已经到凌晨了。这种连轴转到今天早上的时候,闹钟都叫不醒我。整个人特别的困,与此同时也会让我面对环境更加敏感脆弱。所以,过大的压力、不好的作息这些会更让人容易emo,陷入不好的情绪当中。

    今天晚上吃完晚饭就回来了,调节一下。工作的本质,不是为了ld工作,而是给自己工作,提高自己的技能,能挣钱才是目标。不要让自己陷入无尽的社交困境里面,找准靶心,调整节奏,健康作息。

    最近快入冬,身边感冒越来越多,流感也来了,永远是只有身体不舒服的时候才知道健康多重要,

    💼 从工作中学到的 💻 代码思考在正式工作之前,我没有写过单测,主要是平时自己写的代码通常耦合度较高,没有单独抽象设计模块的概念。

    最近开始写一些通用能力的基础库需要写单测。第一次单测的编写是在代码基本完成后开始写的,完成单测后会发现一些bug,于是修改bug。但这个过程中会发现代码设计的一些不合理之处,比如多个接口的返回值是否更统一,对于接口可能出现错误时的返回值,应该如何处理(这个可以多参考chromium base库中的代码实现)。如果一个模块的多个接口设计不统一、那么单测同样也会非常复杂。

    其实上面的过程就有点TDD那味了,但是测试驱动开发,需要先写一个无法通过的测试,通过修改代码来使得测试通过,再重构代码。在这个过程中不断的开发代码,而不是先写完代码,再写单测试。

    单测的重要性是毋庸置疑,因为代码复杂性总可能出现某个分支逻辑错误。因此TDD将单测与开发结合,减轻了写单测的难度和压力,同时也能通过单测进一步发现代码的设计问题。

    参考文章:

    💼 从工作中学到的 工作之前刷题会想,刷题这些有什么用,但是今天真的用上了回溯算法,算法思维在工作中还是有用的,尤其是在做一些底层方法/数据结构设计与封装上很有用(对c++是这样,因为c++的stl 方法并不全能)

    比如chromium中的base::Value 结构是一个递归的结果,如果想拿到最深的key-value 键值对,以及此时的路径上所有key拼接的path,就需要回溯。

    再比如一个目录路径按照分割符打成一个vector,另一个目录下的文件路径同样打成一个vector,想要获取相对路径,就是找两个vector 连续公共的部分。

    之前实习面试中,也有面试官出一些手写的题目,估计就是来源于工作中的一些问题抽象。

联系方式

关于我

  • 来自南部的一个小城市,个性不张扬,讨厌随波逐流。

那年今日
16 月前

还没有阳

18 月前

🍥 正则tip https://cloud.tencent.com/developer/article/1833698?= ?<= ?! ?<!前瞻:exp1(?=exp2) 查找exp2前面的exp1后顾:(?<=exp2)exp1 查找exp2后面的exp1负前瞻:exp1(?!exp2) 查找后面不是exp2的exp1负后顾:(?<!exp2)exp1 查找前面不是exp2的exp1?: 非捕获分组。有的时候我们需要表示一个整体,又不希望它占用正则匹配结果的一个成员,就可以用这个,比如想匹配 字符串中出现foo子串一次或者两次,但又不需要记录这个分组,就可以写 /(?:foo){1,2}/

19 月前

📝 每日记录明天要体检了,今晚不能吃东西,难受...几年前第一次用iOS的时候,发现没有电量百分比,当时觉得苹果为什么连这个都没有,现在iOS16 更新了百分比,用了半天,还是取消显示了,发现百分比对我来说没什么用,而且会让我焦虑...