本文转自：EETproject教师专辑
http://forum.eet-cn.com/FORUM_POST_10011_1200263220_0.HTM?click_from=8800111934,6106462476,2014-04-18,EECOL,NEWSLETTER
1、谨慎选择第1门语言
编程语言各有不同。只是差别不大。但用语言的人差别就大了。选择了一门语言你就选择了一个群落。
假设你想高速建立原型（尤其对于希望对产品进行迭代升级的创始人来说）。那就用 Ruby 或者 JS
2、你不是程序员！
伟大的开发人员可以建构并开发应用。惊艳的开发人员可以在关注业务的同一时候做这件事。业务端的人大都不懂编码。可是肯定可以理解特定功能背后的动机。
别人说什么开发人员就做什么，没有去理解为什么要这么做，导致两方均错失了机会。这种事情太常见了。
精通编程是一个崇高的职业目标。
一旦实现了这个目标，别忘了考虑一下你自己。
不要成为不论什么公司的**或者在毫无价值的东西上浪费你的时间。
要想按期完毕。得在開始技术工作之前事先进行项目沟通（哪怕这并不是先决条件），由于其它人的响应速度千变万化。
3、保持敏捷，不断交付
早公布，不断公布，边说唱边公布。
不断測试。
好的測试包如保单和煤矿里的金丝雀之结合。
它能帮助你在生产周期中更早地找出错误。而错误越早发现越easy解决。
高速失败。编码（及生活）时我希望尽早知道什么地方不能工作，而不是放任无论让它增殖扩散。
全面放开。高速失败，修补缺陷。不断继续。
为全部代码编写自己主动測试！
尽可能践行測试驱动的开发。
4、保持对測试流程的控制
很多项目深受多測试周期之苦。这会拖累项目，导致组织总体出现高级别的问题。
程序猿应该专注于对自己的代码进行单元測试及半回归測试。他们比其它不论什么人更了解代码库，也知道自己会影响到哪些变更。有时此类变更会因为 QA 測试范围有限而缺失，因此导致生产环节出现重大问题。
要想在力所能及的情况下尽快开发出无缺陷代码，永远永远也不要把写測试放到后面。
我们更清楚这一点。
要检查一下測试的覆盖率。确保 100% 无死角。
5、假设你是自由职业者，要学会说不，哪怕面对的是金钱
要对时间和成本有一个合理的评估。然后把它加倍。假设大家都说“这应该非常easy，”那就做
6、荣誉属于过去—理论是一回事。但实践更重要
改进软件开发质量的最好方式就是去开发软件。
很多雄心勃勃的刚入门的project师花了非常多的业务时间去读书，关于最新工具的、关于开放流程的。诸如此类的东西。
非常多人都是这么消磨自己的闲暇时间的。但这样非常easy就把你给耽搁了。别这样，通过尽可能用脑来强化大脑负责开发软件的那部分。
不断探索。我见过的很多编码者手上都有几个在进行的业务项目。
做业务项目迫使你要探索新技术然后学习创建应用的方方面面。
你可能须要做前端的 HTML/CSS，后端的 API 集成，数据库优化。做移动 app。还得设置自己的server。
7、结对评审是你的秘密武器
结对编程很必要。两个程序猿联合开发同一个模块可以相互审查对方的代码。
开发团队每周也要召开代码审查会议。让每个开发人员给其它人的代码提供反馈意见，解释怎样更好地改进代码。这可以形成一种协作文化，把开发人员的自负抛开。
8、像躲瘟疫一样避免过早优化
仅仅有在问题和解决方式都出如今你面前时才进行重构—过早重构是时间上的巨大浪费。不要投入半年后可能被扔掉的不论什么东西的完好上。过早优化是罪恶之源。
不要过早优化！
我不断看到project师在用户还没有到 1000 的时候一再对扩充到 100 万的用户规模操心。
9、你的代码仅仅写一次。可别人会读它千万遍
你写的代码机器会解析运行。可其它人却须要读你的代码，理解它，摆弄它。你必须明确，你的代码会有未来的观众。
代码也是一种书写形式的沟通。
听起来非常奇怪，可是你永远都得替自己的未来着想。问问自己：假设你有健忘症的话。你还能不能理解自己写过的代码？
通读你的文档。设计修改非常多，有时候代码更新的时候凝视不一定会跟进。
保持文档的更新。未来的人（包含你自己）理解起来就更easy。我说不清有多少次我看回自己代码时总在想：“我究竟在干什么？”仅仅要我写出了好的凝视。未来头疼就少非常多。
10、这是一个崇高的职业。把你的技能用到好的地方。
帮助别人是深层次的人的需求。想办法用你的工作，以改善人类，你将有一个成功的把握。