I plan to write a series of articles summarizing my understanding of design patterns and architecture during my four years in iOS. Mainly includes my own summary, Apple source code and excellent tripartite open source project design patterns and architecture learning.

This is just a summary of their own, everyone understands different. I hope this will help you understand better.

Business and Refactoring

The first article in this series focuses on one of my guiding ideas for the code business, which addresses two of the most common problems encountered during rapid development:

  • How to avoid over-design in business development?
  • When do YOU need to refactor?

Why is this a problem? Usually our version is a development plan with small iterations and rapid development, mainly features and fast development. So we are required in the code business to develop features as quickly as possible, but at the same time to pursue high quality code. After a while it became more and more cumbersome to add new features as business piled up and required us to refactor the code. These questions are very contradictory. How do we know when to abstract code? When should you refactor?

God, Grant me

the serenity to accept the thing I cannot change,

the courage to change the thing I can change,

and wisdom to separate the difference.

How to avoid over-design in business development?

DRY principle

The DRY principle is short for Don’t Repeat Yourself. What the DRY principle wants to express is that every knowledge point in the system should be a single, clear and authoritative label. The same functionality should not be repeated in multiple implementations, but should be extracted into a common functionality.

The principle of YAGNI

The YAGNI principle stands for “You aren’t gonna Need it.” The main meaning of the YAGNI principle is: Don’t add extra functionality unless it’s necessary.

Rule Of Three

The Rule Of Three principle is that functionality is not extracted until the third occurrence Of a feature. Why three times? In mathematics, if you want to extract a model:

Complete the pattern:
1, 2, _, _, _, _
Copy the code

When this model occurs only twice, it is very unclear to derive the complete model. Depending on the occurrence of two times, there may be the following model:

1. X2 model 1, 2, 4, 8, 16, 32Copy the code
2. +1 Model 1, 2, 3, 4, 5, 6Copy the code

If there are 3 times before model extraction:

Complete the pattern:
1, 2, 3, _, _, _
Copy the code

At this point the model will be clearer, it will just be a +1 model. By starting the extraction with the third iteration, the model is more certain, and the theory applies to the code as well, so as to avoid wasting time in extracting the wrong pattern.

There are many places in the computer world that have the number 3. HTTP, for example, requires at least three handshakes to establish a stable connection in a trusted relationship. It’s not that you can’t do more than 3 of course more is better, but 3 is the minimum.

conclusion

Software development without relying on these principles, assuming sufficient experience and intuition:

We only see the code once and then we abstract it, and that can be very time consuming because there are a lot of differences in the details of that particular scenario, and those differences can occur in the abstract code, and your experience and intuition can give you a better design, but it’s still a risk. So just do it now and don’t abstract it.

The second appearance of abstraction gives us a better idea of what details need to be present in the abstract code and what doesn’t. However, the abstract model is not clear enough and may require extensive logic modification on a third iteration, which is still time consuming. So it’s annoying not to abstract the second time around, but you can copy it over and change it very quickly.

The third time appears again abstract, the basic magic board has been determined, all the details which need to be abstracted and which do not need to be determined. Even the fourth deviation can quickly determine if abstraction is needed and quickly adjust.

The three principles described above complement each other and guide us as best as possible when we need to abstract our code. Help us develop quickly and save time.

When to refactor?

What is refactoring? There are two explanations:

Refactoring, n: An adjustment to the internal structure of software to improve its comprehensibility and reduce its modification costs without changing its observable behavior.

Refactoring (verb) : The use of a series of refactoring techniques to adjust the structure of software without changing its observable behavior.

When to refactor?

  1. Refactor when adding functionality

I couldn’t understand the previous code.

The design of the code does not make it easy to add the features we need.

  1. Refactor when fixing bugs

Refactoring helps clarify the logic when the code structure is complex and bugs are hard to spot. Find bugs quickly.

  1. Refactor when reviewing code

Review is valuable, and you can read other people’s code to make more appropriate suggestions. Refactoring also helps us understand the code better and come up with more meaningful code. But it’s also important to remember that there are multiple opinions within a team.

The above reconstruction time is arranged in sequence, and sufficient test cases or unit tests are required before reconstruction. Refactoring occurs throughout every release development process.

The above quote is excerptedRefactoring improves the design of Existing Code, highly recommended.

conclusion

Overdesign is a waste of time, and it can take a long time to overturn everything. Rack your brains, and there may be only one place to use a well-packaged module.

Refactoring is an indispensable part of software development and should be accompanied by the whole version development process.

I hope the above two points can be useful to you. 🙂

reference

The Way of Programmer Training

Abstraction: The Rule Of Three

Refactoring improves the design of Existing Code