1836 条评论

友人C 昨天 23:56
💼 工作记录 做事情的时候一定要做一步记录一步，每一步都走踏实了，切忌同时并行铺开很多方向，每个方向都浅尝辄止，这样前面的很多时间的收益就没有那么高了。最慢的反而是唯一的捷径。
 0 发自Mac OSX

友人C 昨天 23:43
💼 工作记录 工作三年得出最重要的一个想法：你始终要坚信自己能做的比任何人好，不迷信权威
 0 发自Mac OSX

友人C 2 天前
💼 工作记录 发现有不少代码都是我当时参加的方案评审，当时想的是，每个人都有自己的编程习惯，所以我不太会强求别人在代码设计上一定要怎么样...比如命名风格，函数抽象，类设计等。但是这些我参加评审的代码模块最后都交接给我了 所以如果别人找你review代码或者是方案评审，就一定要坚持自己原则，别人如果觉得不对，那就提出来讨论就好了
 0 发自Mac OSX

友人C 2 个月前
💼 工作记录 职场不是学校，没有人有义务为你的努力打分，除非你能证明它值钱。
from deepseek。 🤖 AI
 1 发自Mac OSX

友人C 2 个月前
💼 工作记录 三年前，我用 electron 写了一个番茄钟（为什么是electron，因为它是跨平台成本最小的开发方式了 hhh），当时的初衷是为了替代滴答清单里面番茄钟，因为不想再用滴答清单了，所以它的界面就是参考滴答清单的番茄钟。

我在https://www.ihewro.com/archives/1205/ 也提到了这一点。
这个软件我用了两年，在2023年、2024年我又基本上没有再用了，而今年我准备重新捡起来，用于增强注意力专注能力。在博客右侧边栏增加了当天的专注数据小组件。
后端比较简单，就是同步数据库更新指令操作数据库，之前用python实现的，后面准备改为typecho的一个插件来实现，后面再准备以合适方式对外发布这款软件。
它有一些特点：
• 自定义番茄开始的背景声：支持指定音乐文件夹
• 有趣的想法：加了一个“慢启动”的模式，即第一个番茄钟只有10分钟，完成后，下一个番茄会自动设置为15分钟，直到最高值45分钟。它能承载更多我们自己的想法。
• 自己部署后端：意味着数据完全可控，同时支持各种API接口，能将数据可视化到更多地方，可玩性更高，比如 notion api 真的强大，写了一个逻辑将番茄钟的记录同步到notion的database...
• 数据统计可视化：支持当天数据时间轴方式查看，还支持按周、按月方式查看专注信息
• 多种显示模式：比如悬浮模式、全局模式
• 可以和自己的博客联动：比如handsome主题左侧边栏头像下自动显示番茄钟状态
当然还有一些想法未实现，但整体还是希望简单，而不是成为一个项目管理这种复杂逻辑的软件：
1. 提醒补录
2. 自动记录电脑上的软件行为（需要调研）
3. 支持不同类别的时间记录
 18 发自Mac OSX

Jason 1 个月前
很需要这个～～ 简单而又高效
 0 发自Mac OSX

胖哥 2 个月前
您好，工具方便分享吗？同想用。
 1 发自Windows 10

友人C 2 个月前
代码还需要再整理一下才能发布 比如现在软件里面调用后端接口地址是写死的。如果有其他感兴趣朋友可以给这条说说点赞提升优先级～
 2 发自iPhone

JIeJaitt 1 个月前
挺感谢去的，作者大大加加油
 0 发自Windows 10

友人C 1 个月前
大家也可以分享下，现在有无使用番茄钟，现有的番茄钟是否有未被满足的需求的
 0 发自Mac OSX

胖哥 1 个月前
另外一个非常大的缺点就是付费，虽然不多，就百块一年，但是就很不爽。
 0 发自Windows 10

胖哥 1 个月前
刚刚付费的我的碎碎念(生气#/qf)
 0 发自Windows 10

胖哥 1 个月前
很多不能满足的需求，整理下回复到这条评论下面。
我在做一个和硬件结合的番茄时钟，但是实现上不是非常顺利，滴答清单的API虽然丰富，但是数据用起来很不习惯，而且数据大部分都是单向的(本地获取服务器上的清单)，我很多时候需求都是提醒自己什么时间做什么。 然后就是UI，不喜欢番茄时钟的风格，不支持缩放，对多屏不友好，提醒比较软，不支持一键开始，等等。
 1 发自Windows 10

友人C 2 个月前
💼 工作记录 从工作中学到的一点：任何没有细化的目标都是空中楼阁。工作中可能有的时候leade一时兴起说要达成什么目标，但是又不给资源和重视，甚至也没有截止时间，就感觉只是提了一嘴，属于“薛定谔的重要且不紧急”的工作，这种工作很容易就会被遗忘掉...给自己制定目标同样，如果没有细分任务、阶段性汇报、阶段性里程碑，这样的目标完全就是欺骗自己。
 0 发自Mac OSX

友人C 3 个月前
此条为私密说说，仅发布者可见
 4 发自Mac OSX

holwell 2 个月前
确实，同感
 0 发自Windows 10

友人C 3 个月前
📝 每日记录 有点感冒了，今天疲惫的要命。晚上和另一个同事随口说感冒好难受，昨晚睡了12个小时。我才发现自己并不是需要对方做什么，就是一句同理的回应就足矣了，比如“啊，这真的太难受了吧，上次感冒我也是这么疲惫了好几天”。 😷 生病的事
💼 工作记录
下午leader给我们小组做了“结构化表达”的培训。简单来说就是表达需要带有目的，在这个基础上使用一些框架（比如SQCA描述问题或者PREP 表达观点）。
会上提到了一个小问题，是华为的一道面试题“怎么运输800斤的牛过承重700斤的桥”。有点可悲的是，当时想象力完全被扼杀了，以至于我看到这个问题后，除了把牛杀了想不到别的方法了，甚至还会有“把牛杀了这个答案肯定不行的吧”的自我否定。
结构化表达的第一步骤是将“隐性思维显性化”，问题是运输牛，实际上就涉及到牛、运输方式、桥这三个基本因素，再发散一点还和当时的环境有关。所以分别在这四点上进行改进就能回答这个问题了。
这个思维方式给我有很大的启发。 表达和思维是相关的，因此这些模式即可用来表达（组织已有的内容），也可以用来思维（思考未完成的内容）。
 1 发自Mac OSX

友人C 4 个月前
💼 工作记录 工作中，如果同事对你的工作不满你会如何应对？比如跨团队同事合作，因为细节之前不了解，反复追问对方，然后对方不耐烦了，或者是别人对你的工作提出批评。
之前，我可能会下意识的内在批判者就开始启动了，肯定是自己太笨了，自己太让人烦了吧。
其实很早就会告诉自己，不要批判自己，但是一直没有去思考：“那正确答案是什么？”存在一种不用批判自己的应对方式吗？
可能你会说，转而批胖别人，将情绪的宣泄口转向对方，别人骂我我就骂回去。这还不对。
承认自己做的没有足够好，承认自己让别人烦了，但是不批判自己可以吗？因为这不是我们自己的错。承认是表示同理对方的感受，对方也可能经历“战反应”的情绪闪回。但不认为是自身价值的缺失，即抛弃“全或无”的观点。
 1 发自Mac OSX

友人C 4 个月前
💼 工作记录 今天要修复一个之前写业务代码模块时候的一个bug，已经好几个月没写太多业务代码了。这让我回想起写业务代码有写业务的挣扎。新增或者修改一个接口经常要想很久，尤其设计了很多业务特化点的时候，减少特化和最小改动之间不断进行权衡。
 1 发自Mac OSX

友人C 4 个月前
💼 工作记录 最近整理之前最早工作时候调研的一些关于进程、内存指标概念的文章。
刚开始工作有很多时间用来调研和学习，mentor也很支持我，所以当时想猛攻这部分然后能写出一篇非常专业、完善、严谨的文章来。但是因为内存指标涉及到的内容很广，比如系统物理内存管理方式，虚拟内存技术中的概念，内存申请方式，不同操作系统中术语看似相似实际差别巨大，导致这篇文章一直没有写完。
这次重新整理内容发现，像这种复杂的话题的写作，如果是专注于全就不用太深（配合更多的图表来梳理概念之间的关系）,同时尽量避免知识性错误；如果专注于深，就不能太广泛，否则就会让自己陷入一个短时间难以完成的境地（比如内存这个话题可能需要很年的排查经验、源码研究等才能又全又深入，到足以出书的程度）。这个方式适合很多复杂话题的写作，比如耗时问题优化、性能品质、某个工具的使用等等。
 3 发自iPhone

友人C 8 个月前
💼 工作记录
    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

胖哥 8 个月前
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

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

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

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

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

友人C 10 个月前
💼 工作记录 对于客户端开发来说，crash是性能/稳定性中最重要的指标之一，因为crash意味着功能不可用。
最近工作上引入了两个功能crash，被折腾了一番，有一个感想：“对任何改动的上线一定要测试”。这里“测试”根据不同情况有不同程度测试，其中最基本的测试是确认功能是否能跑起来，而不仅仅是编译通过即可。
可能你会说，提代码肯定需要测试啊。但是有些场景，可能就会偷懒，比如加一行日志，或者简单增加一个指针判空，或者简单调整了两行代码的位置，就因为“匆忙”，并且过度自信，就没有测试，甚至基本测试都没有！
上述的场景可能是本地的分支开发别的功能，突然反馈过来的一个bugfix，为了本地不切分支，而选择在网页端简单提交bugfix的代码
这些看上去“人畜无害”的代码，其实往往暗藏“玄机”。比如日志打印调用了一个指针的函数，却没有检查指针是否为空，误以为指针一定不为空，尤其是在编写宏的情况，更容易忽视。
除了这些改动极小的代码，一些不是特别大的改动也可能引入意想不到的问题。举个例子，移动了某一个observer 事件发送的位置，在模块owner看来可能没什么关系，但可能外部利用了这个observer，并且依赖了某种时序，一旦某两行代码调整了顺序就可能导致异常。
这里有一个调整两行代码顺序导致问题的例子：
....
std::string str = "1234";
SomeStrToInt(str);
SomeClassConstruct class (std::move(str));
其中第3行和第4行的位置调整就会导致异常，而这个问题非常难以发现，因为最开始的这段代码可能比较久远，甚至不是自己写的，因此就会忽视后面对string move的调用。
---
有经验的程序员是否可以避免上述问题，足够细心的条件下一些简单的错误可以被避免，比如上面的std::move 顺序问题。但是对于更复杂的场景忽略掉也是可以被理解的，更不用说，粗心是一种很容易犯的问题。
因此黑盒测试的必要性是无法被白盒测试替代，白盒测试100%覆盖是一个理想而不及的目标，受限于代码可测性、ut质量等等因素。意味着一定有不少场景是UT无法覆盖的部分，对于大型项目尤其如此。（尽管如此，UT重要性仍然是不言而喻）
---
我个人的一点想法是对任何提交MR做以下两点检查：
• 做了哪些测试来减少问题发生 （至少要测试功能是否可以跑起来，而不是过度自信）
• 是否对该处改动的所有外部依赖都清楚，如果不清楚则优先考虑使用灰度验证的方式上线（比如修改某个对外的接口返回值，不要过度自信！）
上面的两点check不能避免所有的问题，但可以拦截大部分很低级的问题（事实很问题都来自低级的错误），除此之外，成熟的工程会一般会有完备的稳定性流程来拦截更复杂的问题。
 1 发自Mac OSX

胖哥 10 个月前
冒烟测试 你们这边是开发自测的吗 还是有专门的团队、工具做冒烟测试的呢？
crash我们一般很多会遇到，在冒烟测试拦截的居多， 然后取dump文件，分析定位，建BUGid 解决bug 回顾总结 写rootcase。
 0 发自Windows 10

友人C 10 个月前
各个环节也是有的，比较头疼是写「回顾总结」文档，感觉团队里有些太重文档，文档写了具体原因还要一遍遍的修改细节，绘制图之类
 0 发自Mac OSX