言论

1.所有事情所花费的时间总是比你预期的要长








2.先了解现有的代码


大多数的编码都需要以某种方式改变现有的代码。即使是新功能，也需要适应现有的程序。所以，在你加进去新的内容前，首先需要了解当前的解决方案。否则，你一不小心就很有可能会打破现有的功能。这意味着，阅读代码和编写代码都是必要的技能。这也是为什么看似微小的变化仍可能需要很长时间才能解决的原因之一——你首先必须了解上下文






3..面对面的交流最有效


当我们需要讨论如何解决问题时，那么面对面的交流比视频、打电话和电子邮件都要好。




4.橡皮鸭法


遇到你绞尽脑汁也解决不了的问题时，不妨找一个同事，然后将问题解释给他们听。很多时候，当你在叙述时，即使你的同事一言不发，你可能也会突然灵光乍现找到问题的关键。






5.带着问题睡觉


如果你正在解决一个很难的问题，那么不妨带着问题睡觉。有科学研究表明，这样做虽然你表明上并没有在主动思考，但你的潜意思却这么做了。其结果就是，第二天再去研究问题，解决方案已经呼之欲出了。




6.跳槽


不要害怕跳槽。和不同的人共事，开发不同的产品，感受不同的公司文化是非常有意思的。




7.不断学习


我们需要不断地学习和了解软件开发。你可以尝试不同的编程语言和工具，阅读软件开发的书籍，接受MOOC课程。相信我，量变才能达到质的飞跃，这些小小的学习积累，终有一天会大大地提高你的知识和能力。






8.不断学习


我们需要不断地学习和了解软件开发。你可以尝试不同的编程语言和工具，阅读软件开发的书籍，接受MOOC课程。相信我，量变才能达到质的飞跃，这些小小的学习积累，终有一天会大大地提高你的知识和能力。




9.大量刻意的训练


我们还可以训练自己从而提高执行任务的能力。这是一种技巧和技术，也意味着重复——意味着带着某种目的去执行任务。不断地重复and重复，一遍又一遍，直到你达到所需的能力级别。


译者注：我曾经学asp的时候重复写了几十遍数据库操作的代码，都会背了：）




10.做点所谓的“重复工作”


使用现有的代码与一步步设计自己的软件——测试、修复、改进——是完全不同的。这些旁人看来所谓的“重复工作”有助于你更深刻地熟悉并理解现有的各个组件是如何运作的。


大多数开发人员可能从来没有创建过核心的软件库，因此对它们的工作原理也不甚了解。其结果就是，一旦碰到这些种类的软件出现问题就会束手无策。了解表面永远是不够的，只有将里面隐含的工作原理挖出来，才能让你真正地在这一行业，独步武林。




11.不断学习


阅读。
参与邮件讨论。
获取并编写代码。
找一个导师。
了解你正在使用的框架和库。
犯了错误，需要修复bug或遇到问题时，弄清楚原因。
教人也是学习的一种好方法，可以教学相长。
参于用户组或本地会议。
加入或启动研究小组。
听讲座或在线观看会谈。
学习一门新的编程语言。
梳理出新的，可用于技术堆栈的想法和点子。






12.错失采用多态的机会。


多态允许我们创建小型的本地化执行上下文，而不需要if-else模块。它可以让我们写出的代码更少更易于理
解。




13.
编写测试程序


一个优秀的测试程序可以当作开发文档来使用，因为它们已经描述了代码是如何工作的。对于每一个场景，测试程序必须做到：


1、将程序的上下文、运行起点或者必须满足的前提条件描述清楚。
2、写清楚程序是如何被调用的。
3、将程序运行的期望结果描述清楚。
当然不同的情况下这3个规则也会略有不同。其他程序员只要看了测试程序就可以判断软件会有哪些不同的行为，因此，每一个测试程序应该将程序的因果关系描述清楚。






14.“理论不懂就实践，实践不会就学理论！”。










15.优秀的软件工程师写尽可能少的代码。


伟大的软件工程师删除尽可能多的代码。








16.鲍勃·马丁曾经说过：“当你在为一段代码写注释的时候，你应当对自己糟糕的表达能力而反思。”  只有在使用命名都无法表述清楚某个方法或者变量的目的时，注释才是最后的选择。事实上，表达无法轻易在代码表达的东西才是注释的真正作用。












17.在编写代码之前你应当清楚你的代码要做什么














18.努力做到化繁为简


所有的的问题都可以进行分解。而最优雅的解决方案通常都非常简单。但是，要变得简单并不容易，这需要许多的工作。








19.每天都要学一些新东西