2015-3-21 23:40:37
来源：51CTO
所有的的问题都可以进行分解。而最优雅的解决方案通常都非常简单。但是，要变得简单并不容易，这需要许多的工作。
1.技术只是解决问题的选择，而不是解决问题的根本
我们可以因为掌握了最新的JavaScript框架ahem、Angular的IoC容器技术或者某些编程语言甚至操作系统而欢欣雀跃，但是这些东西并不是作为程序员的我们用来解决问题的根本——它们只是用于帮助我们解决问题的简单工具。
我们必须非常谨慎，不要对某项正好喜欢或者正好很火的特定技术走火入魔。否则，我们将进入这样的思维怪圈：把掌握的那项技术比做是锤子，在思考问题时，会自然的把所有的问题都想象成是锤子可以解决的钉子。
2.聪明是代码清晰的敌人
当编写代码时，我们应当努力做到代码清晰易理解。
虽然这句话并不总是正确的，但在一般情况下，聪明确实是代码清晰的敌人。
事实证明，当我们写一段自认为非常了不起的代码的时候，这些代码在别人眼里可能会是一头雾水。
所以当你在编写某段聪明高效的代码的时候牢牢记住这个原则是很有必要的。
如果你对如何编写整洁清晰的代码很感兴趣的话，我强烈推荐你看罗伯特·C·马丁的书《The Clean Coder: A Code of Conduct for Professional Programmers》。
3.写尽可能少的代码
这句话看起来有一些矛盾。程序员的工作不就是编写代码么?
嗯，是的但也不是。
我们的工作需要我们编写代码，但是我们在尝试解决问题的时候应当做到尽量编写更少的代码。
这并不意味着我们需要尽量把代码写得更紧凑或者把所有的变量都使用单个字母。它的意思是我们应当尝试用更精简的算法来实现所需要实现的功能。
通常情况下，我们在代码中所添加的各种很酷的特性是非常诱人的，这还能让我们的代码看起来更“健壮”和“灵活”，能够处理各种不同类型的情况。但是，在更多的时候，我们尝试更多可能有用的特性或者预防可能在未来存在的问题的做法是错误的。这些额外的代码可能不具备任何的价值，但是却可能造成更多的伤害。因为代码越多，出现未知错误的机会就越多，代码的维护也更加的麻烦。
优秀的软件工程师写尽可能少的代码。
伟大的软件工程师删除尽可能多的代码。
4.注释是代码表述的最后选择
鲍勃·马丁曾经说过：“当你在为一段代码写注释的时候，你应当对自己糟糕的表达能力而反思。”
这并不意味着我们以后就不要写注释了。但在大多数情况下这种情况是可以避免的，你可以选择用更好的命名方式来取代它。
只有在使用命名都无法表述清楚某个方法或者变量的目的时，注释才是最后的选择。事实上，表达无法轻易在代码表达的东西才是注释的真正作用。
举个例子，注释可以告诉你在代码中的那些奇怪的操作命令并不是一个错误，而是故意的，那是因为在底层操作系统存在着某个bug。
虽然在一般情况下，许多注释还是非常有用的，但是却存在着误导的风险。
在其它代码更新后，与某些更新前代码相关的注释常常会得不到同样的更新，这就导致了某些注释会变得非常的危险，它们很可能会把你引导到一个错误的方向。
你检查过与代码密切相关的每一段注释么?是否确保代码都是在按照注释所说的那样做?如果你都照着这样做了，那么注释的意义又何在呢?如果你没有这样做，你又怎么知道注释说的都是真的?
所以，注释的作用并不象所宣扬的那么好，这种东西切勿滥用。
5.在编写代码之前你应当清楚你的代码要做什么
这看起来是理所当然的，但实际情况却不是。
现实工作中你有多少次是在没有经过充分了解到你的代码要干些什么就开始着手编程的?反正对于我来说，是不计其数了，所以我把这条记录下来用来随时提醒我。
测试驱动开发(TDD)的实践在这里可以帮助你，因为你需要在编写代码之前了解这些代码将要用于什么地方，虽然这仍然不能阻止你创建错误的东西，但是它仍然非常重要。所以当你完完全全了解需要构建的需求和功能时，再动手编程。
6.提交完成代码之前先自行测试
不要在完成编程工作后，就把代码扔给QA，然后就坐等消息了。这样会浪费每一个参加处理不必要Bug和问题的人的时间。你应当在报告编程工作完成之前，花费几分钟时间运行测试场景进行自我检测。当然，在你把代码提交给QA之前不一定会发现每一个Bug，但至少你可以杜绝一些我们每个人都可能犯下的愚蠢低级错误。
很多的软件开发人员认为测试代码只是QA人员的工作。这是不对的。保持质量是我们每个人的责任。
7.每天都要学一些新东西
有句名言“刀不磨要生锈，人不学要落后。”这句话是很有道理的，因为无论是否获取到新的知识，你每天都会遗忘掉一些以前的东西。
每天学些一些新东西并不会花费掉你很多的时间。试着每天用15分钟时间去读书，然后你就会发现每天你都会有一点点的进步，在未来的某个时候，你会发现这种进步是巨大的。因此，为了在今后获得丰厚回报你必须从现在开始就进行投资。另外，今天的技术发展日新月异，如果你不改善自己的技巧，学习新的东西，你很快就会被甩开。
8.写代码应该成为一种乐趣
这是非常正确的。或许，你进入这个行业仅仅是因为它的薪水可观。选择一份报酬丰厚的工作这并没有错，但是还有更好的选择，比如医生或者律师。事实上很多人选择做软件开发还有一个原因，那就是他们喜欢写代码。在你被工作压力所累的时候，不要忘了你选择这份职业的初衷。
编写代码可以带来很大的乐趣。多年的时间里，很多人可能都已经遗忘了这一点，那么从现在起，重新唤回以前的那份热情吧，从身边的项目开始，把你的观念和意识转换到以前你开始学习编程的那个时刻。
9.你不需要无所不知
在你学到了很多知识的时候，你仍然有很多东西不知道。
意识到这点很重要，因为它可以驱使你去了解更多更多的东西。
不知道问题的所有答案没有关系，不了解某个东西说出来并寻求帮助也无关紧要。在很多情况下，你可以选择现学现用——相信我，我就是这么走过来的。
我的观点是，不要企图去学习所有的知识，因为这是一个不可能完成的任务。你需要关注和掌握的是能够帮助你快速学习的技巧。
10.最佳的实践视环境而定
测试驱动开发最好的方法是先编写测试代码?
我们应该保持结对编程的习惯?
如果不使用IoC容器是否会低人一等?
所有这些问题的答案是“看情况。”这取决于所处的实际环境。
人们试图把最佳的实践通过喉咙等方式传输给你，他们会告诉你，他们平时都是这样应用的。所以，你也应该这样做——这其实并不正确。
在写代码的时候，我也借鉴过不少别人的成功经验。但是，这些借鉴都是有条件的。
知识是死的，人是活的。最好的实践需要视环境而定。
11.努力做到化繁为简
所有的的问题都可以进行分解。而最优雅的解决方案通常都非常简单。但是，要变得简单并不容易，这需要许多的工作。
比如，这篇文章的目的是从复杂的软件开发工作和日常生活中提取经验，通过归纳，以较简洁的方式呈现给大家，而这并不是一件容易的事情。
在解决问题时，可以先找到一个较为复杂的笨方法。在此基础上进行努力改进和提炼，使它在正确的基础上变得简单。这需要花费很多时间和努力，而人类不正是因为这个过程才慢慢变得聪明么?
来源：51CTO
所有的的问题都可以进行分解。而最优雅的解决方案通常都非常简单。但是，要变得简单并不容易，这需要许多的工作。
1.技术只是解决问题的选择，而不是解决问题的根本
我们可以因为掌握了最新的JavaScript框架ahem、Angular的IoC容器技术或者某些编程语言甚至操作系统而欢欣雀跃，但是这些东西并不是作为程序员的我们用来解决问题的根本——它们只是用于帮助我们解决问题的简单工具。
我们必须非常谨慎，不要对某项正好喜欢或者正好很火的特定技术走火入魔。否则，我们将进入这样的思维怪圈：把掌握的那项技术比做是锤子，在思考问题时，会自然的把所有的问题都想象成是锤子可以解决的钉子。
2.聪明是代码清晰的敌人
当编写代码时，我们应当努力做到代码清晰易理解。
虽然这句话并不总是正确的，但在一般情况下，聪明确实是代码清晰的敌人。
事实证明，当我们写一段自认为非常了不起的代码的时候，这些代码在别人眼里可能会是一头雾水。
所以当你在编写某段聪明高效的代码的时候牢牢记住这个原则是很有必要的。
如果你对如何编写整洁清晰的代码很感兴趣的话，我强烈推荐你看罗伯特·C·马丁的书《The Clean Coder: A Code of Conduct for Professional Programmers》。
3.写尽可能少的代码
这句话看起来有一些矛盾。程序员的工作不就是编写代码么?
嗯，是的但也不是。
我们的工作需要我们编写代码，但是我们在尝试解决问题的时候应当做到尽量编写更少的代码。
这并不意味着我们需要尽量把代码写得更紧凑或者把所有的变量都使用单个字母。它的意思是我们应当尝试用更精简的算法来实现所需要实现的功能。
通常情况下，我们在代码中所添加的各种很酷的特性是非常诱人的，这还能让我们的代码看起来更“健壮”和“灵活”，能够处理各种不同类型的情况。但是，在更多的时候，我们尝试更多可能有用的特性或者预防可能在未来存在的问题的做法是错误的。这些额外的代码可能不具备任何的价值，但是却可能造成更多的伤害。因为代码越多，出现未知错误的机会就越多，代码的维护也更加的麻烦。
优秀的软件工程师写尽可能少的代码。
伟大的软件工程师删除尽可能多的代码。
4.注释是代码表述的最后选择
鲍勃·马丁曾经说过：“当你在为一段代码写注释的时候，你应当对自己糟糕的表达能力而反思。”
这并不意味着我们以后就不要写注释了。但在大多数情况下这种情况是可以避免的，你可以选择用更好的命名方式来取代它。
只有在使用命名都无法表述清楚某个方法或者变量的目的时，注释才是最后的选择。事实上，表达无法轻易在代码表达的东西才是注释的真正作用。
举个例子，注释可以告诉你在代码中的那些奇怪的操作命令并不是一个错误，而是故意的，那是因为在底层操作系统存在着某个bug。
虽然在一般情况下，许多注释还是非常有用的，但是却存在着误导的风险。
在其它代码更新后，与某些更新前代码相关的注释常常会得不到同样的更新，这就导致了某些注释会变得非常的危险，它们很可能会把你引导到一个错误的方向。
你检查过与代码密切相关的每一段注释么?是否确保代码都是在按照注释所说的那样做?如果你都照着这样做了，那么注释的意义又何在呢?如果你没有这样做，你又怎么知道注释说的都是真的?
所以，注释的作用并不象所宣扬的那么好，这种东西切勿滥用。
5.在编写代码之前你应当清楚你的代码要做什么
这看起来是理所当然的，但实际情况却不是。
现实工作中你有多少次是在没有经过充分了解到你的代码要干些什么就开始着手编程的?反正对于我来说，是不计其数了，所以我把这条记录下来用来随时提醒我。
测试驱动开发(TDD)的实践在这里可以帮助你，因为你需要在编写代码之前了解这些代码将要用于什么地方，虽然这仍然不能阻止你创建错误的东西，但是它仍然非常重要。所以当你完完全全了解需要构建的需求和功能时，再动手编程。
6.提交完成代码之前先自行测试
不要在完成编程工作后，就把代码扔给QA，然后就坐等消息了。这样会浪费每一个参加处理不必要Bug和问题的人的时间。你应当在报告编程工作完成之前，花费几分钟时间运行测试场景进行自我检测。当然，在你把代码提交给QA之前不一定会发现每一个Bug，但至少你可以杜绝一些我们每个人都可能犯下的愚蠢低级错误。
很多的软件开发人员认为测试代码只是QA人员的工作。这是不对的。保持质量是我们每个人的责任。
7.每天都要学一些新东西
有句名言“刀不磨要生锈，人不学要落后。”这句话是很有道理的，因为无论是否获取到新的知识，你每天都会遗忘掉一些以前的东西。
每天学些一些新东西并不会花费掉你很多的时间。试着每天用15分钟时间去读书，然后你就会发现每天你都会有一点点的进步，在未来的某个时候，你会发现这种进步是巨大的。因此，为了在今后获得丰厚回报你必须从现在开始就进行投资。另外，今天的技术发展日新月异，如果你不改善自己的技巧，学习新的东西，你很快就会被甩开。
8.写代码应该成为一种乐趣
这是非常正确的。或许，你进入这个行业仅仅是因为它的薪水可观。选择一份报酬丰厚的工作这并没有错，但是还有更好的选择，比如医生或者律师。事实上很多人选择做软件开发还有一个原因，那就是他们喜欢写代码。在你被工作压力所累的时候，不要忘了你选择这份职业的初衷。
编写代码可以带来很大的乐趣。多年的时间里，很多人可能都已经遗忘了这一点，那么从现在起，重新唤回以前的那份热情吧，从身边的项目开始，把你的观念和意识转换到以前你开始学习编程的那个时刻。
9.你不需要无所不知
在你学到了很多知识的时候，你仍然有很多东西不知道。
意识到这点很重要，因为它可以驱使你去了解更多更多的东西。
不知道问题的所有答案没有关系，不了解某个东西说出来并寻求帮助也无关紧要。在很多情况下，你可以选择现学现用——相信我，我就是这么走过来的。
我的观点是，不要企图去学习所有的知识，因为这是一个不可能完成的任务。你需要关注和掌握的是能够帮助你快速学习的技巧。
10.最佳的实践视环境而定
测试驱动开发最好的方法是先编写测试代码?
我们应该保持结对编程的习惯?
如果不使用IoC容器是否会低人一等?
所有这些问题的答案是“看情况。”这取决于所处的实际环境。
人们试图把最佳的实践通过喉咙等方式传输给你，他们会告诉你，他们平时都是这样应用的。所以，你也应该这样做——这其实并不正确。
在写代码的时候，我也借鉴过不少别人的成功经验。但是，这些借鉴都是有条件的。
知识是死的，人是活的。最好的实践需要视环境而定。
11.努力做到化繁为简
所有的的问题都可以进行分解。而最优雅的解决方案通常都非常简单。但是，要变得简单并不容易，这需要许多的工作。
比如，这篇文章的目的是从复杂的软件开发工作和日常生活中提取经验，通过归纳，以较简洁的方式呈现给大家，而这并不是一件容易的事情。
在解决问题时，可以先找到一个较为复杂的笨方法。在此基础上进行努力改进和提炼，使它在正确的基础上变得简单。这需要花费很多时间和努力，而人类不正是因为这个过程才慢慢变得聪明么?
2257
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
