Tag: 软件工程
这篇文章记录了一次教孩子用 VS Code AI Agent 修改 GitHub Pages 个人主页的经历。相比传统手写代码，AI 时代的编程教育更重要的是学会描述需求、指挥 Agent、理解 GitHub 工作流，并能审核 AI 生成的代码。文章借此引出 Harness Engineering 的概念：大模型是“大脑”，而围绕模型的工具调用、文件编辑、工作流和验证机制，才是真正让 AI 干活的 Harness。 去年弟弟学了一些 GitHub、Markdown 和 HTML，也在 GitHub 上搭了自己的个人主页。虽然页面已经能跑起来了，但整体看起来还是比较乱：有些排版不统一，有些内容结构不清楚，代码也有点像“想到哪里写到哪里”。 这次我就借这个机会，给弟弟演示了一下如何在 VS …
视频：油管/Youtube | B站/小破站 | 微博视频 | 西瓜视频 | 微信视频号 | X/推特 | 小红书 马斯克的x.ai到年底有免费的25美元的credit可以使用Grok大语言模型 前不久（今年初），伊隆·马斯克/Elon Musk的X公司开源了Grok大语言模型，并且给免费提供了25美元的credit可以调用。可以在其官网x.ai注册一个帐号，申请API KEY即可，官网还贴心的的给出了调用的例子。 curl https://api.x.ai/v1/chat/completions -H "Content-Type: application/json" -H "Authorization: Bearer xai-......" -d '{ "messages": …
Google（谷歌）是全球知名的互联网巨头之一，几年前被认为是养老终级大厂，福利优厚，压力相对较小。在英国伦敦，Google设有一个主要从事开发和研究的办公室。 第一次面试 2016年 我在2016年首次面试Google。第一轮是电话面试，由一位在瑞士的工程师主导，通过电话交流并在Google Doc上同步编写代码。由于当时技术水平有限，我用C++完成了那道消息打印的题目，核心是使用队列和哈希表来解决问题，写得很磕磕巴巴。 当时对软件工程师的级别没有特别概念，推测自己面的是SWE L4/L5的级别，因为当时也就工作了5年多。 我查了一下邮件，2013年11月份的时候谷歌猎头联系我问我要不要试试？我说我当时没拿到英国永居，不想冒险，虽然他说到谷歌可以办工签，我当时还是没有选择去面试，现在想起来实在不可思议，后来2014年/2015年的时候同一个猎头还每隔6个月就check-in一次，最后面是在2016年4月份的时候才开始第一次的。 我要是当时聪明一些，努力刷题一些，搞不好当时进谷歌，现在也工作将近十年了，拿着谷歌股票到现在，也不至于现在混个高不成低不就的。 第二次面试 2020年 第二次面试是2020年11月份，第零轮其实应该算是Google的猎头问的一些选择题，比如C++里的哈希表/map如果访问一个不存在的键会发生什么？Google的软件工程师包括SRE站点可靠工程师在面试的时候都可以选两种路径，一个是数据结构和算法（编程），另一个是运维/DevOps偏LINUX知识的。我都选前者，毕竟这个我感觉只要短期刷题就好了，相反后者需要多年工作实战的积累。 通过了猎头的小测试，我进入了第一轮，是道编程题，但是并不是那种力扣上可以见到的，这一轮45分钟，给得是一个比较有意思的游戏，比如迷宫生成算法。面试的时候需要你主导整个过程，包括澄清问题，构思，写代码，分析复杂度等等，每一步都需要你Think Aloud。虽然这一轮我犯了些错误，但是给得反馈总题还不错，面试官说他觉得我应该进入下一轮。 到了终面，安排在了同一天，上午2轮，下午3轮，我记得3轮编程/Coding，一轮系统设计，一轮Culture Fit/Behavior/行为模式。除了系统设计是1小时，其它的4轮都是45分钟，谷歌的Coding面试45分钟都是解决1题即可，题目并不是力扣上的，题目范围/scope较大，偏难。一般来说coding完还会有一些Follow-up的问题，比如怎么优化算法。这个和Meta/Facebook的Coding面试不同，Meta百分百喜欢出力扣上原题，40分钟内需要解决2题力扣原题（留5分钟问问题），这个可以通过力扣按公司归类最近3/6个月的试题准备即可。 系统设计我记得是设计一个类似AWS S3的文件存储，也不知道是不是看我当时在AWS S3工作。很可惜，最后面这一轮不过关，当时我面的是L5（Senior），软件工程师级别越往上走，对系统设计的能力则要求越高（设计可扩展/分布式/高性能的系统 ）。 Unfortunately Google doesn’t disclose specific feedback per interview session …
技术债 Technical Debt 是软件工程上特别是敏捷开发 (Agile Development) 中的一个概念. 指的是解决一个当前问题最好的方法往往需要更久的时间和精力, 但是为了加快软件开发进度, 赶在代码冻结前按时交差, 采取的一个较为折衷的解法方法. 但是这就是一笔债一样, 可能会把潜在的问题越积越大(利息), 甚至将来却无力偿还(修复). 1年半前, 我提了个BUG, 这个BUG大概是说一种数据文件里如果用TAB而不是空格来隔开字段, 则导入数据过程中软件会崩溃, 这个BUG的确是有效的, 因为把这数据文件放到别的软件中导入则是没有问题的. 前前后后讨论了半年, 然后总算被批准了, 不过由于开发任务繁重, 而且也不是那种非改不可的BUG, 所以就一直拖, 拖到今年10月份, 突然接到邮件通知: “agreed to …
在代码出现性能瓶颈的时候,我们通常使用性能评估软件也就是Profiler 来查看代码中到底是哪几行,或者哪几个模块比较耗资源(速度慢或者占内存). 最近我就用 Profiler 跑了一下,发现我写了几处无用的代码.具体如下: 每行代码左边那个数字是被调用的次数,中间是执行时间(毫秒),右边是子函数的执行时间.我红色标出来的执行次数都是 1498179,而在进入这个函数的前几行都是在判断,如果条件不符合就立马退出函数,避免继续往下执行而导致程序崩溃(数组访问越界等). 但是明显来说,这几行代码都没有起作用.删掉这几行代码能省下2-3秒的执行时间.其实这种编程风格是 “Defensive Programming” 也就是处处加些判断(比如判断对像是否为 null)而不让程序崩溃.但实际上并不推荐,因为最好是一遇到错误就立即抛出异常,这样可以让我们更早的知道潜在的问题,而不是隐藏错误. 英文: The profiler told me I wrote some useless code (An Example of Defensive Programming) 本文一共 305 …
一种观点是 写更多的代码 程序员就更有经验 这样程序里错误就会相对少一些. 但这并不是 说代码越多越好. 如果能用更少的代码完成更多的事 那么越少的代码隐藏的错误就更少. 统计代码行数只会鼓励糟糕的代码. Less is more! 代码审核 可以由多种方式来完成 比如可以结对编程 (Pair Programming) 或者可以由专门代码仓库负责人 按阶段审核并接受提交. 有了代码审核以下的错误就会少了很多. 英文: https://helloacm.com/case-study-importance-of-code-review/ 本文一共 171 个汉字, 你数一下对不对. 再谈代码审核的重要性. (AMP 移动加速版本) …
没有单元测试的工程就不是好工程, 至少不是大工程. 在 Visual Studio 里可以很方便的进行单元测试的创建和运行. 下面的教程是基于C#但是也可以很容易的应用到其它语言,比如 C++. // Example: How to Create Unit Tests // helloacm.com using System; namespace ClassLibrary1 { public class Class1 { public int GetEven() …
