Review your own code after some time, or another task.
Some time ago I had an idea. What if I could do a code review for my own code? Of course It would be nonsense to do it just after code was written. But what about day or two later?
This idea appears probably in the time, when I was the only backend developer in my team (holidays or something…). In such situation creating too much code and making too much tasks could be worse, than doing nothing. Checking this code would take all of my teammates’ time, I’ll have to make some fixes to at least some of them. And even, when the rest of team will be present, they will do CRs of my code and what could I do then? Writing more code equals more CRs. Infinite loop 😉 In such situations slack time would be better option imho.
So, I thought about some ways to be more efficient in such conditions. And self code reviews appears.
Another contribution to Symfony merged! \o/
My Pull Request has been accepted by Symfony docs guy and will be merged soon. This is a minor change, but I think it’s a good idea to improve anything we see that can be improved.
This particular change was created because I’ve seen at least 3 programmers getting parameters in service not from injection but from the container. Hope it helps them to understand how to use parameters in a good way 🙂
PR can be seen here: https://github.com/symfony/symfony-docs/pull/8399
Feels good 😎
I use git for about 3 years. First I knew only how to use it with PhpStorm –
cmd + t to update branch,
cmd + k to commit and push changes. To make new branch I used menu and let the IDE do the work. It was fine until I heard about
squash. I heard that it is often used when you contribute to someone’s repository. Maintainer of the repo often want clean history – if you want to contribute you must make pull requests with only one commit. And you may do it using squash.
It was a bit too much for me at that time:
push --force. No thanks 😉
Some time later a couple of people in my company started to use git more. They started to make squashes, rebases and so on. So if they wanted to use it I had to learn it too.
Lets talk about Git hooks. You’re using Git, right? No? But… you have to! Seriously, go to git-scm, GitHub or whatever and check it out.
In Git you have 3 types of files: tracked, ignored and untracked.
Tracked ones are simple – they’re just files you’ve added to the repository. This might be your application’s code. Ignored ones are also simple – if you don’t want to have any file you can add it to
.gitignore file and you will have it locally but not in the repository. This might be any vendors you can easily install and don’t need to store them in your repository.
But untracked files are a little bit more complicated. These are files you’ve just created and didn’t specify what to do with them. Are those useful and should be added, or are they just temporary files or vendors? They might be also autogenerated files and this post is really about them.