Lack of comments isn't such a bad thing anyway - you can largely do away with them by writing clear, expressive code and tests that specify the behaviour. I disagree that comments help you maintain code. Maintenance usually requires changing code and comments can't tell you if you've broken anything. Tests, however can, because they'll fail in that case. Tests also serve as documentation, precisely because they specify the behaviour of the system (or parts of it).
I do, however, agree, that mixing GUI code and "business logic" is undesirable. Code that has several concerns (or concepts, responsibilities, etc.) mixed together is inherently more complex to understand.
When we're taught to program, usually the emphasis is on learning the tools in the language to solve problems. This is for good reason, I think, because that's a big enough chunk of stuff for us to understand. Writing maintainable, understandable software goes beyond that though. The book Clean Code by Robert Martin gives a lot of advice about the sorts of things one should think about.
What I'll also say is that nothing is perfect. My team had an issue recently where a library upgrade broke something in one of our applications.
Tests didn't catch it. We had a good test there, which made sense at the time it was written - you can't plan for things you don't know are going to happen and anyway, trying to account for all possible things that could go wrong isn't going to be a good use of time (aside from the things one could reasonably expect to go wrong, of course). Anyway, once we knew what the problem was, we could tweak the test and the failure was reproduced. We made a fix and the test passed, giving us feedback that things were working as expected.
There are different kinds of tests and the app in question is a web app. What we should have also had were smoke tests that hit the running app and check things are OK at a high level (e.g. you get a 200 OK response). These are run at deployment time and if they fail, the deployment doesn't succeed, leaving the previously deployed version.
I do, however, agree, that mixing GUI code and "business logic" is undesirable. Code that has several concerns (or concepts, responsibilities, etc.) mixed together is inherently more complex to understand.
When we're taught to program, usually the emphasis is on learning the tools in the language to solve problems. This is for good reason, I think, because that's a big enough chunk of stuff for us to understand. Writing maintainable, understandable software goes beyond that though. The book Clean Code by Robert Martin gives a lot of advice about the sorts of things one should think about.
What I'll also say is that nothing is perfect. My team had an issue recently where a library upgrade broke something in one of our applications.
Tests didn't catch it. We had a good test there, which made sense at the time it was written - you can't plan for things you don't know are going to happen and anyway, trying to account for all possible things that could go wrong isn't going to be a good use of time (aside from the things one could reasonably expect to go wrong, of course). Anyway, once we knew what the problem was, we could tweak the test and the failure was reproduced. We made a fix and the test passed, giving us feedback that things were working as expected.
There are different kinds of tests and the app in question is a web app. What we should have also had were smoke tests that hit the running app and check things are OK at a high level (e.g. you get a 200 OK response). These are run at deployment time and if they fail, the deployment doesn't succeed, leaving the previously deployed version.