现代软件工程 软件工程师能力自我评价表

这是《构建之法》和软件工程教学的一部分，用于学生/工程师自我评价。 

软件工程师如何评价自己的能力？ 有人写Java，有人用C++，还有人用1980年代就出现的 Object-C, 有人写前端，有人写后端，有人偏于行业应用，有人做平台，还有越来越多的人让 AI 进行 vibe coding ... 有人在小公司，有人在大公司，...  如何衡量一些通用的软件工程能力，并找到精进的路径呢？

一个最简单的起步：把你的技术简历和这个网页的考察点都发给 AI，然后问：我目前处于什么水平，我马上可以动手提高的方向在哪里？

 

开源版本在： https://gitee.com/zgcai/oscanner/blob/main/engineer_level.md 

 

2026 AI-Native 工程师实战能力评估标准

 

The 2026 Practical Competency Standard for AI-Native Engineers

 

前言：当代码不再稀缺

 

在 Vibe Coding（自然语言编程）时代，生成一个“看起来能跑”的 App 变得前所未有的容易。当任何人都能在几分钟内提交代码并构建出应用时，传统的“能写代码”已不再是衡量工程师水平的有效标尺。

 

我们面临着新的挑战：如何区分“AI 的搬运工”与“真正的系统构建者”？ 既然所有人构建的简单 app 都能大致跑通，其中大多数代码都是 AI 写的，那么高低之分究竟藏在哪里？ 我们要考察人类工程师在构建真对复杂问题的高质量解决方案时展现出来的工程能力和水平。

 

本标准建立在一个核心假设之上：代码是不会撒谎的，特别是在开源社区。

 

我们不再依赖面试中的口头陈述，而是将目光聚焦于 GitHub/GitLab 等开源平台上的数字足迹 (Digital Footprints)。通过像“法医”一样审视代码仓库的细节——从 Commit 的粒度、测试用例的断言强度，到重构的轨迹和架构决策的文档——我们能够精准地还原一个工程师的真实段位。

 

这套体系的意义在于：

 

  • 去伪存真： 穿透 AI 生成的表象，识别出谁在真正掌控逻辑，谁只是在堆砌代码。
  • 精准导航： 为学生和初学者指出明确的进阶路径——不仅仅是让 App 跑起来，更要学会如何让它健壮、安全、可维护且可复现。
  • 开源取证： 所有的评价都基于公开可见的证据 (Public Artifacts)。没有黑箱，没有主观臆断，Code is Law。

 

 

评分等级定义与行为画像 (Rating Scale & Behavioral Profiles)

 

L1 理论认知 (Novice)

 

  • 定义描述： 处于依赖与盲目阶段。听说过相关概念，但在实际操作中完全依赖 AI 生成代码，且无法鉴别其正误。
  • 行为特写： 他们的工作状态就像是 AI 的“搬运工”，只会机械地把 Prompt 结果复制进 IDE。一旦 AI 生成了错误代码或幻觉（Hallucination），他们往往无法察觉，或者看着报错信息束手无策，彻底停工等待救援。
  • 判断依据： 代码中常出现低级的逻辑错误或未使用的导入（Unused Imports）；在 Code Review 被问到“为什么这里这么写”时，只能回答“AI 是这么生成的”，无法解释底层逻辑。

 

L2 独立实践 (Competent)

 

  • 定义描述： 属于执行与交付层级。能独立完成任务，是合格的执行者。提交的代码经过测试，符合团队的基本规范。
  • 行为特写： 能把 AI 当作“高级自动补全”工具使用，大大提高写代码的手速。他们能验证代码在“正常流程（Happy Path）”下是工作的，但很少去思考架构的合理性、边界情况或潜在的性能陷阱。
  • 判断依据： 能交付可运行的功能模块，PR（Pull Request）规范整洁，CI/CD 能够通过，但缺乏对复杂系统问题的深层思考或主动优化的证据。

 

L3 一人全栈 (The Maker)

 

  • 定义描述： 具备闭环与破局能力，是 AI 时代的“特种兵”。能熟练配合 AI 工具，一个人抵一个团队，能快速构建 MVP（最小可行性产品）。
  • 行为特写： 极度务实，什么工具快用什么（PaaS, BaaS, Serverless），不拘泥于形式。他们敢于闯入陌生领域（如后端工程师写前端，前端工程师写 Python），利用 AI 迅速填补技能短板，把一个模糊的想法在几天内变成可交互的产品。
  • 判断依据： GitHub/Gitee 仓库通常是一个完整的全栈项目；代码结构可能稍显粗糙（Spaghetti Code），但功能完整度极高，解决了核心痛点，展现出惊人的生产力。

 

L4 团队基石 (The Anchor)

 

  • 定义描述： 代表严谨与赋能，是工业界的“正规军”。不仅求快，更求稳。致力于建立质量门禁、V&V（验证与确认）体系与工程规范。
  • 行为特写： 他们往往是“L3 烂摊子”的收拾者。当 L3 的原型需要扩容或通过合规审查时，他们会站出来引入自动化测试、安全审计和架构解耦。他们本能地关注“Day 2 Operations”（运维、维护、成本），确保系统长期稳定运行。
  • 判断依据： PR 中包含大量的测试代码、重构逻辑和详细的文档；在 Code Review 中能指出架构风险；有主导遗留系统现代化改造（Legacy Modernization）的实际记录。

 

L5 领导者 (Leader)

 

  • 定义描述： 处于生态与战略高度。定义技术标准，设计跨组织架构，深度参与并影响开源生态。
  • 行为特写： 他们不再只是使用工具，而是创造工具或定义模式（Patterns）。他们能透过喧嚣的技术泡沫，看清未来 3-5 年的技术演进路线（如 Agent 协作范式），并引导整个组织或行业提前布局。
  • 判断依据： 是主流开源项目的核心贡献者（Core Contributor/Maintainer）；主导了跨部门或跨公司的技术架构变革；其技术决策被同行视为“最佳实践 (Best Practices)”并广泛效仿。

 

 

维度一：规格实现与内建质量 (Specification & Built-in Quality)

 

核心考察： 在本地开发环境中，利用 AI 将 Spec 转化为高质量、可复现的代码。

 

1. 需求对齐与代码健康度

 

L1

 

  • 状态描述： 代码能运行正常流程 (Happy Path)，但结构冗余，缺乏对非功能性需求（如异常处理）的关注。
  • 开源取证： 存在单个文件超过 500 行或函数圈复杂度 > 15 的情况（e.g., 一个主函数处理所有逻辑，无拆分）；包含大量未使用的死代码 (Dead Code)；注释中残留 AI 生成的解释性文本；Commit 消息模糊；PR 中无 Diff 审查痕迹。

 

L2

 

  • 状态描述： 代码通过静态检查，实现了模块化拆分，清理了冗余逻辑，符合基本工程规范。
  • 开源取证： 仓库配置了 Linter (ESLint/Pylint) 且检查无报错；实现了模块化拆分（如 UI 与逻辑分离）；移除了未使用的变量和 Import；Commit 消息描述清晰；PR 包含基本审查评论。

 

L3

 

  • 状态描述： 主动重构 AI 生成的代码，确保逻辑清晰、类型安全，具备一人全栈的交付质量。
  • 开源取证： Git 历史中有明确的 Refactor Commit；使用强类型定义 (TS Interface/Python Type Hints) 拒绝 any；手动修正了 AI 生成的冗余逻辑；添加 AI 确定性检查：Commit 中显示多次生成 Diff，变异率 < 5%。

 

L4

 

  • 状态描述： 代码内置防御性逻辑，对输入参数进行严格校验，实现了 Spec 中的性能与安全约束。
  • 开源取证： 函数入口处存在显式的 Schema 校验代码 (Zod/Pydantic)；代码复用率高，无重复逻辑块 (DRY Principle)；技术债阈值：SonarQube 扫描无高优先级问题。

 

L5

 

  • 状态描述： 引入高级验证技术，如合约编程并集成自动化审计，实现需求到代码的可追溯性和优化。
  • 开源取证： 核心模块包含合约库引用和自动化审计脚本；代码注释明确标注了对应 Spec 的 Requirement ID；PR 包含审计覆盖率报告 > 95%。

 

2. 验证深度与测试覆盖

 

L1

 

  • 状态描述： 无测试或仅有无意义的测试，完全依赖人工手动点击验证。
  • 开源取证： tests/ 目录缺失，或测试文件中仅包含 assert True 等无意义断言；无 CI 配置，无覆盖报告。

 

L2

 

  • 状态描述： 建立了标准的单元测试，覆盖了主要业务逻辑。
  • 开源取证： 包含标准的单元测试文件；测试覆盖率报告 (Codecov) 显示 Line Coverage > 60%；断言能验证返回数据的基本结构。

 

L3

 

  • 状态描述： 测试覆盖了 Spec 隐含的边缘情况（如空值、超时），隔离了外部依赖。
  • 开源取证： 测试用例包含边界条件 (Edge Cases) 数据；使用了 Mock/Stub 库隔离数据库或 API 调用；扩展到测试金字塔：单元比例 > 60%。

 

[Image of software testing pyramid]

 

L4

 

  • 状态描述： 包含集成测试覆盖完整业务流，追求高分支覆盖率。
  • 开源取证： 包含集成测试 (Integration Tests) 代码；分支覆盖率 (Branch Coverage) > 90%；CI 流水线中集成了测试报告生成步骤；添加 AI 变异测试。

 

L5

 

  • 状态描述： 引入生成式测试和优化策略，自动生成用例验证代码健壮性，并监控测试效率。
  • 开源取证： 引入了属性测试库 (Hypothesis/FastCheck)；CI 中包含变异测试 (Mutation Testing) 报告；PR 包含效率阈值检查。

 

3. 工程复现性与构建完整度

 

L1

 

  • 状态描述： 环境配置依赖本地特殊设置（绝对路径、全局包），在他人机器上无法直接运行。
  • 开源取证： 代码引用了本地绝对路径；缺少依赖描述文件或版本未锁定；README 缺乏环境准备步骤。

 

L2

 

  • 状态描述： 提供了标准文档和依赖列表，按步骤执行可以跑通。
  • 开源取证： README 包含 Install/Usage 章节；依赖文件完整（如 requirements.txt）；提供 .env.example；按文档命令序列能成功启动。

 

L3

 

  • 状态描述： 封装了复杂性，实现一键启动（Make/Docker），降低启动摩擦力。
  • 开源取证： 根目录包含 Makefile / Justfile 封装指令；或包含 docker-compose.yml 可直接拉起全套环境。

 

L4

 

  • 状态描述： 彻底消除环境差异，开发环境与生产环境高度一致，强制代码检查。
  • 开源取证： 包含 .devcontainer 配置；配置了 Pre-commit hooks 强制检查；严格提交了 Lock 文件 (package-lock.json)。

 

L5

 

  • 状态描述： 追求构建可复现性和跨平台优化，支持混合环境（如 ARM/x86），确保高效部署。
  • 开源取证： 使用 Nix 或 Bazel 等构建工具；构建系统实现了密封性 (Hermeticity)；支持 GitHub Codespaces 秒级启动。

 

 

维度二：云原生与架构演进 (Cloud-Native & Architecture Evolution)

 

4. 云原生部署与资源优化

 

L1

 

  • 状态描述： 仅有本地开发视角，部署依赖手动操作或缺乏云端配置。
  • 开源取证： 硬编码敏感配置 (API Key)；Dockerfile 包含冗余工具导致镜像过大 (>1GB)；无部署相关文档或配置。

 

L2

 

  • 状态描述： 掌握容器化流程，能将应用打包并部署到云端。
  • 开源取证： 使用环境变量管理配置；Dockerfile 使用多阶段构建；包含基础的 K8s Deployment/Service YAML。

 

L3

 

  • 状态描述： 优先选择 Serverless/PaaS 减少运维，支撑 MVP 快速验证。
  • 开源取证： 仓库包含 vercel.json / fly.toml 配置；使用 BaaS 服务 SDK；通过云控制台配置了自动扩容。

 

L4

 

  • 状态描述： 通过代码管理基础设施 (IaC)，实现精细化的资源与成本控制。
  • 开源取证： 提交 Terraform/Pulumi 代码；K8s 配置包含资源限制 (requests/limits)；代码包含 Spot 实例中断恢复逻辑；PR 附带成本报告。

 

L5

 

  • 状态描述： 设计可扩展云架构，优化资源利用和成本，支持实际生产场景。
  • 开源取证： 提交了双活架构代码；开发自定义 Kubernetes 配置；设计了流量调度系统；PR 包含量化报告 > 20% 节省。

 

5. 遗留系统现代化

 

L1

 

  • 状态描述： 新旧代码风格割裂，试图暴力重写或完全避开旧系统。
  • 开源取证： 重构 PR 无测试覆盖；新代码与旧代码风格不一致；一次性重写大量代码导致回归错误。

 

L2

 

  • 状态描述： 能针对旧系统具体 Bug 进行修复，风格保持一致。
  • 开源取证： 提交针对旧代码的 Bug Fix 及复现测试；修改风格遵循原有项目规范；PR 包含前后 Diff 确认一致性。

 

L3

 

  • 状态描述： 利用 AI 理解旧逻辑，将特定功能剥离为独立模块。
  • 开源取证： 提交针对旧模块的特征测试 (Characterization Tests)；将单体应用中的函数剥离为微服务；Commit 显示 AI 辅助重构。

 

L4

 

  • 状态描述： 通过架构模式 (如防腐层) 确保新旧系统平滑过渡。
  • 开源取证： 代码中引入 Facade/Adapter 模式；配置网关流量灰度规则；实现“影子模式”代码；迁移度量：灰度成功率 > 95%。

 

L5

 

  • 状态描述： 构建工具和策略来解决规模化的遗留代码迁移问题，确保高效过渡。
  • 开源取证： 开发基于 AST 的自动化重构工具；定义通用的迁移模式标准；PR 量化迁移时间减少 > 30%。

 

 

维度三：AI 工程与自动进化 (AI Engineering & Automated Evolution)

 

6. 智能体编排与工具使用

 

L1

 

  • 状态描述： 依赖单一长文本 Prompt，无结构化控制流，缺乏错误处理。
  • 开源取证： 代码中仅包含 Prompt 字符串拼接；无 try-catch 处理 JSON 解析错误；无函数定义或工具类。

 

L2

 

  • 状态描述： 正确集成 LLM SDK，处理基本交互与重试。
  • 开源取证： 正确调用 SDK 并配置参数；包含结构化日志记录 Prompt/Response；实现了简单的 Retry 逻辑。

 

L3

 

  • 状态描述： 使用框架编排复杂流程，定义清晰的工具供 AI 调用。
  • 开源取证： 使用 LangChain/LangGraph；定义清晰的 Tools 类；展示多步推理 (CoT) 日志。

 

L4

 

  • 状态描述： 构建确定性的状态机和防御体系，确保 Agent 行为可控。
  • 开源取证： 实现标准 MCP Server 接口；Agent 代码包含状态机管理；工具调用入口有数据清洗和校验；集成 LangSmith Trace。

 

L5

 

  • 状态描述： 设计和优化多智能体系统，确保可扩展性和鲁棒性，支持实际应用。
  • 开源取证： 实现自定义的多智能体通信协议；设计动态组队逻辑；解决死锁与上下文污染的代码；Hybrid 扩展优化。

 

7. 自动化进化闭环与数据飞轮

 

L1

 

  • 状态描述： 无数据收集机制，修复问题依赖随机尝试。
  • 开源取证： 无日志记录代码；无反馈收集接口；无评估测试集；修复依赖手动操作。

 

L2

 

  • 状态描述： 记录了运行日志，能进行人工复盘。
  • 开源取证： 实现了完整的 Logging；文档记录了 Prompt 调整前后的对比；PR 包含日志样本。

 

L3

 

  • 状态描述： 建立了数据收集通道，积累优化素材。
  • 开源取证： UI/API 实现“用户反馈”接口；有脚本导出对话历史；定期人工分析 Bad Case。

 

L4

 

  • 状态描述： 反馈回路自动化，通过回归测试发现并修复问题。
  • 开源取证： 仓库包含“黄金数据集 (Golden Dataset)”；CI 包含自动化评估脚本；PR 附带 Ragas/TruLens 评分报告。

 

L5

 

  • 状态描述： 系统具备学习和优化能力，能处理数据生成并进行微调，支持持续改进。
  • 开源取证： 构建课程学习 (Curriculum Learning) 流水线；实现模型自动蒸馏或合成数据生成闭环；PR 包含退化模拟报告。

 

 

维度四：工程底座与职业操守 (Engineering Mastery & Professionalism)

 

8. 开源杠杆与社区贡献

 

L1

 

  • 状态描述： 盲目复制大段代码，依赖管理混乱，文档缺失。
  • 开源取证： 复制粘贴无来源代码；依赖版本号未锁定 (* 或 latest)；无 README；PR 显示依赖冲突无解决。

 

L2

 

  • 状态描述： 规范引入开源库，文档基本合格。
  • 开源取证： 依赖版本锁定；README 包含基本运行步骤；引用代码注明出处；PR 确认无冲突。

 

L3

 

  • 状态描述： 巧妙整合多个组件实现强大功能，文档具备产品思维。
  • 开源取证： 组合创新，代码量少功能强；README 清晰且包含架构图；集成最新工具/论文实现；平衡依赖：至少 20% 自写核心逻辑。

 

L4

 

  • 状态描述： 向社区贡献代码，记录架构决策，提升团队水位。
  • 开源取证： GitHub 有 Merged PR (Bug Fix/Perf Opt)；包含 ADR (架构决策记录）；Code Review 提供建设性指导。

 

L5

 

  • 状态描述： 项目维护者，定义技术实践并贡献优化，提升行业效率。
  • 开源取证： Star > 1000 项目的 Core Maintainer；代码实现行业标准协议；技术方案被广泛引用。

 

9. 手动掌控力与底层原理

 

L1

 

  • 状态描述： 离开 AI 无法完成基础编码，看不懂底层报错。
  • 开源取证： 无法手写基础正则/SQL；看不懂编译器堆栈；存在资源泄漏；PR 显示报错未解决。

 

L2

 

  • 状态描述： 掌握语言基础，能独立解决常规逻辑错误。
  • 开源取证： 脱离 AI 能编写业务逻辑；能通过日志定位常见错误；能手写基础 SQL/Regex。

 

L3

 

  • 状态描述： 具备独立排查跨栈问题能力，能修正 AI 逻辑错误。
  • 开源取证： 独立排查跨前端/后端/DB 的问题；手动修正 AI 生成代码中的逻辑漏洞；PR 测试跨栈运行。

 

L4

 

  • 状态描述： 深入内核/网络/内存层面进行调试与优化。
  • 开源取证： 提交针对内存泄漏、死锁、TCP 参数的修复；手写算法替代低效库；解释底层执行模型；融入 AI 调试：添加 LLM Trace 分析。

 

L5

 

  • 状态描述： 修改和优化核心基础设施，解决复杂系统问题。
  • 开源取证： 提交针对 Kernel/DB 引擎/框架底层的 Patch；通过反汇编解决闭源 Bug；从零构建专用引擎；PR 量化 Bug 定位 < 30min。

 

 

 

===== 2024 年前的版本 ======

第 0 部分：基本数据结构和算法问题，请看《编程之美》 等书籍； 如果想了解应聘的门道，那请看 如何花两年的时间面试一个人 。 

 

第一部分：硬的问题。要在找工作的时候说服别人你是适合这个工作的， 那就要搞清楚对方期待什么东西，自信地展现出你的价值和能力。 (这个列表也可以说是 - 面试中最关键的问题) 

 

下面还有更详细的调查表，适合大家自评，或者在上课前后衡量并找出自己的强项和薄弱环节：

 

 

 

对于一个具体的语言, 例如Java， 你掌握了多少呢？能通过实例来回答下面的每一个问题么？ 

（图片来源于微博 @聊聊架构）

 

 

 

第二部分：软的问题，在成长路上学到了什么？

工程师的能力和成长路径都有多种选择，没有一定之规。IT 行业变化也很快，例如 Swift 语言刚出来两年的时候， 一些招聘广告上就要求 “有 3 年以上 Swift 实际开发经验”， 那么，一个写了 5 年 C++，学了三个月最新版本Swift 语言的工程师能算够格么？  除了每一门具体的语言和工具， 工程师在行业中不断磨练，和各种人合作，参与了各类开发活动，一个优秀工程师是否会培养出独立于具体语言的 “工程师能力”？ 如果一个项目领导带领团队做了几年的项目，团队中的工程师用各种编程语言解决具体问题， 他和不做领导的工程师相比有什么特别的能力？他在每一个具体的编程语言上可能都不如某个工程师， 那他的独特价值是什么？

我们把这些叫做 Soft Skill， 软的能力。 

很多时候，我们希望获得一些可以跨专业衡量和交换的数字，这样便于比较，所以下面的的每项回答都可以换算为一个分数， 以满足部分读者的需求：

 

1. 保持高标准，不要受制于破窗理论(broken windows theory)[i]。
当你看到不靠谱的设计、糟糕的代码、过时的文档和测试用例的时候，不要想 “既然别人的代码已经这样了，我的代码也可以随便一点啦。”

    a) 从来没听说过；   b) 我就是这样随便过来的；  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

2. 主动解决问题。当看到不靠谱的设计，糟糕的代码的时候，不要想“可能别人会来管这个事情” ，或者“我下个月发一个邮件让大家讨论一下”。要主动地把问题给解决了[ii]。

   a) 不懂啥是靠谱的设计；   b) 随便应付一下即可；  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

3. 经常给自己充电，身体训练是运动员生活的一部分，学习是软件工程师职业的伴侣。每半年就要了解和学习一些新的相关技术。通过定期分享（面对面的分享，写技术博客等）来确保自己真正掌握了新技术。

   a) 从来不看书；   b) 看了就忘；  c) 有时分享。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

4. DRY （Don't Repeat Yourself）——别重复。在一个系统中，每一个知识点都应该有一个无异议的、正规的表现形式。

   a) 从来没听说过；   b) 听说过，但是认为意思不大；  c) 这要讲场合。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

5. 消除不相关模块之间的影响，在设计模块的时候，要让它们目标明确并单一，能独立存在，没有不明确的外部依赖。

   a) 从来没听说过；   b) 出了问题再说吧；  c) 想做，但是不知道怎么衡量效果。  d) 能够在多种语言和架构中做到     e) 不但主动做， 还会影响同事一起做好

 

6. 通过快速原型来学习，快速原型的目的是学习，它的价值不在于代码，而在于你通过快速原型学到了什么。

   a) 从来没听说过；   b) 把原型直接用于产品，不然就浪费了；  c) 不用原型，一直在产品中直接改。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

7. 设计要接近问题领域，在设计的时候，要接近你目标用户的语言和环境。

   a) 从来没听说过；   b) 按我的想法设计，用户以后会适应的；  c) 大概同意，但是怎么接近用户呢？  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

8. 估计任务所花费的时间，避免意外。在开始工作的时候，要做出时间和潜在影响的估计，并通告相关人士，避免最后关头意外发生。工作中要告知可能的时间变化，事后要总结。

   a) 做完了，就知道花费了，不用事先估计；   b) 大概估一下，不必在意时间   c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

9. 图形界面的工具有它的长处，但是不要忘了命令行工具也可以发挥很高的效率，特别是可以用脚本构建各种组合命令的时候。

   a) 一直用鼠标和GUI；   b) 到时候问牛人；  c) 正在学习命令行工具。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

10. 有很多代码编辑器，请把其中一个用得非常熟练。让编辑器可以实现自己的定制，可以用脚本驱动，用起来得心应手。

   a) 只用老师教的一个；   b) 随意；  c) 没有任何定制。  d) 会定制，并且分享给其他人     e) 还会学习和使用各种编辑器的扩展。

 

11. 理解常用的设计模式，并知道择机而用。设计模式不错，更重要的是知道它的目的是什么，什么时候用，什么时候不用。

   a) 从来没听说过；   b) 模式没用；  c) 每写100行程序，我就尽量用一个模式。  d)有实际使用的经验     e) 能用具体代码说明模式的利弊

 

12. 代码版本管理工具是你代码的保障，重要的代码一定要有代码版本管理。

   a) 从来没听说过；   b) 用QQ，u盘即可；  c) 领导要求才用。  d) 经常用     e) 不但主动做， 还会影响同事一起做好

 

13. 在debug的时候，不要惊慌，想想导致问题的原因可能在哪里。一步一步地找到原因。要在实践中运用工具，善于分析日志（log），从中找到bug。同时，在自己的代码里面加 log.

   a) 从来没听说过；   b) 只会printf；  c) 加log 太麻烦，我的代码不会有bug 的。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

14. 重要的接口要用形式化的“合同”来规定。用文档和断言、自动化测试等工具来保证代码的确按照合同来做事，不多也不少。使用断言 (assertion) 或者其他技术来验证代码中的假设，你认为不可能发生的事情在现实世界中往往会发生。

   a) 从来没听说过；   b) 太麻烦，不用；  c) 想用，但没有时间。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

15. 只在异常的情况下才使用异常 (Exception),  不加判断地过多使用异常，会降低代码的效率和可维护性。记住不要用异常来传递正常的信息。

   a) 从来没听说过；   b) 抓住所有异常  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

16. 善始善终。如果某个函数申请了空间或其他资源，这个函数负责释放这些资源。

   a) 从来没听说过；   b) 随缘；  c) 有时这样做。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

17. 当你的软件有多种技术结合在一起的时候，要采用松耦合的配置模式，而不是要把所有代码都混到一起。

   a) 从来没听说过；   b) 没有实践的机会；  c) 代码都在一起比较好管理。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

18. 把常用模块的功能打造成独立的服务，通过良好的界面 (API) 来调用不同的服务。

   a) 从来没听说过；   b) 拷贝代码过来用也可以  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

19. 在设计中考虑对并行的支持，这样你的API 设计会比较容易扩展。

   a) 从来没听说过；   b) 并行不会出错的；  c) 任何代码都应支持并行。  d) 考虑在适当的层次支持并行     e) 不但主动做， 还会影响同事一起做好

 

20. 在设计中把展现模块 (View) 和实体模块 (Model) 分开，这样你的设计会更有灵活性。 

   a) 代码都在一起比较好改；   b) 随缘啦；  c) 没搞清楚啥是V，啥是M。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

21. 重视算法的效率，在开始写之前就要估计好算法的效率是哪一个数量级上的（big-O）。

   a) 从来没听说过；   b) 我的数据量不大，无所谓；  c) 不会有效率问题的，现在CPU 都快了。  d) 主动测试程序效率，以验证估算     e) 不但主动做， 还会影响同事一起做好

 

22. 在实际的运行场景中测试你的算法，不要停留在数学分析层面。有时候一个小小的实际因素 (是否支持大小写敏感的排序，数据是否支持多语言)会导致算法效率的巨大变化。

   a) 从来没听说过；   b) 想用，但不知道工具  c) 主要靠肉眼观察算法效率。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

23. 经常重构代码，同时注意要解决问题的根源。

   a) 从来没听说过；   b) 任何修改都可以叫重构；  c) 每天应该重构两次。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

24. 在开始设计的时候就要考虑如何测试 ，如果代码出了问题，有log 来辅助debug 么? 尽早测试，经常测试，争取实现自动化测试，争取每一个构建的版本都能有某些自动测试。

   a) 从来没听说过；   b) 我的代码不会出问题的；  c) 项目没有安排时间，我也没有提这事。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

25. 代码生成工具可以生成一堆一堆的代码，在正式使用它们之前，要确保你能理解它们，并且必要的时候能debug 这些代码。

   a) 从来没听说过；   b) 从来不看那些代码；  c) 那些代码没有bug。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

26. 和一个实际的用户一起使用软件，获得第一手反馈。 

   a) 从来没听说过；   b) 用户太蠢，不值得听反馈；  c) 想做但是没有机会。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

27. 在自动测试的时候，要有意引地入bug，来保证自动测试的确能捕获这些错误。

   a) 没听说过；   b) 不必这么麻烦；   c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

28. 如果测试没有做完，那么开发也没有做完。

   a) 从来没听说过；   b) 签入代码，就是做完了；  c) 。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

29. 适当地追求代码覆盖率：每一行的代码都覆盖了，但是程序未必正确。要确保程序覆盖了不同的程序状态和各种组合条件。

   a) 从来没听说过；   b) 覆盖20% 就好了；  c) 要覆盖至少60%。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

30. 如果团队成员碰到了一个有普遍意义的bug,  应该建立一个测试用例抓住以后将会出现的类似的bug。

   a) 从来没听说过；   b) 每个bug都是特殊的；  c) 测试用例不值得加  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

31. 测试：多走一步，多考虑一层。如果程序运行了一星期不退出，如果用户的屏幕分辨率再提高一个档次，这个程序会出什么可能的错误?

   a) 从来没听说过；   b) 如果有问题，用户会报告的，我们不用测这些；  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

32. （带领团队）了解用户的期望值，稍稍超出用户的期望值，让用户有惊喜。

    a) 从来没听说过；   b) 我们决定用户的期望；  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

33. （带领团队） 不要停留在被动地收集需求，要挖掘需求。真正的需求可能被过时的假设、对用户的误解或其他因素所遮挡。

   a) 从来没听说过；   b) 用户不说的，我们不做；  c) 如果有明确要求，我可以做好。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

34. （带领团队）把所有的术语和项目相关的名词、缩写等都放在一个地方。

   a) 从来没听说过；   b) 都记在我脑子里；  c) 大家看代码就好  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

35. （带领团队）不要依赖于某个人的手动操作，而是要把这些操作都做成有相关权限的人士都能运行的脚本。这样就不会出现因为某人休假而项目被卡住的情况。

   a) 从来没听说过；   b) 我们没有休假的，没关系；  c) 出了问题再说  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

36. （带领团队）要让重用变得更容易。一个软件团队要创造一种环境，让大家有轻松的心态来尝试各种想法 （例如，模块的重用，效能的提升，等）。

   a) 都听领导的；   b) 团队严肃紧张最好；  c) 不必尝试，失败的可能性太大。  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

37. （带领团队）在每一次迭代之后，都要总结经验，让下一次迭代的进度安排更可靠，质量更高。

    a) 没有时间总结，直接做下一版；   b) 总结用处不大；  c) 如果上级有要求，就做一下；  d) 一直主动这样做     e) 不但主动做， 还会影响同事一起做好

 

38. （带领团队）团队中往往会有矛盾产生，作为领头人，怎么办？

    a) 我没看见矛盾。  b) 和稀泥，过得去就行 ；  c) 如果没有捅到上级那里，就打哈哈，希望他们自己搞定；  d) 有明确和一致的处理矛盾的原则     e) 不但有明确和一致的处理原则，而且对于影响团队士气的任何事情追究到底

 

 

 
第三部分 团队管理源代码的水平：
团队如何评价自己的软件工程水平？ 有人说，“我们团队很强...” 是碰巧公司很有钱，还是团队的某个人有真功夫，那这个人走了团队还强么？ 究竟什么是团队的软件工程能力强？
团队的共有财产就是源代码和数据， 能力强的团队怎么管好自己的财产？ 可以看看这些管理源代码的问题，你们团队的每个成员都能回答么？

[ii]      Jim Barksdale 是Netscape 公司的CEO, 他提出了Snake Rule，见到问题，就要解决问题，但是也不要沉溺于无法挽回的事情中。参见：http://www.menk.com/blog/archives/2006/11/20/jim-barksdales-rules-of-snakes  以及 http://www.celebrazio.net/jimb/15.html

 

 

posted @ 2014-07-17 21:19  SoftwareTeacher  阅读(28906)  评论(26)    收藏  举报