最新

大家好，你们能帮我检查一下我的想法吗？我是不是一个糟糕的开发者（这总有可能），或者我是不是过于关注一些不重要的事情？ 我有超过13年的工作经验，已经在大型科技公司工作了大约4年，刚刚加入一家成立了10年的盈利性初创公司一个月，我在想自己是否在与“影响力”竞争、绩效排名等方面脱节。 我不知道自己是否应该留在这家公司，因为我觉得在这里无法做出好的工作，感觉如果我继续待下去，五年后我的经验会比刚开始时还要少。 ----- 所以 我一个月前加入了一家成熟的初创公司，他们正在逐步将一个遗留应用从Angular 1迁移到React。 他们的“好”应用是一个非常复杂的自定义React实现，极难理解，包括某种组件中间件和半成品的Redux集成，根本无法与任何开发工具配合使用。 客户端的JavaScript文件大约有20MB，而本地开发工作流程相当糟糕。 90%的代码是JavaScript，10%是TypeScript，团队实际上并不想转向TypeScript，禁止将现有代码迁移到TypeScript。 我刚开始时注意到一些基本错误，比如没有将package-lock提交到代码库，所以我询问了这个问题并提交了一个增加package-lock的PR，但被拒绝了，理由是“风险太大”。 在npm审计中，package-lock引发了60个严重漏洞，我提出了这个问题，但被告知解决这些问题风险太大。我建议至少应该为应用添加一个CSP，因为一些漏洞与注入攻击有关，但同样被认为“风险太大”。 在开发过程中，热重载时间为30秒，所以我提交了一个PR，添加了`npm run dev:next`，该命令使用Rspack仅为开发构建客户端，将热重载时间缩短了一半，但也被拒绝了。 我注意到他们没有任何自动化测试（有一个海外团队在每次发布前进行手动QA），我询问他们是否愿意构建一个自动化测试套件，他们回答不愿意。 他们也没有任何CI，所有验证都发生在预提交钩子中，他们也不想添加这个。 我发现他们在客户端没有任何可观察性——没有错误率，没有加载时间。我问他们如何知道是否出现了问题，显然，如果在QA中没有发现，“客户会打电话给我们，我们就修复”。我建议采用像Sentry这样的工具来开始跟踪客户端，以帮助量化功能的影响并在错误升级之前预防错误，但再次被告知不行，因为这“风险太大”。 今天早上我的经理和我进行了一对一的谈话，他告诉我不应该尝试在我被分配的任务之外做贡献，并且我每天必须提交一个PR，否则会被解雇。 我重复了我之前的担忧，他说他们雇我就是为了完成任务，仅此而已。

嗨，HN，我是Hal，App Dev for All的首席技术官。我想分享一下我们在过去一年中解决的一个技术问题，以及我们的处理方法。 我们正在开发“随时编码”（Code on the Go），这是一款功能齐全的集成开发环境（IDE），可以完全在Android手机上运行。无需笔记本电脑，无需ADB连接，也无需云构建服务器。它使用Gradle在设备上本地编译项目，支持Java和Kotlin，并包含一个在与被测试应用相同手机上运行的调试器。 最有趣且具有挑战性的部分是调试器。Android操作系统有着严格的安全模型，这可能会妨碍传统的进程间通信。Android调试依赖于ADB，而ADB又假设有两台机器。我们完全绕过了ADB，在启动时将JDWP代理附加到目标进程，并通过本地套接字将其输出路由到我们的调试器。我们使用了Shizuku项目的范围适配，以获取必要的系统访问权限，而无需获取root权限。 在“随时编码”中，我们还面临了一些其他技术挑战：Sketch-to-UI（从手绘布局的照片生成Android XML，完全离线运行，使用Yolo）、一个可选的Gemini驱动的编码助手（可选择，需自备API密钥），以及一个具有隔离类加载器的插件系统。 我们的一个预发布社区成员已经使用它在Play商店构建并发布了一个僧伽罗语/英语键盘应用，完全在他的手机上完成。这为我们的Play商店兼容性提供了测试案例。 我们是一个慈善项目。没有广告，没有追踪，没有订阅。许可证为GPLv3。 APK: [http://appdevforall.org/codeonthego](http://appdevforall.org/codeonthego) 源代码: [http://github.com/appdevforall/CodeOnTheGo](http://github.com/appdevforall/CodeOnTheGo) 欢迎就实现方面的问题进行提问。

我用 Rust、libghostty-vt 和 quickjs 构建的一个玩具 UNIX 模拟器。