A good paradigm shift always allows you to see things differently and become a better developer. I would suggest you read up on functional programming and maybe learn a functional language like Haskell or Scheme.
YAGNI (You Ain't Gonna Need It) and DTSTTCPW (Do The Simplest Thing That Could Possibly Work)
It's easy to spend a lot of time thinking about edge cases, and find that you've implemented something that's completely useless. I believe that a far better approach is to knock out a simple prototype, and then poke and prod it until you understand the domain well enough to create production code.
Recognize, however, that your prototype is going to evolve into production code whether you like it or not. So write it with that in mind.
Learning how to use your IDE and tools. This to me resulted in a far greater productivity increase.
For examples:
learning how to use a source level debugger
using tools like purify/boundschecker
fxcop
etc. I realize I am dating myself, but those were big steps. There are many more.
Any time you can change the way you think about a problem or solve a problem without having to undo previous work is HUGE gain. Process, tools, etc all can help with that. Don't limit yourself to finding silver bullet techniques for productivity gains.
Watching productive people work and getting them to tell you what they are doing and why is also invaluable.
For methodology I would advice Agile development that is great. There are a numerous number of techniques and methods (I'm personally fan of extreme programming) and reading that can keep you busy and improve your general approach.
Design Patterns. Learning how to break dependence upon implementation and inheritance, and depending on interfaces (contracts) instead changed the way I think about programming.
Debugging. Once I figured out how to actually step through the code and go line-by-line, examining the underlying state, it revolutionized how I troubleshoot code.
Practice, practice practice: I didn't realize how important it is to keep working on my skills apart from work until a relatively short time ago. Mistakes and solutions I make at home make me a better programmer at work, and vice a versa. Learning should never stop if you want to be good at something, and programming isn't an exception.
If you want to expand your experience into web programming, you should try and get a good handle on the HTTP Request/Response paradigm. This will make creating web apps much easier on you because you understand the underlying framework.
学习 Smalltalk 帮助我提高了工作效率。 它是一种易于学习的语言，并且可以非常快速地构建事物。 要获得令人惊叹的生产力帮助，请查看 Seaside，它是一个用于构建 Web 应用程序的框架。 而且，如果您只习惯过大括号语言，Smalltalk 也会让您微笑！
Learning Smalltalk has helped me become more productive. It is an easy language to learn and things can be built extremely quickly. For a stunning productivity aid check out Seaside, it's a framework for building web applications. Moreover, if you have only been used to curly brace languages Smalltalk will also make you smile!
从长远来看，高层次的理解、创建具有适当依赖关系的良好抽象是有回报的。 例如，德米特定律是一个重要的指导方针。 我还建议阅读 Eric Evan 的 领域驱动设计
High level understanding, creating good abstractions with proper dependencies, is what pays off in long term. For example, Law of Demeter is an important guideline. I recommend also reading Eric Evan's Domain Driven Design
Code generators. They're the best thing in software engineering.
Would you like to write all your projects in asm? Nope, let's generate it from C++. Or from something sat above the JVM which diligently generates the necessary machine code.
Duplicating the same source code all over the place, but stuck with a language that insists on the line noise? Use macros.
Want to use lambdas in a language that doesn't have them? Work out how to fake the anonymous name and variable scoping required then generate the boilerplate.
None of the readily available languages quite fit your pattern of thought, desired syntax or even semantics? Write a compiler for a new one.
Better languages are nice. Better design patterns are nice. Emacs is awesome. But compilers are where all the power lies in our field. I suspect the only reason they aren't mentioned in any of the other answers is that we can't imagine programming without any.
发布评论
评论（19）
良好的范式转变总是能让你以不同的方式看待事物并成为更好的开发人员。 我建议你阅读函数式编程，也许学习一门函数式语言，比如Haskell 或 方案。
A good paradigm shift always allows you to see things differently and become a better developer. I would suggest you read up on functional programming and maybe learn a functional language like Haskell or Scheme.
YAGNI（你不会需要它）和 DTSTTCPW（做可能可行的最简单的事情）
很容易花费大量时间思考边缘情况，并发现您已经实现了完全无用的东西。 我相信更好的方法是敲出一个简单的原型，然后对其进行测试，直到您足够了解该领域以创建生产代码。
然而，要认识到，无论您是否喜欢，您的原型都将演变成生产代码。 因此请牢记这一点来写。
YAGNI (You Ain't Gonna Need It) and DTSTTCPW (Do The Simplest Thing That Could Possibly Work)
It's easy to spend a lot of time thinking about edge cases, and find that you've implemented something that's completely useless. I believe that a far better approach is to knock out a simple prototype, and then poke and prod it until you understand the domain well enough to create production code.
Recognize, however, that your prototype is going to evolve into production code whether you like it or not. So write it with that in mind.
学习如何使用 IDE 和工具。 对我来说，这大大提高了生产力。
例如：
等工具来使用源代码级调试器。我意识到我正在和自己约会，但这些都是很大的进步。 还有更多。
任何时候你可以改变你思考问题的方式或解决问题，而不必撤销以前的工作，这都是巨大的收获。 流程、工具等都可以提供帮助。 不要局限于寻找提高生产力的灵丹妙药。
观察富有成效的人们工作并让他们告诉你他们在做什么以及为什么这样做也是非常有价值的。
Learning how to use your IDE and tools. This to me resulted in a far greater productivity increase.
For examples:
etc. I realize I am dating myself, but those were big steps. There are many more.
Any time you can change the way you think about a problem or solve a problem without having to undo previous work is HUGE gain. Process, tools, etc all can help with that. Don't limit yourself to finding silver bullet techniques for productivity gains.
Watching productive people work and getting them to tell you what they are doing and why is also invaluable.
老实说，使用、和学习像 .NET 这样的优秀框架确实提高了我的工作效率。
我经常惊讶于人们愿意重新发明什么，因为他们不知道框架中已经存在相同的功能。
If I'm honest, using, and learning a great framework like .NET has really increased my productivity.
I'm often amazed what people are willing to reinvent due to their ignorance that the very same function already exists in the framework.
敏捷，尤其是测试驱动开发。 自面向对象设计发明以来，软件开发发生了最好的事情。
AGILE and especially Test Driven Development. Best thing to happen to software development since the invention of Object Oriented Design.
关于编码，我会说设计模式和架构模式总是很好看，并且可以帮助您编写更清晰/更好的代码。
对于方法论，我建议敏捷开发非常棒。 有许多技术和方法（我个人是极限编程的粉丝）阅读可以让你保持忙碌并改善你的总体方法。
最后我想说学习新语言，比如 Ruby
Concerning coding, I'd say design patterns and architecture patterns are always nice to look at and can help you write cleaner/better code.
For methodology I would advice Agile development that is great. There are a numerous number of techniques and methods (I'm personally fan of extreme programming) and reading that can keep you busy and improve your general approach.
Finally I'd say learn new languages like Ruby
设计模式。 学习如何打破对实现和继承的依赖，以及对接口（契约）的依赖改变了我对编程的思考方式。
调试。 一旦我弄清楚如何实际单步执行代码并逐行检查底层状态，它就彻底改变了我排除代码故障的方式。
练习，练习练习：直到不久前，我才意识到在工作之外继续锻炼自己的技能是多么重要。 我在家里犯的错误和解决方案使我在工作中成为更好的程序员，反之亦然。 如果你想擅长某件事，学习就永远不应该停止，编程也不例外。
Design Patterns. Learning how to break dependence upon implementation and inheritance, and depending on interfaces (contracts) instead changed the way I think about programming.
Debugging. Once I figured out how to actually step through the code and go line-by-line, examining the underlying state, it revolutionized how I troubleshoot code.
Practice, practice practice: I didn't realize how important it is to keep working on my skills apart from work until a relatively short time ago. Mistakes and solutions I make at home make me a better programmer at work, and vice a versa. Learning should never stop if you want to be good at something, and programming isn't an exception.
如果我必须选择一个，我会说测试驱动设计，又名 TDD：在增量添加功能之前编写单元测试（并检查它们是否失败）。
If I had to pick just one, I'd say Test-Driven Design, aka TDD: write unit tests (and check that they fail) before you incrementally add features.
尝试学会从用户的角度看待事物。
例如：
请记住，用户看到的是您的应用程序，而不是您的代码。
Try to learn to see things from the user's standpoint.
For example:
Remember that the user sees your application, not your code.
VIM 快速参考卡。 在我开始使用高级 vim（宏、插件）后，我已经停止在手动编码期间执行任何重复操作。
除此之外，Scrum 和晚上工作，当没有人打扰时，你给了我最大的好处。
VIM Quick Reference Card. After I started using advanced vim (macros, plugins) I have stopped doing any repetitive actions during coding manually.
Apart from that, Scrum and working at night, when noone interrupts You gave me the highest benefit.
如果您想将您的经验扩展到 Web 编程，您应该尝试很好地掌握 HTTP 请求/响应范例。 这将使您更轻松地创建 Web 应用程序，因为您了解底层框架。
(http)://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
If you want to expand your experience into web programming, you should try and get a good handle on the HTTP Request/Response paradigm. This will make creating web apps much easier on you because you understand the underlying framework.
(http)://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
我会研究一些结合了 OO 和函数式元素的较新语言，例如 C# 或 Scala。
I would look at some of the newer languages that combine OO and functional elements, like C# or Scala.
学习 Smalltalk 帮助我提高了工作效率。 它是一种易于学习的语言，并且可以非常快速地构建事物。 要获得令人惊叹的生产力帮助，请查看 Seaside，它是一个用于构建 Web 应用程序的框架。 而且，如果您只习惯过大括号语言，Smalltalk 也会让您微笑！
Learning Smalltalk has helped me become more productive. It is an easy language to learn and things can be built extremely quickly. For a stunning productivity aid check out Seaside, it's a framework for building web applications. Moreover, if you have only been used to curly brace languages Smalltalk will also make you smile!
以下范例按此顺序对我有所帮助：
1）自下而上的编程
2）自顶向下编程（C、Pascal）
3）面向对象编程（Smalltalk、Java）
4）函数式编程（lisp、Mathematica）
以及一些逻辑编程（prolog）。
I was helped by the following paradigms in this order:
1) bottom-up programming
2) top-down programming (C, Pascal)
3) object-oriented programming (Smalltalk, Java)
4) functional programming (lisp, Mathematica)
with some logic programming thrown in (prolog).
nHibernate 轻而易举。 我不需要为我的业务对象编写数据库功能，这一事实非常有用且节省时间。
nHibernate hands down. The fact that I dont need to write database functionality for my business objects is very useful and time saving.
从长远来看，高层次的理解、创建具有适当依赖关系的良好抽象是有回报的。 例如，德米特定律是一个重要的指导方针。 我还建议阅读 Eric Evan 的 领域驱动设计
High level understanding, creating good abstractions with proper dependencies, is what pays off in long term. For example, Law of Demeter is an important guideline. I recommend also reading Eric Evan's Domain Driven Design
代码生成器。 它们是软件工程中最好的东西。
您想用 asm 编写所有项目吗？ 不，让我们从 C++ 生成它。 或者来自 JVM 之上的某个东西，它会努力生成必要的机器代码。
到处复制相同的源代码，却坚持使用一种坚持线路噪音的语言？ 使用宏。
想要在没有 lambda 的语言中使用它们吗？ 弄清楚如何伪造所需的匿名名称和变量范围，然后生成样板文件。
没有一种现成的语言完全适合您的思维模式、所需的语法甚至语义？ 为新的编译器编写一个编译器。
更好的语言是好的。 更好的设计模式是很好的。 Emacs 太棒了。 但编译器是我们领域的所有力量所在。 我怀疑其他答案中没有提到它们的唯一原因是我们无法想象没有它们的编程。
Code generators. They're the best thing in software engineering.
Would you like to write all your projects in asm? Nope, let's generate it from C++. Or from something sat above the JVM which diligently generates the necessary machine code.
Duplicating the same source code all over the place, but stuck with a language that insists on the line noise? Use macros.
Want to use lambdas in a language that doesn't have them? Work out how to fake the anonymous name and variable scoping required then generate the boilerplate.
None of the readily available languages quite fit your pattern of thought, desired syntax or even semantics? Write a compiler for a new one.
Better languages are nice. Better design patterns are nice. Emacs is awesome. But compilers are where all the power lies in our field. I suspect the only reason they aren't mentioned in any of the other answers is that we can't imagine programming without any.
复制/粘贴技术
Copy/paste technique