一个程序员的总结

1 、 分享第一条 经验 ：“学 历 代表 过 去、能力代表 现 在、学 习 力代表未来。”其 实这 是一个来自国外教育 领 域的一个研究 结 果。相信工作 过 几年、十几年的朋友 对这 个道理有些体会吧。但我相信 这 一点也很重要：“重要的道理明白太 晚 将抱憾 终 生！”所以放在 每 一条， 让刚刚毕业 的朋友 们 早点看到哈！

 

2 、 一定要确定自己的 发 展方向，并 为 此目的制定可行的 计 划。不要 说 什 么 ，“我 刚毕业 ， 还 不知道将来可能做什 么 ？”，“跟着感 觉 走，先做做看”。因 为 ， 这样 的 观 点会通 过 你的潜意 识 去暗示你的行 为 无所事事、碌碌无 为 。一直做技 术 ，将来成 为专 家 级 人物？向管理方向走，成 为职业经 理人？先熟悉行 业 和 领 域，将来自立 门户 ？ 还 是先在行 业 里面混混， 过 几年 转 行做点 别 的？ 这 很重要，它将决定你近几年、十年内“做什 么 事情才是在做正确的事情！”。

 

3 、 软 件 开发团队 中，技 术 不是万能的，但没有技 术 是万万不能的！在技 术 型 团队 中，技 术 与人品同等重要，当然 长 相也比 较 重要哈，尤其在 MM 比 较 多的 团队 中。在 软 件 项 目 团队 中，技 术 水平是受人重 视 和尊重的重要砝 码 。无 论 你是做管理、系 统 分析、 设计 、 编码 ， 还 是 产 品管理、 测试 、文档、 实 施、 维护 ，多少你都要有技 术 基 础 。算我孤陋寡 闻 ，我 还 真没有 亲 眼看到 过 一个外行 带领 一个 软 件 开发团队 成功地完成 过软 件 开发项 目，哪怕就一个，也没有看到。倒是曾 经 看到 过 一个“高学 历 的牛人” ( 非技 术 型 ) 带 一堆人做完 过 一个 项 目， 项 目交付的第二天， 项 目 组 成 员 扔下一句“再也受不了啦！”四分五裂、各奔 东 西。那个 项 目的“成功度”大家可想而知了。

 

4 、 详细 制定自己 软 件 开发专业 知 识 学 习计 划，并注意及 时 修正和 调 整 ( 软 件 开发 技 术变 化 实 在太快 ) 。 请 牢 记 ：“如果一个 软 件 开发 人 员 在 1 、 2 年内都没有更新 过 自己的知 识 ，那 么 ，其 实 他已 经 不再属于 这 个行 业 了。”不要告 诉 自己没有 时间 。来自 时间 管理 领 域的著名的“三八原 则 ”告 诫 我 们 ：另外的那 8 小 时 如何使用将决定你的人生成 败 ！本人自 毕业 以来，平均 每 天 实际 学 习时间 超 过 2 小 时 。

 

5 、 书 籍是人 类进步 的 阶 梯， 对软 件 开发 人 员 尤其如此。 书 籍是学 习 知 识 的最有效途径，不要 过 多地指望在工作中能遇到“世外高人”，并不 厌 其 烦 地教你。 对 于花 钱买书 ，我个人 经验 是：千 万 别买 国内那帮人出的 书 ！我 买 的那些家伙出的 书 ， !00% 全部后悔了，无一本例外。更气 愤 的是， 这 些 书 在二手市 场 的地 摊 上都很 难卖 掉。“ 拥 有 书 籍并不表示 拥 有知 识 ； 拥 有知 识 并不表示 拥 有技能； 拥 有技能并不表示 拥 有文化； 拥 有文化并不表示 拥 有智慧。”只有将 书 本 变 成的自己智慧，才算是真正 拥 有了它。

 

6 、 不要 仅 局限于 对 某 项 技 术 的表面使用上，哪怕你只是偶 尔 用一、二次。“ 对 任何事物不究就里”是任何行 业 的工程 师 所不 应该 具 备 的素 质 。 开发 Windows 应 用程序，看看 Windows 程序的 设计 、加 载 、 执 行原理，分析一下 PE 文件格式， 试试 用 SDK 开发 从 头开发 一个 Windows 应 用程序；用 VC ＋＋、 Delphi 、 Java 、 .Net 开发应 用程序，花 时间 去研究一下 MFC 、 VCL 、 J2EE 、 .Net 它 们 框架 设计 或者源 码 ；除了会用 J2EE 、 JBoss 、 Spring 、 Hibernate 等等 优 秀的 开 源 产 品或者框架，抽空看看大 师们 是如何抽象、分析、 设计 和 实现 那些 类 似 问题 的通用解决方案的。 试 着 这样 做做，你以后的工作将会少遇到一些 让 你不明就里、一 头雾 水的 问题 ，因 为 ，很多 东 西你“知其然且知其所以然”！

 

7 、 在一 种语 言上 编 程，但 别为 其束 缚 了思 想。“代 码 大全”中 说 ：“深入一 门语 言 编 程，不要浮于表面”。深入一 门语 言 开发还远远 不足，任何 编 程 语 言的存在都有其自身的理由，所以也没有哪 门语 言是“包治百病”的“灵丹妙 药 ”。 编 程 语 言 对开发 人 员 解决具体 问题 的思路和方式的影响与束 缚 的例子俯拾皆是。我的 经验 是：用面 对对 象工具 开发 某些 关键 模 块时 ， 为 什 么 不可以借 鉴 C 、 C51 、 汇编 的模 块 化封装方式？用 传统 的桌面 开发 工具 ( 目前主要有 VC++ 、 Delphi) 进 行系 统 体 统结 构 设计时 ， 为 什 么 不可以参考来自 Java 社区的 IoC 、 AOP 设计 思想，甚至借 鉴 像 Spring 、 Hibernate 、 JBoss 等等 优 秀的 开 源框架？在 进 行 类 似于 实时 通信、数据采集等功能的 设计 、 实现时 ， 为 什 么 不可以引用来自 实时 系 统 、嵌入式系 统 的 优 秀的体系框架与模式？ 为 什 么 一切都必 须 以个人、 团队 在当然 开发语 言上的 传统 或者 经验 来解决 问题 ？？？“他山之石、可以攻玉”。

 

8 、 养 成 总结 与反思的 习惯 ，并有意 识 地提 炼 日常工作成果，形成自己的个人源 码库 、解决某 类问题 的通用系 统 体系 结 构、甚至 进 化 为 框架。众所周知， 对软 件 开发 人 员 而言，有、无 经验 的一个 显 著区 别 是：无 经验 者完成任何任 务时 都从 头开 始，而有 经验 者往往通 过 重 组 自己的可 复 用模 块 、 类库 来解决 问题 （其 实这 个 结论 不 应该 被局限在 软 件 开发领 域、可以延伸到很多方面）。 这 并不是 说 ，所有可 复 用的 东 西都必 须 自己 实现 ， 别 人成熟的通 过测试 的成果也可以收集、整理、集成到自己的知 识库 中。但是，最好 还 是自己 实现 ， 这样 没有知 识产权 、版 权 等 问题 ， 关键 是自己 实现 后能真正掌握 这 个知 识 点， 拥 有 这 个技能。

 

9 、 理 论 与 实 践并重，内外双修。工程 师 的内涵是：以工程 师 的眼光 观 察、分析事物和世界。一个合格的 软 件工程 师 ，是真正理解了 软 件 产 品的本 质 及 软 件 产 品研 发 的思想精髓的人