Nice to meet you, this is my first post. Newcomers have been assigned to new teams for several months, and more and more people are asked, "How can I write a program?" Even if you say "you can write a program", I think there are various stages depending on the person. I talked with various people about how to go up the growth stairs of programming while feeling the growth. Not all people can write programs, and some people can't. Climb the stairs at your own pace. This article is primarily aimed at object-oriented languages.
To put it in the extreme, the task of writing a program can be done as long as you learn the grammar. I don't think there are many people who can't understand the meaning no matter how many times they look at the grammar. In such a situation, the points that make me feel "I can't write a program" and step on it are as follows.
These are "something" that anyone can feel, and they are often found in the actual field. It is inevitable that you will become a programmer who can only write programs in the transaction script pattern [^ 1] when you learn only the grammar and put it in the development site. What this means is that when you enter the field at a level where you only know the grammar, you only have a skill set that procedurally implements business processing in a fixed part of the application, like the so-called "Action craftsman" in the heyday of Struts. You will not be able to. In this state, you do not know or understand the processing contents other than your own implementation part. Software created with this labor-intensive method (called a labor-intensive pattern) is extremely vulnerable to function additions and troubleshooting. What's worse is that growing up in such an environment makes it a matter of course and contributes to quitting further programming learning. If you stop learning, you will not only be able to program with the labor-intensive patterns you know, but you will also be on the dark side of imposing it. It's a type that often goes up as an anti-pattern SE. If you see such a person, please introduce this article.
So how can you reach a level where you can be confident that the program will work without you having to step on it? In the following, assuming the acquisition of object-oriented languages such as Java, C #, and JavaScript, we will organize the growth in four stages. By the way, I think that 1, 2 and 3 are bad and 4 is in the middle of studying.
[^ 1]: Transaction Script
From the outside, this state looks like "writing a program". However, I think that many people who are doing it think that it is impossible to create an application by themselves just by copying some sutras. I think most people stumble on interfaces, generics, lambda expressions, LINQ, etc. in C #. It is too early to feel frustrated here, as the understanding of stages 3 and 4 described later will deepen the understanding spirally. This is the road that everyone has taken. At this stage, I think it is enough to copy the sutras and solve some of the problems at the end of the chapter that are common in books. As for the end-of-chapter question, the questioner does not understand the reader's level correctly, and the background required to solve the question varies from person to person, so the perfection is "I can't ask all the questions, so I can't do it anymore." The principle should come somewhere early. In any case, it is important to set a deadline for studying grammar, and I think it is better not to continue studying grammar forever. I think it's about 2 weeks to 1 month at the longest.
Here are some points to note when proceeding with copying sutras at this stage and developing applications that apply them a little. ・ Be careful about class names, method names, variable names, etc. as much as possible, and be strongly aware of writing them neatly. ・ It is recommended that you also read books for writing neatly, such as readable codes. Since the sample code in books and online is not always correct, get in the habit of performing checks (static analysis) using the code analysis function of Visual Studio and IntelliJ and Sonarlint / FindBugs / PMD / CheckStyle of Eclipse. Please give me. Above all, if you do not write clean code, even if it is a basic application, after a month you will not know what you wrote, and it will be a chance to keep programming away.
Even in the state of step 1, if you create an application by combining libraries and external services, you can create software that works to some extent. If you use the cloud, you can even develop what you provide as a service. Nowadays, if you use cloud services, it is not wrong to say that you can create an application even if the program is not in a state where you can write it.
However, even in this state, the anxiety that "I could make something that works ..." should not be resolved. I think the biggest reason for this anxiety is that we have not reached the 4th stage described below. Design patterns are broadly defined, but by understanding architectural patterns such as MVC and MVVM, you can control what is necessary for application development, and your anxiety will gradually disappear. However, first of all, making software that works reveals your current state. If you find it difficult in this second phase, it's not that you lack coding skills, but that you may have a lack of understanding of the web, database access, and the cloud. First of all, I think that the shortcut is to look up the basics of the field that you feel you are not good at in books etc. and proceed to understand the basic operation. By utilizing the library while investigating, the standard skills of application development will be greatly improved before you know it. Next is object-oriented! With that feeling, some people may move on to object-oriented learning after learning grammar, but it is recommended that you first create a working application. After that, I think that the order of object-oriented refactoring will be a good motivation to continue.
From this stage, I think it will be the biggest barrier for those who are not good at programming. As soon as you come across an application that uses inheritance, polymorphism, and encapsulation techniques, your program can't keep up. Or, I'm sure many people have felt that they can't design the right additions to their applications. You can't easily overcome this barrier without programming for the interface and understanding the relationships between is-a and has-a. However, it is surprisingly easy to overcome this by having someone who already knows explain it while writing the code, rather than overcoming it by yourself. It's not really easy, so don't be afraid to ask people and move on.
I think pair programming is the fastest way to understand object-oriented programming. However, if you don't have that kind of person around you, refactoring your past code according to SOLID principles will help you understand the effects and implications of object-orientation.
With some understanding of object orientation, you'll be able to read and write code a lot. Perhaps it's easy to modify the code in the production product. However, in that state, I think that there are still uncertainties regarding the construction of new applications and the implementation of complex business processes.
Design patterns are a tool to go beyond that. Design patterns such as database access design and business process division methods are packed with wisdom to do so effectively. Applications with the correct object orientation and design patterns also have the advantage of being easy to understand and modify. Above all, I think it has the effect of greatly reducing the time and effort required to explain to people who enter later. However, there are innumerable design patterns in the world. It covers a wide range of SOLID principles for object orientation, GoF design patterns, and architectural patterns such as MVC and MVVM for UI realization. There are many, but don't be disgusted. (Which one to start with depends on the purpose, but I don't think it's a dog's way to understand what it is.) If you can understand the design pattern to some extent, writing a program will be fun and irresistible. Looking at labor-intensive applications, you'll be dying to refactor.
Coding learning, making things that work with libraries, object thinking, and refactoring with design patterns can be better understood by repeating them in a short period of time rather than spending a lot of time. Please set a period and work on it.
Based on the above learning steps, I would like to write two points that are rarely done by beginners.
Most of the things that you probably find difficult to understand in a program are in object-oriented and functional programming. If the book lacks information about it, I will never lose my weakness even if I read it forever. Let's change the book. And, as explained in the above four steps, even if you understand only the grammar, you can not reach the point where you can use the object-oriented language with confidence, so do not cherish the same grammar book forever and proceed to the development of different books and applications. Let's look.
As is often the case with learning C #, I see people reading translated books based on Version 3 and Version 4. It's not completely meaningless, but I don't think it's good to be blind to the book "Old but highly rated by Amazon." (I don't think it's just as good to keep track of the latest) However, I dare to write it contrary to this, but "Effective Java 2nd edition" is an old book, but it is still worth reading because it is a book that holds down the parts of stages 3 and 4 written above. Therefore, if you really want to use an old book for grammar learning, we recommend that you also purchase and read a book with the specifications of the new version.
Here are some recommended books to keep up with the latest language specifications and move on to the 3rd and 4th stages.
Recommended Posts