Cohesion and Coupling in Large Projects

OK, but that's fraught with peril. You first have to know what the method or class is supposed to do now and in the future, and code has a tendency to mutate out from under you. The trouble is that the change can be slow and subtle, and then one day it strikes you (or, more likely, another developer) that the class has become kind of gnarly. The absence of fairly clear-cut guidelines means you're winging it all along.

"Also I am sure you must have some idea of how you can group code modules your project."

Things go together until the don't. Over time the behavior some code creeps over to some new realm, and one day you find the code a bit tangled. I'm wondering to what extent there are, or can be, applicable rules to alert you before your gut kicks in.

"Moreover looking at types of cohesion can give a decent idea of what elements can be grouped together."

True, understanding the different ways things can be associated can help. But there's quite a bit of subjectivity. Maybe that's unavoidable, but the article (and perhaps most similar articles) don't go far enough in discussion concrete, repeatable practices to deal with this, or discussing why this may not even be possible.

It is very much like design articles that advocate being "simple" without offering a compelling definition of simple or how you actually achieve it.

But that's the hard part.

(Also, I have to wonder to what extent this is more a problem with OOP and less with FP. )