信息来源：阮一峰每周分享
Fight for Pareto 遵守帕累托原则
Pareto’s law states that 80% of the results come from 20% of features (effort) of your application. Bear this in mind when planning the next scrum/delivery.
帕累托原则指出20%的因素影响着80%的结果，在计划下一次交付时要记住这一点。
The best engineers are those who can estimate the effort of new requirements and they are the only with enough information to refuse the 80% that is not in the optimal next scope.
最好的工程师是那些可以估算新需求的人，只有他们才拥有足够的信息来拒绝80%对结果影响不大的非重要因素。
Own it! This is not the army, they pay you to think and take decisions and responsibility so speak up if you consider the requirements proposed are superfluous.
牢记帕累托原则吧！提需求的不是军方，他们付钱来让你思考并做决定和负责任，所以如果你认为一些需求是多余的，那就大声说出来吧。
The worst code you’ve ever written is the code that is no longer used. Is called YAGNI (You Are Not Gonna Need It).
你写出的最垃圾的代码是那些不再使用的代码，我们称之为YAGNI（You Are Not Gonna Need It）
The best code you’ve ever written is the code you didn’t write, simply because it’s the only that never fails.
你写出的最牛逼的代码是你还没写出来的那些代码，很简单，因为只有它们是没有任何错误的。
Prioritize 优先级
There’s something I call fixing a bug by sedimentation (fixing it by accumulation of other bugs) or by erosion (client changed his mind). These are good examples where prioritization and waiting saved you from doing a worthless job.
有一些我称之为通过降级（就是通过积累其他bug来修复它）或者侵蚀（客户改变了注意）来修复bug。有很多好的例子来证明按优先级做事和等待一段时间能帮助你避免做无用功。
Minimalism is not about not doing things but about focusing first in the most important.
极简主义不是不做事情，而是着重做最重要的事情。
Perfect is enemy of good “完美”是”不错”的敌人
Look for perfection, but not yet. Iteration is that friend that gives you the right advises at the right time.
追求完美，但是不要太过头。迭代能够在正确时间给你正确建议。
First do it, then do it right, then do it better.
先开始做，然后再考虑做对做好。
Engineers like to think that the world could be designed, however Nature shows the opposite. Any sufficiently complex system cannot be built out of design, it has to be evolved.
工程师喜欢认为世界是可以设计的，但是大自然显然站在了对立面。任何足够复杂的系统都不能在设计之外构建，必须保持进化。
Consider everything as a work in progress and don’t panic if it doesn’t work right yet, remember Mosher’s law, if everything worked right, you’d be out of a job.
将一切视为正在进行的工作，如果它还不能正常工作，请不要惊慌，记住Mosher定律，如果一切正常，你就会失业。
Kill the baby 扼杀萌芽
Kill it. The sooner the better. Don’t be afraid of throwing to the rubbish a project you’ve working on last months.
扼杀萌芽，越早越好。不要害怕将你上个月工作的项目丢到垃圾桶。
When you start from scratch, innovation comes organically inspired by previous experiences.
当你从头开始时，创建会受到之前经验的启发。
Evaluate your work constantly. This is what the book Lean Startup is all about, make your MVP (Minimum Viable Prototype) and validate it, if it doesn’t fit, kill it, you will already learned from it.
经常评估你的工作，这也是Learn Startup这本书的主要内容，打造你自己的MVP (Minimum Viable Prototype)并且对它验证，即使这个不合适，至少你已经从中吸取到了经验。
Fail fast, learn soon.
失败地块，学习地也快。
Add value 增加价值
Nobody can know much of everything.
没有人能够了解一切。
Try to ask yourself how can you add value to your team. What do they need the most? Somebody who is an expert with scalability?, Somebody who knows every detail of the programming language? Somebody more focused in the product? A coordinator?
试着问问自己，如何为团队增加价值，他们最需要什么？有可扩展性的专家吗？有谁知道编程语言的每一个细节？有人更专注于产品？协调员？
Every team is different so you have to adapt and choose, try to analyse the strengths and weakness of both you and your team.
每个团队都是不同的，所以你必须适应和选择，试着分析你和你的团队的优势和劣势。
Learn to love a particular thing and master it. Try to position yourself, it’s like a brand, you like products that fulfill your needs not those who do a lot of things you already do by yourself.
学会爱一个特定的东西并掌握它。尝试定位自己，就像一个品牌，你喜欢满足你需求的产品，而不是大部分需求都是你自己来完成的产品。
Of course it’s easier to get along well with people with whom you share common language but the real power is on complementary people, remember the A-team!
当然，与你有共同语言的人相处会很容易，但真正的有用的事能够形成互补的人，请记住A团队！
Basics, first 基础是首要
In some late point of our life we realise about the importance of basics. It’s normally old people who claim they have gone back to basics. Don’t be a fool and don’t wait to realise about that so late, bet for basics, first.
在我们生命的某个晚期，我们意识到基础知识的重要性，通常都是老人在说他们需要重新重视基础知识。不要成为傻瓜，也不要到太晚的时候才意识到基础知识的重要性，你应该从一开始就重视基础知识。
There are very valuable concepts in CS (Computer Science) and the good thing is that you can apply them to every new design. You should try always a top-down thinking starting from them.
在计算机科学中有很多有价值的概念，而且有一点好处是你可以将这些概念应用到你所有新的设计中取。你应该从这些概念出发，保持从上到下的思考方式。
Borrowing an old saying, the three most important things in software development are: architecture, architecture and architecture, in that order.
借用一句古话，软件开发中的最重要的三件事是：架构，架构，还是架构。
Some examples of basics are: Separation of concerns, Systems engineering theory, GOF design patterns, GRASP responsability patterns, SOLID principles, Cleancode smells & heuristics, Agile guidelines, Algorithmia, Data structures, HTTP specification…
一些基础知识列举如下：关注点分离，系统工程理论，GOF设计模式，GRASP责任模式，SOLID原则， Cleancode smells & heuristics，敏捷指南，算法，数据结构，HTTP规范。。。。
For example before you start digging into the details of how to use an specific unit test framework Jasmine, JUnit, Mocha… start learning in how to write testable code (for example isolating stateless code of your application and reducing the coupling between components).
比如，在开始深入研究如何使用特定单元测试框架Jasmine，junit，Mocha的细节之前，学习怎样编写可测试的代码（例如，隔离应用程序的无状态代码并减少组件之间的耦合）。
Think different 差异化思考
Simple is harder than complex, minimalism requires a lot of creativity in order to find new ways of doing more with less.
简单比复杂更难，极简主义需要很多的创新来以简克繁。
Technical Skill is the mastery of complexity, while Creativity is the master of simplicity.
技术技能是复杂性的解决方案，而创造力是极简的源泉。
Creativity is intelligence having fun! so enjoy the opportunity.
创造力是充满乐趣的智慧！所以享受创造力带来的这个享受机会吧。
So don’t focus on working more, but in working less but smartly, Think! about your work, turn off the autopilot, leave the comfort zone and take control.
所以，不要一直想着干得更多，而是聪明得干得更少，认真思考一下你得工作，关掉自动驾驶，将舒适性调为0后，自己接手控制。
And hey! Don’t be shy, it takes guts to change the status quo. But remember, the world you are living in is made by people no smarter than you are, they just believed it was possible.
嘿，不要害羞，改变是需要勇气的。但是请记住，构成这个世界的人并不比你更聪明。他们只是相信这是可能的。
Of course people will think you are a weirdo sometimes because the things you try are different, but you can’t be a leader if you are not an innovator.
当然，当你尝试一些不同的事情时，他们会觉得你是怪物，但是不创新的话你永远不可能称为引领者。
For example I’m sure every one of us has thought in some point that his company is losing too much time in meetings where you discuss about nothing. So Jeff Bezos, Founder and CEO of Amazon, has a particular and apparently a weird way to conduct meetings in his company. When all the attendants arrive to the meeting room they have 30 minutes to read the report of the meeting IN STRICT SILENCE. After that the meeting can start.
比如，我敢肯定我们每个人都有这样想过，公司浪费太多时间在那些竟是什么也没讨论出来的会议上。所以亚马逊的创始人兼CEO杰夫贝索斯就他们公司产品会的议立了一条看起来明显很奇怪的规则。当所有参会者到达会议室后，花30分钟时间安静阅读一下会议报告，然后才开始会议。
Synthesise 合成
We have to write code for humans, not machines, and synthesis is the key of communication.
我们写的代码是给人看的，不是机器，所以综合是沟通的关键。
A good example is the Pascal’s quotation “If I Had More Time, I Would Have Written a Shorter Letter”.
一个很好的例子是Pascal的引文“如果我有更多的时间，我会写一封更短的信”。
Try to keep methods as short as possible, classes with a single responsibility, few parameters, avoid redundant comments… The work is finished when you have nothing to take away.
尽量保持方法尽可能短，只有一个责任的类，几个参数，避免多余的注释……当你没有任何东西可以去掉时，工作就完成了。
Keep it plain 保持清醒
In software programming you can solve any problem by adding another layer of indirection, except the problem of too much indirection. This is true, and it means that we have to find balance in the complexity of our designs.
在软件编程中，你可以通过添加另一层间接来解决任何问题，但是这会引起中间层过多的问题。确实是的，这意味着我们必须在设计的复杂性中找到平衡。
Abstraction is good, it allows us to create a new semantic level in which one can be absolutely precise. However, in some cases like refactoring we have to understand the big picture and it makes everything harder.
抽象化是好，它允许我们创建一个新的语义级别而且可以足够精准，但是在某些情况下，我们需要了解整个项目工作流程，这让一切变得难以理解。
This is why we have to look for the natural points where we can make the division and try to understand the different possible trade-offs.
这就是为什么我们需要寻找可以进行划分的自然点，并尝试理解不同的权衡。
Examples of that are: Root-Leaf paradigm in Domain Model. Controller/Tools paradigm, High Cohesion/Low Coupling principle, plain RESTful APIs…
这方面的例子是：领域模型中的根叶范式。控制器/工具范例，高内聚/低耦合原理，简单的RESTful API ……
Clean kipple
There’s a concept named kipple that refers to all those things we keep but we never use. Our homes are full of it, so are our codebases. For example, legacy methods we are afraid to delete, just-in-case libraries we will never need, out of date comments…
有一个名为kipple的概念，指的是我们保留但我们永远不会使用的所有东西。我们的家里充满了这种东西，我们的代码库也是如此。我们害怕删除之前遗留的代码，我们永远不会使用的所谓的以防万一的库，过时的注释。。。
It’s only human nature to complicate so we have to enforce ourselves to simplify. This is a process we have to follow periodically, identify the kipple and destroy it.
人性就是复杂的，所以我们需要强迫自己简化。这是我们必须遵循的过程，识别kipple并清理掉它。
Minimalism: it’s all about avoiding distractions so that we can focus in the important things.
极简主义：一切都是为了避免分心，以便我们可以专注于重要的事情