|
|
|
|
|
|
by the_other
961 days ago
|
|
|
In the case of understanding a system you’re contributing to, you’re only half-right. Often code includes decisions, assumptions and designs which aren’t onvious from the code itself. It’s pretty common to understand how it works by reading it, but not to know why it was made to work THAT way; not to learn about the problem the code attempted to solve. It’s very hard to capture even when you’re rigorous with naming conventions and don’t abuse patterns and idiom. So relying on reading code also relies on having the people who wrote the code available to explain the “why”. Or documentation. |
|
|