undefined | Better HN

0 pointsdijksterhuis1y ago0 comments

> Of course I agree that code should be organized logically, but I wonder if you could expand on what you mean. Do you drill down into finer and finer directories of detail, code units, classes and functions?

from the parent (i am not the parent)

> I try to follow the logic and structure of the project in a way that feels natural and easy to follow later.

in my own experience it applies to everything in a codebase.

what the end state looks like completely depends on the problem domain at hand, and the tools used to solve the problem.

how to make a codebase “intuitive” is learned, not taught. understand the problem domain, understand the tools in use, then refactor, refactor, refactor, refactor until it makes sense.

> I work with someone that navigates the tree structure of all our directories every time they need to look for something

sounds like they have yet to learn how the code modules are organised.

possibly because the modules are not intuitively organised, possibly because there’s a lot of code, possibly because they just don’t care and don’t mind the mental break of mindlessly looking for the right module.

0 comments

1 comments · 1 top-level

daltonpinto1y ago

Not only learned, but it changes with time.

When reviewing code, the reviewer responsability is not only to make sure that it works, otherwise tests and its coverage would be enough, but they aren't.

If a reviewer sees that something does not fit with the convention that the team agreed, it should be questioned and also teached or discussed (if some new addition force the team to do so).

You don't need to know all the code base by heart, but how to follow it and place it.

Something like, does your team uses DDD? Where code that interacts with database should be? And how? How your templates are done? Do you use presenters? When? How? Any other patterns?

j / k navigate · click thread line to collapse