Hello, I'm Zheng Ye, columnist "10x programmer Work Act," the fire chief architect currency net.
Programmers are a busy professional, associated with this career together phrases are usually busy, overtime, late at night, fatigue, sub-health ...... when busy has become the main theme of "efficiency" of the term naturally surfaced .
However, programmers programming efficiency is determined by the ability to do? The answer is "not necessarily."
Over the years, I have been studying one thing: why the master programmer, you can take into account N times the average person's work, but also methodically? They work exactly with what law? According to my observations and summary, they are often not open around the following four working principles.
1. Begin with the End
exploded task 2.
3. Communication feedback
4. Automation all
Begin with the End
DoD
DoD (Definition of Done, complete definition), it is easy to see from the name, it is to solve common software development "done" problem students. DoD itself is not complicated, it is to tell us how to be completed, because of the ambiguity as to minimize waste caused.
Since it is a DoD understand the difference to make up the practice, then it should play a role in the collaborative work between people. The most frequent approach is to determine the DoD good in the team. such as:
Properties developed, expressed through a demand for clarification developers, functional design, coding, unit testing, acceptance testing by the staff, ensure that the code can be deployed in a state, the relevant documents had been prepared. Developed, it represents developers to write good function code, the code to write good unit tests, integration tests to write good code, test by the code through the code style checking, test coverage check.
We are all smart people, once determined DoD Well, who should do something to clear out.
1, DoD is a list, the list is one of the inspection items used to check our work is completed. DoD inspection items, is a series of valuable activities required to develop our products. For example: writing code, writing tests, and acceptance by testers.
2, DoD is one mechanism among team members report to each other. Do not "report" think complicated, simple report that is a "function done." When we have the DoD, they work only two states, namely "done" and "not finished", 80% did not finish the argument.
3, DoD check the actual items should be checked: You say the code written, where the code; you said test coverage standards, and how to see; you say you function well, show you.
In the preceding discussion, we are talking about DoD just start from the individual level. In the team level, we can also define DoD, such as:
1, DoD certain functions, such as: This feature has been developed, through the person in charge of product acceptance, in a state that can be deployed.
2, an iterative DoD, for example: all the features of this iteration planning has been completed.
3, the first release of the DoD, for example, the software can be released in the state, has made it clear on-line program.
Lean Startup: validation framework for thinking product features
Lean Startup that "development (build) - Cognitive (learn) - measured (measure)" The concept of such a feedback loop and a minimum viable product.
When you have a new idea (idea), put the idea into a product development (code) into the market, then, collect data (data) get feedback to see if the idea is not a fly front. Nothing more than to get two results: a good idea to continue to strengthen, not fly the idea lost forget. Whatever the result, you will have new ideas, and then proceed to the next loop. In this feedback loop, you get knowledge is the most important, because it is proven.
We have access to most of the products can be placed within the framework of thinking. When the product manager to do a new product, a new feature or product, we can take a test to see if a product manager to think clearly with these concepts of Lean Startup.
For example, you have to do the product characteristics, you want to verify what is it? He wants to verify whether the target data can measure it? To solve this problem is not the most important thing the current, whether there are other more important problems? If these questions are answered in the affirmative, then verify that the target is there an easier solution is not necessarily to be achieved through the development of a product feature.
Task decomposition
Musk task decomposition
Tesla founder Elon Musk (Elon Musk) also created a space exploration company SpaceX. SpaceX has a goal is to send 100 million people on Mars. The US government had calculated that an account, put a man on Mars, based on existing technology is feasible, but it takes 10 billion dollars. If Mars will send 100 million 10,000 trillion, equivalent to the money the United States 500 years of GDP, more expensive to even the US government can not afford.
Musk how to solve this problem? His first step is to prepare the per capita cost down to $ 500,000, the equivalent of money to a person in the house on Earth. The original 100 billion to 500 000, can be reduced by 2 times.
Of course, reduced by 2 times is still a distant goal sounds. Concerns came, Musk second step is to put 20,000 broken down into "20 × 10 × 100", which is a simple math problems, but also the direction Musk three key efforts.
"20": Now Mars spacecraft can only take 5 people, Musk intends to build a bigger rocket, the first sitting 100 people, so that is equivalent to 20 times lower cost. If you are concerned about the news, then, SpaceX did try making this regard.
"10": Musk thinks he is a private company, efficient, cost can be reduced to 1/10. In fact, SpaceX's current cost has dropped to 1/5 counterparts.
Finally, what is it 100? Recycling is reusable rocket. If this goal can be achieved, the cost of launching the rocket would only fuel costs, which is what we frequently see reason SpaceX rocket test flight news.
So doing, you are not feel like Musk's goal began to hear that most do not fly it? It is task decomposition by ambitious goals, Musk can be a seemingly far-fetched goal forward.
Micro-operation
When working in ThoughtWorks, ThoughtWorks my Sponsor is the current CEO Guo (Sponsor, the factory is similar to the relationship between apprenticeship), he is also writing code origin. He and I talked about him and Wiki inventor Ward Cunningham with knot scene of programming.
After Ward needs to get a day, not in a hurry to write code, but do together and Guo task decomposition, decomposition is very clear to each task, a task completed just fine. Guo was very nervous although I think the work, but the idea is very clear. Sometimes, he is also very strange, because before we start work, he will find that very difficult to solve the problem, the results break down all the way down, every step is clear, we did not encounter any difficulty to complete.
Task decomposition is a good habit, but want to grasp it, a lot of practice is required. I also really spend a lot of time to practice. With the increase in my practice, I understand more and more mission-critical decomposition is "small." Small to what extent? Sometimes even as small as you think it does not deserve to be an independent thing, for example, rely on a version upgrade, do a variable's name. So do a good job at that, it ensures that I can stop at any time.
I have read a story about the famous golfer "Tiger" Woods. Golfers play at the time, may be subject to a number of outside interference, in general, okay, if he has begun to swing, this time disturbed, generally players certainly continue to play down the rod, but the result is usually played not ideal. Woods In such cases, he would stop and re-do the swing action to ensure that the standard of each rod.
Woods can stop, of course, it is the result of a lot of practice, but there is a key that, for others, hitting a ball is an action, must one go, but for Woods, this action is composed by a number of little tricks, he is only just completed a little trick, but it did not do the next trick. In other words, it is all the same to complete an atomic operation, but Woods atomic operation is much smaller than others atoms.
After a post-task decomposition, demanding attention is limited, we can address this task, the details of every aspect of think more clearly. The reason why a lot of people write code full of loopholes, one important reason is the task size is too large.
Communication and feedback
Visualization: Radar Technology
ThoughtWorks art radar technology to track, by way of visual system to provide a more programmers intuitively understand how the new technology.
In radar charts, the technology is not organized complex. Each technique is represented as a blip, i.e. a light spot on the radar. The tissue is then used blip "quadrant" (Quadrant) and "ring" (ring).
Among them, the quadrant representing the kind of a blip, there are four categories: technology, platforms, tools and languages and frameworks. Ring represents a blip in the technology adoption life cycle stage at which, the current life cycle consists of four phases: A (Adopt), trial (Trial), assessment (Assess) and suspend (Hold).
Radar chart is a good form of the knowledge classification organization, it allows you to see at a glance all the knowledge to understand the point, and according to their needs, to decide whether to understand.
For example, after each release radar technology, I would particularly look at "a" and "** suspend" the two. "With" ** strongly recommend, I will go to compare yourself whether in the practical application uses, for example, in November 2018 technical radar, storm event (Event Storming) into the "a" in.
" Suspended ", said the new project Do not use this technology, and this will give me a reminder, this technology may have better alternatives, such as, Java the world's most common long Maven build tool put "on hold" but today, many people still choose to start a new project Maven, mostly do not understand the technology trends.
In my opinion, a radar chart is not just for the organization, also be applied to the team.
I have also in the manner of a radar chart his team used technology to organize. The most need to understand the technology must be placed on the inner ring, for example: a Java project, I will ask the programmer to understand Java, scale-out is that you work within the team will gradually come into contact with technology, such as the Docker and deployment relevant knowledge. As the outermost layer, it is to be we abandon the technology, such as, Maven.
As a result, team members can more clearly understand technical team used. When someone new joins the team, this radar can help newcomers quickly seize the key, he's learning path is to learn outward from the inner ring.
Fail Fast
Write programs there is an important principle called Fail Fast, encountered a problem and error as soon as possible.
A lot of people to build a robust system on the grounds, is compatible with a lot of strange questions, but will the system Bug hidden. By debug the problem is a practice to locate the most time-consuming, do not be afraid system problems, there are problems earlier reported out.
举个例子，我做了一个查询服务，可以让你根据月份查询一些信息，一年有 12 个月，查询参数就是从 1 到 12。
问题来了，参数校验应该在哪做呢？如果什么都不做，这个查询参数就会穿透系统，传到你的数据库上。如果传入的参数是合法的，当然没有任何问题，这个查询会返回一个正常的结果。但如果这个参数是无意义的，比如传“13”，那这个查询依然会传到数据库上。
事实上，很多不经心的系统就是这么做的，一旦系统出了什么状况，你很难判断问题的根源。在这个极度简化的例子里，你可以一眼看出问题出在输入参数上，一旦系统稍具规模，请求来自不同的地方，这些请求最终都汇集到数据库上，识别来源的难度就会大幅度增加。尤其是系统并发起来，很难从日志中找出这个请求的来源。
你可能会说，“为了方便服务对不同数据来源进行识别，可以给每个请求加上一个唯一的请求 ID 吧？”看，系统就是这么变复杂的，我经常调侃这种解决方案，就是没有困难创造困难也要上。当然，即便以后加上请求 ID，理由也不是这个。
稍有经验的人都知道，参数校验应该放在入口的位置上，不合法的请求就不让它往后走了。这种把可能预见的失败拦在外面的做法就是 Fail Fast，有问题不可怕，让失败尽早到来。
上面这个例子很简单，我再给你举一个例子。如果配置文件缺少了一个重要参数，比如，缺少了数据库最大连接数，你打算怎么处理？很多人会选择给一个缺省值，这就不是 Fail Fast 的做法。既然是重要参数，少了就报错，这才叫 Fail Fast。
自动化
SOLID 原则
《敏捷软件开发：原则、实践与模式》的作者 Robert Martin 提出的面向对象设计原则：SOLID，为软件设计的目标“高内聚、低耦合”提供了很好的指导。“SOLID”其实是五个设计原则的缩写，分别是
单一职责原则（Single responsibility principle，SRP）
开放封闭原则（Open–closed principle，OCP）
Liskov 替换原则（Liskov substitution principle，LSP）
接口隔离原则（Interface segregation principle，ISP）
依赖倒置原则（Dependency inversion principle，DIP）
什么是单一职责原则呢？Robert Martin 把单一职责原则的定义修改成“一个模块应该仅对一类 actor 负责”，这里的 actor 可以理解为对系统有共同需求的人。
这可能不是很好理解，我举个例子你就懂了。在一个工资管理系统中，有个 Employee 类，它里面有三个方法：
calculatePay()，计算工资，这是财务部门关心的。
reportHours()，统计工作时长，这是人力部门关心的。
save()，保存数据，这是技术部门关心的。
之所以三个方法在一个类里面，因为它们的某些行为是类似的，比如计算工资和统计工作时长都需要计算正常工作时间，为了避免重复，团队引入了新的方法：regularHours()。
接下来，财务部门要修改正常工作时间的统计方法，但人力部门不需要修改。负责修改的程序员只看到了 calculatePay() 调用了 regularHours()，完成了他的工作，财务部门验收通过。但上线运行之后，人力部门产生了错误的报表。
如果你问程序员，为什么要把 calculatePay() 和 reportHours() 放在一个类里，程序员会告诉你，因为它们都用到了 Employee 这个类的数据。
但是，它们是在为不同的 actor 服务，所以，任何一个 actor 有了新的需求，这个类都需要改，它也就很容易就成为修改的重灾区。更关键的是，很快它就会复杂到没人知道一共有哪些模块与它相关，改起来会影响到谁，程序员也就越发不愿意维护这段代码了。
人的大脑容量有限，太复杂的东西理解不了。所以，我们唯一能做的就是把复杂的事情变简单。我在“任务分解”模块中不断强调把事情拆小，同样的道理在写代码中也适用。单一职责原则就给了你一个指导原则，可以按照不同的 actor 分解代码。
领域分层
分层，实际上是在构建抽象，构建抽象，最核心的一步是构建出你的核心模型，核心模型就是表达你业务的那部分代码。换句话说，别的东西都可以变，这部分不能变。
这么说有点抽象，我们回到前面提到的三层架构的演变：REST 服务的兴起，让 Controller 逐渐退出了历史舞台，资源层取而代之。换句话说，访问服务的方式可能会变。
放到计算机编程的发展中，这种趋势就更明显了，从命令行到网络，从 CS（Client-Server） 到 BS（Browser-Server），从浏览器到移动端。所以，怎么访问不应该是你关注的核心。同样， 关系型数据库也不是你关注的核心，它只是今天的主流而已。从前用文件，今天还有各种 NoSQL。
如此说来，三层架构中的两层重要性都不是那么高，最重要的是剩下的部分，我们习惯上称之为服务层，但这个名字并不能很好地反映它的作用，更恰当的说法是“领域模型”（Domain Model），它便是我们的核心模型，也是我们做软件设计时，真正应该着力的地方。
为什么“服务层”不是好的说法呢？这里会遗漏领域模型中一个重要的组成部分：领域对象。很多人理解领域对象有一个严重的误区，认为领域对象属于数据层。数据存储只是领域对象的一种用途，它更重要的用途还是用在各种领域服务中。
Thus also leads to another common design errors, domain object contains only data access, which is often said getter and setter, without any logic. If only for data storage, data access only enough, but if the object is an area, you should have a business logic. For example, a user to change the password, there should be a changePassword method on the user object, rather than every time I go setPassword.
I reproduced in: https: //www.jianshu.com/p/393433604029