Task decomposition and splitting function as well as future-oriented programming ideas to share

I. Background

This article and many people may think differently, not so unfathomable, but it may be very practical, it may be easier to avoid mistakes.

Business development, many of whom may face this situation:

1, every extension task, the task is not a single time and assessed by the resolution, but depends Clap

2, many functions of more than 80 lines, a large Italian group did not empty the line, did not split out the sub-function, leading others to read your code is very painful

3, write code no flexibility, such as adding a caching function, need to remove the back, had to re-modify the code publishing.

4, often found on the line to worry about what's missing some configuration

 

This article first introduces the concept and contact task decomposition and split function, then a brief for the future programming habits.

I refer here to "future-oriented programming" refers to write the code to give due consideration to future modifications.

Second, to explore

2.1 Task decomposition

Geek Time "10x programmer Work Act"

Most people know the executable size is insufficient, underestimated the extent of the task decomposition, do you need a good break down to the extent that "micro-operations". With very little decomposition of the task, we can easily develop a complete cycle, it plans to make adjustments as possible. In the software industry advocates to embrace change, and the task decomposition is a prerequisite to embrace change.

Before you begin to do a job, please carry out its task decomposition

Some companies offer a complete set of efficiency platform, including the status of the task, project, everyone split, documents, etc. involved in the project.

The need to break down tasks and estimated time before development.

Task split reasonable estimate of the time it is relatively accurate, the ability to control risk is strong, if adding an extra few hours of urgent matters, later than expected so long to come out relatively easy to evaluate.

Task decomposition makes tasks easier to perform and more measurable time, can be very clear understanding of the progress in the implementation of the current task, the remaining time.

We suggest that you can learn to do a similar project ideas.

In addition you can set aside when appropriate estimate of one-time measure, set aside time to deal with sudden events, very few cases will be developed during this time do not need to deal with any other matters urgent inserted.

 

If the company does not provide tools, you can consider trello

Or teambition

Even be in the proper way cloud the notes, create to-do to achieve.

 

2.2 Function split

Many people like to put together all the code is written, a function may lead to hundreds of lines, if other people to modify your code, extremely painful.

And myself a long time when you need to modify, if the comment is still not perfect, they themselves would waste a lot of time, but also very easy to get it wrong.

 

"Ali Baba Java Development Manual" recommended code a function of the length should not exceed 80 lines.

In order to better prepare the business function, we should be split into several logical units business function, such as inspection parameters, query, data assembly.

Different logical boundary by a space, the extracted feature suggests bulk portion subfunctions in private. Such code more readable.

For example, we concurrentGet code refactoring, its parameters and return values clear, logical, very easy to reconstruct, but also very easy to test.

 

2.3 Future-oriented programming

That is programmed to be flexible to the needs of some of the future (not all) circumstances that may arise.

2.3.1 For example, the development of a cache function

To avoid the problem on the line buffers can be removed in time, do not go to the test environment to test the cache, the cache may be provided a switch.

By apollo configuration so that no code changes and the lines can achieve a certain function (not just cache) switch.

2.3.3 For example, a module is supposed to be independent to Functions

The future is destined to be replaced by other means, it is recommended to write a separate subroutine, the future only need to replace this function just fine.

If you wrote a big business code, we need to understand the context, the difficulty of such changes on the great.

For example, here we replace the third part, the return value may be constant parameters, only modify the logic like.

 

2.3.3 For example, calling a two-way interfaces

The return value is the type Map <String, Object> So, even if the value of a key "affirmative" yes Long, try to turn our DTO objects with fastJson the Map, do not get a single property after strong turn.

If a two-way data interface to use Redis use JSON serialization, and then taken out was transferred into a Long Integer, if we get acquired by Object for strong turn, as shown in FIG Long containing the type of data map, the second go cache request, be wrong.

But if we cached our final result, then the deserialization errors that may have been hidden.

"JSON serialization lead to Long Integer type is the classic giant mess pit" https://blog.csdn.net/w605283073/article/details/90941038

Future-oriented programming, we decided to test environment to realize that although the data is correct, does not mean that the future will not change, how to better cope with change is the key.

2.3.4 notes for the future, is very important!

For example, you develop a new feature that involves a configuration change, involving changes to SQL, need to rely on other services to on-line, on the line so the situation needs to be configured XXX.

It can be recorded to the "on-line" cloud notes "Notes" folder and other notes during development.

This greatly avoids scratching on the front line to check your thinking changes, the desired configuration dependent services.

Of course, still have to re-think on the front line, but greatly reducing the workload, to avoid missing a great error.

Future development phase can record the testing phase matters that need attention.

Even needs assessment phase, you can use notes organize your thoughts, and even pre-conceived technical programs.

Functional testing stage notes in the cloud can "test" folder, recorded facilitate the testing of the tools needed to test the account, SQL statements, URL, etc., each test step to bring the best shots.

If you need to back again this manual testing, direct copy things turn out just fine.

If you want to test a consultancy part of the problem, facing the notes look like a direct shot.

If I want to mention that afternoon contents measured and tested again, as will the name of the branch, change content, function names involved, can help test log, test precautions in advance collated, that time is very easy . You do not need to organize language site, on-site to find all kinds of things need to avoid the waste of time.

and many more.

2.3.5 lessons for the future

Many people do not pay attention to method, not learning good troubleshooting techniques (see "Code troubleshoot and correct posture to avoid mistakes" ), do not take the initiative to lay a solid foundation, not like the summary.

Resulting in lost opportunities for rapid growth.

Take debugging, the wrong method of investigation mainly on so few, logical thinking through the combination of a solid foundation, careful proof can be found in the vast majority cause of the error.

We can accumulate troubleshooting experience, including the F12 Dafa (Ethereal Dafa), Code Review Dafa, Dafa debug log Dafa, Dafa search engine, control of variables, such as changing the environment Dafa.

 

Also avoid missing some things when on-line, we can accumulate on the line items to note, and then on the front lines every function investigation again.

For example, SQL change has not submitted and entered into force? There is no modify configuration item, whether submitted and entered into force? On-line order is what? How to verify the validity of functions on the line? and many more.

These should be carefully checked before on the line, and the development phase, if a conclusion can write notes in advance, before re-verify the line.

 

Third, the summary

Task decomposition and resolution functions have very similar place, large tasks are split into smaller units and easier to perform evaluation.

The future-oriented programming, in which the future is destined to replace the part, can be extracted to a subroutine, directly next to the reconstruction sub-function.

Future programming is considered more future changes, some convenient functions like a switch.

Finally, and most important point is to read the code helps to improve robustness, maintainability books, in another article on my blog super multi recommendation, welcome reference. https://blog.csdn.net/w605283073/article/details/89893440

Of course, over-design is not very good, but as far as possible "," thinking all kinds of unexpected situations, lessons for the future, for the future to do some preparation.

 

If you think this article has helped you, thumbs welcome, welcome attention to me if there is supplementary to welcome the exchange of comments, I will try to create more and better articles.

Welcome to another planet my knowledge, knowledge Planet ID: 15165241 can talk about.

CSDN marked from the time of application https://t.zsxq.com/Z3bAiea.

 

Published 379 original articles · won praise 862 · Views 1.32 million +

Guess you like

Origin blog.csdn.net/w605283073/article/details/91057040