Jump to content

Do you use Design Pattern ?

NoOverflow

All is in the title

 

Personnaly for small personnal project i only use Factory and Adapter generaly (a listener is needed of course), but i don't really do unit test

For bigger project i use way more pattern and more test

And you ?

Link to comment
Share on other sites

Link to post
Share on other sites

I use tons of patterns at work. DTOs, builders, observers, factorys, adapters, facades, etc. The important thing is to use patterns organically, and not shoehorn a pattern into your code just for the sake of patterns. And for me everything needs to be unit tested, because our software goes into hospitals and they REALLY don't like it when things break. Not to mention HIPAA stuff if the defect involves patient security. (and even if it wasn't hospital software, unit testing is just industry standard best practice for anything beyond the most simple projects) 

 

fun fact: When a hospital experiences an issue with software that could potentially result in patient harm or financial loss for the hospital, it's called a CHIA, and we sometimes have chia pets in the room during chia investigations. (chias aren't actually fun. like at all.)

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

I probably do, but unconsciously, unless I'm looking at the overall project and trying to see what best fits what I need. However, rather than thinking about design patterns so much, I try to think more about development principles, such as KISS, DRY, YAGNI, and parts of SOLID.

 

I also tend to lean on  "Worse is better" (don't take the name at face value)

Link to comment
Share on other sites

Link to post
Share on other sites

4 hours ago, NoOverflow said:

All is in the title

 

Personnaly for small personnal project i only use Factory and Adapter generaly (a listener is needed of course), but i don't really do unit test

For bigger project i use way more pattern and more test

And you ?

I ran a unit testing initiative at a client once, built documentation, did tooling, trained folks - and it went nowhere. Honestly, it seems like a better fit for libraries and frameworks than business applications, in the former you need to ensure your not breaking other people's applications with your changes and in the latter the business often doesn't know what they want or how their own things should work.

 

I don't go out of my way to use particular patterns but use a lot of decorator/wrapper as I don't have the source to the application I support and I'll need get behavior that doesn't come out of the box. My main things is trying to keep my functions/methods small and simple enough they can be understood and to try to always document my intent with them. Also, I refactor whenever my code starts making me sad.

Web Developer and Java contractor

Link to comment
Share on other sites

Link to post
Share on other sites

1 hour ago, programmer said:

I ran a unit testing initiative at a client once, built documentation, did tooling, trained folks - and it went nowhere. Honestly, it seems like a better fit for libraries and frameworks than business applications, in the former you need to ensure your not breaking other people's applications with your changes and in the latter the business often doesn't know what they want or how their own things should work.

 

I don't go out of my way to use particular patterns but use a lot of decorator/wrapper as I don't have the source to the application I support and I'll need get behavior that doesn't come out of the box. My main things is trying to keep my functions/methods small and simple enough they can be understood and to try to always document my intent with them. Also, I refactor whenever my code starts making me sad.

We build financial software at we just at the stage where testing is becoming very important, moving are apps to aws ecs and having everything in docker images, lots of app depend on other apps so any changes could take down a lot of things.

 

I was tasked for adding server-side validation to our main product and that ended up breaking a lot of things as the front didn't always conform the new rules.

 

Testing and documentation is extremely import to insuring nothing breaks.

                     ¸„»°'´¸„»°'´ Vorticalbox `'°«„¸`'°«„¸
`'°«„¸¸„»°'´¸„»°'´`'°«„¸Scientia Potentia est  ¸„»°'´`'°«„¸`'°«„¸¸„»°'´

Link to comment
Share on other sites

Link to post
Share on other sites

Quote

Honestly, it seems like a better fit for libraries and frameworks than business applications

This is a pretty dangerous mindset. If i had to find a new job, I would immediately dismiss a company that did not have a unit test requirement as standard for newly written code (there are always exceptions, and legacy codebases are rarely tested since they are usually un-testable spaghetti code, but i'm not counting those). 

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

18 hours ago, reniat said:

This is a pretty dangerous mindset. If i had to find a new job, I would immediately dismiss a company that did not have a unit test requirement as standard for newly written code (there are always exceptions, and legacy codebases are rarely tested since they are usually un-testable spaghetti code, but i'm not counting those). 

Automated testing has pros and cons. When code is critical and regressions are likely, tests help ensure the stability of code; but extending lists, adding data fields, and changing the UI can't be meaningfully tested. Code that doesn't get extended/inherited and won't change often has less value to test than framework and scaffolding code. Sometimes code is needed as a bridge until future functionality can be written - why would you test something intended to deprecate?

 

Tests cost time and treasure that can be spent in other places and its important to consider whether they are the right tool for a purpose. Will a decrease in regressions be enough to offset the decrease in velocity? Will the other programmers be able to effectively test (both capable and motivated?) The testing initiative I did was such a failure because the client had a churn and burn mentality and was constantly firing and replacing developers. No amount of testing was could to fix a project with toxic management - people who were scared, stressed, and confused created a indecipherable, buggy mess of a codebase - with or without tests.

 

It's also hard to tell if a project is good or not since you don't meet the manager you'll be working for nor get an opportunity to get candid feedback from the other developers. Also, when a contract ends you need another if you want to keep getting paid.

 

The projects/clients that were the most abject failures taught me the most. Seeing what not to do and how not to treat people is incredibly valuable - as long as you don't stay too long.

Web Developer and Java contractor

Link to comment
Share on other sites

Link to post
Share on other sites

i know visitor pattern, never find a used for it. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

On 5/3/2018 at 8:37 AM, programmer said:

tests help ensure the stability of code; but extending lists, adding data fields, and changing the UI can't be meaningfully tested

I'm not entirely sure what you mean. I can think of plenty of examples where we test all three of those examples in our code base. 

 

As far as time goes, unit tests should be very small and easy to write. If writing tests is a considerable time cost, than I would argue that perhaps the code being written is not as modular as it could be (obviously I don't know your codebase, but in my experience that's nearly always the case for "untestable" code, and is the same reason most legacy code is not tested).

On 5/3/2018 at 8:37 AM, programmer said:

The testing initiative I did was such a failure because the client had a churn and burn mentality and was constantly firing and replacing developers. No amount of testing was could to fix a project with toxic management - people who were scared, stressed, and confused created a indecipherable, buggy mess of a codebase - with or without tests.

This sounds like an absolute nightmare, but I'd argue that it would be a nightmare with or without test and that's not really an example that tests should be able to fix. In my experience, over many kinds of tasks (UI changes, REST APIs, service implementations, low level projects working with OS APIs, etc.), all of them were testable and as long as the code was written well, the tests themselves did not take long to write at all. In fact, there were many cases were code was thought to be done, only for tests to reveal an obscure edge case that wasn't considered until actually going through and consuming our own API in those tests. 

 

I'm not fully in the TDD camp (I don't write tests first), but my company definitely write code and tests in parallel (write code with testing in mind, write tests for everything before considering the task done) and I can honestly say that I do not think our velocity would improve if we removed tests. Short term maybe, but it's normally such a small % of the total time on a task and provides so much valuable safeguards (not perfect, but better than nothing) that I simply can't see significant unit test coverage as anything but required for any modern codebase that wants to claim it meets industry standards.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

The way my company does tests is that it tests against a set of requirements that a task (we call them "change records") is working on. That's all they're doing. The code can be designed however necessary, implemented however necessary, but as long as the software meets the requirements, the software is good to go. Requirements only describe the functionality of the software, but they don't drive the design or the implementation much. That is, we don't write requirements to say how something should be implemented ( "the user shall be able to change this option through a drop-down menu"), only that a feature should be implemented ("the user shall be able to change this option").

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×