DRY   1437

« earlier    

Repeat yourself, do more than one thing, and do more than one thing — programming is terrible
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever!.

Following “Don’t Repeat Yourself” might lead you to a function with four boolean flags, and a matrix of behaviours to carefully navigate when changing the code. Splitting things up into simple units can lead to awkward composition and struggling to coordinate cross cutting changes. Avoiding rewrites means they’re often left so late that they have no chance of succeeding.

The advice isn’t inherently bad—although there is good intent, following it to the letter can create more problems than it promises to solve.

Sometimes the best way to follow an adage is to do the exact opposite: embrace feature switches and constantly rewrite your code, pull things together to make coordination between them easier to manage, and repeat yourself to avoid implementing everything in one function..



Repeat yourself, but don’t repeat other people’s hard work. Repeat yourself: duplicate to find the right abstraction first, then deduplicate to implement it.

With “Don’t Repeat Yourself”, some insist that it isn’t about avoiding duplication of code, but about avoiding duplication of functionality or duplication of responsibility. This is more popularly known as the “Single Responsibility Principle”, and it’s just as easily mishandled.



Gather responsibilities to simplify interactions between them

The only real difference between pushing something together and pulling something apart is that some changes become easier to perform than others.

The choice between a monolith and microservices is another example of this—the choice between developing and deploying a single service, or composing things out of smaller, independently developed services.

The big difference between them is that cross-cutting change is easier in one, and local changes are easier in the other. Which one works best for a team often depends more on environmental factors than on the specific changes being made.

Although a monolith can be painful when new features need to be added and microservices can be painful when co-ordination is required, a monolith can run smoothly with feature flags and short lived branches and microservices work well when deployment is easy and heavily automated.



Modularity is more than reducing things to their smallest parts.

A layer of small components with no shared features creates a need for a layer above where these features overlap, and if absent, the user will create one, with bash aliases, scripts, or even spreadsheets to copy-paste from.

Even adding this layer might not help you: git already has a notion of user-facing and automation-facing commands, and the UI is still a mess. It’s always easier to add a new flag to an existing command than to it is to duplicate it and maintain it in parallel.

Similarly, functions gain boolean flags and classes gain new methods as the needs of the codebase change. In trying to avoid duplication and keep code together, we end up entangling things.

Although components can be created with a single responsibility, over time their responsibilities will change and interact in new and unexpected ways. What a module is currently responsible for within a system does not necessarily correlate to how it will grow.



Modularity is about limiting the options for growth

A given module often gets changed because it is the easiest module to change, rather than the best place for the change to be made. In the end, what defines a module is what pieces of the system it will never responsible for, rather what it is currently responsible for.



This means recognizing which bits are slightly more entangled than others, knowing which pieces need to talk to each other, which need to share resources, what shares responsibilities, and most importantly, what external constraints are in place and which way they are moving.

In the end, it’s about optimizing for those changes—and this is rarely achieved by aiming for reusable code, as sometimes handling changes means rewriting everything.



Rewrite Everything

The reason rewrites are so risky in practice is that replacing one working system with another is rarely an overnight change. We rarely understand what the previous system did—many of its properties are accidental in nature. Documentation is scarce, tests are ornamental, and interfaces are organic in nature, stubbornly locking behaviors in place.

If migrating to the replacement depends on switching over everything at once, make sure you’ve booked a holiday during the transition, well in advance.

Successful rewrites plan for migration to and from the old system, plan to ease in the existing load, and plan to handle things being in one or both places at once. Both systems are continuously maintained until one of them can be decommissioned. A slow, careful migration is the only option that reliably works on larger systems.



The reason we say “Never Rewrite Code” is that we leave rewrites too late, demand too much, and expect them to work immediately. It’s more important to never rewrite in a hurry than to never rewrite at all.



null is true, everything is permitted

The problem with following advice to the letter is that it rarely works in practice. The problem with following it at all costs is that eventually we cannot afford to do so.

It isn’t “Don’t Repeat Yourself”, but “Some redundancy is healthy, some isn’t”, and using abstractions when you’re sure you want to couple things together.

It isn’t “Each thing has a unique component”, or other variants of the single responsibility principle, but “Decoupling parts into smaller pieces is often worth it if the interfaces are simple between them, and try to keep the fast changing and tricky to implement bits away from each other”.

It’s never “Don’t Rewrite!”, but “Don’t abandon what works”. Build a plan for migration, maintain in parallel, then decommission, eventually. In high-growth situations you can probably put off decommissioning, and possibly even migrations.
dry  srp  programming  bestpractices  refactoring  maintenance  modularity  onethingwell 
3 days ago by cdzombak
A few tips to write better code - Imaginary Cloud
Here I'll share a few tips on how to write better code, using some best practices that have proven to be very effective.
programming  tip  suggestion  swift  mvc  dry 
11 days ago by gilberto5757
Rug Cleaning West Timperley WA14 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning W. Timperley Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Timperley WA15 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning in Timperley Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Hale WA15 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning Hale WA15 Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Hale Barns WA15 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning Hale Barns WA15 Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Broadheath WA14 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning Broadheath WA14 Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Bowdon WA14 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning Bowdon WA14 Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Rug Cleaning Altincham WA14 0161 768 0208 - YouTube
Spotless Rugs by Deluxe Rug Cleaning Altrincham WA14 Have rugs that you can enjoy and be proud of .... call us today Deluxe Dry Carpet Cleaning 36 Abbots Close, Manchester M33 2DB 0161 768 0208 https://ift.tt/2xF19Vj https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
23 days ago by deluxedrycarpet
Upholstery Cleaning Altrincham 0161 768 0208 - YouTube
Upholstery Cleaning in Altrincham Areas Have spotless furniture and sparkling sofas with Deluxe Dry Upholstery Cleaning services for WA14 and WA 15 Deluxe Dry Carpet Cleaning 36 Abbots Close Manchester M33 2DB 0161 768 0208 https://ift.tt/2xohMDU https://goo.gl/maps/sA3U18GSQKt
dry  carpet  cleaning  manchester  stockport  deluxe 
4 weeks ago by deluxedrycarpet

« earlier    

related tags

(mgd)  -  15  1st  2015  2018-08-06  4g  500px  a  a:tef  abcc11  abstractions  ac  add-on  advice  advocacy  anchor  and  antiperspirant  apnea  arch  architecture  art  async  atomicdesign  auta  aw18  axios  b&w  b/w  baby  beans  bed  bem  best  bestpractices  black  blackandwhite  blasting  blog  body  book  brushing  bugs  buy  cab  cactus  callbacks  can  canine  carolina  carpet  cars  clean  cleancode  cleaners  cleaning  cloth  clothes  cms  coastal  code-design  code-quality  code-style  code  coding  cold  collection  composition  conservatory  content  cooking  cool  craft  crawl  criticism  css  damage  damp  ddd  dehumidifier!  dehumidify  delivery  deluxe  demand  dental  deodorant  desert  design  development  devops  documentation  does  don't  dried  dry  drying  drywall  duplication  during  dust  dysfunction  earwax  eczema  emu  emulator  engine  enumerations  erase  etching  eva  eye  face  farm  faster  feature  fiber  fine  fix  florence  flowers  food  for  framework  freeze  from  fruit  fry  garden  gemini  gene  gland  green  grinding  grub-emu  grub  guide  hair  health  helix  hole  home  household  how  howto  html  ice  ideapaint  ifttt  in  industrial  info  install  installed  it  japanese  javascript  kit  konjac  korean  lake  latest  law  lithium  loss  lotion  maintenance  management  manchester  materials  mealworms  medium  meibomian  metaprogramming  microservices  mini  mmm  mode-  modularity  moisture  moisturizer  mono  monochrome  more  mouth  mvc  needles  niobate  node.js  noodles  north  odor  offerings  on  one  onethingwell  optic  optics  oral  organization  ornamental  oz  p:programming-is-terrible  paint  parami  phone  photography  php  plasma  preserve  principles  programming  programming_architecture  protect  pug  quality  rains  recipe  recipes  refactor  refactoring  relay  reliability  repair  repeat  research  resonator  rights  roast  rock  rot  rough  rub  run  safe  safety  sage  sahara  samochody  science  screw  sealed  sepia  sheet  sheetrock  shop  sichuan  sill  skin  sleep  slide  smoke  software-design  software  softwarecrafting  solid  spaces  spaghetti  split  sprint  srp  standards  stay  stayed  stockport  stone  stream  structure  studioone  study  style  succulent  suggestion  survival  sweat  sweng  swift  system  technology  teeth  tef  template  terraform  terragrunt  test  testings  texture  the  thought-provoking  tip  tips  to  tolearn  tool  tools  tooth  toread  totry  tounderstand  town  tutorial  twig  uk  valenciana  variables  venison  vented  verify  vs.  wall  wash  washing  water  waveguide  web  webdesign  webdev  wet  wham  white  whiteboard  window  with  work?  wynajem  xerostomia  yourself  zone4  zone5  | 

Copy this bookmark:



description:


tags: