I'm a self-taught dev focused on websites and Python development.
My friends call me the "Data Genie".
When I get bored, I find tech to read about, write about and build things with.
Oh BTW on the SOLID part yes knowing that theory (and also applying it) gives one an approach to architecture using patterns and best practices for main table code. So I agree with studying up on those.
I read a book on TDD which said the authors knew a team which have super SOLID code and code coverage with tests etc. So looking at stats the codebase looks healthy. But the codebase was a nightmare to work with because for example the abstraction was so high that you have to look at 7 classes or functions which are strung together in order to make a change or even just read what is going on.
I currently work on a codebase at work which is that spagetthi code in a sense where one class inherits from 5 classes and they each inherit... so it becomes magical and hard to reason about.
I like a philosophy or "Zen of Python". About don't try and be clever and show off how few lines you can use or what obscure code you can use. Rather make the code readable and editable for yourself and fellow devs.
And sorry to hear about your poor experiences in receiving vague code reviews. I've generally had good experience in that regard and I am to give non emotional feedback with reasons. I also separate what I would prefer from my style and what is best practice if we had the time and what is right given the problem (let's not over-engineer and knitpick but rather focus on something else more important)
That problem that you mention about having multiple is a smell identified by Martin Fowler. It is called 'shotgun surgery', I believe that happens when developers forget about abstraction. At some point someone didn't do his job and throw code without giving a refactor.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oh BTW on the SOLID part yes knowing that theory (and also applying it) gives one an approach to architecture using patterns and best practices for main table code. So I agree with studying up on those.
I read a book on TDD which said the authors knew a team which have super SOLID code and code coverage with tests etc. So looking at stats the codebase looks healthy. But the codebase was a nightmare to work with because for example the abstraction was so high that you have to look at 7 classes or functions which are strung together in order to make a change or even just read what is going on.
I currently work on a codebase at work which is that spagetthi code in a sense where one class inherits from 5 classes and they each inherit... so it becomes magical and hard to reason about.
I like a philosophy or "Zen of Python". About don't try and be clever and show off how few lines you can use or what obscure code you can use. Rather make the code readable and editable for yourself and fellow devs.
And sorry to hear about your poor experiences in receiving vague code reviews. I've generally had good experience in that regard and I am to give non emotional feedback with reasons. I also separate what I would prefer from my style and what is best practice if we had the time and what is right given the problem (let's not over-engineer and knitpick but rather focus on something else more important)
That problem that you mention about having multiple is a smell identified by Martin Fowler. It is called 'shotgun surgery', I believe that happens when developers forget about abstraction. At some point someone didn't do his job and throw code without giving a refactor.