成为一个合格的工程师

20120328

@highkay

目标• 事业目标型• 团队精英型• 技术高手型• 得过且过或养家糊口型

独特的个性知识经验组合• 纵向专业技能• 业务领域知识• 横向扩展技能

专业技能• 前端（ GUI）• 后端（ Server）• 语言• ...

够用的知识 -〉系统的知识结构

领域知识• 社交• 游戏• 电子商务• 门户• 金融• ...

扩展技能• 演讲• 运维• 写作 *

• 沟通 *

• ...

能力模型• 设计能力（不要过早的编码，也不要过多的进行假设，可行的技术方案）

• 交付能力（代码胜于雄辩）• 规范与协作（避免重复劳动，提高工作质量）

• 团队效率贡献（知识积累，分享精神，取长补短）

如何解决问题• 准确的描述一个问题，你已经解决了一半• 提供足够多的线索• 你的想法，证据，尝试• 结论• 回顾总结（文档，代码）

知识获取的途径• 官网 /官方文档 /官方邮件组 /论坛（如果连官网都没有，建议直接放弃）

• Stackoverflow（依赖英文描述问题能力）• Google

• iteye/csdn

• 论坛 /QQ群• 同事

不重复造轮子• apache（推荐 commons系列）• sourceforge

• googlecode

• github

• spring

• ...

权衡 /Trade-off

• 复杂度（代码行数）和交付时间• 功能点数量和交付价值• 关键路径和一般路径• 大概率场景和小概率场景• 模式和反模式• ...

采取一个 Trade-Off时，是否对最坏情况进行过假设？

KISS

• 代码越少越好• （单次）交付的功能点越少越好• 依赖越简单（集中）越好• 细节越少越好

简单！ =简陋

一个例子

如何做项目• 分析需求，技术选型（切勿急着写代码，梳理出关键路径，对涉及到的业务逻辑进行技术评估，最重要的是留下文档【数据库设计，联网接口设计，流程图 ... 】，明确项目周期【定义里程碑 /节点】，不要扯淡）

• 完成代码框架，构建一个可随时发布的工程• 根据关键路径制定开发 /交付顺序，从近到远，从详细到

粗略，注意项目组内的进度协调• 开始集中精力编码吧，少年！在适当的时机考虑重构（不是为了性能，除非存在明显的性能问题，而是代码结构）

• 频繁交付，频繁发布，尽早测试（考虑实施单元测试）• 发布之前进行全局的 profile，适当的进行优化

如何做技术调研• 寻找并且评估轮子（ 0-1 天），一轮评估目标不建议超过 3个

• 搭环境跑例子（ 1-2 天）• 看文档写快速原型（ 1-2 天）• 总结归档，确认方案

不理想？在第二轮回归中加入自己造轮子的选项。

闲下来干啥？• 业界新闻 via rss,web, 微博• 读技术 blog

• 总结经验，更新文档• CodeReview和重构• 为项目做技术储备• 自己写 blog/准备技术分享• 维护一个开源项目

善用工具• GTD ： Google 日历、任务列表• 资料同步工具：快盘、 dropbox 、 box

• 知识管理工具： wiki， evernote， wiz

引用来源• http://timyang.net/management/engineer-p

erformance/

• http://blog.csdn.net/myan/article/details/3247071

• 这个系列的漫画挺有趣的，都是程序员的哏 http://blog.xiqiao.info/category/programmers

谢谢