Roll the program, fix it later!
Over the past 5 weeks of learning how to code at Flatiron School, I’m always reminded to not repeat the same line of code over and over (it’s a flag). Sometimes it takes a lot of my time during coding to refactor what I just wrote and end up spending way too much time looking at it.
Most of the time when we’re programming, we usually get caught in thinking what’s the best possible way to get this code to look good, “is this DRY enough?” etc. I find it easier to put out what’s working before you start refactoring, because in the end it puts out similar, if not the same results.
Now I’m not saying that we shouldn’t make our codes look cleaner, but if you do have a deadline and you’re not sure what line of code to use in order to do that, then it might be better to leave it for the time being and continue working on the more complex behaviours you want on your application. After all, we all want the MVP (Minimum Viable Product) to at least function before anything else.
It is also important that we make small commits to GitHub every now and then to or after every step during our project so it’ll be easier to pinpoint whenever we encounter an error.
Ruby on rails is amazing in a way that it can help generate a bunch of necessary files in one go. They’re called generators. Such as:
- Rails new: produces the bone structure of our application.
- Rails generate: this creates a folder in your application to put your code file, depends on what generator is being used. The main ones are Models, Controllers and Views. More on generators for rails here.
It can get pretty overwhelming when you have created a lot of migration files over the other, changing columns, names and the schema of your database but once they are set up most of your coding will be done in the Models, Controllers and Views folder.
With all those files set, handling bugs can be pretty annoying especially when you don’t know where to start from. Luckily, there’s Byebug! Which is sort of an upgrade from binding.pry in ruby.
You use it the same way as you would binding.pry, which is inside the code you are trying to run and make sure that the actions in your application reaches the code you are testing (correct routing). Here are some basic functions of it:
- n => executes the next line of code and move to the next line after the function.
- s => this will run the next function
- c => continues the program until it reached the end of code or it reaches another byebug point
- l => this outputs the source code that is currently being ran.
- q => quit ByeBug and return to the program.
Documentations on byebug .
You’re Basically Creating a Prototype
In the video above, it is mentioned that tech is always evolving and that “you’re just creating prototype”. What we created today may look good now, but might not do what we need it to do anymore in the future. Some codes might get completely overwritten, some might only need changes but no code is ever perfect.
When the project works and you want to keep developing it, you can invest more time in restructuring and refactoring your code so it will look nice to other people you collaborate with.
