849 karma · joined October 7, 2009
Reading the code may not be enough to understand the behaviour of your program, but believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
(by high level, I mean the code living in the higher layers - of course we don't often read the code of the generated assembly, or the interpreter, or the browser, but that's because they're reliable abstractions, unlike prompts!)
I mean, in an app that uses Rails by-the-book, you won’t even find a class instantiation. No call to new. You won’t find a class that does not inherit from a framework bass class either. The framework handles everything, don’t worry.
Emphatically, no. It’s way too complex, every time. Ceinture et bretelles, as we say in French.
There is no one size fits all solution. Frontend-heavy projects have their place, server-rendered ones too.
I have some questions.
Are you doing this for client-facing production code?
It seems you believe painting over APIs with some amount of documentation will guarantee the implementation is correct and well designed. Am I misreading that?
You say you still read code when code is « algorithmically hard ». How do you define that?
Software systems have requirements that are essential but not algorithmically hard. For instance, access control in a web application must be thorough and cover all REST resources. How do you know the implementation has the desired properties if you don’t read the code?
Do you have tests? How do you know they’re correct if you don’t read the code? Moreover, how do know if their coverage is sufficient if you don’t read the code?
Do you refactor code or is that not needed anymore?
I don’t understand your answer to the question of why anyone would publish a library if no one reads code anymore. « For the exact same reasons as before ». How so? This isn’t making sense.
This is as misguided as « don’t make mistakes ». Do not expect good decisions from something that does not feel the pain of bad decisions.