The Great Web Maintainability Survey (Responses)
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
View only
 
 
Still loading...
ABCD
1
TimestampWhat techniques do you find useful to keep websites maintainable?What do you find detrimental for website maintainability?What resources do you turn to to learn about web maintainability?
2
4/25/2017 22:53:11Human beings incentivized to work on it.Zero humans beings left that care about it.
3
5/14/2017 12:09:13BEM, IIFEInline JS, No Code ConventionWeb, other experts, know how
4
5/14/2017 13:33:14Lots of simple CSS classes on a single element, grids, type systems, simple build tools, as basic as possible.Too much reliance of HTML structure for CSS design make for brittle websites.All the main online web places.
5
5/14/2017 18:00:33Using a JavaScript framework and build tool. This may sound strange, but using a framework prevents me from doing weird stuff, and things that are anti-patterns, while build tools give me versioned assets and automate everything, so there’s far less chance that the project will become an unmaintainable mess.Not using a JavaScript framework or build tool. Sorry for basically repeating my previous answer, but I can say from my own experience that trying to do your own thing instead of relying on tools, can make the project unmaintainable very easily.I can’t point to any specific resource, but tools, tools, tools.
6
5/15/2017 17:51:54Use a consistent coding style.
Ability to easily find and delete dead code.
Try to keep implementations simple.
Complex and untraceable dependencies, making maintenance risky or impossible.
Lack of appreciation for maintenance, resulting in maintenance being seen as a low priority.
7
5/16/2017 18:39:50Bem, living pattern librariesUnshared code styles.
8
5/16/2017 18:52:08We build a lot of WordPress-driven websites at our agency. Whenever I can, I try to avoid using plugins that handle tasks that can be carried out via functions written within the theme. Every time a plugin or visual builder is brought into the fold, it presents another entirely new array of problems and potential security holes. Plugin updates can break things and when a plugin developer abandons their work, you are left trying to disconnect it from your theme (extra work that you don't get paid for is no fun at all).Tying into the above answer, relying on plugins for everything your theme does. You are creating dependencies which are often times warranted, but sometimes not (e.g. a plugin that does nothing but insert social icons can be consolidated into a single, reusable function in your theme or project). Also, relying on tools that rarely get updates is bad for business. Vague class and ID naming conventions can make life hell for developers that haven't worked on a site. This is why I stick to a pseudo-BEM style naming convention. Vague namespaces are just bad practice. Another big one: not writing clear, concise comments for things. As soon as someone has to jump in years later to fix or update something, they are playing the "what the hell does this do?" game.I refer to practices like BEM CSS and always try to think into the future. "How can I write this in a way that a developer 5 years from now will understand it? Can I make this comment more descriptive?" I don't have a specific source for this but instead look to people like Chris Coyier, Wes Bos, Ethan Marcotte, Eric Meyer, and lots of Codepen stuff.
9
5/16/2017 18:59:12Clarity & consistency in design/format, interaction, layout/placement, and labels. The whole labeling system is EXTREMELY important. Consistency does not mean 'no visual hierarchy.' Consistently communicating a visual hierarchy is good for UX.Lack of consistency & clarity. https://www.nngroup.com/articles/
10
5/16/2017 19:00:14#1 - Detailed, understandable documentation
#2 - Enforced, standard methods in line with the documentation
#3 - (Whatever method fits you and your organization best)
Non-standardized methods. Many developers on a team tackling the problems that come their way, in different methods from each other.
11
5/16/2017 19:00:31Breaking websites down into reusable components.Small budgets and rushed schedules (both relative to project size and scope).
12
5/16/2017 19:05:14* Choose simplicity over flexibility when considering design patterns.
* Strong JS and CSS linting.
* Write legible, human readable code then use a build step to optimize it.
* Don't try to constantly jump to the latest and greatest framework, the best tool is often the one in your hand.
* Don't use tools that you don't need and understand the ones you do
* Write semantic html
* Keep concerns separated (I'm looking at you CSS in JS)
* Organize your file and folders as if you were going to open source your project and would be kicked in the shin for every poorly placed or named file.
* Peer review your work
* Keep a 1:1 pairing of scripts/modules to stylesheets if you're using a component based system
* Import your CSS from its corresponding JS component if you're using a component based system and a bundler that can handle it.
* BEM
* Using a "boilerplate" setup that you didn't write yourself (particularly for builds)
* Adopting a new technology for every project you undertake
* Shooting myself in the foot over and over, then meditating on why it happened
* Mentoring new hires who start working on front end project, where did they struggle with my previous choices?
* Listening to the big guys (Facebook, Amazon, Google) when they talk about the troubles they've had or the decisions they made. (e.g. the React documentation is littered with "we recommend doing it this way", which is often good advice)
13
5/16/2017 19:13:12Comments, Documentation, Modularity, Low code couplingHigh code coupling, really long functions, lack of comments from original developersNone
14
5/16/2017 19:34:17templatesrequiring/expecting administrators to know HTML and follow patterns faithfully
15
5/16/2017 19:40:52Using latest tools, switching regularlyLeaving unnecessary code lying aboutFeedly and lots of blogs
:)
16
5/16/2017 20:23:00Not creating code abstractions until we have at least 3-4 usages. We often have the tendency to create abstractions (classes, interfaces, APIs) even before we reuse a component/concept in at least two places. I tend to favor code code duplication until I get at least 3-4 different usages and only then do I have enough perspective to make a good abstraction. This is because a bad abstraction is much harder to maintain than no abstraction and code duplication.I find tooling around wordpress is very much lacking for deploying a website in development environments/QA environments. As soon as changes are done on the production environment, bringing these changes in upstream environments must be done via custom scripts/tooling, adding a maintenance burden for new teams.Not a website in particular, knowledge is mostly gathered via numerous blog posts, books and experience over the years.
17
5/16/2017 20:36:58Team communication is key. The more we talk about what we're doing and WHY, the easier the site will be to maintain. Additionally, communication prior to implementing a new feature should include discussion about maintainability of the feature and the code.
Tandem coding can also help as can a code style guide that the team agrees to be governed by. Tandem coding can help with communication and with sticking to the code style guide as well.
Cowboys. Tight deadlines which make code pairing seem like a good way to cut time and make it okay to not adhere to best practices because IT'S GOT TO GET OUT THE DOOR NOW.A List Apart/Event Apart/Book Apart
18
5/16/2017 21:12:07Good Authoring Experience (AX), UI for updating CMS (WordPress)Having to update a file structure (Drupal)More advanced technoogies such as Git, Composer, etc
19
5/16/2017 21:18:30communication. making use of reusable patterns. focusing on the mundane rather than the new shiny.Outsourcing to agencies or freelancers for initial build and expecting the internal team to just “figure out” how to keep the collection of scope creep and cutting-corners they call a “site” from catching fire and burning to the ground.
20
5/16/2017 21:34:26Be diligent in what you add and generous in what you take offSpecial cases or making exceptions to the system. Articles from A List Apart, Smashing Magazine, and Jeremy Keith
21
5/16/2017 21:50:04Test, test, test...I not always testBooks of Robert C. Martin
22
5/16/2017 22:12:44I'm a web designer that focuses on Web Accessibility. I use SiteImprove to scan our website for accessibility issues that include outdated HTML, poorly structured content and tables, extra markup and missing alt text. SiteImprove’s accessibility checker helps clean up the inconsistencies that developers, designers and web editors have created during the few years the site has been in production. SiteImprove can't find all issues, but hopefully we'll be prepared for the next redesign or content migration without many surprises.Once the initial build and launch of a new website is done we lose that dedicated larger team and teamwork during the maintenance phase of the site. Portions of that new website may still be developed, but there is less input, feedback and knowledge available because the maintenance team is smaller. Some developers may skip a step or two here or there. Code may be sloppy because it didn't get thorough QA. Inconsistencies build up on the website.https://alistapart.com
23
5/16/2017 23:11:36Separation of concerns, modular development, SASS/LESS, constantly keeping up with the latest library.Too much CSS from "pixel perfect" implementation, too many libraries being used in both CSS and JS. Writing to more than one DB can be a pain on the backend. Getting too far behind on both UI libraries and backend frameworks.Nothing really, aside from mailing list updates from the libraries I use and making sure I'm keeping my web parts modular and independent.
24
5/16/2017 23:11:56Strict and clear procedures. Quality assurance checks for consistent application of those procedures. Regular ROT removal.Too many rogue processes. Lack of mission and purpose for the website. For maintainability and general web standards:
https://alistapart.com/
https://www.sitepoint.com/
https://www.smashingmagazine.com/
https://www.blog.gov.uk/
https://www.canada.ca/en/treasury-board-secretariat/topics/government-communications.html
http://www.w3.org/
https://boagworld.com/
25
5/16/2017 23:19:02Using a SCM (Git), following KISS as much as possibleNot adding comments to obscure, clever code (guilty of that one); not paying the technical debt
26
5/16/2017 23:23:44Version Control using Git!Non-literate web content administratorsA List Apart
27
5/16/2017 23:45:12feature flags and turning things off. A range of tools for analysing codebases (from linting to dependency checking live apps) and keeping things up to date. Generally difficult to find the right balance between keeping code DRY and locking everything into shared components/tools (which due to expanding use cases can get more complicated and harder to maintain than less DRY codebases)... an art not a science to know when something is mature enough to share between things, but when done well, shared code that can easily be updated globally by changing a single dependency can make life easierThe more mature a project becomes the bigger the problems caused by poor/no longer fit for purpose decisions made in the earlier days of the project, but as the code base grows it becomes harder to move away from those decisions

The single biggest detriment to maintainability, however, is winning the argument that tech debt etc. is as important as feature development. Many developers on my team either feel they have no time to pay down their technical debts, or feel they have to do it 'off radar'. Underlying that, I think, is the difficulty of communicating about technical and often quite hard to define problems with non technical stakeholders.
Mainly fellow team members. Each team is different, and approaches will vary from workplace to workplace

As far as tooling goes, blogs, twitter etc are a good source of potential solutions, but how they are used depends entirely on what the team needs.

28
5/16/2017 23:57:09Clearly structured codeImplementing 'quick' changes at client requestBrad Frostv Atomic Design
29
5/17/2017 0:49:02refactoring every time you touch something and see potential for improvementlack of propogating and documenting patternsmeetups and talks about what others do
30
5/17/2017 0:49:49Simplicity, clarityComplexity, cleverness
31
5/17/2017 2:35:52Modular, single purpose code
Namespaced/modular CSS
"temporary" fixes that stick around forever
Append only CSS files
!important in CSS
Book: Maintainable JavaScript by Nicolas Zakas
https://smacss.com
Always looking for more
32
5/17/2017 6:39:47Good loggingPoorly structured code
33
5/17/2017 9:53:09Very strict linting rules.Over-engineered solutions. Undocumented subject-matter knowledge.
34
5/17/2017 9:56:43Refactoring toward the single responsibility principleCopy and paste codeSafari Books Online
35
5/17/2017 10:32:28Keeping it short. I think it's a universal truth that short code is easier to maintain that long code. It doesn't even matter that sometimes you have to use slightly obscure techniques to get your code shorter - less is definitely more. This is especially true of CSS (which is what I do most of my work in) - the more exceptions and overrides you add, the more unexpected the behaviour, and the more you have to crawl through to diagnose and fix issues.Short deadlines. The 'get it done yesterday' culture of my previous employer caused me to write some nasty code, and maintaining that was a nightmare. You can write a lot of code quickly if you have to, writing less often takes time.I don't have any specifically for maintainability, but learning new techniques and tools always helps. My go-to resources are alistapart and smashing magazine. When googling I will generally pick results from stackoverflow before looking elsewhere.
36
5/17/2017 10:39:06Don't repeat yourself (DRY)Managers deciding on technology stack.
37
5/17/2017 10:59:03Write documentationAvoiding planning
38
5/17/2017 11:13:45Strict CSS architecture (we use BEM), semantic HTML (no unknown divs and spans, unless properly commented), styleguide with component samples, in-file documentation.Mess in the code, lack of documentation (especially different modes and function params - we use JADE and SCSS). The goal is to not have to read the actual innards of a function in order to use it, and every non-standard / non-semantic / weird-looking code has to be commented. Nothing special - just picking things from newsletters etc. The only big sites I subscribe to are Smashing Magazine and A List Apart.
39
5/17/2017 11:14:17Regression TestingTime pressure for developmenthttps://www.heise.de
40
5/17/2017 11:18:51Component-based approach, naming conventions, style conventions, documentation, testsBroad CSS selectors, global JS listenersCSS tricks, Frond-end Dev Weekly, HTML5 Weekly, Smashing Magazine, Google Chrome Developers YouTube channel.
41
5/17/2017 11:32:14Using a CMS (WordPress mostly) for the client to be able to maintain it... Otherwise, keeping it manually up-to-date with regards to security.Tedious process of checking whether updates are available. Love the automatic minor updates of WordPress.A list Apart, A book Apart, Tutsplus, WPMUDEV (WordPress blog), ...
42
5/17/2017 12:19:10Clear structured code and naming conventionsWhen multiple people have worked on a project without using naming conventions and, for example, things get called "green button", "green button 1" etc and there is no reference/easy guide to what these names refer to. In the case of one website, we have three different parts of the CMS controlling different things that are simply called "Settings", which makes maintenance very difficult.
43
5/17/2017 12:28:05Documentation within code and outside explaining what things doNo documentationOther web devs
44
5/17/2017 13:32:15We mainly use WordPress. The best way I have found to keep WordPress sites maintainable is to only use the plugins that are needed. If something is able to be coded, code it. Don't rely on plugins.Time. The time it takes to update and QA a site.
45
5/17/2017 13:48:15Separate content from style as much as possible and document wellcustom wigits and behaviors
46
5/17/2017 14:22:35Consistency. Never do the same thing in two different ways without a very good reason. "Clever" code without comments/documentation.
47
5/17/2017 15:06:18Using short functions with few parametersBracket souphttp://phpdeveloper.org/, https://alistapart.com/, https://css-tricks.com/, http://ithare.com/, https://www.commitstrip.com/en/?, and https://xkcd.com/
48
5/17/2017 15:13:51Scrum methodology.Maverick developers.Google
49
5/17/2017 15:45:46Regularly audit your sites. Use automated QA services like SiteImprove.Shiny new projects often come at the expense of iterating existing projects.
50
5/17/2017 15:59:16A proper package manager that can list outdated packagesDependencies that themselves are not being maintained. Also, big-bang maintenance, where everything has to be updated at the same time.
51
5/17/2017 15:59:34Strong logic behind taxonomy and navigation so categories and tags are robust -- paired with a commitment to use existing taxonomy as much as possible when posting new content. This requires someone on the web maintenance team to serve as a thoughtful nexus between content (substance), site structure, design, and broader organizational communication goals and methods.Keeping technical and content decisions separate; allowing managers who have no familiarity with web content strategy to direct the addition of new content.https://alistapart.com/
https://www.nngroup.com
https://www.digitalgov.gov/
http://everypageispageone.com/
http://contentmarketinginstitute.com
52
5/17/2017 17:22:22This is a non-technical answer, but the most useful technique for keeping websites maintainable is excellent and thorough documentation - comments in the code, written standard operating procedures on how and when to do maintenance, version history easily accessible, etc. It can be very difficult to walk into a new job and maintain a site without this kind of documentation.It can be difficult finding the right block of time to do maintenance upgrades and installs where I am not inconveniencing users and where I can work uninterrupted. Usually this means waking up in the middle of the night, but that also means that other support people (network, database staff) that I may need aren't available.lynda.com, alistapart.com, smashingmagazine.com, dnnsoftware.com
53
5/17/2017 17:35:58Setting reminds and assigning it as a specific responsibility.New projects.Drupal.org
54
5/17/2017 18:19:29Self-documenting code (appropriate choices of syntax, variable naming, spacing etc.)Not testing on a wide enough range of devices (often due to project budget/time constraints, and small budgets for acquiring new/updated test devices - obviously emulators can be used, but testing it on the real thing matters)https://docs.microsoft.com/en-us/dotnet/articles/csharp/programming-guide/inside-a-program/coding-conventions
55
5/17/2017 18:24:04Having a spreadsheet to know when we've done major updates on sections of a large site.
Setting any kind of reminder schedule for individual pieces of content.
Making good notes, either as separate documentation or in code comments.
Keeping a separate spreadsheet or documentation means the knowledge is separate from the work
Often building a "good enough" solution means that it's not something that can be easily maintained.
Many times we take on so many new projects that there's no time to go back and fix or update
It doesn't seem like there's a lot out there! I've really wanted to go to the Now What! conference (http://2017.nowwhatconference.com/), though.
56
5/17/2017 19:09:24Well-commented code. Nothing helps a new developer get acquainted with a new project as much as this.The constant churn of new technologies. Too often, a developer writes code using the latest tool or library, then quickly moves on to an even newer fad. Five years later when the site needs to be updated, not even the original developer remembers how to use that tool.
57
5/17/2017 19:11:03a person who is accountable for maintenance, i.e., it can't be the town's cat.no codified processes or guidelinesLisa Welchman's book, Managing Chaos - http://rosenfeldmedia.com/books/managing-chaos/
58
5/17/2017 20:51:01Documentation and well commented code seem to be the two most useful techniques thus far. Having context as to how something "should" function before digging into it's code makes it easier to understand the decisions and compromises the original author made. Not refactoring and iterating upon codebases frequently enough. Letting a codebase stagnate to the point where the technical debt (usually measured by an outdated technology used) becomes unreasonable, and a full rewrite is required.https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy http://www.cleverpm.com/2017/05/12/a-product-managers-guide-to-technical-debt/
https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
59
5/17/2017 21:47:13inline documentation, limit foundational 3rd-party tools/scripts/libraries to those that are known to be maintained and supported, don't put off updates to build processesOverreliance on 3rd-party tools, lack of documentation (inline and external)CSS Tricks, CSS Wizardry
60
5/18/2017 7:13:11Resist the urge to integrate a new technology before planning its rollout across the entirety of your codebase. Use off-the-shelf technology where possible, for easier ramp up and easier help. Update software (internal and external) whenever possible, even in small ways, to stave off bit rot.Changing direction (e.g. adding a technology or framework or library) takes nearly forever to saturate, resulting in many layers of partial changes (aka lava flow).
61
5/18/2017 7:32:52Perhaps you should define what you mean by ‘maintainability'.A lack of a budget for maintenance.Perhaps you should define what you mean by maintainability.
62
5/18/2017 9:28:07bugs time constraintsnone
63
5/18/2017 10:00:36consistencyMaintaining Accessibility
64
5/18/2017 10:11:12Keep it simple. Most people get bored with their work or want something cool to work on or to experiment and over engineer things without always considering context. E.g. Introduce react to a project which needs a few lines of JS to display a twitter widgetWriting documentation or lack thereof. Assuming the next person working on the same code base has all of your knowledge is silly. People forget that a lot of knowledge is contextual. I'm not talking about things like jsdoc, but just things like "please ref to https://some-link-goes-here. For why we implemented x using y" or "I fixed this by doing z" in a Readme or comment goes a long wayTalks (search for empathy driven development by shamim). Talks by John Allsopp, he has given some great talks on current over engineering trend. We really should to other fields for inspiration, not enough people think about longevity of their work, so much code lives a lot longer than peopl anticipate
65
5/18/2017 10:14:22Pattern library/styleguide, collaborative working rather than silo working, acknowledgment that Design Systems can workDisorganisation (ie no attempt at understanding, growing or maintaining a system).* PatternLab by Brad Frost http://patternlab.io/
* Style guide guide http://bradfrost.github.io/style-guide-guide/
* Anna Debenham, work on Styleguides, including a podcast http://www.maban.co.uk/ & http://bradfrost.com/blog/post/style-guide-podcast/
* Jeremy Keith, initial work on pattern libraries https://adactio.com/
66
5/18/2017 14:20:27Writing tests (obv. helps with regression detection but also with documentation), rotating team members on all parts of the code base (forces code to be understandable, or at least be read and used by more than one person), using dependency injection helps compose objects and keep development fluid.Using the latest and shiniest tech usually comes at a high price (bugs, lack of maintenance over time, difficulty to find seasoned devs to work on it).Sadly, I use mostly experience and I rely heavily on the judgement of my colleagues.
67
5/18/2017 15:05:19Code design patternsScope creepYoutube talks by Rich Hickey, Uncle Bob, and others
68
5/18/2017 15:34:46Comments, documentation, and keeping the website as simple as possible (avoiding scripting except when it's absolutely necessary, for example). Inconsistent file naming, redundancy of content, not cleaning up test files when you're done with them, not deleting content when it becomes outdated or is replaced.http://www.worldcat.org/oclc/759583769 http://www.worldcat.org/oclc/965803137
69
5/18/2017 17:15:51I find component libraries helpful.Tech debt / legacy code
70
5/18/2017 17:32:12Good separation of concerns: content, display logic, and presentation nicely separated. Logical separation and object oriented principals in writing of server-side code, css (sass modules), and html templates.When deadlines are tight or client/design changes come in late in the project it is easy to "just get it done"BEM, Object Oriented Programming, Cross-training, KISS
71
5/18/2017 18:09:47An easy build and publish process.Poorly or incompletely planned sites, either architecture or long-term goals.
72
5/18/2017 18:13:47Trigger reminders in outlook, manual combing through of pages, googling key terms to see what comes up, broken links reports.Inability to keep up a living site inventorya list apart, google stuff, twitters
73
5/18/2017 20:46:32Build a simplified backend of the site from the start! Considering the lifespan and use of the site from the start of the project helps to shape your solutions into something that is easy for you and the client to maintain. More upfront work reduced the burden later.1. Time: just finding time in your schedule to perform code or content maintenance is hard unless you have a large dedicated team for it. When it is not your primary role or there is no designated role it is hard to carve out time in your already busy schedule.
2. Its boring work (for some people): again when it is not your primary role it can be considered boring work so finding motivation is hard.
3. The if it ain't broke don't fix it attitude: with busy lives people pick and choose priorities - if the site is still running sometimes it gets pushed to the back of the priority list - until it crashes!
Honestly - not until something breaks. I think this is a great topic to discuss in detail and build a trusted resource and workflow for everyone to build into their practice.
74
5/18/2017 23:19:33Documentation and examples! Breaking complex procedures into components.Art direction. For example, tweaking images to look just so, visually or compression-wise.alistapart.com theinterconnected.net css-tricks.com twitter.com
75
5/18/2017 23:26:47Leave a paper trail of your decisions, especially outlines committed to version control.CMS ingests that take in custom markup. This is obvious from the get-go but seems tolerated as standard, so leading to a spiral of one-off CSS classes and infinitely-nested divs.My gut! This is a serious problem.
76
5/19/2017 4:30:55• Always do documentation (comment code, do a readme and styleguide)
• Refer to official documentations (i.e. https://codex.wordpress.org/WordPress_APIs)
• Stick to normal practices for standardisation of work between other team members (e.g. PHP Standards Recommendation or PSR)
Easy coding and fixes done for the short term (we need to launch!) leads to technical debt, and thus making our websites harder to maintainhttps://material.io
http://foundation.zurb.com/sites/docs/
http://www.php-fig.org/psr/
http://gulpjs.com/
https://www.vagrantup.com/
77
5/19/2017 4:55:59Write all code from scratch where possible, and only use well supported third party libraries.Using crappy third party libraries and frameworks (e.g. Bootstrap, Materialize CSS)NNGroup, articles on Medium, AListApart. Depends on what aspect of maintainability I'm looking at (JS, CSS, consistency in UI).
78
5/19/2017 13:30:59Maintain an inventory of digital assets in a spreadsheet.Absence of documentation.Didn't find anything useful when searching for "site management"... (I agree with The Checklist Manifesto by Atul Gawande)
79
5/19/2017 15:47:28Keep all software on website up-to-date. If you've coded the software, make sure it uses the latest versions of software libraries and languages (e.g., PHP 7).Software that doesn't document it's dependencies. Software that, in a system like WordPress, loads it's own JavaScript libraries instead of the ones loaded by WordPress.Tom McFarlin's blog, Stack Overflow
80
5/19/2017 16:51:21Keep dependencies to a minimum. Enforcing strict coding standards. Proper abstraction; not abstracting too early; valuing simplicity over abstraction when it improves code readability and prevents needless obfuscation. Poor choice of third party packages. Lack of coding standards. Lack of in code documentation.
81
5/19/2017 18:25:41Table of contents, commenting.outdated codelynda.com, mozilla, stack overflow.
82
5/19/2017 22:29:14utilize strong code standards with reusable libraries that are easily extensible when necessary."too many cooks in the kitchen" when working with others on a project, direction and code standards suffer.www.csstricks.com, www.webdesignernews.com
83
5/19/2017 22:51:36Comments in the code - leaving little notes for "yourself in the future" Unpredictably indented nested codehttp://stackoverflow.com/
84
5/20/2017 15:47:49Commenting code decisionsPrevious developers building on other previous developers' workMisc websites shared by dev colleagues
85
5/20/2017 20:41:02separation of content and presentation, templatingdependency on themes/plugins/software by others that are poorly maintainedhttps://alistapart.com, staying on top of the development of the tools you are using
86
5/21/2017 18:14:50Style Guides, Development Standards, DOCUMENTATIONLack of rigor in following guides and providing documentationIndustry standard guides, practices, such as PHP PSRs
87
5/22/2017 5:34:46Good documentation and standards based code.Focusing too much on the "parts", and neglecting the "whole." Developers (myself included) sometimes jump into projects head first, knowing that we are capable of completing the initial ask rather simply. In doing so—and this is even more applicable to maintenance tasks than initial build tasks—we can easily cause unintended consequences to the project as a whole, including injecting idiosyncratic or overlapping code into the project. Also, there's way too much terrible "bespoke" javascript out there.https://www.w3.org/
88
5/22/2017 6:17:09Keeping it consistent to your goals, structured, and consistentUsing outdated softwareOther developers
89
5/22/2017 8:11:40BEM, SMACSSSelectors that reflect most parts of the DOM, especially those parent(s) to the module.There are too many. Some articles on medium, SMACSS, the books of Ben Frain and Micah Godboldt.
90
5/22/2017 8:45:04Pattern Library, Linting rules and automated UI testingHandling dependencies manually, having no code guide linesI can't refer to specific end-points. I just soak in, what ever comes in handy.
91
5/22/2017 9:21:21Auto updates of WordPress versions; WordPress plugin update notices.The need to test every change (I test each plugin after I update it)Blogs about WordPress
92
5/22/2017 14:22:58Having a disciplined routine. Wordpress
93
5/22/2017 14:51:14Taking ownershipShort term fixesTwitter, List apart
94
5/22/2017 14:54:36Version control (git/svn), CI tools, preprocessors / dev tools like Sass and Less Removing old, unused JS and CSSNot a lot. I often overlook maintainability but as I move toward continuous integration and iteration for clients this is becoming an important part of my process
95
5/22/2017 15:16:17Standards based developmentCustomizations of third party add one or extras
96
5/22/2017 15:20:42version controllack of documentationhttps://www.phparch.com/
97
5/22/2017 15:40:31Componentizing and commenting are top of my list.Projects that are poorly planned (pen and paper phase) and rushed tend to be the hardest to maintain -- lack of proper documentation.I honestly can't think of any. I've been involved in the Drupal project for a while though, and can say my involvement has taught me a lot in this regard.
98
5/22/2017 19:25:42styleguideslack of communication (human-written logs of changes)stackoverflow
99
5/22/2017 22:50:28IK
100
5/22/2017 23:18:13Version Control, CMS integrationUnversioned files, poor code quality
Loading...
 
 
 
0 Original
1 Content Scan
2 @@ Reformulation and Normalization