There’s very little code that’s completely independent of other code. A simple “hello world” in your favorite language relies on the code powering your language. As your objective gets more complex, you start relying on more and more code to get things done. Your code depends on other code, which depends on other code, which … you get the idea.
An unfortunate side-effect of code dependency is yours inherits the flaws of other code it relies on. As a result, your code sucks because the code it relies on sucks.
Instead of getting on a soapbox about poor code, since we’ve written and released our fair share of it, lets focus on how you can make code great again.
Recently I’ve been working with Node.js and MySQL. When I needed a dump of the database, I leaned on a module called mysqldump to get the job done. It exports queries that can build and populate the database as a .sql file.
While the process worked flawlessly, there was very little flexibility in how the dump works. You get a file. You may pick the location and the name of the file, but that’s it. It must be a file. This worked perfectly for the module’s author, but other users have different needs and environments to work in. In my case, my application is running on an ephemeral filesystem, which means files don’t stick when the server shuts down. Storing the dump on the server doesn’t work for me.
Great module.
any plans to add an option to save the mysql dump to s3 instead of to local disk file? looks like this might be changed by expanding line 151?
Alternatively, could you have on option to turn off the file creation on line 151 and instead return the datadump in the callback so the user can do the s3 upload themselves?
Tim
Source: https://github.com/webcaetano/mysqldump/issues/7#issue-153757451
Apparently I’m not the only one with the same problem. Tim wanted the content of the dump instead of a file written. He even identified the line of code where the file was being written. Four lines of code later, the module can hand you the dump in a callback instead of writing the file.
“You made a pull request and it was accepted. Cool story, bro.”
Thanks 🙂
Lets focus on how to make code great again, though.
- Use Other People’s Code
Seems like a moot point since most code relies on other code, but you need to make a conscious effort to use what others have written. Before you start writing code, check if someone else has written something you need.I could have written a dump module myself, but it’s likely to have had all sorts of bugs in it. The great thing about other people’s code is at least one other person is using it. The extra users will help unearth flaws in the code, making it more bulletproof.Making code great starts with consolidation of effort.
Instead of everyone writing their dump implementation, we focus the energy on making a good one. We can write wrappers around it for different use-cases, or tweak the core to improve how it works, but we don’t get ahead by having ten versions, each with their own peculiarities and bugs.
- Share Your Code
If the author didn’t share his module, I would either be writing my subpar version of the module or living with the bugs its bound to have. For example, someone noticed mysqldump didn’t terminate the connection to the database when it finished the dump. Despite an existing test suite and continuous integration, the author never noticed it. It was a really trivial issue though; one line of code added and the problem disappeared.Sharing the module gave others the chance to use it and discover the bug. The solution being shared also allowed others to get the fix instead of having to discover and fix the problem on their own.
I wish I had more insight to offer, but I’m still working on these two: intentionally using more of other people’s code and sharing more of mine. I’ll write more on the subject when I have a better understanding of how to make code great again.