1888 条评论

友人C 9 个月前
C++Tips Google C++ Style 关于输出参数在2020年5月20号 以及之前推荐使用指针：
Input parameters are usually values or const references, while output and input/output parameters will be pointers to non-const.
而在之后，则修改规范推荐使用了引用：
Input parameters should usually be values or const references, while required (non-nullable) output and input/output parameters should usually be references
个人认为指针作为输出参数更明确语意，如果使用引用参数，程序员可能漏写了const，从而输入参数被误认为是输出参数。
但是可能这不是一个好的理由，因为这是程序员自身的错误，同时传递指针需要内部判空使用有些麻烦。
 0 发自Mac OSX

友人C 9 个月前
📖 读书 最近在读《非暴力沟通》，很早在微信读书简单看过几页，这次买来实体书去看，觉得写的很不错。
非暴力沟通流程上并不复杂，沟通中遵循四个步骤即可：观察、感受、需要和请求，非暴力沟通核心在于不批判/评判任何事情，而专注自己的感受和需求是否被满足。
首先需要区分观察与评价。我试了一天进行这个训练，并不容易。比如“食堂有人不小心撞了一下，会下意识的骂道没长眼吗”，“等红绿灯的时候有人闯红灯就会暗想真没素质”。除了这种明显的评价以外，还有一些非常容易混淆的评价。比如你总是很早就下班，他每次开会都很晚才过来，他经常见面故意不打招呼。看上去是在描述事实，实际上已经带上评价的词汇，比如“总”、“每次”，“经常”，“故意”，这些词汇的评价大概率都是评价，观察在于描述准确的事实而不带有任何感情偏好。
其次区分感受与想法。感受一般以“我感到”开头，或者直接表达自己的情绪，比如我饿了、我感受孤单，我害怕等等。但是很容易与想法混淆。想法和评价类似，一般以“我认为” 开头，比如我认为他故意不理我，我认为他不尊重我，我认为他工作能力不行。会发现这两种很重要的区别在于，感受是来己自身，与他人无关，他人行为只是外在因素，并非是我们的感受。"我感到被孤立" 这种说法非常迷惑，实际上是一种想法，而非感受，更准确的表达是“我认为我被孤立”。
在非暴力沟通中，非常重要的一点就是意识到我们感受的根源是来自自身的需求未被满足，而非是他人的行为（可能有关，但不是根本因素）。只有意识到这里才能让我们跳出指责🫵他人的思维，更好的把注意力放到如何满足自身的需要上。
因此发现自己的需要至关重要。但特别注意的是，“需要”是我们自身渴求的资源，“需要”和满足需要的方法区分开。具体来说，“需要”不涉及到具体行为的人。比如，宿舍里太吵了，”我需要其他人安静一点“这不是书里定义的”需要“。这里真正的需要是”我需要更安静的环境以便更好休息/学习等“。只有区分这两点，在沟通中表达我们的需要，才能让对方不会觉得是在指责🫵对方。
在实际的的沟通中，为了让对方更好的倾听我们表达的感受、需要和请求，我们也需要主动的先去倾听对方的感受、需要和请求。尤其是识别对方语句中的感受和需求。
在这本书里，还有两个观点让我感觉很有意思：
• 对”感受“来源的曲解。现实中我们很容易将我们的感受归咎到其他人身上，比如，“他总是很懒让我很生气”。这里的潜意识是，我们希望通过这种表达，让对方内疚，希望利用对方的内疚来达成我们的目的，这其实就是一种语言“暴力”。换成“非暴力沟通”大致是：这一周的每天回家的时候，衣服都直接扔在沙发上（观察），我感到不开心（感受），我希望家里能够更整洁、更舒适（需要）。你能把衣服放到衣架上吗（请求）。” 由此可以发现同一种情绪，换一种表达方式就会减少对抗，实在是很神奇的，而后者没有指责🫵对方，更关注对方能够满足自己需要上。
PS：你也许会说，一次说了，这次改过来了，后面又是一次次的回家就扔到沙发上，每次都说，想不生气都难。一旦有生气的情绪，其实本质还是自己的需要没有被满足。如果自己表达了自己需求仍然没有被满足，说明对方没有真心认可你的说法，很可能是对方的需要没有被满足，不妨引导对方表达对方的感受和需要。比如对方可能工作回来很累，回家需要更放松，不希望太过有形式。在充分理解对方基础上，再协商提出新的需要，直到双方都能满足各自的需要为止。非暴力沟通中，倾听也是非常重要的一部分，不仅以更合适的方式表达自己的感受和需求，同时也需要从对方的话中识别出对方的感受和需要，
• “不得不”的曲解。我经常早上起床的时候会想，今天又“不得不”起床上班了，今天又不得不面对那些工作上的烦心事情了。这种表达方式是别人逼迫自己做的选择，自己也没有别的选择了，淡化了个人责任。书中建议改为“我选择___，因为”。比如上面的表达就可以改成"我选择每天起床上班，是因为我想要得到收入报酬以便自己能够过的更加体面和自由"。在这个表达里可以看到我们做的选择是为了满足我们特定的需要。
这两个 常见的曲解本质都是逃避了自己责任，是需要更好的觉察到的。
 0 发自Mac OSX

友人C 6 个月前
要想让自己始终是 “请求”，而不是“要求”别人的一个方法是，当你有一个对别人的请求的时候，就立即去说出来。在脑海里构建的时间越长，投入的精力越多，就越可能强迫别人满足自己的“请求”，从而变成一个要求。
 0 发自Windows 10

友人C 9 个月前
💬 随便聊聊 对抗负面情绪是一件非常容易和非常困难的事情。简单是因为负面情绪不是真实的物理伤害，是可以人为控制的，比如别人给了你一拳，你首先感到疼痛，其次感到愤怒。前者是物理伤害，而后者则是自己产生的负面情绪和他人无关。困难的是很多事情似乎无法控制，负面情绪就是潮水一般的淹没大脑。个人觉得可能因为物理伤害经历的太少，所以才会过分的纠结于负面情绪吧。
经常看到一些“矫情”评论，底下回复：“关两天空调就老实了”。可能是类似的道理。关空调带来的难以忍受的热是物理伤害，只有当经历的物理伤害足够大的时候，才会对那些“情绪伤害”嗤之以鼻和云淡风轻吧。如果没有经历过彻骨的痛苦，又怎能珍惜当下呢，就很容易的陷入负面情绪了
所以如果你经常陷入负面情绪，也许你是不幸的，但也许也是幸福的OωO 因为痛苦总是相对的，也许你会说痛苦不能被比较，和他人比较痛苦是无意义的，但是自己感受的到的痛苦却是真实可比较的
 0 发自Mac OSX

友人C 6 个月前
"情绪闪回"
 0 发自Mac OSX

友人C 9 个月前
💬 分享 New York is 3 hours ahead of California but it does not mean that California is slow, or that New York is fast. Both are working based on their own "Time Zone."
LINK
 0 发自Mac OSX

友人C 10 个月前
💼 工作记录
    std::string origin_response_body = "test_content";
    const int body_len = origin_response_body.length();
    std::unique_ptr<char[]> response_body(new char[body_len]);
    memcpy(response_body.get(), origin_response_body.c_str(), body_len);
    std::string body = response_body.get(); 
这段代码是有隐患的，但是却比较难发现。因为如果这个数组中最后一位不是\0 结束符，构造string的过程中就会一直按照地址递增访问内存直到找到结束符为止，这个过程会导致内存异常访问等问题
但在真实环境中，可能不一定会导致崩溃，因为当我们new[body_len] 申请一段内存的时候，由于内存对齐以及操作系统的差异性，分配的大小会大于申请的大小，因此在body_len 位置的内存很可能就是结束符。 C++Tips
 1 发自Mac OSX

胖哥 9 个月前
1:
std::unique_ptr<char[]> response_body(new char[body_len + 1]); // 分配空间 这种非常重要 且常见
memcpy(response_body.get(), origin_response_body.c_str(), body_len + 1); // 拷贝完整字符串
2：动态分配 在设计、开发阶段是要被严格管控的， 至少做到1、在详细设计阶段就要体现在文档里。2、边界检查 3、测试覆盖
 0 发自Windows 10

胖哥 9 个月前
好像发的不对，检查了下，基本没有临时的动态分配、
 0 发自Windows 10

友人C 9 个月前
我这里简化了，memcpy的逻辑是另一个函数的事情，函数参数就是char*，所以外部必须传入一个分配好空间的字符指针进去
这个是sdk的代码，个人觉得c++项目而且没有那么高的性能要求下，尽量可以不用char*指针，同时这个sdk内部保存的就是string，但是函数参数是char*导致string->char*->string 这样诡异的逻辑出现
 0 发自Mac OSX

友人C 10 个月前
📝 每日记录 「自我觉察」
今天晚上在写一篇“读后感”，写了1小时左右发现自己进入了“状态”了，从而发现进入状态的重要性。
之前可能觉得“进入状态”只是一个形容词，而今天发现它确实是做好事情的一个具体的步骤。
这里列举目前想到的一些条件：
1. 良好的环境：环境是重要的，比如安静环境下更容易专注。但是很多的时候可能没有那么好的环境，因此可以尝试更好的环境，比如耳塞或者纯音乐，文档全屏等，但注意不要为此舍本逐末了。
2. 第一个可以看到显著效果的行动：如果是写文章，很容易一下午一个字也憋不出来，原因很可能是我们脑子里想的太多了，从文章的摘要到各种细节都在脑子里面转，而不在纸上，导致无法聚焦到一点，因此可以考虑先写下几点，然后不用太关注格式，再去展开第一点，等写完第一点后，就会发现后面的内容自然的有了思路。如果是写代码，可以尝试从UT开始写起，完成第一个可验证通过的UT。如果不具备写UT的条件，可以从完成第一个可以编译通过的代码开始，再到实际上产生具体作用的函数。一定不要一开始就kuchikuchi的创建一堆文件，也编译不通过，希望一次性写完编译，这是非常严重的错误。
3. 进入状态的决心：必须要有想进入状态的决心，比如今晚你确实计划想完成某项任务，这非常重要。
4. 较长的时间长度：进入状态的时间最好是1小时起。如果太短，则完成的事情有限，因此需要确保这一小时不被其他事情打断（比如开会，其他人找过来问问题等）
5. 单一工作内容：只专注在一件事，而非同时多个任务切换
 0 发自Mac OSX

友人C 10 个月前
💬 随便聊聊 最近很火的 AI 认为 9.11 > 9.8 我的第一反应居然和AI一样... 可能是版本号看多了吧
 6 发自Mac OSX

友人C 10 个月前
💬 随便聊聊 看到一个评论很有意思：“至少我从来没听说过有人死前还会想着，这辈子没有赚更多的钱没有为当年的公司做更多的牛马之事。”
 1 发自Mac OSX

友人C 10 个月前
💼 工作记录
最近的两个需求尝试以 “面向测试开发”来开发。所谓“面向测试开发”，或者“测试驱动开发”，我理解就是先去写UT，先去在UT里面写好调用的函数和预期的接口。每写一个EXPECT，对应去实现类的功能，这样写完UT，功能也开发完成了，保证了模块的质量。
通过这种方式发现写代码的阻力更小一些。之前写代码脑子里可能混杂多个接口的设计想法，通过UT，每次只增加一个新的case，实现该case，能够“小步快走”，会更不容易出错。
这对项目代码质量是有比较大的要求的，如果是一个新的独立模块，还好一些，可以从零开始写UT，如果这个模块有依赖外部模块，需要mock或者外部模块也具有可测性。
如果是在已有的功能模块里新增新的功能，这就要求已有模块可测性非常强才行。历史的很多代码都没有UT，这也是困难之一吧。
 2 发自Mac OSX

友人C 11 个月前
💼 工作记录
“当你排除一切不可能的情况，剩下的，不管多难以置信，那都是事实。”
工作中排查bug的时候很像是侦探🕵️寻找真相。简单的bug可能很快从代码review就能发现，比如空指针等。这周遇到了一个bug ，简单来说，
• 正常情况下是先执行B操作，再执行 C操作。
• 执行A 操作后，预期就不可能有B操作或者C操作了，但是A操作它是跨线程异步过程（一般时间很短几毫秒或者几十毫秒之内）。
线上的问题是在A操作过程中，出现了B操作，导致后续C操作的时候直接崩溃。所以线上会有概率非常小的情况下崩溃。
这里写代码的时候没有考虑到这个异步过程，同时B操作或者C操作中应该增加判断，如果A操作后，就是空操作。
 1 发自Mac OSX