Not Coder But Programmer

I want to write this topic for a long time, but because I am just a new Programmer (who said: Code 10 thousand lines, you will get started), I have been afraid to write, I am afraid that I am writing too superficial. Even so, today I talked to a senior on Weibo about this matter. He encouraged me to write this article, so I had to make an axe to the class. In this article, I will try to show you what a qualified programmer should do.

-- Before the article

Glossary:

· Coder

I believe that many people take "writing code" as the first step in their programmer's career. However, unfortunately, many people have been writing code for a few years and still regard it as their only job, usually such a person is a Coder.

·Programmer

If all the bad situations I mentioned below have nothing to do with you, congratulations, you are at least a "general programmer. (Even if you become a programmer, there are eight levels. For more information, see this article and a more reliable translation)

 

I. Understanding requirements:

In the initial stage of project initiation, many programmers always stick to their own expectations and never put the customer's needs in mind, let alone take the initiative to contact the customer. Of course, the strict procedures of some companies make it difficult for programmers to directly access customers. However, even so, they should also analyze their needs in a timely manner and even communicate with sales personnel to have a profound understanding of their needs.

Case:

The assignment assigned by a teacher once was: Write a huffman code to compress the text. At that time, I did not seriously think about it. I simply understood this question as: compressing an English article with huffman encoding. I also found the word frequency of English letters on the wiki, and wrote the compression scheme to the code based on the word frequency. As a result, when the teacher mentions that there are not only words, but also special symbols and languages in other countries to be compressed, my entire program is directly discarded.

Note:

Without understanding the real needs of the customer, the software will be designed only for the surface at the beginning of the software development, or for a specific scenario. The final software is difficult to be practical.

In addition, in some extreme situations, we should also consider some critical points. For example, consider special relationships when creating a family map. To achieve this, we need to have a deeper understanding of user needs, and usually need to have some relevant professional knowledge-for example, to do medical-related software, we must have a better understanding of the handling of medical accidents, in order to increase the robustness of the program.

Of course, programmers should not worry too much about their own needs, because after all, this is what needs analysts should do in the early stage of the project.

2. Feedback on requirements:

It is often possible to hear programmers complain that the people who do the design and the requirements do not understand programming, and the specific requirements cannot be completed ". However, sometimes I think about whether I have discussed these requirements with leader or designer before the project plan, and whether I have participated in risk control. It is true that the design and non-technical leaders do not know programming, but you can quantify the difficulty of the problem so that it is easier to achieve the expected results: for example, you can tell leader, * ** special effects can be made, but they may take five days. However, our project only has one day, so can we slow down or postpone the project. Do not use complicated and profound technical terms to fool your leader. Otherwise, you will die badly.

In addition, you can control the difficulty in the demand at the beginning. It is better than you can tell PM when you do half of the work. The time is far from enough.

3. rich documentation:

I believe that many programmers hate documents most. All kinds of design documents seem to be the best reason for programmers to fail to complete their tasks-"I have time to write documents and I have finished writing this function !"

However, documents are essential for a formal project. For programmers, the document has the following benefits:

1. Read Requirement documents: the biggest benefit of reading Requirement documents is that you can complete the first and second articles in this article;

2. Write progress documents: In terms of project time control, people are always arrogant about new users. Writing a daily or weekly summary not only helps new users understand their progress, it is also helpful for the project manager to grasp the real progress (don't be afraid to tell the manager that you are too late because he will discover it later ). Many people complain about formatting documents, which are too bureaucratic and time-consuming. My experience in the ninth city is quite good. Each of them sends a group of emails to the team before getting off work. The content is:

I. Schedule Tasks today:

1 ,***

2 ,***

Ii. Complete the task:

1 ,***

2 ,***

Iii. scheduled tasks for tomorrow:

1 ,***

2 ,***

I believe no one will dare to say that this progress document is delayed. In other words, if you don't know what to write about this content, you must be just a code today.

3. Design Documents: This is very important because these design documents tell your partner what functions you have implemented (team members, field deployers, or secondary developers, and how to use these features. This is similar to the code annotation, which we will focus on later.

Case:

In my recent project, I encountered a problem with Designer: I said I wanted the material for the XX button. She said it was okay and sent it to me soon. The result is that the button size is different from that of other matching buttons. I have to adjust this material again (fortunately, I will click fireworks ).

Note:

Because our project is too busy and few participants are involved, there are no detailed design documents at the beginning. On the contrary, if we have a design document, she will understand the size and format of the material. However, a conflict is introduced here: only four people are directly involved in this project, and the time is very tight, only one week. Therefore, if documents are prepared according to the formal process, Deadline may have been in the past few days before development can begin.

That is to say, although the document is good, we cannot ignore the effort it brings. In the face of the fixed Deadline, we must make a trade-off in terms of the details of the document. However, even though detailed and formal documents cannot be listed, some small documents can still be prepared. For example, after this case occurs, she and I decided on a design draft (at least two of us can understand) and written a clear record of RGB values and controls.

4. Reject procedural programming:

At the beginning, most programmers had a hard time getting rid of procedural habits:

Case:

When a friend of mine wrote a database Interaction Using C #. NET, he had the following code:

~ Declare some variables

~ Read user input data from the front-end input box

~ Construct a sqlconnection

~ Connect to database

~ Write Data

Note:

I believe that some people with a little OO programming habits will think that such code is very ugly and Hate cannot start refactoring immediately. However, I am not planning to use this example to explain refactoring, instead, we will discuss the generation of this Code.

In addition, we need to believe that my friend is very good and will certainly be restructured. In fact, when he compiled this code, he soon realized the problem, therefore, this code is not retained in the final project version. The point is, why can we generate such code.

When programming, many people do not have design first, let alone detailed design documents, or even don't want to think about it in their minds, so they can't wait to start "catch up with the progress. The reason for generating the above Code is actually very simple: when he starts writing this function, he first tells him that he wants to update the information submitted by the user to the database, so the whole process is: Reading data, then write data. In this way, it is the same as this code. Therefore, the reason for procedural programming is not what language you use, but that your thinking is process-oriented.

In other words, when thinking about a complete functional design, we should be more OO in terms of our thinking. In the same example, we should consider this: we need to update user information to the database, therefore, we need a function to get the user input, a function to update the database, and then I call these two functions respectively. At a deeper level, I should put these two functions into two classes: the first class is related to processing the current page, functions provided in this class are used to update and read the visualization page. On the contrary, the other class is dedicated to processing database calls, and in order to improve efficiency, when a class is constructed, I can create a link and close the link during class analysis. Other common functions of the class perform specific operations on the database.

As a result, a more OO design was first formed, not just relying on a lot of refactoring.

5. Good writing habits:

Anyone who can program can write code that the machine can recognize, but not everyone can write code that is suitable for humans to read. If you only make the first one, you are a thorough Coder. Good code writing habits should include: 1. Good naming rules; 2. reasonable layout (especially indentation); 3. consistency. I will not elaborate on the specific writing habits here. I suggest you look at the famous open-source projects, especially those that have been completed by many people. Generally, there will be a very learning writing habit, here we recommend a Google programming specification. Of course, consistency is also very important. Even if the rules in each file are different, it is still very bad.

Take sorting as an example to describe the naming rules:

1. The name should indicate the function:

Error: int [] function (int [])

Reference: int [] BubbleSort (int [] src)

2. The name should not be too long: (in this regard, the functions in Microsoft's MFC almost bring this error to the extreme)

Error: int [] featherelfsbubblesortwithcpp (INT [] unsortednums)

Reference: If you want to indicate the ownership in the function, you can consider declaring it in the comment or using a special namespace.

3. unified rules:

Error: Function 1: bubblesort (); function 2: sortbyswap (); Function 3: quicksort ()

Reference: Make sure that the settings are consistent in a project file regardless of the case or terminology.

6. Annotations:

As the amount of Code increases, the question of "whether to add comments" is becoming more and more obvious. From a simple perspective:

1. Comments should be added to good code: Comments can help readers quickly identify the purpose and usage of functions;

2. Good Code does not need to be annotated: if you pay attention to naming rules, you can allow others to quickly identify their own functions even if there is no annotation;

3. Comments should be added to a good project.

How can we understand annotations? It should be said that if your code must rely on annotations for others to understand, it does imply that the code you write is very bad, but it does not mean that we should discard annotations. For example, most open-source projects add comments to the header of each file to indicate the ownership of the copyright. At the same time, you can use comments at the beginning of the file to clearly understand the purpose of the entire file, which will certainly help others understand your code. However, it is difficult to avoid the defects of long-lived names simply by naming them to describe the function usage. Special annotations are also the text materials that ultimately generate design documents.

In addition, some well-designed ides usually help display function interpretations by identifying annotations of specific rules, which is also one of the benefits of annotations.

7. Lazy principle:

People who have read the design patterns and refactoring may all understand that although the various models are different, they all have one thing in common: reduce repetitive work. Repetitive work will not only make the code ugly, reduce efficiency, occupy memory, but also lead to errors. Here are a few examples that are easy to understand:

1. Many UI interfaces often add some inherent constants to the Code. These numbers sometimes appear in multiple places. Then we should extract all of them and put them into a constant. The advantage is:. b. if you need to change a specific value, you only need to change the constant value assignment, instead of making an error because you forget a change;

2. Use enumeration instead of magic number. The biggest drawback of magic number is that its value has no meaning and is not easy to remember;

3. You can consider extracting functions with high similarity and passing parameters to achieve different effects.

Now, let's talk about the concept of "restructuring. So here, I would like to say that every programmer is recommended to read design patterns and refactoring books, which is the only way to write high-quality code for you.

8. Do not write "Dead Code ":

In addition to the lazy principle, when writing code, we also need to consider providing design extensibility, which seems easy to do. Here I only intend to share some basic principles with you through one case.

Case:

Suppose we want to design an application to print the names, addresses, and phone numbers of some people. For the sake of simplicity, we may design a two-dimensional string array. The first dimension represents different people, and the second dimension stores the three values to be printed.

Then I asked to add a gender to the printed list. No problem. Although it is a bit annoying, just add a grid to the second dimension.

However, I want gender to be an enumeration type. So the array is not suitable, so I have to re-introduce the class. So we have a one-dimensional array of this class.

Then I asked the support staff to add, delete, and modify, so the one-dimensional array was not suitable, and finally changed to a linked list of classes.

Note:

Although the cost of continuous modification in the case is small, it can be seen that the simple and convenient code design at the beginning leads to the final result of completely redo as needed. Similarly, the persistence of OO programming is because a well-designed object-oriented code has a good scalability. Therefore, when designing our own code, we should not easily write the code to death for the convenience of diagrams.

9. Robustness:

The Code Compiled by programmers should be fault tolerant and can throw exceptions. For example:

1. When operating an array, you must first verify the array length to avoid exceeding the limit. For a variable obtained through a function, check whether it is a NULL value;

2. You are advised to add a default operation for the selected statement. Even for a single IF sentence, you can consider adding an ELSE to handle exceptions;

3. An exception that cannot be handled by the current function should be thrown again until the function that can be resolved is captured. Another benefit of doing so is to remind others using your code to note the exceptions that may occur;

If the error cannot be recovered, a proper warning is displayed, adding logs, and then exiting the program. Few programmers will develop the habit of recording error logs in programs, which is inconvenient for users to report errors. In addition, there is a pop-up warning. Many people often print system error information directly to the interface, which is very confusing for software users.

One of my teachers once provided a very good solution to the error report: at the beginning of the project, each developer was assigned an error number segment. For example, I got 1 ~ 1000. In this way, each error message can have a unique identifier. When a customer asks for help from the Support Team, the support team only needs to identify the cause of the error by using the error code, or find me to handle it directly.

* 10. Do not show off the technology:

This topic has some limitations, that is, it is only intended for product developers. for R & D personnel, it is estimated that it is the right way to show off the technology?

I remember a book or magazine that I have read in detail, but I really don't remember it. Sorry! In short, we can use two sentences to describe the two scenarios:

Case 1: Sorry, my boss. I really don't know that there is no operation on the camera in SilverLight2.5. Do you want to switch back to flash?

Case 2: The boss is finished! Is ...... Is ...... HTML5 is not fully supported by browsers, and special effects are all supported.

Show-off technology seems to be a common problem for technicians. It seems that they are always not interested in using old technologies for projects. However, to ensure the maturity and risk control of technology, you must consider it.

* 11. KISS principles:

For many small project teams, design and programmers are sometimes a person. Therefore, this design principle must be emphasized here. The so-called KISS Principle is"Keep it simple, Stupid!". This is why the products of the most popular Microsoft companies often win. The boss of a antivirus vendor seems to have said something like this: Don't let users make choices that he doesn't understand, and 360 security guard has been developing since now, this sentence is also being put into practice (although not said by Zhou Hongyi ). There are countless examples of winning users by using the KISS Principle. Here, I just want to remind programmers who work part-time design not to make programs unfriendly to show off their technology or pursue full functionality.

Finally:

Write it here for the time being. If you have any good suggestions, please tell me that I have collected enough and I will write the second edition ^