Using Free Code the Right Way
At some point in trying to create that next great app or finding a lasting solution to that irk-y software bug or just wanting to fix up a nice new way to code up some functionality that will ensure your code stays DRY — (Don’t Repeat Yourself), we (developers) are always confronted by the need to balance the trade-offs between time spent working on code for a product/service and the overall results achieved for completing a prototype or a release candidate with requisite specifications met. Thanks to the graciousness of “Open source”, we can always find bits of code that can help us do less work and cover more ground in a software project or more work in a little amount of time. Different people all over the world are always writing good working code and putting them up for consumption at little or no cost. This culture of “build and share” in the various communities of practice for several computer software creators has been around for as long as I can remember (actually, way before I wrote my first code back in 2005) and it will continue for years to come (long, long after I’m dead I guess). But, we all know there’s some price to pay for stuff that comes free or ‘*Awoof*’ (the slang for free stuff where I come from).
The Problem
Free food can be good thing for anyone who is used to it though most people will tell you that it sometimes is tasteless and not well cooked (making you fart so bad). And it’s always difficult to add good taste to a food that has already been cooked with a bad one. The same applies to code you didn’t write and obtained for free. It’s sometimes done with a lot of haste, and little regard for pertinent use cases (which you might be interested in). Even with these challenges, most people still prefer to work with free code for most scenarios because it provides some way to stay with the latest trend and the benefits well outweigh the inconveniences of writing yours from scratch. Consumers of free code have over time found a way to ignore poor quality code and go for code written by seasoned professionals in the field (me inclusive). Best practices, robust APIs and sound logic are some of the ingredients that make free code so attractive and have early adopters (plus late ones) screaming for more. Over the years, free code has become so mature. It goes through various acid tests as a means to benchmarking performance (based on CPU cycles used, memory usage etc). Contributors to free code never stop shaping it into better capabilities and creators of this free code have to keep deciding whose contributions make it into the masterpiece and whose never see the light of “compilation” or “interpretation” as the case may be. However, even with all these well guided efforts, free code still isn’t “free” of problems. Some of these problems can keep a developer up through the night for days (even weeks) or worse completely break the code that existed before a recent update release. My experiences with language updates, code libraries and application frameworks over the years have taught me a lot about free code and how to use it without sacrificing control and creativity. Here are some of the steps I recommend in using them while keeping it all together.
The Right Way
The right way to use free code is to get involved with free code. By this i mean create a very structured approach to your usage of freely available code whether offline or online. Here are a few tips to help you along the way.
Careful Review of Documentation
Get the code and documentation from the first party: There’s no one who knows the code better than the one who wrote it. This is true for all things open source. The authors of the code you use should always be the first point of contact to the code. Find their repos on GitHub (or GoogleCode or Sourceforge), checkout their blogs for information on the code. These days, API designers and open source evangelists/angels prefer not to use their blogs to give detailed preambles about their codes. They either have an self-managed site for the code (jQuery/React/Vue/Wordpress/Drupal plugins mostly) or an official community-managed site for the code (Flask, Laravel, KnockoutJS etc).
Dig the Source
Read about half of the source: Did I hear you say “WHAT!!!”? I know, I know, but give me a break (would you). It’s a tough job already being a developer so, am I suggesting that you make it tougher? Well, not exactly. Doing a code review is a lot of work. But, if you want to be able to experiment a lot with several coding options, you may have to dig deep into the code itself. I have read a lot of online forum posts on different platforms which discuss programming and the recurring issue with the content of these posts is that their owners lack an understanding about how the code is supposed to work. Some of them feel they have just the right amount of information from the official docs but often isn’t enough to tackle certain issues with the code and others (having read the docs too) seem to bring their idiosyncrasies into the way they think the code should work for them but don’t really understand what’s going on under the hood. So, when they try to get “creative” so to speak, that lack of understanding comes to bear and then they start seeking for help from the internet. It’s not as if these problems with code absolutely need many heads to figure stuff out. No! It just needs a bit of moving through the origins and see what’s at work. These are some of the ways bugs are found and reported to the authors. My advice will be if you can’t read the code or simply don’t have the time, get someone who knows the code well (he/she might be a member of the core development team). The explanations from such a person can lead you to a deep understanding of the code and a much better advantage at using it well.
Find out about caveats (a.k.a gotchas)
There are already countless resources on the internet that contain information about the free code you are currently using or planning to use. From the popular StackOverflow to Google Groups, discussion threads are reeling with a lot of detail about the many challenges faced by other developers like you. Gotchas arising from wrong use (even when you think it is right) of code can bite when you least expect it. For example, it took me several roundtrips to and fro different search engines to find out that JavaScript `localStorage` didn’t work with the file:/// protocol. Things like these slow you down as you code up. You will want to get some knowledge on known pitfalls for the code you use so you don’t fall victim!
Secondary Sources
Search for and consume the “secondary docs”: What’s the “secondary docs”? — you might ask. Well, these include every other thing about the code (source code excluded here though) that isn’t contained in the official documentation — issue logs, release notes, cheat sheets, and the cliché readme. Much of the information tucked away in these items is very valuable especially if you plan to use the code for a very long time with several different projects. They inform you on some salient and not-so-obvious things that may come up while trying to use the code in a specific environments or wanting to push execution performance to the negative extreme. An example is the annoying “Class Not Found” error that crops up when you don’t re-generate the class loader for newly added packages or don’t import the namespace for the class properly in Laravel. This can be quite a hitch especially when your boss is breathing down your neck every 5 seconds. My advice is that you use secondary docs when you can.
Best Practices
Seek out best practices: When I have discussions with colleagues over the internet, in person or on the phone, the need for making use of code patterns, modular constructs and standard architecture paradigms is never under emphasized. Software has become a whole lot more complex than it used to be over the last decades. The MVC paradigm for instance, is no older than it was 5 decades ago (It was known by a different name then). But, it now has a lot of addition from that time and it’s also gaining fast and contagious adoption all over the software community. I listened to a beginner once complain about AngularJS. He said the pattern of development it presented was very confusing and he had to drop it 3 weeks into trying to learn the framework. I think as developers, it is important to find out the trend and stay with it. It could be very difficult to use free code that makes use of best practices if you don’t know and use best practices yourself.
Conclusion
Coding is fun for those who love it but frustrating at times too. One basic step to not fall a victim of code frustration is proper review of a code or library that is not originally yours. Please kindly share your opinion about other ways to use free code.
