{"id":246568,"date":"2016-10-21T06:08:18","date_gmt":"2016-10-21T13:08:18","guid":{"rendered":"http:\/\/css-tricks.com\/?p=246568"},"modified":"2016-10-22T16:28:00","modified_gmt":"2016-10-22T23:28:00","slug":"on-style-maintenance","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/on-style-maintenance\/","title":{"rendered":"On Style Maintenance"},"content":{"rendered":"<p>I was talking to a brilliant engineer friend the other day who mentioned they never get to build anything from the ground up. Their entire career has consisted of maintaining other people&#8217;s (often quite poor) code.<\/p>\n<p>In a perfect world, we&#8217;d all get to write code from scratch, it would work perfectly, and we would put it into a bin in the sky, never to be looked at by anyone again.<\/p>\n<p>We all know that&#8217;s not how it works. Code need to be <em>maintained<\/em>.<\/p>\n<p><!--more--><\/p>\n<p>Kyle Simpson often begins his talks explaining that we spend only 30% of our time writing code, and 70% of our time maintaining it. Being a good coworker and programmer is not just about being a skillful problem solver, but being legible. Great developers produce code with maintenance in mind.  <\/p>\n<p>I often joke that I don\u2019t want to hire a code ninja. Ninjas come in the middle of the night and leave a bloody mess.<\/p>\n<p>I want a code janitor. Someone who walks the hallways of code, cleaning up pieces, dusting up neglected parts, shinning up others, tossing unnecessary bits. I prefer this gentler, more accurate analogy. This is the person you want on your team. This is a person you want in your code reviews. <\/p>\n<p>Shoutout to <a href=\"https:\/\/twitter.com\/goodrobot_jd\" rel=\"noopener\">JD Cantrell<\/a>, who is an awesome code janitor and code reviewer.<\/p>\n<h3>Let&#8217;s think about code maintenance through the lens of two different programming paradigms<\/h3>\n<p>In programming there are many tools and procedures available to meet the same end. There is no right answer. Here is a succinct definition by Michael Feather of two very popular programming paradigms:<\/p>\n<blockquote>\n<p>Object-Oriented Programming makes code understandable by encapsulating moving parts&#8230;<\/p>\n<p>Functional Programming makes code understandable by minimizing moving parts.<\/p>\n<\/blockquote>\n<p>Let&#8217;s consider both in terms of not just understandability but also maintenance.<\/p>\n<h4>Functional Programming<\/h4>\n<p>I have seen for myself the value of using a functional approach in front-end JavaScript. When we write code, sometimes we want to assume that it will be used forever the way we intended, but most of us have been doing this long enough now to acknowledge that that isn\u2019t always the case. <\/p>\n<p>Functional programming includes, but is not limited to:<\/p>\n<ul>\n<li>It is <strong>declarative<\/strong> &#8211; we\u2019re writing in a way that can be reused and not telling the computer exactly what you need it to do at every step. This shares some similarities with abstraction.<\/li>\n<li>It is <strong>pure<\/strong> &#8211; we\u2019re not modifying or changing things outside of the function\u2019s scope, and for this reason&#8230;<\/li>\n<li>It is <strong>immutable<\/strong> &#8211; you won\u2019t get into a situation where you feed it the same value and retrieve different results on multiple executions.<\/li>\n<\/ul>\n<p>I believe functional programming can be extremely useful in terms of maintenance because of the lack of side effects. This is huge. This keeps our code from becoming brittle. People sometimes think the biggest problem is errors in our code. I\u2019d argue that the worst code isn\u2019t code that errors out and fails. We can track down with methodical isolation. <strong>The worst code is code that behaves a way that you can\u2019t predict, quietly, all over the place.<\/strong> You run around the code base playing whack-a-mole and sometimes it\u2019s difficult to find the culprit. A functional programming style takes on this problem preemptively, because it\u2019s built from the ground up to keep this from happening (as much).<\/p>\n<p>Here are some resources if you\u2019d like to dig deeper into functional programming:<\/p>\n<ul>\n<li>Anjana Vakil: <a href=\"https:\/\/www.youtube.com\/watch?v=e-5obm1G_FY\" rel=\"noopener\">Learning Functional Programming with JavaScript<\/a> &#8211; JSUnconf 2016<\/li>\n<li>Mary Rose Cook: <a href=\"https:\/\/maryrosecook.com\/blog\/post\/a-practical-introduction-to-functional-programming\" rel=\"noopener\">A practical introduction to functional programming<\/a><\/li>\n<li>Kyle Simpson:<a href=\"https:\/\/github.com\/getify\/Functional-Light-JS\" rel=\"noopener\">Functional Lite<\/a><\/li>\n<\/ul>\n<p>As much as I&#8217;m in love with functional programming, please be aware that there can still be issues with maintenance. If a few things use the same pure function, and over time you adjust that function for one of its applications, you can get into a problem where you&#8217;re also altering other things that are hidden dependencies. Good documentation is really helpful here.<\/p>\n<h4>Object-Oriented Programming<\/h4>\n<p>In contrast, Object-Oriented Programming is a little more like following the steps to a recipe. It uses objects, which may or may not contain data, and methods, which tends to be procedural. Typically objects have an idea of self (e.g. &#8220;this&#8221; in JavaScript). Object-Orientation doesn&#8217;t focus on purity, but rather, tends to use encapsulation to make sure nothing leaks into outer scope.<\/p>\n<p>At it&#8217;s best, Object-Oriented approaches tend to think of the highest order of something, then pares down to each type of instance you can have, breaking out what to do in each case. If you&#8217;re thinking about it like the Linnean System of Classification for animals and how we&#8217;d make Morphology Trees (who wouldn&#8217;t? :)) You&#8217;d start by asking is it warm-blooded? Then, does it have fur? Then does it have a snout? etc. I&#8217;m really butchering biology here, but it&#8217;s an example.<\/p>\n<p>At it&#8217;s worst, Object-Oriented programming gets a lot of pretty necessary criticism because sometimes you&#8217;re not clearly describing what you think you&#8217;re describing. You can think of this like: you think something\u2019s a banana but really it\u2019s a peach because the only thing that\u2019s described to you is that you have a fruit. We talked a little bit before about how that kind of code can be a nightmare to maintain, so while that&#8217;s not always the case, it can certainly come up.<\/p>\n<figure id=\"post-246598\" class=\"align-right media-246598\"><img decoding=\"async\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2016\/10\/oop.gif?ssl=1\" alt=\"\" data-recalc-dims=\"1\" \/><\/figure>\n<h3>An applicable example in CSS<\/h3>\n<p>With both functional and object-oriented approaches in our minds, let&#8217;s consider how that applies to CSS and the concept of authoring versus maintenance. CSS is written declaratively and purely. You can&#8217;t mutate one CSS block using another CSS block.<\/p>\n<p>I think a lot of people would anticipate that a purely functional approach would be best for CSS. They might associate that with keeping CSS as pure as possible, which is where ideas like <a href=\"https:\/\/github.com\/css-modules\/css-modules\" rel=\"noopener\">CSS Modules<\/a> come from. The concept is that if you encapsulate the styles for the thing you&#8217;re modifying them right where you need them. You&#8217;re only ever dealing with that instance. No side effects. I don\u2019t disagree. You avoid a few things this way.<\/p>\n<ul>\n<li>You avoid <strong>collisions<\/strong>. This is where object-oriented programming gets a bad rap for sometimes.<\/li>\n<li>You avoid <strong>naming<\/strong>. Naming is hard. You can avoid naming with this approach.<\/li>\n<li>You avoid dealing with the <strong>cascade<\/strong>. I\u2019ll address this in a minute.<\/li>\n<\/ul>\n<p>For other kinds of (non-CSS) programming, we keep things pure and avoid global scope and we\u2019re golden! So it must apply everywhere, right? <\/p>\n<p>Here&#8217;s where we need to get into <em>the right tool for the job<\/em>. If we\u2019re considering <strong>maintenance<\/strong> over <strong>writing<\/strong>, here is where other approaches shine:<\/p>\n<ul>\n<li>Companies big and small tend to have redesigns at least every 1-2 years. If your code base is large, with many people, and you need to change the line-height everywhere from 1.1rem to 1.2rem, <strong>are you having to go back into every module and change that value<\/strong>? A global or an object that\u2019s extended becomes extraordinarily useful here.<\/li>\n<li>The cascade can help, if you understand and organize it. This is the same as any sophisticated software design. You can look at what you\u2019re building and make responsible decisions on your build and design. You decide what can be at a top-level and needs to be inherited by other, smaller, pieces. This avoids spaghetti code in CSS and keeps your code <abbr title=\"Don't Repeat Yourself\">DRY<\/abbr>.<\/li>\n<li>CSS is about design. <strong>Good design, is by it&#8217;s nature, successful when it&#8217;s cohesive<\/strong>. A CSS codebase that aligns itself with the design infrastructure it&#8217;s built from allows for cleaner code, with the added benefit of better collaboration. CSS can be self-checking for designers as well: <em>&#8220;Wait we have another tertiary button? Why?&#8221;<\/em> Leaks in cohesive UI\/UX announce themselves well in this model.<\/li>\n<li>Naming can help with documentation. This point is a little more prickly, and I&#8217;m not sure totally necessary, but worth mentioning. Whether you like BEM, or SMACSS\/OOCSS, or Atomic, naming when done well can actually give you good information on where a class is used and why.<\/li>\n<\/ul>\n<h3>The paradigms share traits<\/h3>\n<p>As you might suspect, though I see value in other paradigms, my preference is a functional style. With that in mind, you might wonder why I would find value in an <a href=\"https:\/\/www.smashingmagazine.com\/2011\/12\/an-introduction-to-object-oriented-css-oocss\/\" rel=\"noopener\">Object-Oriented approach to CSS<\/a>. <\/p>\n<p>Despite it&#8217;s name, OOCSS shares traits with Functional Programming. To correctly work with OOCSS the way it was intended, you&#8217;re mostly creating mixins that are expressed similarly to functions with parameters (often with defaults) across your system. They are pure, and can be applied to multiple uses. <\/p>\n<p>It still uses Object-Oriented approaches as well. With a very intelligent architecture built with anticipation of how things might be affected by each other, and carefully considering what should be inherited. Considering that CSS is fundamentally a group of objects, this tends to make more sense in a CSS context than in other languages. <\/p>\n<p>Last year I lead a team to completely refactor a giant Front-End component system. It used an OOCSS architecture, I and saw for myself the benefit of this type of model. Designers could ask me to modify something, and we could quickly see it update across the site. They could even change their minds without too much of a hassle. A last minute request from above did not stall our release. I&#8217;m definitely not saying it wasn&#8217;t without it&#8217;s pain points- but it was surprisingly smooth for it&#8217;s scale. This has made me look at the way I write CSS for other applications in a whole new light.<\/p>\n<h3>Future-forward<\/h3>\n<p>People tend to pit these things against each other:<\/p>\n<ul>\n<li>CSS<\/li>\n<li>Styling via JavaScript<\/li>\n<\/ul>\n<p>I would argue that you can be maintenance friendly or create a maintenance nightmare either way. <\/p>\n<p>You can absolutely deal with things like line-heights, fonts, and behaviors responsibly in Aphrodite, or React-CXS, or CSS Modules. I quite like some of these approaches. They can handle inheritance, and be written to extend for a DRY-er and more maintainable approach. <\/p>\n<p>But even though you <em>can<\/em>, I personally haven\u2019t seen enough examples of projects that <em>do<\/em>. (I&#8217;d love to see some examples!)<\/p>\n<p>Mostly I see people pull out a variable or two for the brand color and nothing else. A few variables does not a responsible system architecture make. I think we can do better here, if we think about our code not in terms of what is easier to write, but what&#8217;s easier to change. Or better yet, in terms of what&#8217;s easier for <em>others<\/em> to change.<\/p>\n<p>Please also take care to create good documentation! With either programming paradigm, you have to know about all of your dependencies before you adjust it. Great documentation also means you are more purposeful in your decision-making as well. There are less &#8220;oh well&#8221;s when you have to explain what a thing is and where it&#8217;s used to other people.<\/p>\n<p>The issues I\u2019m tackling in this article are issues of collaboration and scale. Not every company or site or even web app is tackling these things. This is an opinion article that comes from experience. Different things work for different projects.<\/p>\n<p>My hope for this article is to encourage developers to think ahead. We\u2019re all in this together, and the best we can do is learn from one another. If you completely disagree with me, that\u2019s totally fine. My hope is that even in taking a stance, you might solidify a direction you head towards with <strong>maintenance<\/strong> as the core concept.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I was talking to a brilliant engineer friend the other day who mentioned they never get to build anything from the ground up. Their entire career has consisted of maintaining other people&#8217;s (often quite poor) code. In a perfect world, we&#8217;d all get to write code from scratch, it would work perfectly, and we would [&hellip;]<\/p>\n","protected":false},"author":7699,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":[]},"categories":[4],"tags":[885,884],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":372485,"url":"https:\/\/css-tricks.com\/removing-jquery-from-gov-uk\/","url_meta":{"origin":246568,"position":0},"title":"Removing jQuery from GOV.UK","date":"August 23, 2022","format":false,"excerpt":"The GOV.UK team recently published \"How and why we removed jQuery from GOV.UK\". This was an insightful look at how an organization can assess its tooling and whether something is still the best tool for the job. This is not a nudge to strip libraries out of your current project\u2026","rel":"","context":"In &quot;Link&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2022\/08\/govuk-jquery-featured-image.jpg?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":357600,"url":"https:\/\/css-tricks.com\/embrace-your-codes-transience\/","url_meta":{"origin":246568,"position":1},"title":"Embrace your code\u2019s transience","date":"December 2, 2021","format":false,"excerpt":"Websites change. Healthy codebases are constantly being updated. Legacy code dies when it eventually goes down with the ship. Recognizing that my code is transient allows me to be more practical about my code and what guides my decision-making as I author it. Your code is transient. I like to\u2026","rel":"","context":"In &quot;2021 End-of-Year Thoughts&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/12\/shutterstock_1720536811-1-scaled.jpg?fit=1200%2C953&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":149058,"url":"https:\/\/css-tricks.com\/wordpress-fragment-caching-revisited\/","url_meta":{"origin":246568,"position":2},"title":"WordPress Fragment Caching Revisited","date":"September 5, 2013","format":false,"excerpt":"The following is a guest post by Ryan Burnette. As you'll read below, Ryan was working on a WordPress site that utilized a plugin that used the Instagram API to pull down photos. He was using it in a bit of a non-standard way that lead to lots of requests\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":291379,"url":"https:\/\/css-tricks.com\/if-you-can-build-a-site-with-wordpress-com-you-should-build-your-site-on-wordpress-com\/","url_meta":{"origin":246568,"position":3},"title":"If you can build a site with WordPress.com, you should build your site on WordPress.com.","date":"June 18, 2019","format":false,"excerpt":"That\u2019s what I like to tell people. I\u2019ve seen too many websites die off, often damaging the company along the way because the technical debt of hosting and maintaining the website is too much in the long term. For a few examples, there is the domain name itself to handle\u2026","rel":"","context":"In &quot;Sponsored&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/06\/wpcom-featured.png?fit=1200%2C600&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":353429,"url":"https:\/\/css-tricks.com\/the-case-for-developer-experience\/","url_meta":{"origin":246568,"position":4},"title":"The Case for \u2018Developer Experience\u2019","date":"October 8, 2021","format":false,"excerpt":"A good essay from Jean Yang. What I mean by\u00a0developer experience\u00a0is the sum total of how developers interface with their tools, end-to-end, day-in and day-out.\u00a0Sure, there\u2019s more focus than ever on how developers use and adopt tools, and there are entire talks and panels devoted to the topic of so-called\u2026","rel":"","context":"In &quot;Link&quot;","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2021\/10\/microservicesdeathstars_jeanyang_Future.jpg?fit=1200%2C527&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":407,"url":"https:\/\/css-tricks.com\/listless-navigation-using-css-to-do-more-with-less\/","url_meta":{"origin":246568,"position":5},"title":"Listless Navigation &#8211; Using CSS To Do More With Less","date":"December 13, 2007","format":false,"excerpt":"The best part about CSS is that it allows web developers to achieve more with less. What exactly does that mean? Well, for a start, CSS allows developers to: Code much, much less XHTML Separate website formatting from content Control as much of the website theme\/design as the developer allows\u2026","rel":"","context":"In &quot;Article&quot;","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/246568"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/7699"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=246568"}],"version-history":[{"count":31,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/246568\/revisions"}],"predecessor-version":[{"id":246931,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/246568\/revisions\/246931"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=246568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=246568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=246568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}