Architect comes up with library to make it so even a monkey could handle use case X without fucking it up. Then they go to architect land where they all stay in their ivory tower. Then use case Y comes along but nobody thinks to switch from or extend what the legendary architect gave to the people. Those who try are heretics who have gone full cowpoke. Then when things get bad enough who should come to save the day but the hurdy gurdy architect, probably not the same one as last time.
Nobody cares about your clean code
101–110 of 177 posts
Re: Nobody cares about your clean code
#102Silly premise. There's plenty of open-source products out there that will attest to the fact that the quality of a codebase has no effect on its overall commercial viability. The adage "Move Fast and Break Things" is a cancer on the software industry. I've personally had the displeasure of working in numerous teams, departments and companies that adopted such silly philosophies in the pursuit of being "innovative". I…
Rewrites aren't the worst thing ever. Sometimes writing it twice takes less time than getting it correct the first time.
Re: Nobody cares about your clean code
#103Clean code is not meant for end users.
Re: Nobody cares about your clean code
#104"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what…
Honest question - does that really make you finish up prototyping faster than having SOME level of organization? Unless I’m coding something so quick that I’ll be done in the same couple of hours, I feel like at least having some sensible names for things, some comments here and there (in particular TODOs), etc helps think (and prototype) much faster.
Re: Nobody cares about your clean code
#105Developers are stakeholders to, ESPECIALLY the author. Writing clean code gives me aesthetic pleasure so that is reason enough for me to do so.
Re: Nobody cares about your clean code
#106Earlier quoted context omitted.
It’s because it makes no effort to prevent people doing insanely insecure things. Rails has a lot of safeguards for insecure things like using user input to update a record. PHP won’t even fix bugs due to backwards compatibility. They worked out their sql string escape function didn’t escape properly but instead of fixing it and telling everyone to check their code, they duplicated the function and prefixed the name…
PHP has supported SQL parameter binding for at least 17 years now. It's the standard way to execute SQL queries and it replaces any usage of mysql_escape() or related functions. It seems your criticism towards PHP is the use of legacy code which is kept for backwards compatibility. No sane person in the industry writes code like that. Those who do would have had concatenated user input to SQL queries in any language…
I read somewhere, about two years ago, that php is present in about 80% of the web to this day. Let me see if I find the link.
Edit: found the link https://w3techs.com/technologies/details/pl-php
Re: Nobody cares about your clean code
#107At first I thought "Meh, so what?" but then, after visiting remoteok.io, I'm impressed. That's a pretty polished site with a laser-like focus.
Still seems crazy to have the whole site in a single PHP file, though. A dozen files (or even a few dozens) might have been saner. But then again, in that case we wouldn't be talking about the site...
Re: Nobody cares about your clean code
#108Clean code shouldn’t be thought of as a principle. It is an engineering decision and every engineering decision has trade offs.
Re: Nobody cares about your clean code
#109Earlier quoted context omitted.
When I'm prototyping or hacking something together, it eventually becomes production. I cannot relate to people who make prototypes to throw away, I've never done it, and I don't know why I'd do it. Due to that, I write my first line of code as if it's going to be on production forever, because it will.
> I cannot relate to people who make prototypes to throw away, I've never done it Have you ever had that moment when you say: "Oh damn, now I got it! I should do it entirely differently!" — and then you code up a different approach, the approach that works well enough. If you had this moment, it was the moment of throwing away the prototype.
This occurs frequently.
Convincing management to refactor your code is another thing entirely.
Re: Nobody cares about your clean code
#110"throw the first one away" When I'm prototyping or hacking something together, I don't write tests, I don't comment/document much, I use lots of shitty variable/type names, lots of commented out code, debugging printfs, not much organization of files (often one large file). The prototype software is write-once, read-maybe. Maybe I'll want to see what I did down the road, but more likely I'll be shortly rewriting what…
I do the opposite:
- I paper prototype until we have something that makes sense, fills the space our crew sees an opportunity in, and seems to do the job without needing too much work to implement. Takes about half a day to a day of "what if we did this" and "how about that" scribbling to do this if everyone's available and focused, and then we discuss what we have and whether it works for us and whether we actually have a business or not.
- Next, I spend a day or two thinking: What architecture makes the most sense? What language makes the most sense (in terms of what it can do for us and how many people know it)? What technologies will cut away the most work without requiring a lot of shoe-horning? etc.
- Next, I write the minimum within that framework to get a visual prototype that allows us to go through the various sections and see it in action.
- Next, we look at this prototype and decide how closely it matches our vision, and whether our vision needs changing.
From there, the most common changes to the actual code are tweaks to systems rather than the whole architecture, but the architecture itself makes this easy since it's designed to be modular for our particular use case.
I actually can't think of a single prototype that I've thrown away to rewrite in the last 20 years, including a complex 6-minigame educational product I brought from zero to live-and-generating-revenue in the app store in 3 months as the only developer. Clean code isn't for your clients; it's for YOU and your team. Clean architecture, code and discipline make your work go easier and faster IF you actually do it.
If you're starting with code prototypes rather than paper prototypes, you're doing it wrong and it will take you longer as a result (and you'll probably also need a rewrite).