Ruben Astudillo wrote:
I recently came across the following blog-post:
http://blog.cleancoder.com/uncle-bob/2015/04/15/DoesOrganizationMatter.html
It speaks a bit of simplicity, efficiency and stuff that isn't important. What is important at least to me was the concept of project scheme, summarized on the following phrase:
``And so this gets to the crux of the question that you were really asking. You were asking whether the time required to learn the organization scheme of the system is worth the bother. Learning that organization scheme is hard. Becoming proficient at reading and changing the code within that scheme take time, effort, and practice. And that can feel like a waste when you compare it to how simple life was when you only had 100 lines of code.''
And that is something I totally struggle at approaching new projects. The only reason I could understand XMonad for example is because they gave a general overview (thanks) of it on the Developing module.
I feel I got a problem of methodology. What approaches are you guys using to understanding new projects schemes on a efficient manner? How long it usually takes you?. Any advices? Thanks in advance.
I find it very difficult to understand large projects and I very well know the feeling of being overwhelmed with masses of detail. One way that often worked for me is to just start hacking. Find something that bothers you, a lacking feature, or some badly written piece of code you think should be re- factored, anything that gets you motivated. Start with a small change somewhere, then see what breaks. This lets you explore at least the parts that are somehow related to the change. It helps if there is a comprehensive test suite. After a while, when you feel more confident, change something deep at the bottom, preferably so that it requires tedious work in many dependent modules to make the whole thing compile again. This gets you in contact with large parts of the system and has always been a great help to understand the whole because now and then you do have to think about what you do (not everything will always work if it compiles and in Haskell even getting things to compile can be a challenge). Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams