Someone on MyKnowledge-Planet asked if coding-ios is worth learning. The open source client has 3500 + stars and seems to be very popular.

After I downloaded the code and looked at it for a while, I came to the conclusion that this project is not worth studying as a good one. To be clear, I’m not saying the code is bad, but as a model project to learn from, the overall level of the project is mediocre.

Problems with the project

Poor code quality in details

I saw the code in this project in 2014, which means it has been a project for many years. The quality of the details of the code is sloppy, from the syntax, to the naming, to the implementation logic of the functions.

Poor resource management

It has been 9012 years and the picture resources in the project are not managed by Assets, they are still managed by the old @2x @3x pictures. It can be said that due to historical reasons, Assets were not used at the beginning of the project, but such a simple migration has not been done up to now, indicating that the developer is not sensitive to the application of new technology.

Simple Architecture

The code organization in this project is very simple. Following the proud tradition of MVC, the project logic is divided into three folders: Models, Views, and Controllers. It may be acceptable to manage code files in this way when the project is starting, but as the project grows larger, this structure becomes very unmaintainable.

Let’s say you have business A, and to implement that business you write XModel, YView, CController. After A period of time, service A is unavailable and needs to be offline. At this point the maintainer needs to be very clear about finding three code files scattered in three folders and deleting them. Otherwise, there is unnecessary code in the project. In this way, it feels good. In actual business, one business may correspond to many views and cells. The developer performing offline task A is most likely not the developer who was previously responsible for it. It could be a three-year-old business that went offline, and the programmer who was in charge of the development had left. It is very difficult for the maintainer to find all the relevant code for the business, and it takes a lot of time to find it. Especially in this project, the level below MVC level is not very differentiated, and it is quite difficult to find a file in dozens of cells.

componentization

This project does not componentize business modules. All the business code is stacked in one project. The bigger the project grows, the higher the maintenance costs. The higher the cost of understanding for newcomers. It’s also bad for simultaneous development.

Suggested learning paths

It’s understandable to want to improve your programming skills by learning about good open source projects. But most of the time learning a real project is cheap.

A real project often has this problem:

  • A lot of design is business-specific, and if you don’t understand the business scenario, you can’t understand why the code is written the way it is. As a result, you need to be familiar with the business of the project before you can understand the code.
  • There is a high probability that some Featrue will run out of time for actual development, so release a version with a cost implementation first. So some of the code in the project might be good, and some might be poorly implemented. It doesn’t matter as a project, as long as the functionality is stable, the user will use it regardless of how well the code is implemented. But for learning developers, the time spent learning bad code is not worth the cost.
  • Requirements in real projects are iterative. Many projects were originally designed according to requirement A, but ended up doing what the customer required and then adding requirement B. The design of the original code didn’t take this into account, and continuing to implement it on top of the original code would be painful. If you’re maintaining an old project, you might as well have a place to name the implementation, but in a bad way. In fact, the original need to take care of another piece of functionality, but later requirements changed, no longer need to take care of. So the last person looking at the code is wondering why don’t we just implement it in a straightforward way.

So even with a good program, pre-learning costs are high.

I think a good project has two parts: good architecture and good implementation. Just like a big project will be broken down into many modules, if you want to improve your programming ability, you also need to break down into many small modules to achieve. For example, if you feel that your name is not good, the code readability is poor, you go to the relevant materials to study. Check out The Art of Writing Readable Code, Clean Code. If you don’t feel good about module abstraction, learn about object orientation, design patterns, etc. If you do not know the quality of these specific modules, you can learn a high-quality project directly without understanding. Imagine a foreigner who only drinks coffee, but not tea. Then you give him a pile of good tea leaves to drink, and then you ask him to summarize the characteristics of good tea leaves, and he can’t tell you why.