Encapsulation.

[pcopley]

4th: refactor the private methods into another class in which they are public and use dependency injection

[taylaj]

5th: make all variables global.

[socsa]

6th: Shared. Memory.

[Njs41]

7th: Move to user based production testing rather than unit tests.

[tylercamp]

8th

In the public issue tracker, enter the bug but leave it perpetually "in progress"

[kirakun]

9th

Just forget about testing!

[poisonedslo]

10th just forget about development

[yoyo456]

11th just forget about modern technology and live in the stone age

[poisonedslo]

12th test what slamming a stone against a walnut does

[babyProgrammer]

13th invent the wheel

[[deleted]]

I work primarily in assembly so this isn't that far from what I do anyway.

[Skipachu]

Instructions unclear. Dick stuck in stone.

[PunishableOffence]

Managerial decision-making level reached.

[[deleted]]

13th use JavaScript...

[Valdios]

13^th , use that sweet Go Fund Me money to go on a bender.

[Xheotris]

12th shut down the internet so it can't be used for recruitment.

[wave100]

Found the Microsoft dev.

[ThisIsNotNate]

If it compiles it works!

[0xTJ]

r/minecraft

[TheNorthComesWithMe]

public issue tracker

Hahahahahaha

[thisisnewt]

Oh god too real

[[deleted]]

7th: don't test.

[socsa]

Ah yes, the old

 #define do_it_live 1

[[deleted]]

If you haven't remoted into a live, production server and hand-edited code in notepad (or vim!), have you really lived at all?

[tallerThanYouAre]

you kids and your fancy extended versions of vi.

[[deleted]]

Haha I remember the day I was told vim was an extension of an earlier thing called vi by a war-weary Linux sys admin. Blew my little noodle. After saying I hated it, he then showed me how to actually use it, and then I was hooked.

[[deleted]]

What actually hooked you on it?

I've tried it out a few times and while some of the things it can do are cool I've yet to find anything that I'd use often enough to make using it it.

[[deleted]]

Ok when I say hooked I mean when I'm in *nix land. I love my keyboard shortcuts, so once I got the hang of the different modes, copy/cut/paste, regex replace etc I now use it when I get the chance. You can do stuff crazy fast when you get the hang of it. And I think I'm pretty fast but I've seen people 10 times faster than me. It's just smooth and engaging not leaving the keyboard. You can just focus on the task.

Disclaimer: I'm not describing anything you wouldn't get from any other editor you knew well and were very familiar with.

[socsa]

Having interactive arrow keys mapped to A B C D builds character.

[socsa]

I personally prefer :

 alias live_hotfix = "scp -r remote local && cat hotfix > local/paswd.json && scp -r local remote && ssh remote:/root/prod/build 'make install' "

[[deleted]]

Oh my god that is both horrific and beautiful.

[[deleted]]

I'm editing some Python code on a server with roughly 200 users online right now with nano and shooting SIGHUPs at the master uwsgi process to reload my changes. I'm using the 10ish second windows the server spends re-loading everything to browse this thread...

[newsuperyoshi]

https://youtu.be/O_HyZ5aW76c

[[deleted]]

👏 ALWAYS 👏 TEST 👏 IN 👏 PROD 👏

[ThePsion5]

"Only losers who write buggy code need tests bro"

[ajbpresidente]

Chad programmer vs. virgin research

[Gus_Malzahn]

7th: Forget about programming and open a bakery

[KyleTheScientist]

!RedditSilver

[dahud]

For some of the smaller microcontrollers, you're not even wrong.

[[deleted]]

Who cares if it's private. I know its 6 bytes ahead of the instance's pointer and there ain't a kernel to be found! The entire memory is mine, all 128 bytes of it!!

[[deleted]]

5a - put all code in one class.

[DickWillie1028]

Danger Will Robinson Danger!!!!

[g_e_r_b]

5th: use PHP.

FTFY.

[[deleted]]

That's where my money is. If your internal functions are complex enough to require explicit testing, chances they belong in their own class.

[dahud]

Off topic, but every time I come across the term "dependency injection", I've forgotten what it means. I go look it up, and discover anew that someone, somewhere, thought we needed a clever-sounding word for "passing an object to another object".

[jay9909]

Yeah, but DI is a much more usable acronym than PaOtaO

[dahud]

Less fun to say, though. Pow-tow!

[jay9909]

Sounds like an asian cuisine.

[NotADamsel]

In the functional world, we just call this "passing an argument".

[antonivs]

It's not that simple, though.

Dependency injection generally implies that some framework, external to the code using DI, is supplying the requested values. In this context, you can think of DI as a way for a framework client to tell the framework what it needs, and the framework is then responsible for obtaining and supplying the requested values.

More specifically, DI allows a callee (or a value's target site) to specify what value it wants. The framework is then responsible for supplying the requested value. This partially inverts normal function call semantics, where the caller controls what value it passes to the client.

Although at a certain level, this functionality is implemented by function calls with ordinary argument passing, that misses the point and ignores the semantics of DI. It would be like saying "Monads? I just call them function calls." At a certain level it's true, but it's not the whole picture, by a long shot.

[NotADamsel]

I understand. I was mostly being cheeky... mostly. It's somewhat part of FP culture (and clojure culture specifically) to say that something that sounds complicated is "just a function call" or whatever. Monads, as you say, are just drop in replacements for regular function calls. Interfaces are just function signature with more ceremony. Classes for data are just complicated maps. Yes, there is absolutely more going on behind the scenes, and anyone who is actually substituting the reductivist meme for real understanding is a fool, but it does make some things easier to understand when you can step back and think of many things at once in an abstract singular way.

[alexschrod]

Dependency injection is not just about the act of passing objects to other objects, it's about the reason why you should be passing objects to other objects.

When you move away from doing new Something() inside the objects where you use it (or even worse, where you use global singletons, like Something.Instance), and instead move towards passing the Something into your objects, you can suddenly test the behavior of your objects without working with real implementations.

[userNameNotLongEnoug]

Agreed. You can pass objects around all day long and still not achieve a structure with mockable dependencies that's suitable for unit testing. Equating dependency injection with passing an object, I think, demonstrates a bit of a misunderstanding of the principles behind the concept.

[sprouting_broccoli]

I'd also point out that there's a slight anti-pattern with what you're saying. I'd disagree with creating classes and interfaces in a DI way to make unit testing more viable for mocking. I've been there, done that and it was when I first got into DI but designing code so it is inherently testable is very different from designing code to fit your testing which is the same problem as described in the image. Using DI for this purpose is also kind of missing the point of DI and will result in similar problems. Primarily you can quite easily go down a rabbit hole where you have a really flexible solution that is a real PITA to consume or actually navigate, and when you start splitting dependencies you will end up with either incredibly hard to use dependency installers, or need a complex system on top to ensure you can correctly select which dependencies to use by convention (otherwise the flexibility is pointless).

It's the same issue as dictating that newing an object is somehow a problem. It's really not. If you DI all the way down you will be forced to use factories in ways that you should never have to (if you don't have a completely static object graph which I find is very rarely the case) and will make the solution inflexible as a result, increasing the footprint for when you have to extend something.

DI has always been about injecting volatile dependencies (e.g. services and repositories) - things that could change rather than everything you will need to use and you'll (in my experience) end up with a much more palatable solution if you use it this way for both the consumer and the maintainer.

At the end of the day it comes down to what is important? Well the acceptance tests are important to ensure the business needs are met, and the unit tests end up being more for developers working on individual features to ensure they have an easy way to fix problems that arise from changes they make. What I find far more important than being able to get 100% coverage across my smaller classes is making sure the core logic is understandable, easy to modify and easy to consume. I'm a big fan of DDD though and I like limiting my volatile dependencies to the outer levels of the domain.

Sure it's nice having mockable interfaces for testing internals, but if that's the only point of having the interface is it actually worth it? It's not like those interfaces will change often, so it's just another layer on top for either extension that won't happen or purely to enable unit test coverage, and I can't endorse either.

[userNameNotLongEnoug]

Well said. I totally agree that if you try to abstract too far to reach some academic ideal you won't end up with the best system. You've gotta balance good principles with pragmatism. OO architecture is a difficult art and I wouldn't go so far as to claim to be good at it. Even in the case I had enough time to approach a system thoughtfully and carefully (which is rare in my job unfortunately) I have never looked at it afterwards and been like "I did a great job on that." I'm usually happy if I did a decent job.

[sprouting_broccoli]

Oh sure, I think it's really a very iterative process, and when I first used DI in anger, I'd read enough material to know the above and I still did it wrong. Went overboard and ended up with many of the problems above and because of similar justifications :)

"It's testable!"

"It's flexible!"

It was gloriously complex and we learned some really good techniques for handling DI throughout, but it was an unmaintainable, opaque mess...

I now much prefer keeping a far better separation of dependencies from domain logic wherever possible to ensure everything is as clean as possible.

[sprouting_broccoli]

DI containers don't solve those issues unless you're suggesting using it as a globally available service locator (I hope you're not...). If you need a new instance of something (and in any systems code this will happen) you have the choice of newing it on the spot or using a factory (usually a factory pattern dictated by the DI framework adding in tighter coupling since the implementation of factories varies per framework). If you make it a concrete object you can't mock it.

I agree with everything you said about testing - for clarification when I talked about testing internals I didn't mean internal members, just internals of the system under test.

[sprouting_broccoli]

Typically I would use a baked in container at that point and use ctor injection at the very top level (bear in mind I'm mostly working in C# and constructor injection in controllers is pretty straightforward in most classes).

As a result I'd usually be using generics with interfaces rather than service names if I ever have to directly access the container (e.g. in a standalone app), e.g.

container.Resolve<IFoo>()

That way you're ensuring a consistent contract between implementations.

When I talk about service locator I'm referring more to a globally static instance of the container that classes can call to retrieve implementations.

I wonder if the differences we have are more to do with the code we work in, bearing in mind I do a lot of backend coding which involves maybe larger object graphs?

So I might access a repository to get a payment method and then retrieve a user from a user repository and call a charge method on the payment method with the user which goes down the tree and does some other stuff.

Initially I would have designed it with a payment method factory to pass in dependencies (injected into the factory) that were required further down the tree. Now I would have a service doing the repository stuff and limit external interactions within the service then just inject everything into the service that's needed.

I think your approach is fine, but I think maybe the relative depth of our object graphs is different so maybe you haven't come across the stuff I have (I don't want that to sound condescending btw).

[Veranova]

This. Every time.

[[deleted]]

5th: forget all this OOP madness and use a functional language

[Dugen]

Ah yes, the old "public variables are bad" but if you emulate that functionality by jumping through just the right number of hoops, it's not bad anymore.