I have seen two other projects so far making an SSG. One of them was in a different language, so that explains how it would look different. The other one - in the same language I used, JS - had a different structure and implementation.
Nice to read!
This time, however, my third partner had a similar structure to mine! I was glad to read that code, knowing I share the same ideas with someone. Makes me feel like I'm doing something right. On the other hand, we both could just be doing a same mistake. I don't really think there is a "mistaken" way to write code, but some are objectively worse in terms of readability and speed. To be exact, the similarity of our projects was in function structure. I generally encountered a long big piece of code in one single function, or just a couple functions before. In my project and my third partner's however - we had functions for specific tasks, which I think is the whole idea of functional programming. Now, perhaps I divided mine in too many small funcitons, which makes it worse to read. I'm not sure. I am sure that I liked my partner's code though!
Implementing
At first I was lost in my task. I for sure read it wrong, since I have had a similar idea to implement way before this project - back in release 0.1. I wanted to change a default path for my input, since that was considered bad practice. But I still wanted to keep a default option, just for the sake of fast testing, instead of specifying a path every time. That's when the config idea came in. I tried to implement it back then, but I took on too many pieces - config, user input, async functions, error management... Yea, I got mostly stuck on user input which needed async stuff. I really struggle with async.
Now that I saw lab 3, I imagined I have to actually try again implementing all of those things. Turned out it wasn't the case. You didn't even need to generate a config through user input - it's literally a hand written JSON file. Yea.. turns out the task was actually easy...
The main problem I had with figuring out a solution was not understanding my partner's code. Yea, I know I said it was similar, however he used something I didn't - yargs. Many people did. I thought I didn't need to use yarhs, but now as I'm having more and more arguments and it's getting hard to manage. I will add an issue to transfer my own project to yargs. Back to my partner's code - I had to figure out what each line meant and until I did I continued to have problems. It was one of those - OOOOOHHHHH I WAS SO DUMB THAT MAKES SENSE.
It was interesting to see how my partner chose their features to implement. I was so used to seeing a .css in other projects, I was surprised he didn't do it in his.
Actual code
As concrete details go.. I was happy to use my previous knowledge in making this PR work. The idea of first making an object as a template, only then substituting data that you have to keep a logical structure is one I really liked. Simply put - it looks much better to write clothes.hats, clothes.shirts instead of clothes[0], clothes[1] or just hats, shirts.
I have also learned something from my partner's pull request. He checked for existing data before assigning variables, which I haven't thought of by myself. Thanks to him I added those checks to my code as well, only with a better looking shortcut. I actually asked someone I know if I can write checks like if (file) and he said no :D. After I googled, turns out you can do that! It wasn't an argument really, but it was cool to find something a more experienced programmer didn't know.
Reviewing his code
I honestly found this really easy and straightforward. Was it him doing a very good job, or our code structures being similar - he made it work and wrote it according to my style. I was impressed he figured out my argument handling. It looks kind of cancer tbh. That's why I want to change it..
Generally
I found this a good collab. We didn't have issues communicating, we did what we needed to do, learned things from each other, seems like everyone is happy. And I got more work to do...
Top comments (0)