本文转自:EETproject教师专辑
http://forum.eet-cn.com/FORUM_POST_10011_1200263220_0.HTM?click_from=8800111934,6106462476,2014-04-18,EECOL,NEWSLETTER
1、谨慎选择第1门语言
一旦实现了这个目标,别忘了考虑一下你自己。
不要成为不论什么公司的**或者在毫无价值的东西上浪费你的时间。
好的測试包如保单和煤矿里的金丝雀之结合。
它能帮助你在生产周期中更早地找出错误。而错误越早发现越easy解决。
高速失败。编码(及生活)时我希望尽早知道什么地方不能工作,而不是放任无论让它增殖扩散。
全面放开。高速失败,修补缺陷。不断继续。
为全部代码编写自己主动測试!
尽可能践行測试驱动的开发。
程序猿应该专注于对自己的代码进行单元測试及半回归測试。他们比其它不论什么人更了解代码库,也知道自己会影响到哪些变更。有时此类变更会因为 QA 測试范围有限而缺失,因此导致生产环节出现重大问题。
我们更清楚这一点。
要检查一下測试的覆盖率。确保 100% 无死角。
很多雄心勃勃的刚入门的project师花了非常多的业务时间去读书,关于最新工具的、关于开放流程的。诸如此类的东西。
非常多人都是这么消磨自己的闲暇时间的。但这样非常easy就把你给耽搁了。别这样,通过尽可能用脑来强化大脑负责开发软件的那部分。
不断探索。我见过的很多编码者手上都有几个在进行的业务项目。
做业务项目迫使你要探索新技术然后学习创建应用的方方面面。
你可能须要做前端的 HTML/CSS,后端的 API 集成,数据库优化。做移动 app。还得设置自己的server。
开发团队每周也要召开代码审查会议。让每个开发人员给其它人的代码提供反馈意见,解释怎样更好地改进代码。这可以形成一种协作文化,把开发人员的自负抛开。
我不断看到project师在用户还没有到 1000 的时候一再对扩充到 100 万的用户规模操心。
代码也是一种书写形式的沟通。
听起来非常奇怪,可是你永远都得替自己的未来着想。问问自己:假设你有健忘症的话。你还能不能理解自己写过的代码?
通读你的文档。设计修改非常多,有时候代码更新的时候凝视不一定会跟进。
保持文档的更新。未来的人(包含你自己)理解起来就更easy。我说不清有多少次我看回自己代码时总在想:“我究竟在干什么?”仅仅要我写出了好的凝视。未来头疼就少非常多。
原文:http://www.cnblogs.com/gcczhongduan/p/4731104.html