When it comes to programmers, the first labels that come to mind are: miserable, working overtime, staying up all night. However, all the students who work know, in fact, most programmers do things are very simple, code CRUD can be said to have no technical content, even if what do not understand according to a lot of functions can be forced to do, do a multi-threaded concurrency even high-tech, programmers this line of threshold is actually relatively low. (Here is the majority, some awesome, write algorithms, JVM, etc. Please automatically skip)

Do you feel very contradictory, on the one hand, the work is not complicated, on the other hand, but tired as a dog. Ever wonder what the problem is? Ever wonder where you spend your time?

For me, coding is a relatively easy job (I am in charge of the it system of the company, without too much technical content, with a large amount of data, but not much concurrency). From working to now, I have not spent much time on overtime coding. I still do coding every day, and I rarely work overtime for coding.

What everyone writes is some CRUD business logic code, why everyone is so tired, overtime is a striver every day? From my observations on the projects I lead, I find that most people spend most of their time fixing problems + fixing code, not much time actually developing. Locating problems includes problems found during development and testing and problems found after launching, and code modification includes bug modification and code modification due to requirements change (a special post on how to deal with requirements change is opened later).

So simple is not easy. Many people just feel simple, so the function completed their own test ok, without thinking about whether there is a better way. It all boils down to bad coding habits, bad code that can’t be fixed and changed and broken. (I’ll cover most of the coding issues I’ve seen in more detail later.)

For individuals, technology is important, but for work, coding habits are more important than technology. Most of the skills you’re interviewing for at work don’t need to be used. At work, because your coding habits are bad, the code quality is poor, the code is redundant and repetitive, a lot of irrelevant code and business code mixed together, resulting in you struggling to deal with all kinds of problems.

Therefore, as SE, no matter I take over any project team, the first step is to formulate the code framework, formulate the development specifications of the project team, and reduce the amount of code. In fact, it turns out that after this step, everyone’s code volume can go down by at least 1/3, the number of problems in the background drops significantly, and everyone will work less overtime than before.

Just to give you an intuitive example. The following is an interface for deleting data of the controller, which looks like this before I came (actually it is much worse than this at the beginning). The function is very simple, input an object ID to perform the deletion and return whether the deletion is successful. Does anybody see a problem with that?

@postmapping ("/delete") public Map<String, Object> delete(long ID, String lang) {Map<String, Object> data = new HashMap<String, Object>(); boolean result = false; Try {// Locale local = "en ". EqualsIgnoreCase (lang)? Locale.CHINESE : Locale.ENGLISH; result = configService.delete(id, local); data.put("code", 0); } catch (CheckException e) {return code -1 data.put("code", -1); data.put("msg", e.getMessage()); } catch (Exception e) {// Other unknown exceptions, need to print stack analysis, return code 99 log.error(e); data.put("code", 99); data.put("msg", e.toString()); } data.put("result", result); return data; }Copy the code

In fact, the above code is not a big problem. After I took over, I would develop my own code framework and finally make the code delivered by the code framework as follows (this is the part of controller) :

@postMapping ("/delete") public ResultBean<Boolean> Delete (long ID) {return new ResultBean<Boolean>(configService.delete(id)); }Copy the code

The technology used is AOP, and it’s not that sophisticated. How’s that？ One line of code, not a single feature lost. This is what the controller of our project team looks like now! (If there happens to be a person from the project team that I have led, I should be familiar with seeing ResultBean<> and know who I am.)

So it doesn’t matter how skilled you are, it depends on how you use it. First, lang has nothing to do with the business, and I’ve removed the framework from the code behind it (not that I don’t have it, but that it’s hidden and transparent to developers, using a technique called ThreadLocal). Second, the previous code, in fact, only one line of work, the rest of the business code has nothing to do with the framework of my code is completely invisible.

The technology used is really simple, but the coding effect is very good, because you should not think it is not important because the technology used is elementary!! With this framework, you don’t have to spend most of your time writing boring code, and you can spend more time learning other techniques. To be honest, the developers in my project team are lucky, they think they can learn something, unlike other project teams, which have been writing the same CRUD code for several years. Although I am strict, I still prefer to stay in my project team, after all, I work less overtime than other project teams.

This is what I mean when I say that coding habits (or coding styles) are more important than technique at work. I’ve been working for a long time, and these are the things that I think are the most valuable to me. Technically, I know about the same as most people, but I think I can outcode most people. Later I will write out the problems we code in our business systems one by one and share my solutions. The preliminary topics are as follows:

  1. Interface definition specification
  2. Controller specification (See here for ResultBean format and reasons)
  3. The log specification
  4. Exception Handling specification
  5. Internationalization specification
  6. Parameter verification specification
  7. Utility class specification
  8. Suggestions for writing functions
  9. Configuration recommendations

These specifications are not those programming specifications on the Internet, to tell the truth those are long and tedious, it is difficult to prove in practice, I here are fewer specifications, hit the nail on the head, you will know. Stay tuned!

I have a wechat official account and often share some Java technology-related dry goods. If you like my share, you can follow me by searching “Java leader” or “Javatuanzhang” on wechat.

Original link:
Programmer why are you so tired? – monring winds light