ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 记录

记录

原创 Linux操作系统 作者:tyler2002 时间:2011-05-29 09:38:04 0 删除 编辑
1、不要求所有人都是有经验的专业人员,但必须具有专业的工作态度---每个人都希望尽最大可能做好自己的工作。
2、项目时常伴有时间压力--压力会迫使你走捷径,只看眼前利益。但是,任何一个有经验的开发者都会告诉你,欲速则不达。
3、在团队中,大家的重点是做事,应该把重点放在解决问题上,而不是在指责犯错者上面纠缠。
4、如果一个团队成员误解了一个需求、一个API调用,或者最近一次会议做出的决策,那么,也行就意味着团队其他成员也有这样的误解。要确保整个团队尽快消除误解。
5、如果设计或代码中出现奇怪的问题,花时间去理解为什么代码会是这样的。如果你找到了解决办法,但代码仍然令人费解,唯一的解决办法就是重构代码,让它可读性更强。如果你没有马上理解那段代码,不要轻易地否定和重写它们。那不是勇气,而是鲁莽。
6、每周,要求团队中的每一个人主持讲座。给大家介绍一些概念,演示工具或者做团队感兴趣的任何一件事情。然后进行开放式讨论,包括这个主题对于项目的意义。
7、要果断丢弃旧习恶习,一味遵循过时的旧习惯会危害你的职业生涯。
8、“为什么”是个非常好的问题。它是很好的方式,进一步挖掘简单直白的答案,通过这个路线,设想就会更加接近事实真相。
9、在设计方面,做决定的时候必须有开发者参与。可是,在一个项目中,它们不应该做所有的决定,特别是业务方面的决定。
10、不要随意假设低级别的问题不会影响客户的业务。如果能影响他们的业务,就是有价值的问题。
11、项目进入不可发布状态的频率是多少?源代码服务器中的代码是不是遇到紧急情况无法立即启动。 一个简单流程:在本地运行测试--检出最新的代码--提交代码。
12、代码集成是主要的风险来源。要想规避这个风险,只要提早集成,持续而有规律地进行集成。绝不要做大爆炸式的集成。
13、维护项目术语表。不一致的术语是导致需求误解的一个主要原因。经常会遇到团队中的程序员们使用了和用户或者业务人员不同的术语,直接导致bug和设计错误。
14、单元测试是优质股,值得投资。逐步习惯并依赖单元测试。如果代码没有进行测试,就像在高空作业没有系安全带一样。
15、不管它是否是产品的bug,还是文档的bug,或者对用户理解的bug,它都是团队的问题,而不是用户的问题。每一个抱怨的背后都隐藏了一个事实。
16、没有愚蠢的客户,只有愚蠢、自大的开发人员。“它就是这样的。”这不是一个好的答案。
17、解释代码做了什么的注释用处不那么大,相反,注释要说明为什么会这样写代码。
18、提供更易于查找错误细节的方式。发生问题时,要展示出尽量多的支持细节,不过别让用户陷入其中。
19、在团队协作开发中,不要像国家宣称领土主权一样,声明个人对代码的所有权。任何一位团队成员,只要理解某段代码的来龙去脉,就应该可以对其进行处理。如果某段代码只有一位开发人员能够处理,项目的风险无形中也就增加了。
20、

























来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/183473/viewspace-696546/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-07-24

  • 博文量
    62
  • 访问量
    132789