||
难以坚持下去的事情,基本都是因为没有迫切的欲望和激情。没有动机,没有欲望,哪里来的毅力呢?
当我们决定做一件事情的时候,首先就要多问问自己:为什么要做这件事情?它所带来的好处是什么?如果不做它又会有哪些坏处?
有了清晰的目的和思路后再去做事,遇到变化时就知道孰轻孰重,该怎么调整计划,同时也不至于被重复和乏味消磨了一时的意气。
不管路走了多远,错了就要重新返回。——土耳其谚语
选定了要走的路,就是选定了它通往的目的地。——Harry Emerson Fosdick
软件项目时常伴有时间压力——压力会迫使你走捷径,只看眼前利益。但是,任何一个有经验的开发者都会告诉你,欲速则不达。
世上最糟糕的工作就是和一群爱搬弄是非的人共事。他们对解决问题并没有兴趣,相反,他们爱在别人背后议论是非。
“这不是我的错”,这句话不对。“这都是你的错”,这句话更不对。如果你没有犯过任何错误,就说明你可能没有努力去工作。
千里之堤,溃于蚁穴,大灾难是逐步演化来的。
一次又一次的快速修复,每一次都不探究问题的根源,久而久之就形成了一个危险的沼泽地,最终会吞噬整个项目的生命。
所有的大型系统都非常复杂,因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外,你还需要从更高的层面来了解大部分代码的功能,这样就可以理解系统各个功能块之间是如何交互的。
你必须要理解一块代码是如何工作的,但是不一定需要成为一位专家。只要你能使用它进行有效的工作就足够了,不需要把它当作毕生事业。
尽力贡献自己的好想法,如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
只有更好,没有最好。尽管“最佳实践”这个术语到处在用,但实际上不存在“最佳”,只有在某个特定条件下更好的实践。
在开始寻找最好的解决方案之前,大家对“最好”的含义要先达成共识。在开发者眼中的最好,不一定就是用户认为最好的,反之亦然。
你不可能精通每一项技术,没有必要去做这样的尝试。只要你在某些方面成为专家,就能使用同样的方法,很容易地成为新领域的专家。
设计文档应该尽可能详细,这样,低级的代码工人只要敲入代码就可以了。在高层方面,详细描述对象的关联关系;在低层方面,详细描述对象之间的交互。其中一定要包括方法的实现信息和参数的注释。也不要忘记给出类里面的所有字段。编写代码的时候,无论你发现了什么,绝不能偏离了设计文档。
度量剩下的工作量。不要用不恰当的度量来欺骗自己或者团队。要评估那些需要完成的待办事项。
没有愚蠢的用户。只有愚蠢、自大的开发人员。如果代码问题解决不了,也许可以考虑通过修改文档或者培训来弥补。
在编译和测试运行中,停下来想一想,并暂时远离代码细节,这是保证不会偏离正确方向的好办法。
代码几乎总是可以得到进一步精炼,但是到了某个点之后,再做改进就不会带来任何实质性的好处了。这时开发人员就该停下来,去做其他方面的工作了。
要将目标牢记在心:简单、可读性高的代码。
绝对不能允许一个看起来无辜的“查询”去修改对象的状态。
记录问题的时间不能超过在解决问题上花费的时间。要保持轻量级和简单,不必达到对外发布式的质量。
每日立会的好处:
让大家尽快投入到一天的工作中来。
如果某个开发人员在某一点上有问题,他可以趁此机会将问题公开,并积极寻求帮助。
帮助团队带头人或管理层了解哪些领域需要更多的帮助,并重新分配人手。
让团队成员知道项目其他部分的进展情况。
帮助团队识别是否在某些东西上有重复劳动而耗费了精力,或者是不是某个问题有人已有现成的解决方案。
通过促进代码和思路的共享,来提升开发速度。
鼓励向前的动力:看到别人报告的进度都在前进,会对彼此形成激励。
经常抬头看看四周,而不是只埋头于自己的工作。
Archiver|手机版|科学网 ( 京ICP备07017567号-12 )
GMT+8, 2024-9-1 14:40
Powered by ScienceNet.cn
Copyright © 2007- 中国科学报社