Rather than writing a monolithic code, I've been taught to find the parts of code which can be reused (in the same code or in others) and create a function based on them, which should perform "one and only one" task. Is there a term for this programming style? Modularization? It's definitely not functional programming, because that's something different (even though you do tend to define functions and reuse them in functional programming too).
The practice of making smaller (potentially reusable) parts is called functional decomposition. This is a general engineering terminology that is not limited to software engineering.
An even more disciplined practice is the do-one-thing rule rule: Not only are complex functions decomposed in smaller parts, but "Functions shall do one thing only and do it well".
This style alone doesn't have its own name as far as I know. However, together with a couple more principles and rules, it is part of Clean Code practices.
Caution: There is a frequent confusion between do-one-thing rule and the single responsibility principle (SRP). This is because both are described in R.C.Martin's book, Clean Code, and the SRP naming is unfortunate and confusing. SRP is not about functionality, but about reasons to change. This is best explained by Uncle Bob himself in this article
I know at least 3 different principles which fit to your description:
The "Single responsibility principle" (SRP, the "S" in SOLID) refers to what you mentioned by functions with "one and only one" task.
The "Don't repeat yourself" principle (DRY) is applied when you don't copy code for reusage, but refactor it into a function instead.
The "Single level of abstraction" principle (SLA) means not to use "reusage" as the one and only measure for such refactorings, but also use functions as building blocks of a - surprise - certain level of abstraction.
If I got you right, these three principle together should cover what you had in mind.
And yes, the term "modularization" fits also, but more at the level of modules, which is typically coarser than just functions.
The issue is that "separating code" is too broad a topic for it to have a specialized name. For example, most SOLID implementations revolve around introducing additional separation in your code, but doing so in many varied ways, for many varied reasons.
And SOLID is by no means the only guideline here, although it seems to be the most prevalent one in OOP.
If anything, the difficulty is not in separating the code, but rather how to loosely (and of course correctly) connect the now separate pieces.
Purely semantically, I tend to refer to code separation as compartmentalization:
To separate into isolated compartments or categories
This has some relation to the fields of engineering:
When referring to engineering, compartmentalization is the general technique of separating two or more parts of a system to prevent malfunctions from spreading between or among them. This entails the breaking up of a project or problem into sub classes and sub categories, with the intention of simplifying the task at hand, or to efficiently distribute it amongst a number of teams or people.
and information security:
Compartmentalization, in information security, whether public or private, is the limiting of access to information to persons or other entities on a need-to-know basis to perform certain tasks.
While this is, as far as I'm aware, not an established programming term, its meaning seems clear from both the dictionary definition and its application in similar fields.
create a function based on them, which should perform "one and only one" task
"One and only one task" is effectively the Single Responsibility Principle (the S in SOLID) at play.