Whenever I do a design related training and sharing, some students always ask me: how can I improve my design ability quickly? I think this question is very representative, representing the voice of a large group of programmers on the road of hard training. Now I will be thinking about this problem, experience to share, for everyone’s reference, but also welcome to put forward different opinions and views, common discussion.
1. Coding experience
Line of code experience is a very important thing, when you don’t have 10,000 lines of code experience, ask how to improve your design skills, I can only tell you don’t worry too much, just look at the theory, honestly write code to accumulate coding experience. It is said that the average programmer writes 200 to 300 lines of code a day. You might say, I can write 1000 lines of code a day at any rate. Remember, when you are done coding, you have to test, debug, optimize, and Fix bugs. Not to mention the code specification, if your code is still in a mess, don’t worry about design and architecture, I think it’s a bit of crap, of course, it’s good to have such design awareness, you can see your own shortcomings. You must read some coding specification documents, in-depth language features of the book, and then practice. In addition, as code cleanliness patients, recommend you do not write the code, batch formatting processing, or manual to sort out the code. But every time you type a character, it’s compliant. Habits really matter, and sometimes during a job interview, I just want to add an on-site program to complete a simple but error-prone task.
2. Theoretical learning
Simply put, reading books, reading blogs, whatever resources you can get, good quality. For example, “Refactoring – Improving the Design of existing Code”, “Agile Software Development: Principles, Patterns and Practices”, “UML and Pattern Application”, “Object-oriented Design Principles” (five Principles), “Design Patterns”, etc. Design Patterns is a very old book, it’s only 200 pages, but, but it’s one of the most difficult books to read, and you probably won’t be able to read it all in a month (if you’re reading a novel, you might be able to read 200 pages in 3 hours), and if you do, you probably won’t understand it all, probably not more than 30%. It doesn’t matter if you don’t understand it, just read it, don’t worry too much, it doesn’t show anything. In addition, I would like to mention that multithreading is a must for programmers and needs to be understood thoroughly. Advanced technologies such as iOS GCD can cover up your lack of understanding of multithreading because it is so easy to use. Not to mention that you have not written multithreading but still completed a complex project, not to mention that there seems to be no problem with the multithreading code you write at random. Give me your code and I will write a Demo to make it fail or even crash. If I can’t do that, congratulations to you.
Practice 3.
Now that you have some coding experience and you’ve learned enough theory, it’s time to practice. Think over and over about the theoretical knowledge you have learned, how to apply it to the project, and put it into practice. Be sure to make clear those theories and use them to guide your practice. Put away your previous confidence, first deny your previous practice, and ensure that everything you do is better than before.
4. Brush up on theory
You can see your progress and see that you are doing better than before, but it still feels like there is a bottleneck. Congratulations, I can already see your potential in the future. Pick up the book again and go over the things you didn’t understand before. You will find that the things you didn’t understand before are suddenly clear. They are no longer obscure and difficult to understand. Even if you thought you had it figured out before, rereading it often reveals something new.
5. Practice
At this stage, you have mastered more things, not only rich in practical experience, all kinds of theories can also be at hand, but you find that your design is still not professional. And you look back at your old code and you’re like, oh my God, who wrote that code and how could you do that? And then… Without further discussion, you have entered the stage of introspection. You have mastered the learning method that is suitable for you, and it is no longer a matter of learning anything new.
6. Summary
Don’t get too smug (don’t believe me? You need to summarize your learning methods, your project experience, and your design theory knowledge. It would be great if you could have your own understanding, not just use mature design patterns, but draw on your own experience and principles of design.
7. Share
Sharing is the best catalyst study, when you are ready to share a training, you will find what you previously thought already understand actually didn’t really understand thoroughly, because you can’t make it clear, in fact is research is not enough, will force you to learn more at this moment, will converge, and then you will dare to mounted the platform. Otherwise, when someone asks a question, you won’t be able to answer it.
Above, is I think the programmer cultivation road must go through the stage. Then I will mention some other points that are very important for ascension:
Get into the habit of designing first, coding later
Almost all programmers, at the beginning are not willing to write documents, also not willing to elaborate design, get the demand is always unable to help those restless hands, always feel that on the keyboard, line by line code bang out, just have a sense of achievement, is the correct working posture. Don’t code without discussing it, or you’ll be sure to rework it.
Design over coding, interface over implementation
The process of developing the interface is itself a design process. The interface must be deliberated repeatedly, and subtraction rather than addition should be done as far as possible. The simpler the better if it can meet the needs. Additional, do not want a person to meditate hard, do a rudiment to come out simply first, take to seek to use square communication next, until the other side is satisfied so far. Do not design interfaces entirely according to business requirements. Refer to MVVM. ViewModel is a reencapsulation of Model based on the needs of View, and cannot design these interfaces directly into Model.
Don’t blindly follow design patterns
Design pattern is just a kind of routine method to solve the problem, you can also have your own method, of course, if the design pattern is used well, it will make your design appear professional and elegant, after all, the efforts of predecessors. But if abused, it can lead to more serious problems, even disasters. In my opinion, object-oriented design principles are more important. There are some principles that must be followed (one-way dependency, SRP, etc.), and design patterns themselves follow these principles, and some patterns are designed to follow certain principles. Abstraction is not a panacea. It needs to be carefully considered when used in the right place. When there is a better solution to solve the problem without abstraction, try to avoid abstraction. I have seen too many cases of over-abstraction design, which increases the maintenance cost too much. It is better to write in the most natural way.
Empty cup mentality, learn from the classmates around, stand on the shoulders of giants, stand on the shoulders of others
Accept it (whether you accept it or not). A lot of program ape, also have a problem, that is, feel their technical cattle not good, do not want to accept other people’s opinions, especially negative opinions (literary people light). Whether it is theoretical learning or coding practice, learning from classmates around you will have the greatest impact on yourself (three people together, there must be my teacher), than deliberately to participate in the relevant training is much more useful. I have often benefited from discussions with my team members. When I feel overwhelmed, I can usually find the best solution by putting the problem out there and discussing it. Another advantage of discussing your design with the rest of the team is that when your design is compromised or unprofessional, people who see the code don’t question it because they are in the discussion and you don’t have to spend as much time explaining it. During design will have to find others, I have been compared against one finished the design, the document is finished, and then find you open a commenting that pattern, although also have the effect, but the effect is really short of perfection, people not involved in the design, the time understanding through a meeting may not have so deep, the key is, If there is something wrong with the design, but it is not a fatal problem, why should we go back to the redesign? After enough preliminary discussion, everyone knows your ideas and plans, and finally there is a design document, when others read your code, there is no need for you to guide, the future work handover is not very needed, why not?
Finally, I would like to appeal to you that when you modify and maintain other people’s code, you’d better have an in-depth discussion with the module leader, let him understand your needs and your plan, ask him to help evaluate whether the plan is feasible, whether it will step on holes, bury holes and so on. So that our project doesn’t have bad taste spreading, and if you happen to be the module owner, please exercise your right to reject the submission of problematic code that doesn’t meet the requirements. We encourage each other.
Original article, reproduced please indicate the source