Common Sense Driven Development
-
Upload
bozhidar-bozhanov -
Category
Software
-
view
6.999 -
download
0
Transcript of Common Sense Driven Development
Common sense driven developmentBozhidar Bozhanov
Vanity slidehttp://techblog.bozho.net@bozhobgSenior Software Engineer @ TomTom
It’s a mazeTDD, BDDDomain-driven design, Design-driven
developmentSOA, MicroservicesMQs, ESBs, rules engines, data processing
engines
...and software is still crap“because writing software is hard”, we soothe ourselves
Some real methodologiesHype driven development (Big Data in the
Cloud, yeah)Demo driven developmentCopy/paste driven developmentDenial driven development (Not Invented
Here syndrome)
Common senseCommon sense gives you
less bugsmaintainabilityextensibilityscalabilityeternal life
Applying common senseNo definition for common sense...so we’ll define it by counter-examples
Let’s make an API...that we never write againstTransformerFactory tf = TransformerFactory.newInstance();Transformer transformer = tf.newTransformer();transformer.setOutputProperty(...);StringWriter writer = new StringWriter();transformer.transform(new DOMSource(doc), new StreamResult(writer));
String result = writer.toString();
default use-case(s)
Let’s use raw JDBCeasy to setup...and you’ll eventually build a feature-poor,
buggy and time-consuming object mapper.you are probably using ORMs wrong
Let’s use java.util.Date...instead of joda-time, java.timeor let it creep from other libraries
java.util.Date is mutable, not timezone-aware, with a bad, deprecated api. Bottom line: it’s bad
extra effort for: hibernate, json/xml serialization
Let’s homegrow a framework
NIH (Not Invented Here) syndrome“NIH's emphasis is on ignoring, boycotting, or
otherwise refusing to acknowledge solutions by others.”
Our web framework, our DI, our ORM, our build tools.
...what could go wrong?
Let’s not use latest versionsJava 8 is “too new” #notLatest JavaEE/Spring is probably still buggyWe don’t have time to learn the new thingsWe have a “standard infrastructure”… and other bullshitcritical security issues, fixed bugsregularly upgrade
Let’s not support safe-and-refresh...because waiting for 3 minutes to see
changes is coolyou can check facebook
JRebel is not the only optionHotSwap in debug mode
Process
Let’s skip code reviewswe don’t have timewe are really good, we promisesomeone may get offended
...because I suggested to rename a variable
Let’s not write testswe don’t have time
but we do have time to fix recurring bugswe are really good, we promisethe code is simple and doesn’t need testing
yeah, right
Let’s make it work just for the demo...and never actually deliver working featuresit’s fine to show incomplete features
it’s not fine to write crap in the codebase just for a demo to work
Let’s allow management decisions to influence software design
because non-technical managers know better:which database to usewhat frameworks to usehow to structure the deploymentthat 89% coverage is not enough
Architecture
(source: MSDN.com)
Let’s use SOAP...for no apparent reason...where simple RESTful services will do...and we don’t actually need web services
Let’s use an ESB...because I heard it’s cool...even though we have to integrate just 2
systems, both of which are under our controlit won’t break, I promise.
Let’s use an MQ“message-driven” - decoupling, throughput,
fault-tolerance, distributed processingright… do you really need these?what’s the overhead of managing an MQ?
async processing without MQ, in your JVMthere are legitimate use-cases. But fewer than
you think.hardware is cheap, unreadable code isn’t
Let’s use application-level stateinstance fields with datanon-cache (non-dismissable) informationwell, maybe you don’t want to scale out
Let’s split the system...and make separately deployable
submodules communicate with web-serviceswith us as the only user...of our relatively small application
monolithic applications work finesplitting, microservices - prove if necessary
(by Martin Fowler)
Let’s [..]. How about...
So...That’s what commons sense isn’t.
But there were contradictions...like “reuse existing solutions” vs “you probably
don’t need X”or “don’t overdesign in advance” vs “design
good APIs”
This is where you apply common sense to choose what fits your case :)
Obvious?Yes, but every project has many of the above.
Common sense is not a set of rules or a set of slides.
Based on...http://techblog.bozho.net/development-methodologies/http://techblog.bozho.net/you-probably-dont-need-a-message-queue/http://techblog.bozho.net/the-default-use-case/http://techblog.bozho.net/orm-haters-dont-get-it/http://techblog.bozho.net/do-it-either-way-well-refactor-it-later/http://techblog.bozho.net/kiss-my-yagni/http://techblog.bozho.net/two-types-of-deployment-of-subsystems/http://techblog.bozho.net/keep-as-much-stuff-as-possible-in-the-application-itself/http://techblog.bozho.net/state-does-not-belong-in-the-code/http://techblog.bozho.net/save-and-refresh-with-java-web-projects/ http://martinfowler.com/bliki/MicroservicePremium.html
Questions?