sbc11

摘要： 《人月神话》读书笔记（七）：技术债务与维护的挑战 布鲁克斯的维护观 书中强调： 维护成本远超开发：软件生命周期中，80%成本可能花在维护。 “第二个系统效应”：过度设计会让系统变得复杂难维护。 现代技术债务问题 今天的软件维护面临新挑战： 快速迭代的代价：为赶工期牺牲代码质量，积累债务。 微服务的隐 阅读全文

摘要： 《人月神话》读书笔记（六）：软件估算的永恒难题 布鲁克斯的估算困境 书中指出： 软件项目难以准确估算：因创造性工作不可预测。 “乐观主义偏差”：开发者常低估复杂度。 “霍夫施塔特定律”：事情总比预期耗时更长。 现代估算方法 今天，业界尝试用新方法应对估算难题： 故事点与敏捷估算：用相对复杂度（如斐波 阅读全文

摘要： 《人月神话》读书笔记（五）：团队协作的演化与反模式 布鲁克斯的团队协作模型 在《人月神话》中，布鲁克斯提出两种团队组织方式： 外科手术团队：由少数精英（首席程序员）主导，其他人提供支持（如文档、测试）。 民主式团队：成员平等协作，但可能导致设计混乱。 他认为，小规模、高技能团队比大规模、低效协作更优 阅读全文

摘要： 《人月神话》读书笔记（四）：概念完整性的当代意义 概念完整性的新解读 布鲁克斯强调系统设计必须保持一致性，否则会陷入混乱。今天，这一原则依然关键： API设计：REST、GraphQL等需要清晰的约定，否则集成困难。 领域驱动设计（DDD）：统一语言（Ubiquitous Language）确保业务 阅读全文

摘要： 《人月神话》读书笔记（三）：银弹幻觉的当代变种 AI与低代码：新的“银弹”？ 布鲁克斯认为“没有银弹”（即没有能十倍提升生产力的技术突破），但近年来： AI编程助手（GitHub Copilot、Codex）：可自动生成代码，减少重复劳动。 低代码/无代码平台：让非技术人员也能构建应用，但可能导致技 阅读全文

摘要： 《人月神话》读书笔记（二）：现代工程实践的挑战 小团队与敏捷开发 布鲁克斯的观察基于数千人的大型团队，但现代软件开发更多由小团队（5-10人）完成： 微服务架构：系统被拆分为独立服务，减少全局协调成本。 敏捷开发：迭代式开发取代瀑布模型，需求可以动态调整。 开源协作：GitHub等平台让全球开发者能 阅读全文

摘要： 《人月神话》读书笔记（一）：经典命题与时代背景 布鲁克斯的核心观点 《人月神话》最著名的论断是“向进度落后的项目增加人手，只会使进度更加落后”（即“布鲁克斯法则”）。这一观点源于作者在IBM System/360操作系统开发中的经验，揭示了软件工程的独特挑战： 人月（Man-Month）不是可互换的 阅读全文

摘要： 今天上了毛概课程 做了一道力扣题60 思路：通过 计算剩余数字个数的阶乘数，一位一位选出第 k 个排列的数位。 阅读全文

摘要： 上学期java挂科，主要原因是对这门课程不上心，老师布置的任务不完成 本学期在学期结束时应进步不在挂科 阅读全文

摘要： 首先就是先明确自己的身份 确定了使用的技术开始决定使用的语言 然后开始让ai帮你构建项目框架 还可以让ai写出如何创建项目的步骤，有了框架开始让ai生成代码 可以跟据框架让ai一个一个生成 最后对代码进行整合完成 阅读全文