Learning Program organization and organization skills

It has been quite a few days since I came to the blog Park, and the constant theme of the garden is just a bit. Let's talk about my opinion.

I wanted to publish a text to the homepage. However, I am afraid to discuss these issues. I am not optimistic about the value of this discussion for myself and others.

In fact, how to organize the program should start from the needs, not as the design guidelines should do, regardless of the premise. The key to this premise is who your users are. For organizing this work and its results, two of them are ourselves and the other programmers.

At the application development level, there are not many designs for others, and they are not as important as commercial middleware.

Whether immersed in Object-Oriented or a very simple programmer, as long as we are conscientious and responsible, we can always design good interfaces and even frameworks. The mistake of noodle code is not that you are not familiar with the specific principles of XX, but that of a person's sense of responsibility, which many people do not understand.

I gradually know that even some enthusiastic learners think that they can better find a job (or be subconscious-driven) by understanding object-oriented skills ). So I gradually changed from active participation to silence on these topics. Because in the end, this discussion has not hit the essence and has no guiding significance.

User identification, starting from the demand, after one or two rounds of practice, you can always find a better * Current * design (instead of having to learn and think too much preparation knowledge ). This does not have to be supported by any methodology, and they are also unable to afford it. Specific tools (languages or frameworks) are used only to speed up their work.

Different facilities have different acceleration indexes, so extensive understanding of tools is still needed. However, these problems must be viewed only in terms of convenience, rather than in the spring snow.

I do not agree with the mature framework to affirm my learning and draw conclusions. Especially for some programmers, he faces many different situations than the author.

For example, the frameworks and libraries such as ASP. NET have many design flaws, and learners with insufficient levels will be able to effectively implement them for a long time. Even a lot of good decisions are only caused by the designer's consideration of the common needs of the largest part of users.

If you do not understand such blind evidence, there are many chances of making incorrect conclusions. Even a 1% error may affect our future judgment. What's more, even if you find the right path? People who get used to this model always get used to it. Correct explanations do not mean learning the real work.

I have some opinions on the Framework learning. I may want to ask myself some questions. For example, "Will someone use ASP. NET in the Python world ?"

When a person's choice is limited, he wants it to be reasonable. Those who clearly think it is not good also feel "harmless" or think it is Trade Off. When we jump out of this circle and look at other people's choices, we may eventually develop something for use based on Handler.

In the example of ASP. NET, although there is no way to issue a questionnaire, either WebForm or the current MVC may have a chance to get an alternative answer. Next, let's ask why, who will and what will not be. Then we will know where this thing is, or where it is.

With these materials, you can determine whether you are the target user of something. If you resonate with those who do not choose it, it is not suitable for you. At this time, the evaluation of many features will become objective, rather than on a very small acre of land, "Oh, this design should be so considered ".

So you can see that the answers to these questions will eventually be related to who the users are and what they (including ourselves) Want.

Let's look back at what most people call design, that is, how to organize programs. With the above discussion, it is not difficult to see that many seemingly valuable articles are nonsense. We can always find good reasons to support one or more designs (of course, if this design can be affirmed or partially affirmed, it also shows that its authors have a certain sense of responsibility ).

But I think that after the beginner's stage, when we encounter really complicated problems, this learning will become meaningless or even slow. You cannot assume that you are designing ASP. NET, because you are not. Design your own things based on the author's perspectives and reasons, and ultimately it can only be embroidered pillows. After all, the scale of user groups and problems is fundamentally different.

Pay attention to the cost of every extra thing. The Occam Razor is not only used inside the object-oriented system, but also applies to whether or not a certain idea is adopted. Everyone wishes to be a great designer, but they cannot rely on imagination at any time. It's good to make a decision like a cow, but we often don't see how a cow decides in our position ".

Ask yourself, can I design ASP. NET if I have mastered so much? If not, ask yourself why. One of my personal answers is that this is often because we have not learned the correct method: making decisions only based on requirements, rather than having to worry about the prior knowledge.

Soldiers who do not want to be generals are not good soldiers, but those who do not make immediate decisions based on the situation cannot be generals.

Finally, let's look at the same problem from the relationship between the application and the underlying layer.

To become stronger as a pure programmer, you must recognize the real situation. In fact, the complexity faced by underlying programmers and application programmers is not a level. You cannot lie to yourself in this regard, because the user base, the needs of all aspects to be considered, and the order of magnitude are different.

Of course, you can take a good application programmer to despise a poor underlying programmer, but such self (group) is definitely not healthy. When we think we are as good as the underlying programmers, or even as good as Linus, We will ignore such things that the Bulls don't care about and be proud of being "Pure programmers.

But in fact, we are not concerned about the things that many underlying programmers care about (there is no chance at all), so we have to make some effort-consuming learning for a sense of fullness.

As far as I can see, as an application programmer, we should be concerned about many other things if we are not competing with the underlying programmers. What are these things related to your job role. Maybe the business may be other. In short, you have to explore downstream requirements (and return to this ).

Even we can't regard ourselves as programmers, but as a field expert. It is enough to be familiar with the business and how to implement the business quickly and easily.

The differences between these two fields also bring about a lot of interesting content.

For example, some people say that Linus is an object-oriented attack because he and the application programmer face different fields. This is disgusting.

If a programmer cannot see the commonalities of different levels and fields, he does not really understand object-oriented. But how can we choose it? In fact, many methods are both beautiful and easy to use, but most of these methods can only be used on simple issues.

Any method can be used to find beautiful solutions on simple issues. It is also easy to see that in addition to a few fields, the most violent methodology is the application or middleware community with relatively simple questions (maybe very "advanced; however, most of the enthusiastic learning and practitioners are not engaged in a few fields.

Why? Because the good side of methodology is easy to express, it naturally attracts people. But in the end, other methods can work because they are simple. In this way, these methodologies cannot unify the world. In this way, they show an embarrassment in the public community: You can talk about expansion, reuse and the principles behind them with relish, but the problems are still difficult and easy.

This shows that the solution to each of us is not at all what we have mastered. This does not mean that a methodology cannot be used. It is necessary to add new things to our toolbox. We must avoid unnecessary redundancy.

To achieve this, you must be "inert" and use more tools only when you clearly feel the advantages. In this way, we have a tool while avoiding the "mental burden" that Linus calls ". Maybe we should have a table, which is obtained through "requirement-> practice-> experience-> conditional conclusion. It records links between tools and scenarios.

Too much discussion and study is equivalent to answering the question before it is correct or * true.