mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
translated
This commit is contained in:
geekpi
parent
091b521dd5
commit
7a4cef27fd
@ -1,102 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
Don't Waste Time Writing Perfect Code
|
||||
============================================================
|
||||
|
||||
|
||||
A system can last for 5 or 10 or even 20 or more years. But the life of specific lines of code, even of designs, is often much shorter: months or days or even minutes when you’re iterating through different approaches to a solution.
|
||||
|
||||
### Some code matters more than other code
|
||||
|
||||
Researching [how code changes over time][4], Michael Feathers has identified [a power curve in code bases][5]. Every system has code, often a lot of it, that is written once and is never changed. But a small amount of code, including the code that is most important and useful, is changed over and over again, refactored or rewritten from scratch several times.
|
||||
|
||||
As you get more experience with a system, or with a problem domain or an architectural approach, it should get easier to know and to predict what code will change all the time, and what code will never change: what code matters, and what code doesn’t.
|
||||
|
||||
### Should we try to write Perfect Code?
|
||||
|
||||
We know that we should write [clean code][6], code that is consistent, obvious and as simple as possible.
|
||||
|
||||
Some people take this to extremes, and push themselves to write code that is [as beautiful][7] and elegant and as close to [perfect][8] as they can get, [obsessively refactoring][9] and agonizing over each detail.
|
||||
|
||||
But if code is only going to be written once and never changed, or at the other extreme if it is changing all the time, isn’t writing perfect code as wasteful and unnecessary (and impossible to achieve) as trying to write perfect requirements or trying to come up with a perfect design upfront?
|
||||
|
||||
> You Can't Write Perfect Software. Did that hurt? It shouldn't. Accept it as an axiom of life. Embrace it. Celebrate it. Because perfect software doesn't exist. No one in the brief history of computing has ever written a piece of perfect software. It's unlikely that you'll be the first. And unless you accept this as a fact, you'll end up wasting time and energy chasing an impossible dream.”
|
||||
> Andrew Hunt, [The Pragmatic Programmer: from Journeyman to Master][10]
|
||||
|
||||
Code that is written once doesn’t need to be beautiful and elegant. It has to be correct. It has to be understandable – because code that is never changed may still be read many times over the life of the system. It doesn't have to be clean and tight – just clean enough. [Copy and paste][11] and other short cuts in this code can be allowed, at least up to a point. This is code that never needs to be polished. This is code that doesn't need to be refactored (until and unless you need to change it), even if other code around it is changing. This is code that isn't worth spending extra time on.
|
||||
|
||||
What about the code that you are changing all of the time? Agonizing over style and coming up with the most elegant solution is a waste of time, because this code will probably be changed again, maybe even rewritten, in a few days or weeks. And so is [obsessively refactoring][12] code each time that you make a change, or refactoring code that you aren't changing because it could be better. Code can always be better. But that’s not important.
|
||||
|
||||
What matters is: Does the code do what it is supposed to do – is it correct and usable and efficient? Can it [handle errors and bad data][13] without crashing – or at least [fail safely][14]? Is it easy to debug? Is it easy and safe to change? These aren't subjective aspects of beauty. These are practical measures that make the difference between success and failure.
|
||||
|
||||
### Pragmatic Coding and Refactoring
|
||||
|
||||
The core idea of Lean Development is: don’t waste time on things that aren't important. This should inform how we write code, and how we refactor it, how we review it, how we test it.
|
||||
|
||||
Only [refactor what you need to][15], in order to get the job done - what [Martin Fowler][16] calls opportunistic refactoring (comprehension, cleanup, [Boy Scout rule][17] stuff) and preparatory refactoring. Enough to make a change easier and safer, and no more. If you’re not changing the code, it doesn't really matter what it looks like.
|
||||
|
||||
In code reviews, focus [only on what is important][18]. Is the code correct? Is it defensive? Is it secure? Can you follow it? Is it safe to change?
|
||||
|
||||
Forget about style (unless style gets in the way of understandability). Let your IDE take care of formatting. No arguments over whether the code could be “more OO”. It doesn’t matter if it properly follows this or that pattern as long as it makes sense. It doesn't matter if you like it or not. Whether you could have done it in a nicer way isn’t important – unless you’re teaching someone who is new to the platform and the language, and you’re expected to do some mentoring as part of code review.
|
||||
|
||||
Write tests that matter. Tests that cover the main paths and the important exception cases. Tests that give you the most information and the most confidence with the least amount of work. [Big fat tests, or small focused tests][19] – it doesn't matter, and it doesn't matter if you write the tests before you write the code or after, as long as they do the job.
|
||||
|
||||
### It’s not (Just) About the Code
|
||||
|
||||
The architectural and engineering metaphors have never been valid for software. We aren’t designing and building bridges or skyscrapers that will stay essentially the same for years or generations. We’re building something much more plastic and abstract, more ephemeral. Code is written to be changed – that is why it’s called “software”.
|
||||
|
||||
> “After five years of use and modification, the source for a successful software program is often completely unrecognizable from its original form, while a successful building after five years is virtually untouched.”
|
||||
> Kevin Tate, [Sustainable Software Development][20]
|
||||
|
||||
We need to look at code as a temporary artefact of our work:
|
||||
|
||||
> …we're led to fetishize code, sometimes in the face of more important things. Often we suffer under the illusion that the valuable thing produced in shipping a product is the code, when it might actually be an understanding of the problem domain, progress on design conundrums, or even customer feedback.
|
||||
> Dan Grover, [Code and Creative Destruction][21]
|
||||
|
||||
Iterative development teaches us to experiment and examine the results of our work – did we solve the problem, if we didn’t, what did we learn, how can we improve? The software that we are building is never done. Even if the design and the code are right, they may only be right for a while, until circumstances demand that they be changed again or replaced with something else that fits better.
|
||||
|
||||
We need to write good code: code that is understandable, correct, safe and secure. We need to refactor and review it, and write good useful tests, all the while knowing that some of this code, or maybe all of it, could be thrown out soon, or that it may never be looked at again, or that it may not get used at all. We need to recognize that some of our work will necessarily be wasted, and optimize for this. Do what needs to be done, and no more. Don’t waste time trying to write perfect code.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Jim Bird
|
||||
|
||||
I am an experienced software development manager, project manager and CTO focused on hard problems in software development and maintenance, software quality and security. For the last 15 years I have been managing teams building electronic trading platforms for stock exchanges and investment banks around the world. My special interest is how small teams can be most effective at building real software: high-quality, secure systems at the extreme limits of reliability, performance, and adaptability.
|
||||
|
||||
------
|
||||
|
||||
via: https://dzone.com/articles/dont-waste-time-writing
|
||||
|
||||
作者：[Jim Bird][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://dzone.com/users/722527/jim.bird.html
|
||||
[1]:https://dzone.com/users/722527/jim.bird.html
|
||||
[2]:https://dzone.com/users/722527/jim.bird.html
|
||||
[3]:https://dzone.com/articles/dont-waste-time-writing?utm_source=wanqu.co&utm_campaign=Wanqu%20Daily&utm_medium=website#
|
||||
[4]:http://www.youtube.com/watch?v=0eAhzJ_KM-Q
|
||||
[5]:http://swreflections.blogspot.ca/2012/10/bad-things-happen-to-good-code.html
|
||||
[6]:http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
|
||||
[7]:http://www.makinggoodsoftware.com/2011/03/27/the-obsession-with-beautiful-code-the-refactor-syndrome/
|
||||
[8]:http://stackoverflow.com/questions/1196405/how-to-keep-yourself-from-perfectionism-when-coding
|
||||
[9]:http://programmers.stackexchange.com/questions/43506/is-it-bad-to-have-an-obsessive-refactoring-disorder
|
||||
[10]:https://pragprog.com/the-pragmatic-programmer
|
||||
[11]:http://swreflections.blogspot.com/2012/03/is-copy-and-paste-programming-really.html
|
||||
[12]:http://programmers.stackexchange.com/questions/43506/is-it-bad-to-have-an-obsessive-refactoring-disorder
|
||||
[13]:http://swreflections.blogspot.com/2012/03/defensive-programming-being-just-enough.html
|
||||
[14]:https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
|
||||
[15]:http://swreflections.blogspot.com/2012/04/what-refactoring-is-and-what-it-isnt.html
|
||||
[16]:http://martinfowler.com/articles/workflowsOfRefactoring/
|
||||
[17]:http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
|
||||
[18]:http://randomthoughtsonjavaprogramming.blogspot.com/2014/08/building-real-software-dont-waste-time.html
|
||||
[19]:http://swreflections.blogspot.com/2012/08/whats-better-big-fat-tests-or-little.html
|
||||
[20]:http://www.amazon.com/Sustainable-Software-Development-Agile-Perspective/dp/0321286081
|
||||
[21]:http://dangrover.com/2013/07/16/code-and-creative-destruction/
|
||||
[22]:https://dzone.com/devops-tutorials-tools-news
|
||||
[23]:https://dzone.com/articles/dont-waste-time-writing?utm_source=wanqu.co&utm_campaign=Wanqu%20Daily&utm_medium=website#
|
||||
[24]:https://dzone.com/go?i=228233&u=https%3A%2F%2Foffers.automic.com%2Fblueprint-to-continuous-delivery-with-automic-release-automation%3Futm_campaign%3DAMER%252520Online%252520Syndication%252520DZone%252520Platinum%252520Sponsorship%252520Ads%252520JULY-2017%26utm_source%3DDzone%252520Ads%26utm_medium%3DBlueprint%252520to%252520CD
|
||||
101
translated/tech/20141107 Dont Waste Time Writing Perfect Code.md
Normal file
101
translated/tech/20141107 Dont Waste Time Writing Perfect Code.md
Normal file
@ -0,0 +1,101 @@
|
||||
不要浪费时间写出完美的代码
|
||||
============================================================
|
||||
|
||||
|
||||
系统可以持续 5 年或 10 年甚至 20 年或者更多年。但是，特定代码行的生命，即使是设计，通常要短得多：当你通过不同的方法来解决问题，它会有几个月或几天甚至几分钟的生命。
|
||||
|
||||
### 一些代码比其他代码重要
|
||||
|
||||
通过研究[代码如何随时间变化][4]，Michael Feathers 确定了[一个代码库曲线][5]。每个系统都有代码，通常有很多是一次性写的，永远都不会改变。但是有少量的代码，包括最重要和最有用的代码，会一次又一次地改变、几次重构或者从头重写。
|
||||
|
||||
当你在一个系统中有更多体验，或者有一个问题领域或体系结构方法时，应该更容易了解并预测什么代码将永远改变，哪些代码将永远不会改变：什么代码重要，什么代码不重要。
|
||||
|
||||
### 我们应该尝试编写完美的代码么？
|
||||
|
||||
我们知道我们应该写[干净的代码][6]，代码是一致的，很明显也要尽可能简单的。
|
||||
|
||||
有些人把这变成极端，他们迫使自己写出[美丽][7]、优雅，接近[完美][8]的代码，[痴迷重构][9]并且纠结每个细节。
|
||||
|
||||
但是，如果代码只写一次而不改变，或者如果在另一个极端下，它一直在改变的话，就如尝试写完美的需求护着尝试完美的前期设计那样，写完美的代码难道不是既浪费又没有必要（也不可能实现）的么？
|
||||
|
||||
> “你不能写完美的软件。这受伤么？作为生活的公理接受它、拥抱它、庆祝它。因为完美的软件不存在。计算机的短暂历史中没有人写过一个完美的软件。你不可能成为第一个。除非你接受这个事实，否则你最终会浪费时间和精力追逐不可能的梦想。”
|
||||
> Andrew Hunt，[务实的程序员: 从熟练工到大师][10]
|
||||
|
||||
一次性写的代码不需要美观优雅。但它必须是正确的、可以理解的 - 因为不会改变的代码在系统的整个生命周期内可能仍然被阅读很多次。它不需要干净和紧凑 - 只要干净够了。代码中[复制和粘贴][11]和其他小的裁剪是允许的，至少要达到这点。这是永远不需要打磨的代码。即使周围的其他代码正在更改，这也是不需要重构的代码（除非你需要更改它）。这是不值得花费额外时间的代码。
|
||||
|
||||
你一直在改变的代码怎么样？纠结风格以及提出最优雅的解决方案是浪费时间，因为这段代码可能会再次更改，甚至可能会在几天或几周内重写。因此，每当你进行更改时，都会[痴迷重构][12]代码，或者没有重构没有改变的代码，因为它可能会更好。代码总是可以更好。但这并不重要。
|
||||
|
||||
重要的是：代码是否做了应该做的 - 是正确的、可用的和高效的？它可以[处理错误和不良数据][13]而不会崩溃 - 至少[安全地失败][14]？调试容易吗？改变是否容易安全？这些不是美的主观方面。这些是成功与失败实际措施之间的差异。
|
||||
|
||||
### 务实编码和重构
|
||||
|
||||
精益发展的核心思想是：不要浪费时间在不重要的事情上。这应该提醒我们该如何编写代码，以及我们如何重构它、审查它、测试它。
|
||||
|
||||
为了让工作完成，只[重构你需要的][15] - [Martin Fowler][16] 称之为机会主义重构（理解、清理、[童子军规则][17] ）和准备重构。足够使变化更加容易和安全，而不是更多。如果你不改变代码，那么它并不会如看起来的那么重要。
|
||||
|
||||
在代码审查中，只聚焦在[重要的事上][18]。代码是否正确？有防御吗？是否安全？你能理解么？改变是否安全？
|
||||
|
||||
忘记风格（除非风格变成无法理解）。让你的 IDE 处理格式化。不要争议代码是否应该是“更多的 OO”。只要它有意义，它是否适当地遵循这种或那种模式并不重要。无论你喜欢还是不喜欢都没关系。无论你有更好的方式做到这一点并不重要 - 除非你在教新接触这个平台或者语言的人，而且需要在做代码审查时做一部分指导。
|
||||
|
||||
写测试很重要。测试涵盖主要流程和重要的意外情况。测试让你用最少的工作获得最多的信息和最大的信心。[大面积覆盖测试，或小型测试][19] - 都没关系，只要他们做这个工作，在编写代码之前或之后编写测试并不重要。
|
||||
|
||||
### 不是（只是）关于代码
|
||||
|
||||
建筑和工程隐喻从未对软件有效。我们不是设计和建造几年或几代将保持基本不变的桥梁或摩天大楼。我们构建的更加弹性和抽象，更加短暂的东西。代码写来是被修改的 - 这就是为什么它被称为“软件”。
|
||||
|
||||
> “经过五年的使用和修改，成功的软件程序的源码通常和它的原始形式完全无法识别，而五年后的成功建筑几乎没有变化。”
|
||||
> Kevin Tate，[可持续软件开发][20]
|
||||
|
||||
我们需要将代码看作是我们工作的一个暂时的人工品：
|
||||
|
||||
> 有时候面对更重要的事情时，我们被引导迷信代码。我们经常有一个错觉，让发出的产品有价值的是代码，然而实际上可能是对问题领域的了解、设计难题的进展甚至是客户反馈。
|
||||
> Dan Grover，[Code and Creative Destruction][21]
|
||||
|
||||
迭代开发教会我们来体验和研究我们工作的结果 - 我们是否解决了这个问题，如果没有，我们学到了什么，我们如何改进？软件构建从不会完成。即使设计和代码是正确的，它们也可能只是一段时间，直到环境要求再次更改或替换为更好的东西。
|
||||
|
||||
我们需要编写好的代码：代码可以理解、正确、安全和可靠。我们需要重构和审查它，并写出好的有用的测试，同时知道这其中一些或者所有的代码，可能会很快被抛弃，或者它可能永远不会被再被查看，或者它可能根本不用。我们需要认识到，我们的一些工作必然会被浪费，并为此而进行优化。做需要做的，没有别的了。不要浪费时间尝试编写完美的代码。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
Jim Bird
|
||||
|
||||
|
||||
我是一名经验丰富的软件开发经理，项目经理和 CTO，专注于软件开发和维护、软件质量和安全性方面的困难问题。在过去 15 年中，我一直在管理建立全球证券交易所和投资银行电子交易平台的团队。我特别感兴趣的是，小团队在构建真正的软件中如何有效率：在可靠性，性能和适应性极限限制下的高质量，安全系统。
|
||||
|
||||
------
|
||||
|
||||
via: https://dzone.com/articles/dont-waste-time-writing
|
||||
|
||||
作者：[Jim Bird][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://dzone.com/users/722527/jim.bird.html
|
||||
[1]:https://dzone.com/users/722527/jim.bird.html
|
||||
[2]:https://dzone.com/users/722527/jim.bird.html
|
||||
[3]:https://dzone.com/articles/dont-waste-time-writing?utm_source=wanqu.co&utm_campaign=Wanqu%20Daily&utm_medium=website#
|
||||
[4]:http://www.youtube.com/watch?v=0eAhzJ_KM-Q
|
||||
[5]:http://swreflections.blogspot.ca/2012/10/bad-things-happen-to-good-code.html
|
||||
[6]:http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
|
||||
[7]:http://www.makinggoodsoftware.com/2011/03/27/the-obsession-with-beautiful-code-the-refactor-syndrome/
|
||||
[8]:http://stackoverflow.com/questions/1196405/how-to-keep-yourself-from-perfectionism-when-coding
|
||||
[9]:http://programmers.stackexchange.com/questions/43506/is-it-bad-to-have-an-obsessive-refactoring-disorder
|
||||
[10]:https://pragprog.com/the-pragmatic-programmer
|
||||
[11]:http://swreflections.blogspot.com/2012/03/is-copy-and-paste-programming-really.html
|
||||
[12]:http://programmers.stackexchange.com/questions/43506/is-it-bad-to-have-an-obsessive-refactoring-disorder
|
||||
[13]:http://swreflections.blogspot.com/2012/03/defensive-programming-being-just-enough.html
|
||||
[14]:https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
|
||||
[15]:http://swreflections.blogspot.com/2012/04/what-refactoring-is-and-what-it-isnt.html
|
||||
[16]:http://martinfowler.com/articles/workflowsOfRefactoring/
|
||||
[17]:http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
|
||||
[18]:http://randomthoughtsonjavaprogramming.blogspot.com/2014/08/building-real-software-dont-waste-time.html
|
||||
[19]:http://swreflections.blogspot.com/2012/08/whats-better-big-fat-tests-or-little.html
|
||||
[20]:http://www.amazon.com/Sustainable-Software-Development-Agile-Perspective/dp/0321286081
|
||||
[21]:http://dangrover.com/2013/07/16/code-and-creative-destruction/
|
||||
[22]:https://dzone.com/devops-tutorials-tools-news
|
||||
[23]:https://dzone.com/articles/dont-waste-time-writing?utm_source=wanqu.co&utm_campaign=Wanqu%20Daily&utm_medium=website#
|
||||
[24]:https://dzone.com/go?i=228233&u=https%3A%2F%2Foffers.automic.com%2Fblueprint-to-continuous-delivery-with-automic-release-automation%3Futm_campaign%3DAMER%252520Online%252520Syndication%252520DZone%252520Platinum%252520Sponsorship%252520Ads%252520JULY-2017%26utm_source%3DDzone%252520Ads%26utm_medium%3DBlueprint%252520to%252520CD
|
||||
Loading…
Reference in New Issue
Block a user