There are many ways to go around writing software, and especially when the major processes would have to be edited. The most often edited files/folders in ruby on rails is the routes, controller, model and the view and depending on how big the software is, there can be more files needed to be edited such as services after modifying models and controllers, decorators to refactor the view, and stylesheets and javascript to give some flare. And over the course of 4 weeks of being an apprentice I have seen a pattern that works really well (or at least for me)
thinking process
In my day to day tasks, I always try to be as methodological as I can. I do like to have a method or a personal way on how to do things. Immediately when I read a task or feature that needs to be implemented, I do my research on what it is, why is needed, what are the benefits of having it, and how did others implement the same feature. I find that answering these questions helps a lot in my thinking process before I start my task. From this, I can deduce what I want to see in my code, how my code should work and how it should react. From this, I would have a better chance of knowing what to research when I encounter an unexpected bug.
start with the end in mind
When editing files, it is easier to first write the code that you would like to see at the end then write the parts to make it work after. With this, I know that my end result would be better and my train of thought would be better because I would ask myself constantly: how can I make this line of code work. I have noticed that when I edit the model first, I would have to change it a lot more as I go to the controller to access it and the view to render it.
If you start editing the view first, chances are the next file edit would be the controller so it would work. Then from the controller, you might want to refactor a bit to put it in a model or a service.
writing process
After writing the code I do find that git diff (assuming that you use git, and I hope you do), helps so you can see what files you have changed, and if there is a way to make it better. I have read in a job description once that a developer should ALWAYS review his/her work before a commit, which now I see as a really important habit to have after all, when you write something, it would be read by the smartest people you would meet and trying to impress your readers is always a good idea.
write the best code you can to make it work then disprove yourself by writing some tests after. I do know that there are huge benefits to a test driven development but for now, especially at my level, I do know that it would take me three times longer if I want to have a really good design. At the moment, I feel that the design of the code has more precedence against tests but tests are really important. With tests, you would have the confidence to tell your seniors that it actually works.
After writing the tests, refactor until it is stupid simple. It does not matter how many classes you touch just to make one simple feature if it means that it would be easily read by other developers. I have watched a clip on youtube about refactoring which can be watched here: Refactoring from Good to Great by Ben Orenstein. Also, refactor your tests! This is a statement that I try remind myself every day because I do have a tendency to skip it and it is really important.
Refactoring code is really important since it would make it easier for the next developer to add more into the code, and it could also be easier for yourself to add more.