Live data from Hacker News

Are software engineering “best practices” just developer preferences?

floverfelt.org

271–280 of 369 posts

Re: Are software engineering “best practices” just developer preferences?

#271

In your example, read the spring manual. You need the inference to help spring generate proxies for your service class. You could use cglib to remove this requirement but it's the way the spring API has been for ages. Also using an interface let's you easily mock things out and write dummy test implementations. Pretty valuable.

I read about spring's best practices and think some are unnecessary boilerplate code without any real benefits.

I get the theory, but in practice, the benefits are just theoretical. You could reimplement interfaces for your tests, but it is easier just to use a mocking library.

Re: Are software engineering “best practices” just developer preferences?

#272

The biggest issue I saw with "best practices" in my career is the failure to take into account who it claiming it to be a best practice, and in what context . I saw too many junior developers read a rando blog article, then get a non-technical / semi-technical manager excited about something that made their life easier, even though it was by no means a good practice for the context at hand. Or alternatively, believe…

Spot on about reading a random blog or article. I think many engineers at work are under pressure to deliver, and are looking for quick solutions. They do a search and see a Medium post related to their problem written by someone who says they are an “ developer at ”, and for some reason most readers see these authors as an authority in their domain (because why else would they be writing about it? /s), and just accept the blog post’s practices or conclusions. Once read an article a long time ago about Android’s async task , and some blog post claimed it should only be used for operations less than one second. I looked at the official documentation and while it did mention that it should be used for short operations, no where did it mention it should be less than one second specifically (unless I missed it). I saw the same advice mentioned by many other devs who referenced that same article.

Re: Are software engineering “best practices” just developer preferences?

#273
post #252

Earlier quoted context omitted.

Each of these things prevents isolated testing of dependent components. For that reason alone they are nonstarters.

globalvar = new NopImpl() works fine for testing. If you squint, you can even think of dependency injection frameworks like Dagger as a lot of boilerplate around a global database of instantiations.

[deleted]

Re: Are software engineering “best practices” just developer preferences?

#274
Codified Software Best Practices have been around for decades.

Steve McConnell (Code Complete, Rapid Development, etc.)[0] used to be the Best Practices Editor for the IEEE.

It’s just as the author mentioned; no teeth. Companies are happy to pay for slapdash work (thus, undermining the drive to do good work), and employment tests often don’t really have much bearing on real-world engineering.

I’ve spent decades refining techniques and habits that I think work quite well. I occasionally write them down[1], which I find helpful in understanding them better.

[0] https://stevemcconnell.com/

[1] https://littlegreenviper.com/miscellany/

Re: Are software engineering “best practices” just developer preferences?

#275
post #256

Earlier quoted context omitted.

I would trust someone graduating with CS degree from non-ABET accredited Stanford rather than someone from ABET-accredited CS program of Athens State University.

... Except Stanford is ABET accredited, and as are all the major Engineering institutions and leaders. The fact that most users here are reaching to downvote literally the fact that leading Engineering institutions all fall in this bucket is absolutely depressing from this community. It's clear some feelings have been "hurt" here by other users having higher educations.

It's not all-or-nothing for the university -- some programs are not.

"Like the CS department, the EE department is no longer ABET accredited. While such accreditation is useful in certain disciplines such as civil engineering, it has no practical significance whatsoever in computer science."

https://cs.stanford.edu/degrees/undergrad/Considering.shtml

Similarly, UC Berkeley also declined to renew their ABET acreditation for their EECS department, and so they haven't been ABET-accredited for the past few years.

"Both of these programs are accredited by ABET through September 30, 2019, but because we have decided not to continue applying for ABET accreditation, we will be developing a single set of student learning outcomes for our department, rather than using the two sets of outcomes mandated by ABET for EECS departments. "

https://eecs.berkeley.edu/academics/undergraduate/eecs-bs/ob...

Re: Are software engineering “best practices” just developer preferences?

#276

Earlier quoted context omitted.

> somebody got flamed harshly when he mentioned using a global variable. Harsh bashing on global variables is such a dumb thing. Yes, they can be dangerous. Yes, many had problems due to using them. Yes, we should tell beginners to avoid globals. But there is no reason to ban them altogether. Experienced programmers should utilize them whenever it makes sense (instead of passing down a value of a local one to almost…

On the contrary, I think beginners should use them because it reduces cognitive load in tiny applications. My standard rebuttal to anti-global dogmatism is "there's only one instance, and never needs to be more. If/when we do, we can consider doing something else."

[deleted]

Re: Are software engineering “best practices” just developer preferences?

#277
post #4

Steven Sinofsky gave a talk and said something to the effect of, we've been building roads, bridges and edifices for thousands of years. So, best practices and solved problems abound---and even then we still get it wrong sometimes. Whereas, software engineering is maybe 70 years old (generously)? So, there is much to learn and a lot of "baseline" knowledge that has yet to be established. I think it's a good way to th…

Programming changes practice quickly and often because it's cheap to do so compared to physical engineering which is slowed down by execution time, high materials cost, and sunk costs.

The interesting question is this: would other engineering pursuits (say civil) have just as much chaos and lack of authoritative practices, if changing practices would be equally fast and cheap for them?

Re: Are software engineering “best practices” just developer preferences?

#278
post #68
post #34

Earlier quoted context omitted.

Civil (and other engineering) got better because there was motivation to improve that came from multiple directions: literal lives at stake, the pride of good craftsmanship, iterative or even grand steps forward in knowledge, etc. Software engineering as a discipline is dominated by appeals to authority ("Clean Code", "Google does it this way", "Djikstra said so", etc.) without any (or at least not much) attempt to a…

What about we apply this to software engineering? > If a builder constructs a house for a man but does not make it conform to specifications so that a wall then buckles, that builder shall make that wall sound using his own silver. - Code of Hammurabi, 1755–1750 BC

The software is as sturdy as the day it was written, there has been no deterioration - if your copy has become broken, the builder can easily supply another copy using his own silver.

On the other hand, if the customer finds out that their door is inconvenient and it would be much better to have it a bit to the right, noone expects a house builder to fix that at their expense, you bought what you saw. And the same thing if it turns out that the house is very difficult to maintain because it's inconvenient to get to the piping. And ifthe customer buys a bigger car and the garage needs to be adapted to fit it, that's their expense.

Those three would be the main equivalents of all the commonly seen software "best practices" which generally either refer to feature design, the maintainability of the code, and ensuring compatibility when an integrated system changes.

Re: Are software engineering “best practices” just developer preferences?

#279
Lots of Java Frameworks (definitely Spring) will generate wrapper classes for your code to handle things like method level authorization, pre/post method logging, Exception transformation. This is generally termed "Aspect Oriented Programming". This is exactly whats going on with Spring's @Service annotation. In order for you to still be able to call your methods even though the class will be some sort of proxy at runtime, an Interface is required. It may seem silly but it all makes perfect sense when you understand whats going on.

Edit: Surprised I haven't seen this mentioned in any other comments. I had thought this was pretty common knowledge, at least amongst people with Java experience.

Post reply on HN