订单15分钟内支付
“Difficult to make even small changes”
“很难做出很小的改变”
“Breaking functionality of the software by making changes”
“通过进行更改来突破软件的功能”
“Introducing a new bug by fixing another one”
“通过修复另一个错误来引入新的错误”
“Implementing code that is unnecessary”
“实施不必要的代码”
“Almost impossible to add a new feature because of complicated code”
“由于代码复杂，几乎不可能添加新功能”
“The never-shipping product”
“永不出货的产品”
“Throwing code away and rewriting it from scratch”
“丢掉代码并从头开始重写”
Are all the above statements familiar?
以上所有陈述熟悉吗？
Every minute a developer from any part of the World says (or thinks) any of the above statements and wishes to cry. Why?
来自世界任何地方的开发人员每分钟都会说(或认为)以上任何陈述，并希望哭泣。 为什么？
These are common issues talked about by developers very often. These stories are experienced in every development team.
这些是开发人员经常谈论的常见问题。 这些故事在每个开发团队中都有。
There are many small factors that slowly and gradually harm a developer’s projects. They are not immediately destructive. Most of them only do long-term damage. Something you won’t see the damage for a year or more. So when somebody proposes them, often they sound harmless.
有许多小因素会逐渐并逐渐损害开发人员的项目。 它们不会立即造成破坏。 他们大多数只造成长期损害。 一年或一年以上您看不到任何损坏。 因此，当有人提出建议时，它们听起来通常是无害的。
Even when you start implementing them, they may seem fine. But as time goes on — and particularly as more and more of these stack up — the complexity becomes more apparent and grows until you’re another victim of that ever-so-common horror story.
即使您开始实施它们，它们似乎也不错。 但是随着时间的流逝-尤其是随着越来越多的这种堆叠-复杂性变得越来越明显，并且越来越复杂，直到您成为那个鲜为人知的恐怖故事的另一个受害者为止。
To avoid being one of the victims, you should embrace the fundamental laws of software. You should develop a mindset that every developer should have. This mindset will help you make better decisions in your daily programming journey. You can keep your software as simple as possible. You can protect it from being an unmanageable and complex system.
为了避免成为受害者之一，您应该接受软件的基本定律。 您应该养成每个开发人员都应该拥有的心态。 这种心态将帮助您在日常编程过程中做出更好的决策。 您可以使软件尽可能简单。 您可以防止它成为无法管理的复杂系统。
Here are the key points that every developer must master.
这是每个开发人员必须掌握的关键点。
1.构思软件的目的 (1. Conceiving The Purpose of Software)
First of all, you should understand the purpose of the software. There is, in fact, a single purpose of all software: To help people.
首先，您应该了解该软件的用途。 实际上，所有软件都有一个共同的目的： 帮助人们 。
Remember: the purpose of the software is not to show off how intelligent you are. — Max Kanat-Alexander, Code Simplicity
请记住：该软件的目的不是炫耀您的智能。 — 代码简化的Max Kanat-Alexander
Developers who cannot conceive the purpose of the software will write bad software. What is bad software? A complex system that doesn’t help people that much.
无法理解软件目的的开发人员将编写不良软件。 什么是不良软件？ 一个复杂的系统，对人们没有太大帮助。
When you are making decisions about software, you should guide yourself by always keeping this in mind: How we can help? You can even prioritize feature requests this way.
在做出有关软件的决定时，您应该始终牢记以下几点 ： 如何提供帮助？ 您甚至可以通过这种方式确定功能请求的优先级。
2.软件设计的目标 (2. The Goals of Software Design)
Every programmer is a designer.
每个程序员都是设计师。
When software is hard to create or modify, developers spend most of their time focusing on making things “just work,” and less time focusing on helping users. The design of software aims to make developers job as easy as possible so they can focus on what matters. You will create software that will help users and your software will continue to help them for a long time.
当难以创建或修改软件时，开发人员将大部分时间用于使事情“正常运行”，而将较少的时间用于帮助用户。 软件的设计旨在使开发人员尽可能轻松地工作，以便他们可以专注于重要的事情。 您将创建可以帮助用户的软件，并且您的软件将在很长一段时间内继续为他们提供帮助。
However, if you design a bad system, your software’s lifetime will be short.
但是，如果您设计的系统不好，则软件的寿命会很短。
This brings us to the most important goal of the software design:
这使我们达到了软件设计的最重要目标：
To design systems that can be created and maintained as easily as possible by their developers, so that they can be — and continue to be — as helpful as possible. — Max Kanat-Alexander, Code Simplicity
设计可以由其开发人员尽可能轻松地创建和维护的系统，以使它们可以(并且将继续)发挥最大作用。 — 代码简化的Max Kanat-Alexander
So there are two key points here: Your design should be easy for you and helpful for others.
因此，这里有两个关键点：您的设计应该对您来说容易并且对其他人有帮助。
3.(误)理解 (3. (Mis)understanding)
Developers who don’t fully understand their work tend to develop complex systems. It can become a vicious cycle: misunderstanding leads to complexity, which leads to further misunderstanding, and so on.
不完全了解其工作的开发人员倾向于开发复杂的系统。 它可能会变成一个恶性循环：误解会导致复杂性，这会导致进一步的误解，依此类推。
Actually, one of the best ways to improve your design skills is to be sure that you fully understand the systems and tools you are working with.
实际上，提高设计技能的最佳方法之一就是确保您完全了解要使用的系统和工具。
Understanding is the key difference between a bad developer and a good developer. — Max Kanat-Alexander, Code Simplicity
理解是好开发商与坏开发商之间的主要区别。 — 代码简化的Max Kanat-Alexander
Bad developers don’t understand what they are doing, and good developers do. It really is that simple.
不好的开发人员不了解自己在做什么，而好的开发人员则不了解他们在做什么。 真的就是这么简单。
4.简单性 (4. Simplicity)
Simplicity is the ultimate sophistication. — Leonardo da Vinci
简单是最终的复杂性。 —达芬奇(Leonardo da Vinci)
Programming is the act of reducing complexity to simplicity. A “bad developer” is just somebody who fails to reduce complexity. A “good developer” is doing everything in their power to make the code as simple as possible for other programmers.
编程是将复杂性降低到简单的行为。 “不良开发者”就是无法降低复杂性的人。 一个“优秀的开发人员”将尽一切力量使其他程序员的代码尽可能地简单。
A good developer creates things that are easy to understand so that it’s really easy to shake out all the bugs.
优秀的开发人员会创建易于理解的东西，从而很容易消除所有错误。
Now, developers are generally intelligent people and none of them likes to be treated like they are idiots. Ironically, this leads them sometimes to create things that are a bit complicated. They basically think like this:
现在，开发人员通常是聪明的人，没有人喜欢像白痴一样受到对待。 具有讽刺意味的是，这有时导致他们创建一些复杂的东西。 他们基本上是这样认为的：
“Oh, other developers will understand everything I’ve done here. I should write some clever code that is hard to understand so that they can think that I am very smart.”
“ 哦，其他开发人员会理解我在这里所做的一切。 我应该编写一些难以理解的巧妙代码，以便他们可以认为我很聪明。 ”
A mistake caused by a wrong mindset-not necessarily by a lack of programming skills. Most of the programming failures happen because of that mentality.
错误的心态导致的错误-不一定是由于缺乏编程技能。 大多数编程失败都是由于这种想法而发生的。
Showing off that you are smart doesn’t help them.
炫耀自己很聪明对他们没有帮助。
Developers who are new to your code don’t know anything about it; they have to learn.
对您的代码不熟悉的开发人员对此一无所知。 他们必须学习。
So, you should ask this question: “Do I want people to understand this and be happy, or do I want them to be confused and frustrated?”
因此，您应该问一个问题：“ 我是希望人们理解这一点并感到高兴吗？还是希望他们感到困惑和沮丧？ ”
The truth is that if other developers who read your code can understand it easily it means that you are doing good.
事实是，如果其他阅读您的代码的开发人员可以轻松理解它，则意味着您做得很好。
Complexity has nothing to do with intelligence, simplicity does. — Larry Bossidy
复杂性与智能无关，而简单则与智能无关。 —拉里·博西迪(Larry Bossidy)
The question is: “How simple do you have to be?”
问题是：“你必须变得多么简单？”
Here is your answer: Stupid, dumb simple.
这是您的答案： 愚蠢，愚蠢。
5.复杂性 (5. Complexity)
Controlling complexity is the essence of computer programming. — Brian Kernighan
控制复杂度是计算机编程的本质。 —布赖恩·克尼根(Brian Kernighan)
The source of many software failures is complexity. You start out with a simple project that can be completed in one month. Then you add complexity, and the task will take up to three months. Then you start to add features that fulfill some other purpose. Things get very complex because you expand your software purpose for no reason. The tasks will take six months.
许多软件故障的根源是复杂性。 您从一个简单的项目开始，该项目可以在一个月内完成。 然后，您增加了复杂性，该任务最多需要三个月。 然后，您开始添加满足某些其他目的的功能。 事情变得非常复杂，因为您无缘无故地扩展了软件用途。 任务将花费六个月。
But that is not the end.
但这还不是终点。
Then you take each piece of the feature and make it even more complex, and the task will take nine months. Then you start to introduce many new bugs because of the complexity in your code. Naturally, you start fixing them all without thinking how these fixes will affect other parts. At the end, when even small changes become hard. When bug fixes start to introduce new bugs, you will come to one of the most popular programming horror stories: Rewriting code from scratch.
然后，您将每一项功能都变得复杂起来，整个过程将花费9个月的时间。 然后，由于代码的复杂性，您开始引入许多新的错误。 自然地，您无需考虑这些修补程序将如何影响其他部分，便开始全部修复它们。 最后，即使很小的变化也变得困难。 当错误修复开始引入新的错误时，您将了解最流行的编程恐怖故事之一： 从头开始重写代码 。
So, how did you become a victim of this horror story? Nah, who cares. It’s better to ask: How could you avoid being a victim?
那么，您是如何成为这个恐怖故事的受害者？ 罗，在乎。 最好问：您如何避免成为受害者？
Well, it is simple. First, you will exactly know your software purpose and its definition. Second, you will be as simple as possible in every piece of code you write. Third, when a new feature or change request comes to the discussion table, you will evaluate them based on your software purpose and question them.
好吧，这很简单。 首先，您将完全了解您的软件用途及其定义。 其次，您编写的每段代码都将尽可能地简单。 第三，当讨论表中出现新功能或变更请求时，您将根据软件目的对它们进行评估并提出问题。
As a developer, your first behavior should be resistance to (unnecessary) change. This will prevent you from adding unnecessary codes into your software. When you are convinced that this change is a need, then you can implement it.
作为开发人员，您的首要行为应该是抵抗(不必要的)变更。 这样可以防止您在软件中添加不必要的代码。 如果您确信需要进行此更改，则可以实施它。
There are many factors that will increase complexity but those are the most popular ones. Aside from everything, there is only one rule that you should follow:
有许多因素会增加复杂性，但这些因素是最受欢迎的因素。 除了所有内容，您只应遵循一条规则：
Your main purpose is to control complexity, not to create it.
您的主要目的是控制复杂性，而不是创建复杂性。
6.保养 (6. Maintenance)
Maintenance is one of the most important things in software development. Unfortunately, developers usually ignore how important it is. Quick coding and fast shipping look more important than code maintenance. This is the point where they make a mistake — ignorance of future code maintenance.
维护是软件开发中最重要的事情之一。 不幸的是，开发人员通常忽略它的重要性。 快速编码和快速发货看起来比代码维护更重要。 这就是他们犯错的地方-对未来代码维护的无知。
There will always be some implementation of changes. Not only you have to implement them, but you also have to maintain them over time. As a developer, thinking about future maintenance of changes is one of your main responsibilities.
总会有一些变更的实现。 不仅您必须实施它们，而且还必须随着时间的推移对其进行维护。 作为开发人员，考虑将来维护更改是您的主要职责之一。
All changes require maintenance.
所有更改都需要维护。
Simplicity and complexity are the two main factors that affect code maintenance. The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces. The effort of maintenance is proportional to the complexity of the software.
简单性和复杂性是影响代码维护的两个主要因素。 任何软件的易于维护都与单个软件的简单性成正比。 维护工作量与软件的复杂度成正比。
The one rule that you should follow about maintenance is:
关于维护，应遵循的一条规则是：
It is more important to reduce the effort of maintenance than it is to reduce the effort of implementation.
减少维护工作比减少实施工作更为重要。
7.一致性 (7. Consistency)
Consistency is a big part of simplicity. If you do something one way in one place, do it that way in every place. For example, if you name a variable thisIsVariable, then all of your variables should be named that way (otherVariable, anAnotherVariable, etc. not other_variable). – Max Kanat-Alexander, Code Simplicity
一致性是简单性的重要组成部分。 如果您在一个地方以一种方式做某事，请在每个地方以这种方式做。 例如，如果您将变量命名为thisIsVariable，则应以这种方式命名所有变量(otherVariable，anAnotherVariable等，而不是other_variable)。 – 代码简化的Max Kanat-Alexander
Code that isn’t consistent becomes harder to understand. Don’t keep forcing developers to relearn the way your system works every time they look at a new piece of it.
不一致的代码变得更难以理解。 不要一直强迫开发人员在每次查看新系统时重新学习系统的工作方式。
In any team sport, the best teams have consistency and chemistry. — Roger Staubach
在任何团队运动中，最好的团队都具有一致性和化学性。 —罗杰·斯托巴赫
8.优先排序 (8. Prioritizing)
How do you make decisions about your software?
您如何决定软件？
When you face many possible directions, how do you decide which option is the best? What to focus on and which features you should implement?
当您面对许多可能的方向时，如何确定最佳选择？ 要重点关注什么以及应该实现哪些功能？
To answer those questions, there are three important factors that will help you make a better decision. This equation is explained very well in the Code Simplicity book:
要回答这些问题，有三个重要因素可以帮助您做出更好的决定。 该等式在“ 代码简单性”书中得到了很好的解释：
The desirability of a change (D): How much do you want that change to happen?
变更的可取性(D)：您希望变更发生多少？
The value of a change (V): How much value does the change offer? How much does it help your users?
变更的价值(V)：变更提供多少价值？ 它对您的用户有多大帮助？
The effort required to perform the change (E): How much work will you need to do to accomplish this change?
进行更改所需的工作量(E)：要完成此更改，您需要做多少工作？
The equation is simple: D=V/E
公式很简单： D = V / E
The desirability of any change is directly proportional to the value of the change and inversely proportional to the effort involved in making the change. – Code Simplicity
任何更改的可取性与更改的值成正比，而与进行更改所涉及的工作成反比 。 – 代码简单
When you prioritize your work, you should follow this rule:
在确定工作的优先级时，应遵循以下规则：
The changes that will bring you a lot of value and require little effort are better than those that will bring little value and require a lot of effort.
与那些带来很少价值和需要大量努力的变更相比，那些将带来大量价值和需要很少努力的变更要好得多。
9.解决问题 (9. Solving Problems)
The first step is understanding. Know exactly what is being asked. Most hard problems are hard because you don’t understand them. Write down your problem and try to explain it to someone else.
第一步是理解。 确切知道要问什么。 大多数棘手的问题都很棘手，因为您不了解它们。 写下您的问题，然后尝试向他人解释。
If you can’t explain something in simple terms, you don’t understand it. — Richard Feynman
如果您不能用简单的术语解释某些内容，那么您将无法理解。 —理查德·费曼(Richard Feynman)
The second step is planning. Don’t take action. Sleep on it. Give your brain some time to analyze the problem and process the information but don’t spend too much time on planning.
第二步是计划。 不要采取行动。 睡吧 给您的大脑一些时间来分析问题并处理信息，但不要在规划上花费太多时间。
Think before acting.
演戏前要三思。
The third step is dividing. Don’t try to solve one big problem. When you look at the problem as a whole, it can scare you. Divide it into smaller tasks and solve each sub-problem one by one. Once you solve each sub-problem, you connect the dots.
第三步是划分。 不要试图解决一个大问题。 当您从整体上看问题时，它可能会吓到您。 将其划分为较小的任务，并逐个解决每个子问题。 一旦解决了每个子问题，就可以连接点。
10.足够好就可以了 (10. Good enough is fine)
“Perfect is the enemy of good.” — Voltaire
“完美是善的敌人。” —伏尔泰
Whether creating a new project or adding a feature to existing system developers tend to plan everything out in detail from the beginning.
无论是创建新项目还是向现有系统开发人员添加功能，开发人员都倾向于从一开始就详细计划所有事情。
They want the first version to be perfect. They don’t focus on the problem they will solve and how their software will help people.
他们希望第一个版本是完美的。 他们不关注解决的问题以及他们的软件如何帮助人们。
They start by thinking of every small detail they could think about. Then assumptions and predictions come along followed by “What if” sentences. They have to predict the future because they were now so captivated by the imagination of the project in their mind and their project has to be as perfect as they imagined it.
他们从思考所有可能想到的小细节开始。 然后是假设和预测，后面是“假设”句子。 他们必须预测未来，因为他们现在已经对项目的想象力着迷了，他们的项目必须像他们想象的那样完美。
Actually, they are not aware of what’s waiting for them and how much it will cost them by chasing perfection.
实际上，他们并不知道正在等待什么，以及追求完美会花费多少成本。
Let me tell you what will happen:
让我告诉你会发生什么：
- You will be writing code that isn’t needed 您将编写不需要的代码
- You will increase complexity by adding unnecessary codes 您将通过添加不必要的代码来增加复杂性
- You will be too generic 你太普通了
- You will be missing deadlines 您将错过最后期限
- You will be dealing with many bugs caused by the complexity 您将处理由复杂性引起的许多错误
Do you want this to happen? I guess no.
您是否希望这种情况发生？ 我觉得不是。
What you should instead?
您应该怎么做呢？
Start small, improve it, then extend.
从小处着手，加以改进，然后再扩大。
The incremental design should be your guide. Here is how you would use it to design a calculator:
增量设计应作为您的指导。 这是使用它来设计计算器的方式：
- Plan a system that does only addition and nothing else. 计划一个仅执行加法操作而不执行其他操作的系统。
- Implement it. 实施它。
- Improve the now-existing system’s design so you can add other operations also. 改进现有系统的设计，以便您还可以添加其他操作。
- Plan subtraction and repeat step 2 and 3. 计划减法并重复步骤2和3。
- Plan multiplication and repeat step 2 and 3. 规划乘法并重复步骤2和3。
- Plan division and repeat step 2 and 3. 计划划分并重复步骤2和3。
11.预测 (11. Predictions)
“A prediction is simply a forecast that something will happen in the future. It could be factual and based on some kind of objective data or it could be based on an assumption.”
“预测仅仅是对未来会发生的预测。 它可以是事实的，并基于某种客观数据，也可以基于假设。”
When faced with the fact that their code will change in the future, some developers attempt to solve the problem by designing a solution so generic that (they believe) it will accommodate to every possible future situation. – Code Simplicity
当面对他们的代码将来会更改的事实时，一些开发人员试图通过设计一种通用的解决方案来解决该问题(他们相信)，以使其能够适应每种可能的未来情况。 – 代码简单
Being too generic involves a lot of code that isn’t needed.
过于通用会涉及很多不需要的代码。
You can’t predict the future, so no matter how generic your solution is, it will not be generic enough to satisfy the actual future requirements you will have. Most probably, this time will never come and the code you wrote to solve future problems will increase complexity, make it hard to change the pieces of code and eventually it will become a burden that may destroy your software.
您无法预测未来，因此，无论您的解决方案有多通用，它的通用性都不足以满足您将来的实际需求。 很有可能，这一次永远不会到来，您为解决未来问题而编写的代码将增加复杂性，使更改代码段变得困难，最终将成为可能破坏您软件的负担。
Don’t predict to future. Be only as generic as you know you need to be right now.
不要预测未来。 只知道您现在需要的通用性。
12.假设 (12. Assumptions)
What is the assumption?
假设是什么？
“An assumption is something that you accept as true or suppose to be true, although you have no conclusive proof.”
“ 尽管您没有确凿的证据，但 假设 是您接受为真或假设为真的东西。”
One of the great killers of a software project is assumptions. Let’s see how an assumption can kill a software project.
假设是软件项目的最大杀手之一。 让我们看看一个假设如何杀死一个软件项目。
A developer knows that they have to develop a system to do X. Then they think that the system will require them to do Y in the future, and they implement Y as well. They write thousands of lines of code to design Y.
开发人员知道他们必须开发一个执行X的系统。然后，他们认为该系统将来将要求他们执行Y，并且他们也实现了Y。 他们编写了数千行代码来设计Y。
In the future, the developer realizes that the current requirements are completely different than what they thought. But now, the software has unnecessary codes that make it hard to throw away because everything is intertwined. It takes months to refactor the code and now they think to rewrite the whole software from scratch which will cause them to lose months.
将来，开发人员意识到当前的需求与他们的想法完全不同。 但是现在，该软件具有不必要的代码，因为所有内容都交织在一起，因此很难扔掉。 重构代码需要几个月的时间，现在他们认为从头开始重写整个软件，这将使他们损失几个月的时间。
To avoid being a victim like this developer, follow this simple rule:
为了避免像这样的开发人员那样成为受害者，请遵循以下简单规则：
Code should be designed based on what you know now, not on what you think will happen in the future. — Code Simplicity
代码的设计应基于您现在所知道的，而不是您认为将来会发生的事情。 — 代码简单
13.停止重新发明 (13. Stop Reinventing)
If, for example, you invent your own garbage collector when a perfectly good one exists, you’re going to be spending a lot of time working on the garbage collector, when you could just be working on your software.
例如，如果您在存在一个非常好的垃圾收集器时发明了自己的垃圾收集器，那么您将花大量时间在垃圾收集器上工作，而您可能只是在开发软件。
The only times it’s okay to reinvent the wheel is when any of the following are true:
只有在以下任一情况成立时，才可以重新发明轮子：
- You need something that doesn’t exist yet 您需要尚不存在的东西
- All of the existing “wheels” are bad technologies or incapable of handling your needs 现有的所有“轮子”都是不好的技术或无法满足您的需求
- The existing “wheels” aren’t being properly maintained 现有的“轮子”没有得到适当的维护
Simple rule:
简单规则：
Don’t reinvent the wheel.
不要重新发明轮子。
14.抵抗 (14. Resistance)
As a developer, your first reaction to changing requests should be “NO’’.
作为开发人员，您对更改请求的第一React应该是“否”。
Always resist adding more code, more features until you are convinced that they are required and there is a need to implement them. Because unnecessary changes will increase defects in your software.
始终不要添加更多的代码，更多的功能，直到您确信它们是必需的并且有必要实现它们。 因为不必要的更改会增加软件的缺陷。
How can you know that there is a need for them?
您怎么知道他们有需要？
Go back and remember your software purpose. Then remember the simple equation in prioritizing section.
返回并记住您的软件用途。 然后记住优先级部分中的简单方程式。
From: rsc@plan9.bell-labs.com (Russ Cox)Subject: Re: [9fans] design clairvoyance & the 9 way
Date: Thu, 8 May 2003 04:05:31 GMT
> What does tomorrow's unix look like?
I'm confident that tomorrow's Unix will look like today's Unix, only cruftier.
Russ15.自动化 (15. Automation)
Don’t spend your time on repetitive tasks. Set them up and forget about them. They can work while you are sleeping. When you realize that you are doing something again and again, just remember this rule:
不要把时间花在重复性的工作上。 设置它们，然后忘记它们。 他们可以在您睡觉时工作。 当您意识到自己一次又一次地做某事时，请记住以下规则：
If you can automate it, automate it.
如果可以自动化，请使其自动化。
16.代码测量 (16. Code measurement)
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
用代码行衡量编程进度就像按重量衡量飞机建造进度。
Measuring programming progress by lines of code is like measuring aircraft building progress by weight.— Bill Gates
用代码行衡量编程进度就像按重量衡量飞机建造进度。 - 比尔盖茨
I see developers who measure their software quality based on code lines. They think that more code lines mean that they are doing a great job. The software contains hundreds of thousands of lines of code, which means the software they work on is so big.
我看到开发人员根据代码行来衡量其软件质量。 他们认为更多的代码行意味着他们做得很好。 该软件包含成千上万行代码，这意味着他们使用的软件是如此之大。
The question that pops up here is: Is it really that big, or there is something wrong there?
这里出现的问题是：真的那么大，还是那里出了点问题？
The answer is that most probably there is something wrong with their design. Most of the simple solutions don’t require a lot of code. You can achieve simplicity with a little bunch of code and solve the problem.
答案是他们的设计很可能有问题。 大多数简单的解决方案不需要很多代码。 您可以用一小段代码来实现简单性并解决问题。
I’m not saying that fewer lines of code is always better. While you want to avoid having less code, you can easily fall in a trap that will cause you to write clever code that is hard to understand for others. You should find a balance.
我并不是说更少的代码行总是更好。 虽然您希望避免使用更少的代码，但是您很容易陷入陷阱，这将导致您编写难以为他人理解的聪明代码。 您应该找到一个平衡点。
The optimum code is a small bunch of code that is easy to understand, easy to read.
最佳代码是一小堆易于理解，易于阅读的代码。
17.生产力 (17. Productivity)
How do you measure your productivity?
您如何衡量自己的生产力？
By writing more lines of code or by throwing hundreds of lines of code away?!
通过编写更多的代码行还是扔掉数百行代码？
Your main goal should be keeping your code base as small as possible. The question is not “How can I write more code?” rather it should be “How can I remove more code?”
您的主要目标应该是使代码库尽可能小。 问题不是“我如何编写更多代码？” 而是应该为“如何删除更多代码？”
“One of my most productive days was throwing away 1000 lines of code.” — Ken Thompson
“我最有效率的一天之一就是扔掉了1000行代码。” —肯·汤普森
18.测试 (18. Testing)
When should you add logging and error handling to your project?
什么时候应该在项目中添加日志记录和错误处理？
You should add logging in a very early stage. This will help you to find the problem easily and save your time.
您应该在早期阶段添加日志记录。 这将帮助您轻松找到问题并节省时间。
I see many mistakes when it comes to testing code. Let me give you an example. There were two conditions, a simple if-else block. The developer gave input to the software which will enter inside the if block. They tested it and committed code to source control. Done!
在测试代码方面，我看到许多错误。 让我举一个例子。 有两个条件，一个简单的if-else块。 开发人员将输入输入到软件，该软件将输入到if块中。 他们对其进行了测试，并将代码提交给了源代码管理。 做完了！
But what about the else block? When the software was shipped to production, that caused a lot of errors. When you test your code, you must execute all new lines at least once and you should start to test parts before the whole.
但是else块呢？ 当软件交付生产时，这会导致很多错误。 测试代码时，必须至少执行所有新行一次，并且应该在整体之前开始测试部分。
When you have a bug, first you should reproduce it. You shouldn’t guess the source of the bug and apply fixes based on your assumption. Most probably, you will be wrong. You should see it with your own eyes before applying the fix.
当您遇到错误时，首先应该重现它。 您不应该猜测错误的根源，而应该根据自己的假设来应用修复程序。 很可能您会错。 在应用此修复程序之前，您应该亲眼看到它。
You should be reliable. When other developers in your team see that you committed new code to source control, everyone should know that your code is tested, and works.
您应该可靠。 当团队中的其他开发人员看到您将新代码提交到源代码管理时，每个人都应该知道您的代码已经过测试并且可以正常工作。
Untested code is the code that doesn’t work.
未经测试的代码是无效的代码。
19.(不足)估算 (19. (Under)Estimation)
Developers’ estimation sucks.
开发人员的估计很糟糕。
Usually, they underestimate things rather than overestimate them. They underestimate the time and effort required to develop a small amount of code or a feature. In the end, this underestimation leads to missing deadlines.
通常，他们低估事物而不是高估事物。 他们低估了开发少量代码或功能所需的时间和精力。 最后，这种低估导致缺少最后期限。
The solution: Break the big thing into smaller things. The smaller it is, the easier it is to estimate. You’re probably still going to get it wrong, but you’ll be a lot less wrong than if you estimated a big project.
解决方案：将大事分解为小事。 它越小，估计就越容易。 您可能仍然会弄错它，但是与估计一个大项目相比，您的错误要少得多。
Remember:
记得：
Everything takes longer than you think.
一切花费的时间都超出您的想象。
20.避免重写 (20. Running Away From Rewriting)
I believe that when you embrace the fundamental principles of software development mentioned in that article, you won’t come to this point. However, if, somehow you make these mistakes and find yourself thinking about rewriting your code, here is the main thing that you should know:
我相信，当您接受该文章中提到的软件开发的基本原理时，您将不会想到这一点。 但是，如果以某种方式犯了这些错误并发现自己正在考虑重写代码，那么这是您应该知道的主要知识：
Rewriting code is often a developer delusion, not the solution in most cases.
重写代码通常是开发人员的错觉，而不是大多数情况下的解决方案。
Why is it a delusion?
为什么是妄想？
Well, because it’s harder to read code than to write it. This is why it is so hard to reuse code. This is why our subconscious mind whispers to us “Throw it away and start over” when we read another developer’s code.
好吧，因为阅读代码比编写代码更难 。 这就是为什么很难重用代码的原因。 这就是为什么当我们阅读其他开发人员的代码时，我们的潜意识会低声对我们说“ 扔掉并重新开始 ”。
There are many cases that you should consider to rewrite your code from scratch and you can read them here. But, here is simple advice for you:
在许多情况下，您应该考虑从头开始重写代码，您可以在这里阅读它们。 但是，这是为您提供的简单建议：
Refactoring should be the first option.
重构应该是第一个选择。
21.文档和评论 (21. Documentation and Commenting)
One of the common misconceptions about commenting is that developers add comments that say what code is doing. This is wrong. That should be obvious from reading the code. If it’s not obvious, it means that it is not readable and it should be made simpler.
关于注释的常见误解之一是开发人员添加了注释，以说明代码在做什么 。 错了 从阅读代码中应该显而易见。 如果不明显，则表示它不可读，应使其更简单。
When you can’t make the code simpler then you should add the comment to explain this complexity.
如果您无法简化代码，则应添加注释以解释这种复杂性。
The real purpose of comments is to explain “WHY” you did something, not “WHAT” the code is doing. If you don’t explain this, other programmers may be confused and when they go to change your code they might remove important parts of it. – Code Simplicity
评论的真正目的是要解释“为什么”做某事，而不是“做什么” 。 代码正在做。 如果您不解释这一点，其他程序员可能会感到困惑，当他们去更改您的代码时，他们可能会删除其中的重要部分。 – 代码简单
Write a comment to explain “WHY”, not to explain “WHAT”.
写评论以解释“为什么”，而不是解释“什么”。
Another thing is documenting. It is important to have documentation to explain your software’s architecture and every module and components. This is required to see the high-level picture of your software.
另一件事是记录。 重要的是要有文档来解释软件的体系结构以及每个模块和组件。 要查看软件的高级图片，这是必需的。
When a new developer joins your team, it will be easier for them to understand the software as a whole. When developers don’t have any clue about other parts of the software, they could easily make a mistake in their own part which can affect other parts also.
当新的开发人员加入您的团队时，他们将更容易理解整个软件。 当开发人员对软件的其他部分一无所知时，他们很容易在自己的部分中犯一个错误，这也会影响其他部分。
22.拣配技术(工具，库等) (22. Picking Technologies (Tools, Libraries, etc.))
First things first, always remember this rule:
首先，请始终记住以下规则：
Don’t depend on external technologies. But when you have to do so, try to reduce your dependency on them as much as you can.
不要依赖外部技术 。 但是，当您必须这样做时，请尽量减少对它们的依赖 。
Why is that? Because they are another common source of complexity. They can kill your active development and make everything even harder.
这是为什么？ 因为它们是复杂性的另一个常见来源。 他们会扼杀您的积极发展，使一切变得更艰难。
When you are dependent so much on external technologies, you are not free. What if there is a major bug in that technology? You have to wait for the developers to fix that bug and if this technology is in the center of your project basically you are stuck, you can’t move forward. So that’s why it is so important to pick the right technologies for your project.
当您非常依赖外部技术时，您就没有自由。 如果该技术存在重大错误该怎么办？ 您必须等待开发人员修复该错误，并且如果该技术在您项目的核心位置上，您基本上会陷入困境，那么您将无法前进。 这就是为什么为您的项目选择合适的技术如此重要的原因。
There are a few factors you should consider before you start using some technology:
在开始使用某些技术之前，应考虑一些因素：
- Is there active development behind it? 它背后有积极的发展吗？
- Will it continue to be maintained? 它会继续保持下去吗？
- How easy is it to switch away from? 切换离开有多容易？
- What does the community say about it? 社区对此有何评价？
If you can find the right answer these questions, you can reduce the risk of picking the wrong technology.
如果您能找到正确答案这些问题，则可以降低选择错误技术的风险。
23.自我发展 (23. Self-Development)
Keep learning. Try out different programming languages and tools, read books on software development. They will give you another perspective. Every day small improvements will make a real difference in your knowledge and skills.
保持学习。 试用不同的编程语言和工具，阅读有关软件开发的书籍。 他们会给您另一个角度。 每天都有细微的改进会真正改变您的知识和技能。
Be open-minded. Don’t be obsessive about one technology. Use the required technology to solve a specific problem. Don’t be in the unnecessary discussion like Microsoft vs Linux :)
心胸开阔。 不要迷恋一种技术。 使用所需的技术来解决特定的问题。 不要像Microsoft vs Linux那样进行不必要的讨论：)
Know that every specific problem has its own specific solution.
知道每个特定的问题都有其特定的解决方案。
24.别当英雄 (24. Don’t be a hero)
A lot of times it’s better to be a quitter than a hero. As Jason Fried explains,
很多时候，戒烟要比英雄强。 正如杰森·弗里德(Jason Fried)所说，
For example, let’s say you think a task can be done in two hours. But four hours into it, you’re still only a quarter of the way done. The natural instinct is to think, “But I can’t give up now, I’ve already spent four hours on this!”
例如，假设您认为一项任务可以在两个小时内完成。 但是经过四个小时，您仍然只完成了四分之一。 自然的本能是想：“但是我现在不能放弃，我已经花了四个小时了！”
So you go into hero mode. You’re determined to make it work (and slightly embarrassed that it isn’t already working). You grab your cape and shut yourself off from the world. – Jason Fried
因此，您进入了英雄模式。 您下定决心要使其工作(并且有点尴尬的是它尚未工作)。 您抓住斗篷，将自己与世隔绝。 – 杰森·弗里德
Don’t be obsessive. Know when to quit. Don’t hesitate to ask for help.
不要沉迷。 知道何时退出。 不要犹豫，寻求帮助。
25.不要问问题…寻求帮助 (25. Don’t Ask Questions… Ask For Help)
When you have something to implement and you are not sure about the solutions, don’t ask others how to so it …at least not immediately. Instead, try anything and everything you can think of. This is more important the less comfortable you are with a concept or language.
当您需要实施某些解决方案并且不确定解决方案时，请不要问别人如何解决……至少不要立即这样做。 相反，尝试任何您能想到的事情。 您对概念或语言的适应程度越低，这一点就越重要。
When you can’t think of anything on your own, search! Find answers and try them out. Modify those answers, see if you can understand why they work, adapt them to your code.
当您无法独自思考时，请搜索！ 找到答案并尝试一下。 修改这些答案，看看您是否能理解它们的工作原理，并使其适应您的代码。
…But always seek advice.
…但是请务必咨询。
When you have tried everything, and preferably after you have a working solution, now is the best time to seek advice. Look to peers and senior developers to review your code.
当您尝试了所有步骤之后，最好是在找到可行的解决方案之后，现在是寻求建议的最佳时机。 请同行和高级开发人员来检查您的代码。
I tried to explain the fundamentals of a good developer mindset in this article. I used some part from Code Simplicity book which has a big impact on my thinking process as a developer. When I read this book, there was a lot of moment that I reacted “ohh I did this mistake, I did that too.” I mentioned some important parts of the book and combine them with my experience.
我试图在本文中解释良好的开发人员心态的基础。 我使用了《代码简化》一书中的部分内容，这对我作为开发人员的思考过程具有重大影响。 当我读这本书时，我有很多时间做出React：“哦，我犯了这个错误，我也犯了这个错误。” 我提到了本书的一些重要部分，并结合了我的经验。
I strongly recommend you to read Code Simplicity from Max Kanat-Alexander.
我强烈建议您阅读Max Kanat-Alexander的Code Simplicity 。
Thanks for reading! I hope this guide helped you out!
谢谢阅读！ 希望本指南对您有所帮助！
You can read more of my articles at https://huseyinpolatyuruk.com.
你可以阅读更多我的文章 //：HTTPS huseyinpolatyuruk.com 。
订单15分钟内支付
扫一扫
951
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
