21–30 of 89 posts
Book wise, I learnt them from "Head first design patterns" which is useful and fun or for a quicker overview - http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/in... .
Also remember if you have other people around you delegate / meet them / bounce ideas together.
> it's getting from what needs to happen to how to decompose into classes/methods/libraries Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience. If you have to go OO, there have been plenty of peopl…
Or if not the problem, then my brain.
> You could try learning a functional language and see if you find it fitting better.
I come from a physics/science background; what I've seen of functional languages feel natural.
I bought my first book on design patterns 12 years ago (Head First Design Patterns). I worked my way through and it didn't make sense. I've dipped into PoEAA and Gang of Four since, with the same problem. The flow-chart-esque (UML) diagrams, the way messy life is meant to fit patterns... it didn't gel.
Time to try again, but I fancy learning a functional language first :)
Keep walking back to the user and business requirements when you're in doubt. In senior technical positions, you aren't focused on immediate issues in the code, so much as on developing the right processes to attack those problems. Software isn't expected to last very long, and when it does it's both miraculous and ugly, as the tools and techniques become more and more arcane over time. If the solution you develop can satisfy all parties for an extended period, it is as correct as you can hope for - and part of that involves choosing a technical process that can be kept running in an environment of some ineptitude.
When you know the requirements, model the data first. Data comes first because data lasts longer than code. Flexible data lets you do more with less code. And if the data is very well defined you can usually use fewer language features, too - which is a bonus to maintenance later. Think of features in data terms first and lifecycles later.
The best-practices cruft you've learned over time - that's going to have to be sacrificed when you identify ways that your designs can be simpler. You may identify a pattern that is useful but not "with the grain" of the languages you're using. That doesn't mean it's wrong, just that you're breaking past some known boundaries of programming.
As you know, most projects get dirty in order to ship. Not doing that means doing basic research to find the ideal technique, whereas there's always room to tolerate a few more hacks, global flags, mystery-meat callbacks, etc. Your best defense is for the data to be so good that all the code can remain disposable and the system will still turn out more-or-less the same way if rewritten from scratch, with a different-but-equally-awful set of hacks and kludges.
Under the pressure of strong data, code that sticks around after several cycles of disposal becomes the library code by default - and internal APIs will become strong enough to prevent a "lava layer" from taking root, because they'll consistently solve the immediate problem faster than any wrapper layer. The maintainers will feel like geniuses because they'll keep finding clever ways to use the existing data better, instead of mashing out another travesty of reflection and classes-on-top-of-classes.
If data isn't sufficient, you may also have to define a protocol. Protocols, if they work correctly, compact the state management into a small part of the app, and leave you with more data.
https://www.youtube.com/watch?v=GAFZcYlO5S0 https://www.youtube.com/watch?v=iukBMY4apvI (javascript module workflow that helped me (frontend dev) to transition to modules) help?
Watching Simon Brown now & will look at his book too, thanks. To take the current project, I have a CMS, Salesforce and ExactTarget. I'm writing the glue to automate taking new content from the CMS, finding SF users with the right permissions to see it, and emailing it to them via ExactTarget. All good & working until... do I model it as 3 objects? Which object is responsible for creating the DataTable at ExactTarget…
All the while never mind that in 9/10 cases you could have written it either way and it would be of sufficient quality and performance, run more or less without issues for years, be conducive enough to periodic refactoring, etc.
I have a similar feeling as you about software today, although I'm not sure if for the same reasons. I look around me and everything is just so damn complicated. Writing code that is small and understandable is ruthlessly mocked, while a gigantic, complex marvel of engineering (that does the exact same thing) is looked upon as The Right Way. Functionality that would take a week or two to implement 15 years ago now takes a month, or three.
Design Patterns! As you said your problem is "how to decompose into classes/methods/libraries" Book wise, I learnt them from "Head first design patterns" which is useful and fun or for a quicker overview - http://www.java2s.com/Tutorials/Java/Java_Design_Patterns/in... . Also remember if you have other people around you delegate / meet them / bounce ideas together.
Any thoughts?
And thanks for your great reminder about meeting up to bounce ideas around. I'm going looking for them.
It's hard to tell without looking at your code, but I suspect that you are stumbling in to a wall that many do. What's in your favour is that you recognise it, so you will probably be able to do something about it. Systems grow over time. At the beginning, they are simple, which means that they are forgiving. If you make a mistake, it is easy to see and correct. As the software grows, it gets progressively more compl…
You can write plugin folowing OO principles and abstract things out to be able to mock them as nessesery. It really depends on the coding standarts you're folowing.
As for unit testing. In my personal experience it enforces you to write cleaner code, because when I started I had to do heavy refactoring to be able to test my prototype, but as I wrote more testable code I started separate unrelated parts which reduced amount of spagetti code.
Another way to achieve cleaner code in my opinion would be design patters which lets you separate code logically(for example MVC), and make some things cleaner(I'm big fan of laravel's Facades for example).
> it's getting from what needs to happen to how to decompose into classes/methods/libraries Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience. If you have to go OO, there have been plenty of peopl…
If at all possible, take a vacation where you do anything but code. Pull the plug, if only for a week.
I hate to say, I'm just back from a week's vacation. I struggled to switch off & went down with shingles (brought on I am convinced by the work stress)
> it's getting from what needs to happen to how to decompose into classes/methods/libraries Perhaps the problem doesn't fit into an object oriented solution. You could try learning a functional language and see if you find it fitting better. I struggled for years with OO and was never happy with my solutions. Learning functional was my road to Damascus experience. If you have to go OO, there have been plenty of peopl…
Is there anything you could recommend reading that might show how a non-ridiculously-trivial example might be done in a functional language compared to an OO language? The "OO world" seems to me to becoming increasingly unintuitive so I'd be interested to look into something that makes me feel less crazy.