YAGNI and junior developers

When writing code for the new system, I do not want to introduce unnecessary complexity in the design, which I will never need. Therefore, I follow YAGNI here, and, rather, refactoring, as I see the need for more flexibility or how responsibilities become more clear. This allows me to move faster.

But there is a problem with the junior developers, because they will not know when to reorganize or build the project. They simply add more code to the existing design.

So what are the best ways to solve this problem? Should I build a more robust design more often, so when adding to it, they have a good example to follow, even if we may never have to add something? Or should I just continue browsing code, education, etc.? Or both?

Do you have any problems with this type of problem? How did you solve it?

+3
source share
7 answers

I would recommend code reviews or a couple of programs. This gives you the opportunity to train your fellow developers and improve overall quality.

+11
source

, , , - . , . , , , , .

- . , " ". ; 100 70 : -)

: , ( YAGNI +) .. , , YAGNI, , , -, .

, , , . , , (!); / , - , (!) .

  • , , , , , .

  • , , , , . , .

  • , , , .

!

+9

, , .

, , .

, , , . , , , , , .

+2

, - , , , . , .

, -. , , . , .

. , , .

  • , , ?
  • , , ?
  • , , ? (I.e., ?)

, .

+1

YAGNI , .

, - unit test ( BDD, )? ( , , ), .

noobs, ( ) , .

+1

, , . , API , API. , - , , ( ), , .

, . .

0

This can help determine what kind of work they will do and then check to help build their sense of judgment, which is really what you are asking for, in my opinion. Pairing is one option, but if you can’t save a lot of time, then have a kind of “checkpoint” to see how they do it and not let them go down the wrong path.

0
source

Source: https://habr.com/ru/post/1712949/


All Articles