软件交付
Rubbish software is produced when we try to do everything at once.
当我们尝试一次做所有事情时，就会产生垃圾软件。
Principles, guidelines, best practices, and rules of thumb — they all make your life easier. Without them, ten-minute tasks can turn into ten-hour tasks.
原则，准则，最佳做法和经验法则-它们都使您的生活更轻松。 没有它们，十分钟的任务可能会变成十小时的任务。
One of the absolute best pieces of advice I received from my mentor very early on in my career was this simple one-liner:
我很早就从我的导师那里得到了绝对最好的建议之一，就是这个简单的单行代码：
“Make it work, make it better, make it faster.”
“使其工作，使其更好，使其更快。”
It’s a slight alteration of Kent Beck’s famous quote, and its simplicity is enabling and puzzling.
这是肯特·贝克 ( Kent Beck)著名语录的略微改动，其简单性令人感到困惑。
“Make it work” is quite easy to wrap your head around. You have a set of requirements, and you’re coding to fulfill them — kid stuff.
“动手做”很容易使您的头脑转转。 您有一组要求，而您正在编写代码来满足它们-孩子们的东西。
“Make it better” is where the meat is. “Better” is the juicy part that you’ll spend the majority of your day achieving. Better code, better design, better approaches. But what does “better” mean? We’ll get around to that later.
“做得更好”是肉的所在。 “更好”是您一天中大部分时间都会实现的多汁部分。 更好的代码，更好的设计，更好的方法。 但是“更好”是什么意思？ 我们稍后再解决。
Well, let’s be honest: You often never get around to the “make it faster” aspect of your code — at least not for every part of the software. You want to make your hot paths fast and efficient, but you’re likely in good shape, leaving paths rarely traveled. It’s not worth the effort. Simple as that.
好吧，说实话：您通常永远不会绕过代码的“使其更快”的一面-至少不是针对软件的每个部分。 您想使快速路径高效快速，但您的状态可能很好，几乎没有路径可走。 这不值得付出努力。 就那么简单。
Ridiculously, developers tend to focus on “make it faster” whenever they read others’ code. It’s common to read comments like “This inefficient code is horrific!” This totally neglects whether the code solves the problem on time.
荒谬的是，开发人员在阅读他人的代码时往往会专注于“使其更快”。 阅读诸如“此低效率的代码太可怕了！”之类的评论很常见。 这完全忽略了代码是否按时解决了问题。
编写垃圾代码没有任何耻辱 (There’s No Shame in Writing Trash Code)
The first step is to make it work. Plain and simple.
第一步是使其工作。 干净利落。
Making things work by violating principles of good design in a quick, hacky way is completely fine.
通过快速，hacky的方式违反良好设计的原理来使事情正常进行是完全可以的。
Dreaming up premature, elaborate up-front designs is entirely useless. Exploration is best done using a few, battle-tested techniques such as prototyping, proof of concept, simple trashy code, and throwaway code.
幻想过早的，精心设计的前期设计完全没有用。 最好使用一些经过考验的技术来完成探索，例如原型设计，概念验证，简单的垃圾代码和一次性代码。
Everything is laid out right in front of you. There are no abstractions, no magic, no “I wonder how that works.”
一切都摆在您面前。 没有抽象，没有魔术，也没有“我想知道它是如何工作的”。
What’s important, though, is to recognize this as a first step. Leaving trash behind is a surefire way of building up technical debt that’ll come back to haunt you. Experiment like a mad lad, but clean up before pushing the code.
不过，重要的是要将此视为第一步。 丢垃圾是增加技术债务的可靠方法，这些债务会再次困扰您。 像个疯子一样进行实验，但是在推送代码之前先清理一下。
让我们变得更好 (Let’s Make It Better)
Time to be real: No end-user is going to be like “Man, Google’s code is so neatly structured. That’s why I use Google search!” Users couldn’t care less about how much better your code is compared to the mess you made earlier. Users care about good experiences and how easy your software is to use — not how easy it is to modify.
成为现实的时间：没有最终用户会喜欢“伙计，Google的代码结构如此整齐。 这就是为什么我使用Google搜索！” 用户可以毫不关心与您之前的混乱情况相比，您的代码有多好。 用户关心良好的体验以及软件的易用性，而不是修改的难易程度。
Bettering your code is nevertheless an important aspect of the overall quality of your product. The internal software quality affects your ability to pivot, detect and correct defects, and the time to release.
但是，改进代码仍然是产品整体质量的重要方面。 内部软件质量会影响您发现，纠正和纠正缺陷的能力以及发布时间。
Before moving on to making your software better, be sure to somehow validate that your software is still functioning correctly after the modifications. Put in place some sort of regression testing. Unit tests are useful, but code inspection is just as important.
在继续改进软件之前，请确保以某种方式验证修改后您的软件仍能正常运行。 进行某种回归测试。 单元测试很有用，但是代码检查同样重要。
Making your software better is not just about refactoring. Refactoring is essentially behavior preserving changes to your codebase. But making your software better is a different species, where refactoring is only a part of it.
使您的软件更好，不仅仅是重构。 重构本质上是行为，可以保留对代码库的更改 。 但是，使软件变得更好是另一回事，重构只是其中的一部分。
It’s re-architecting. Applying design patterns where applicable. Assessing if your code is SOLID. Fixing code smells and taking care of edge cases.
正在重新架构。 在适用的情况下应用设计模式。 评估您的代码是否为SOLID。 修复代码异味并注意边缘情况。
Better code is:
更好的代码是：
Strive to achieve these characteristics by applying modern practices as well as the famous SOLID and DRY principles. I won’t preach theory here, as there’s already an overwhelming number of articles on these topics. Just google the acronyms.
力求通过应用现代实践以及著名的SOLID和DRY原理来实现这些特征。 我不会在这里讲理论，因为已经有大量关于这些主题的文章。 只是谷歌的缩写。
如果我们能够解决问题，那就更快 (If We Ever Get Around to It, Make It Faster)
Not every aspect of your application or library is created equal. Not every line of code is executed at the same frequency. Don’t rush off code tuning every line.
并非您的应用程序或库的每个方面都是一样的。 并非每一行代码都以相同的频率执行。 不要急于调整每一行的代码。
What you often find is only a small part of your application is using a disproportional share of the runtime. Figure out what part it is, measure its performance, set performance goals, optimize, and measure again.
您经常发现应用程序的一小部分正在使用运行时间的不成比例的份额。 弄清楚它是什么部分，衡量其性能，设定绩效目标，进行优化，然后再次进行衡量。
Optimizing without a target performance is not going to end well. You might do some solid performance optimization, but if you spent a whole workday on it, it’s perhaps not worth it.
没有目标性能的优化将无法顺利完成。 您可能会进行一些可靠的性能优化，但是如果您花了整整一个工作日，可能不值得。
After you reach a certain point of performance, users’ appreciation for every millisecond shaved off is diminishing. At this point, you’re only harvesting street credit from fellow developers, which is completely pointless.
在达到特定性能点之后，用户对每减少一毫秒的赞赏就会减少。 在这一点上，您只从其他开发人员那里获得街头信贷，这是毫无意义的。
Some developers preach that you must optimize as you go. Premature optimization is just as bad as applying a design pattern prematurely.
一些开发人员鼓吹您必须随行进行优化。 过早的优化与过早地应用设计模式一样糟糕。
Instead, write the simplest code possible to begin with. Then refactor, redesign, etc. and optimize only if there’s a bottleneck.
而是编写可能最简单的代码。 然后进行重构，重新设计等，仅在存在瓶颈时进行优化。
资源资源 (Resources)
Code Complete 2, chapters 20 & 25 by McConnell, S.
代码完成2 ，第20和25章，由McConnell，S.发表。
What Is Throw-Away Code? by The Craft of Coding
什么是丢码？ 通过编码技巧
The Art of Software Testing, 2nd chapter 3, by Myers, G.
软件测试的艺术 ，第2章第3章，作者：迈尔斯(Myers)，G。
Make It Work, Make It Right, Make It Fast by Ward Cunningham
让它起作用，让它正确，让它快速 by Ward Cunningham
Seven Basic Principles of Software Engineering by Boehm, B. W.
The Lean Six Sigma Guide to Doing More With Less: Cut Costs, Reduce Waste, and Lower Your Overhead by George, M. O.
精益六西格玛指南，事半功倍：降低成本，减少浪费并降低管理费用
翻译自: https://medium.com/@nmillard/the-principles-of-software-development-7415e7c5a156
软件交付
211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
