Hello. We are a pragma centered on the web system. I've made a lot of mistakes this year, from small mistakes to moderately large ones. I'm a newcomer and haven't received much authority yet, so I did it in the production environment I don't think it has as much impact as everyone else, but there are points to reflect on in coding and development environment construction. I would like to summarize it. Enjoy as there are anti-patterns.
・ Coding ・ Environmental ・ As a person
Anyway, there were many. If it is a class name or function name, an error will occur immediately and it will be easy to find it, but if you misspell the variable name in php, null will be assigned as it is and it will be difficult to find it, and it tends to be a waste of time.
$address = 'hogehoge';
print $adress; //No return value
It's a silly typo, but the time wasted on this kind of error-free typo can be quite huge throughout the year. The solution was to break up the __ code into smaller pieces and run the tests diligently __. I feel that this has made it faster to find typographical errors. Also, the editor uses VS Code and I originally used the __complement function __, but when the amount of code was large, it was difficult to read __ and I sometimes gave up using it and manually entered __. I would like to devise ways to make good use of the complementary function in the future. ...... It may be better to use __static language __ than that.
The other day I had the opportunity to write near-raw SQL using Laravel's selectRaw method. The column that is the target of the WHERE clause contains a path __ that uses a __backslash, and this part cannot be escaped, resulting in a failure that results in 0. It is almost the same as This question.
//Failure example
DB::table('hoge')
->selectRaw('* WHERE `path`="PATH\\TO\\SOME\\MODEL"')
->get();
At first glance, it seems that it can be escaped, but in php, the backslash becomes // → / in double quotes, and it is not escaped by Laravel's raw related methods (or rather That's right because it says raw), so the query sent to MySQL looks like this:
SELECT * FROM hoge WHERE `path`='PATH\TO\SOME\MODEL'
As a result, it was escaped even in MySQL and died safely. It is best not to write such raw SQL as much as possible, but at this time it was unavoidable due to various circumstances, so I solved it as follows.
//Success story
DB::table('hoge')
->selectRaw('* WHERE `path`="PATH\\\\TO\\\\SOME\\\\MODEL"')
->get();
SELECT * FROM hoge WHERE `path`='PATH\\TO\\SOME\\MODEL'
Anyway, backslashes tend to be a source of problems, so I'd like to be cautious.
When you start Docker and work on the shell, you may get command not found by mistake whether you want to execute the required command inside or outside the container, or in the worst case, unexpected processing may start (stripes). did).
Basically, which command to execute and where to execute depends on the project, so I started to check before executing. In particular, I would like to be careful because I had an accident at the execution location of composer.
I often install dependent packages with composer, but I haven't specified a minor version, which may cause problems.
Also, what I was particularly stuck with this year was the different version of __composer itself __.
Version 2.0 of composer was released around October 2020. As a result of executing the docker-compose command without noticing this, various composer-related commands were executed in DockerFile, and a large number of errors occurred.
The solution to this problem used the same method as this person.
The command is:
curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --1 --filename=composer
Details of the version upgrade are here.
When I remember, my stomach hurts ... Even though the progress was poor, I did not inform my boss that the progress was delayed until the deadline due to trial and error trying to recover. His boss didn't get angry at all, and I was scared when he returned a message saying "I understand. Please contact me and consult with me as soon as possible." Anyway, early reporting, contact and consultation are really important. I thought that lack of contact was the most detrimental to technical mistakes.
Even if the specifications are changed frequently or the specifications are difficult to read, as long as the specified specifications are unique, it is absolutely useless if they do not meet the specifications. __ Again __ before committing, do not neglect to check the deliverables. I think it's important. Also, I want to be able to find inconsistencies when I first read through the specifications. I often notice it after I start implementing it ...
After all, most mistakes were due to lack of confirmation. Before committing, before command input, before reporting to my boss ... I would like to look back on this article and reduce mistakes. So, thank you for your hard work for a year. Let's do our best in 2021! !!
Recommended Posts