Introduction
During my Christmas holidays at the end of 2019, I spent a bit of my free time building a Laravel package called Laravel Exchange Rates. The package is pretty simple and is just a wrapper for the exchangeratesapi.io API, with some caching features added for performance. At the time of writing this post, the package has around 43,000 downloads and has started getting around 4,000 downloads per month. It’s not that big in comparison to some other projects, but I’d like to think that I did something right for it to be getting that many downloads.
My main reason for building it was just so that I could experiment with packages. As part of using Laravel on a daily basis, I’d gotten used to using lots of packages. But I felt like the best way for me to properly understand how we use packages in Laravel was to build one myself. By doing that, I would be able to get an insight into every step of the process to try and improve my skills as a developer.
The entire development process was fun and taught me a lot. Here are the main things that I learnt from building Laravel Exchange Rates and that I’d pass on to other developers:
1. Learn to take criticism
When I first started building the package, I had only been working as a Laravel developer for around a year and a half. So, even though I had picked up the fundamentals of the framework, there was still a lot I didn’t know (in comparison to now). Because of this, I was already expecting to get criticism from more experienced developers.
After I’d built an initial version of the package, I posted a link to the GitHub repository on Reddit (on the r/laravel subreddit) asking for opinions and feedback. Overall, the feedback was useful and most people made some really valid points about some of the code that could be improved. I took their feedback onboard and updated the parts that they mentioned.
However, I did get some feedback that came across as criticism. As an example, one comment was just a link to an existing exchange rates package. I wasn’t too sure what to make of this, but I took it as meaning “ what’s the point in using yours? There’s already another one that exists”. As someone who was just starting out in web development and was quite excited to get a bit of feedback from the development community, this was a bit demotivating because it made me think to myself “ what’s the point in me actually doing it if someone else has already made it?”. Obviously, looking back now though, that probably wasn’t the case and the commenter might not have meant it like that.
The important part is that if someone shuns your work or criticises it, don’t let it get you down too much. If it’s possible, try and find out why they criticised your work. It can be good to sometimes take a step back and listen to other developers feedback to help you improve. But, also bear in mind, you don’t know if the person you’re taking feedback from is a top-notch developer or someone who only started writing “Hello World” last week. So, it’s really important to remember that the criticism won’t always be valid.
TOP TIP: Listen to the constructive criticism and use the feedback to improve your code, but don’t dwell on negative comments.
2. Learn to look at code from someone’s else perspective
When I was building the package, I found it really useful to try and look at the package from another developer’s perspective. I tried to imagine how I would want to use the package if someone else had built it. So, my main focus was to keep the method names readable and reduce the amount of parameters that needed to be passed to the methods.
Sometimes when you’re working on your own side projects (especially ones that you’re just building as a learning exercise), it can be easy to let standards slip. You might add a quick hack here and there to get something working instead of spending a little bit more time to do something properly. I wanted to try and avoid doing that with the package because I knew that it would be a sure-fire way to put other developers off wanting to use it. As developers, we don’t use packages purely for saving time, we also use them to make our life easier. It’s such a great feeling when you install a new package into your project and it just works without having to mess around to get it working. So, I aimed to provide that same feeling with this package. I wanted it to be installed and ready to go within a few lines of code without needing any complicated set up.
TOP TIP: If you can, ask another developer you know to give your package a try and see if they run into any difficulties or have suggestions for improvements.
3. Learn the importance of tests
As any developer should know, tests are crucial for any type of development; whether it be a full-blown system or just a small package. Thankfully, I knew that early on in the process and made tests a priority.
When I’m looking at including a new package into my project, one of the main things that I look at are if there are any tests. They provide some form of proof that the code does what it says it should do (assuming that the tests are written properly, but that’s for a whole other article). Without any tests written, how are we supposed to have the confidence that the code works?
These tests can then come in handy if you start to get other developers who want to contribute to the package later down the line. By using something like GitHub Actions, Travis CI or CircleCI, you can trigger your tests to run whenever a pull request is made to the package’s repository. This is extremely useful for letting yourself and the other developer know if the new changes break any existing functionality. After all, one thing that you want to ensure is stability. If projects that use your package start running into issues with the new code, it’ll likely get frustrating for them and they may even remove your package and look for an alternative.
TOP TIP: Make sure that you write tests to give yourself and other developers peace of mind that your code works.
4. Don’t be scared to start again
Near the beginning of this article, I said that I posted on Reddit about the exchange rates package. But that wasn’t 100% the truth. I actually posted about an earlier version of the package that I’d called ‘Coinverter’. Converter was supposed to be the same as Laravel Exchange Rates except from it was going to use the adapter pattern and support multiple APIs rather than just exchangeratesapi.io. The idea behind it was that a developer could just update their .env file to use a different exchange rates driver and change the API keys to switch between services without needing to update any of their code.
I spent quite a bit of time reading into the adapter pattern and I was quite excited to be working on the package. But then I slowly started to realise that I’d bitten off more than I could chew and I wasn’t experienced enough to do something like this properly. Sure, I got it to a working stage, but I just never felt like it was done quite right.
So, I decided to do what I mentioned earlier and I looked at it from another developer’s perspective. One of my main goals from the start of the package development was to try and make the package simple to set up, and intuitive to use, with a limited barrier to entry. As a result of this, I stepped back from the idea of using the adapter pattern. For the sake of simplicity, I chose to use just one service. My reasoning behind using the exchangeratesapi.io API was that it was free, really easy to use, and didn’t require any API keys or accounts to use (at the time time of building it).
I feel like by starting again and rebuilding the package, I managed to strip away a lot of unnecessary code that was just going to be adding unneeded complexity. The end result was a much simpler package that was easier to maintain, test and use.
TOP TIP: Don’t be worried about deleting your code and starting again. The fact that you know to start again shows that you’re learning and can spot your mistakes to improve next time.
5. Understand the importance of standards and documentation
As part of any development, standards and documentation are an absolute must. By following a set standard (in my case at the time PSR-2), you can make sure that your code is in a format that is understandable by other developers. By using a standard that’s well known, you can also make it easier for other developers to contribute to your code because they’ll be able to structure their code to be in the same style as yours.
The documentation is also really important because it’s the only thing really that’s telling developers how to install your package and use it. Before I started to write my documentation, I searched around and looked at other popular packages to see how theirs were laid out. After doing this, I wrote my documentation and provided clear steps on the project prerequisites, installation, usage, license and how to contribute.
Whenever I look at new packages, I read the documentation before deciding whether to install them. I check out things like:
- Does the package solve the problem that I’ve got?
- Does it look easy to use?
- Are there examples of it being used?
All of these questions form my opinion on whether to install the package. If the documentation isn’t very good, it might be a hint that the overall package quality might not be very good either (this isn’t always the case though!).
TOP TIP: Make the package as easy as possible to install and use by writing through documentation with code examples.
Conclusion
In conclusion, to recap I’d say whenever you’re writing a new package, listen to the constructive criticism and use the feedback to improve your code, but don’t dwell on negative comments. If you can, other developers you know to give your package a try and see if they run into any difficulties or have suggestions for improvements.
Make the package as easy as possible to install and use by writing through documentation with code examples. Also make sure that you write tests to give yourself and other developers peace of mind that your code works.
Don’t be worried about deleting your code and starting again. The fact that you know to start again shows that you’re learning and can spot your mistakes to improve next time.
But most of all, make sure that you’re enjoying it and having fun while you’re doing it! 🚀
Originally published at https://ashallendesign.co.uk.
