Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My favorite principle for code quality

pathsensitive.com

Post reply on HN
Print view View original

111–115 of 115 posts

Re: My favorite principle for code quality

#111

Post by cleong »

mikekchar wrote: post #64

My advice for design: Design is hard. Good design is so hard that you will almost never see it in the wild. It becomes even harder when you work with other people. Your carefully crafted ideas will be crushed under the foot of the next confident programmer who thinks they have found the holy grail of design. As more and more programmers are added, they pour in their particular favourite flavour of programming sauce.…

Although pracitcally what you said is true, many teams I've worked in had seniors that would design projects based on their interests. I'd like to say there is a way to design objectively based on trade-offs for the project. If you ever worked in enterprise-like "frameworks" like Magento you will see the design patterns and how they achieve certain goals in a project. E.G EAV, XML module & layout declaration for flexibility, MVVM for single responsibility controllers meant for large enterprise teams working on the same controller at one time.

Re: My favorite principle for code quality

#112

Post by toast0 »

wolco wrote: post #44
some_account wrote: post #36

Earlier quoted context omitted.

I agree. Developers should never build anything more complicated than it has to be at the moment. Simplicity is key to happiness and productivity.

We shouldn't go too far with this line of thinking either. When things are immutable design early. Consider an api. You can build a basic api without a version parameter when you release. When you need to change the api and keep backwards compability you introduce a version parameter. You are forever stuck with the first version being the default.

Whatever version is in the documentation people read is the default. If it's not compatible to use v2 when expecting results from v1, you can't change the behavior for no version specified anyway.

More important for an API is building in a way to signal users that the version they're using will be or has been discontinued, and a way for the users to test that.

Re: My favorite principle for code quality

#113

Post by wvenable »

dagss wrote: post #98
wvenable wrote: post #70

Earlier quoted context omitted.

Tests lock you down to particular design by way of the interface. If you want to fundamentally redesign something, you're likely going to have to change the tests as well. The power of automated testing is really to ensure that nothing changes, which is great when doing bug fixes, but not so great for actually evolving software. Ultimately it just becomes easier to add new code than it is to ever change a design that…

Sounds like you are writing tests at the wrong level then. I was talking about a regression test for a fix for a bug found in production. For a typical backend, write such tests against the publicly exposed API. If you end up breaking tests as you refactor it means that you have broken backwards compatability for others who use the API...

We seem to be talking at cross-purposes here. I agree that tests enforce backwards compatibility (or compatibility in general) but they also enforce a particular design. Fundamentally redesigning something generally involves breaking the testa and the API.

To put it another way, if you never break your tests you can only ever fix bugs or add more code -- you can never remove code or redesign.

Re: My favorite principle for code quality

#114

Post by ScottBurson »

auxbuss wrote: post #102
antirez wrote: post #35

I can't disagree more with this post. One should always aim at trivial code, but as things get more complex, it is there the the sensibility should fire in and make you say, ok I need more abstraction now, and refactor accordingly. But even then it is important to just add the minimum amount of abstraction to generalize the problem at hand, without thinking like "but why if in the future we change things..." Unless i…

There's an excellent discussion on this topic in the sample chapter, Rediscovering Simplicity[0], from Sandi Metz's book, 99 Bottles of OOP[1]. I often use it as a source for discussion with devs. [0] https://www.sandimetz.com/99bottles/sample [1] https://www.sandimetz.com/99bottles

I like this, though I think anyone who mentions SLoC as a metric is honor-bound to quote Dijkstra: My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

Re: My favorite principle for code quality

#115

Post by mikekchar »

cleong wrote: post #111
mikekchar wrote: post #64

My advice for design: Design is hard. Good design is so hard that you will almost never see it in the wild. It becomes even harder when you work with other people. Your carefully crafted ideas will be crushed under the foot of the next confident programmer who thinks they have found the holy grail of design. As more and more programmers are added, they pour in their particular favourite flavour of programming sauce.…

Although pracitcally what you said is true, many teams I've worked in had seniors that would design projects based on their interests. I'd like to say there is a way to design objectively based on trade-offs for the project. If you ever worked in enterprise-like "frameworks" like Magento you will see the design patterns and how they achieve certain goals in a project. E.G EAV, XML module & layout declaration for flex…

Yeah. I think that kind of thing can work in certain circumstances. Definitely I've seen the dictatorial design approach be quite successful -- at least short term. It's pretty awful for the participants, though. Normally your best talent leaves. I'm less convinced about the framework approach. I've never actually seen it work well. Normally the design is just not flexible enough and something breaks pretty badly. Of course, there is a limit to the number of projects you can see in your lifetime, so I could well be missing something :-)
Post reply on HN