From extensive to lean programming

This article is from my independent blog, in order to get a better reading experience, please click the original

----------------------------------------------------------------------------------------------------

"From the extensive program kid to the Lean programming master. 」

I've been thinking about how to be effective at programming, what should individuals do, and what should a development team do? The premise here is to assume the validity of the requirements without considering the unnecessary programming caused by the invalidation of the requirements. The validity of the requirement this is another subject, which is not discussed in this document.

My development team, nearly three years ago, most of the students are just graduating, the whole team's development style is extensive. Here refers to the "extensive" is how to define, the software development of the industry is relatively young, there is no precise definition, but in the traditional industry mentioned in the "extensive" can be used as an analogy, referring to the definition of Baidu entry is as follows:

Extensive (extensive Management), refers to the technical and management level is not high, the production factor utilization efficiency is low, the product is shoddy, the material and the labor consumes the high production operation way.

The above paragraph in the operation of the two words into programming, it is very accurate to express what I want to say the meaning of extensive programming.

Three years ago it was probably the kind of extensive programming that was described above, so what would it be like three years later? Tragedy, or the extensive style. It's causing me to think about what the next stage of extensive programming is, and where is the road? Then think of the "extensive" antonym "lean", and then from the traditional industry to find the "lean production" definition:

Lean production, in a nutshell, is a resource-saving production method that aims to meet the needs of users, strive to reduce costs, improve product quality, and innovate continuously.

Yes, switching the above production to programming is the "lean programming" I want. Feel the light of their own to find the road, saw the dawn of the light. Another look at the original idea of lean software development was raised by Mary Poppendieck early in 2003 and was written specifically to illustrate (Lean software Development:an Agile Toolkit). Well, 2003 I was just beginning to learn programming at school, naturally it is difficult to personally know the idea of lean programming, but the way to finally find great minds think alike, also more confidence, this is really the dawn of light, not a mirage.

This has found the direction, that is, from the extensive to the refinement of the transition, then there is a boundary between the two, just like the history from East Germany to West Germany, as long as the past the Berlin Wall of the world is a big change? Am I going to find this wall of Berlin and push it down and shift from extensive to lean? It is not so obvious a wall to think carefully.

Take a magnifying glass to see the extensive programming is how to work, a demand to arrive after development, open, finish, on-line, finished customer said O, and then did not then. The above process repeats 500 times, and then we get a large application that provides 500 different business services, and then the problem comes up. Add new function began to slow, add a No. 501 demand, the front several functions suddenly is not normal, code volume explosion, maintenance difficulties. This is probably the first stage of extensive programming.

Then start splitting the business functions, packaged as a service with a small feature set, the service is deployed independently, and the cost of reducing development coupling is to increase the complexity and difficulty of deployment and operations. The new term was born, a service-oriented architecture (SOA) or a newer microservices architecture. Extensive programming has entered the second phase.

We use the latest and most popular service architecture, why is it still extensive? Because we are only focused on business functional requirements, split services are simply reducing the coupling of the business and rationalizing the relationship between business services. The development of the business code is the part of the iceberg that is exposed to the sea, while the sea surface is supported by non-functional requirements, including maintainability, extensibility, performance, and so on. Today benefits from the popularity of open source code, many of the base library code reuse saves a lot of development and maintenance costs under the iceberg, but for the above mentioned three aspects are still related to business code development. Just in the early stage of the extensive style we can complete the good function has been good, think of the next graduation can let oneself develop the system to run smoothly, complete customer demand has been very happy.

Service splitting improves the maintainability, scalability, and performance of the system as a whole. But on each individual service, the three points depend on the experience and level of the developer of the service, and if the developer of the service is still part of the extensive first order, it may not be considered so much. The principles of lean programming can help you become perfect by iterating: seeing software development as a process of continuous exploration. In terms of the overall system, each iteration may focus on a different focus, the extensive phase stays in the completion function, while the lean phase focuses on non-functional attributes, which are designed to provide the lowest cost, highest quality service, and maximize customer value.

The system Architect is concerned with the rationality of the overall division and deployment of the system services, looking at the global, which is concerned with the non-functional properties of the whole system. Architects also need to focus on the key details of each core service to avoid bottlenecks affecting the performance of the overall system. The developers of each service need to pay more attention to the non-functional properties of the service and choose the implementation of the optimization. This is entered into the Lean programming phase.

Specific development services, how to focus on non-functional properties, there should be no unified approach, here on my personal experience to understand the simple.

Maintainability

2. A single service provides simple functions and a unique responsibility.
   简单更易维护。
4. functionality is orthogonal between services.
   正交减少重复。
6. Consider the parallelism of the new version of the service when replacing the legacy service.
   意味着多考虑数据结构的稳定性，Linus 说的好程序员关注数据结构是有道理的。
8. Documentation is provided, however.
   像维护代码一样维护文档，像写代码一样写文档，注重明确、清晰。
10. Consider readability, naming, typography, consistency.
    像写文档一样写代码，注重可理解。

Scalability

1. No state is more excellent.
   易于水平扩展，随时启停。
2. Minimize the dependency on shared resources.
   能不依赖更好，扩展到一定阶段的瓶颈可能就是共享资源。
3. The basic service is much considered to provide SPI expansion interface, business services to see the situation.
   业务服务通常通过替换升级，而基础服务经常通过 SPI 扩展升级。

Performance

2. I/O is GBP, memory is RMB.
   访问 I/O 花的是英镑，访问内存花的是 RMB，能不花就不花，一次内存访问都是好几百个 CPU 时钟周期，要像花钱一样心痛。
4. Run into a performance problem and find out the reason for your own code first.
   Java 程序员说起性能调优，总喜欢谈 JVM 调优，其实大部分性能问题都不是 JVM 的。
6. The premise of optimization is that current performance does not meet demand and provides performance data proof.
   服务除了提供功能，还要性能指标说明，支持的 TPS，单次调用时长等，优化后也要提供数据对比。
8. Performance regression automated testing to avoid service upgrade performance degradation.
   其实现在能做好功能回归的都不多，性能花的功夫更少，继续努力。
10. Less code, better performance.

From extensive to lean programming