give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

When Database Source Control Goes Bad 翻訳 Part9

The End… ?

最後に…?


And in the end, it is all about productivity. Much like every other aspect of development, your approach should not be dictated by what you enjoy, or your religious language preferences, or office politics, or any of that other junk that just serves as a distraction. In the end, the only really important criteria is whether your approach is going to help you and your team get more done in less time.


結局、これは全部生産性についての話だ。開発における他の側面と同じように、あなたのアプローチは自分の楽しいことや、宗教めいた言語の好みや、職場の政治や、気晴らしにしかならない他のつまらないもろもろを通じて語られるべきではない。結局、本当に重要な基準はそのアプローチがあなたやあなたのチームが短い時間で多くのことを完了できるかどうかということだ。


So please work to improve your database source-control. Think of the children. At least, the ones that will have to grow up and deal with your legacy crap. And yes, no matter how good of a job you do, they will vilify you anyway.


だからデータベースのソース管理を改善するために努力してほしい。そして子どもたちについて考えてほしい。少なくともその子たちはあなたのレガシーながらくたと一緒に育ち、付き合っていかなければならない。そしてどれだけあなたがいい仕事をしたって、彼らはあなたをけなしてくるだろう。


But in your quest to improve, keep an objective eye on your progress. If you come up with a system that introduces a little bit of overhead but greatly reduces integration issues and deployment-time debugging, great. But however if your process introduces more overhead and doesn’t actually reduce integration issues (and this will be the case most of the time), you have to be grownup enough to admit it and change what you are doing. Experienced developers tend get stuck in a rut of what they are used to doing, and refuse to change because it inevitably implies that they were wrong, and the company and their career suffers from the resulting mediocrity. One of the true tests of a developer’s wisdom is how readily they will objectively admit, to themselves and everyone else, that their grand idea completely sucked and should be thrown out. So to wrap up, here are the key things to remember: keep it scripted, keep it source-controlled, keep it trackable, and keep it local. Draw big fat lines between your environments, and handle promotion of database scripts even more thoroughly than your application code. Ensure that you can recreate any database anywhere, anytime, and use that create separate databases for every single environment, especially local development environments. Be aware of the politics and work around them the best you can, but don’t get pulled into them yourself. Clearly define your ground rules for how developers are going to merge your changes together. Lean heavily on your build server to enforce as much of this as possible, because a process that is enforced manually is a process that will never be followed.


しかし、改善を追求するなら自分の進歩に対して客観的な視点を持ってほしい。もし、ちょっと余分な時間を追加するだけでシステム統合に関する問題やデプロイ時のデプロイ時間を大きく削減できるシステムにあなたが出会えば、それは素晴らしいことだ。しかし、あなたのプロセスがもし、時間がたくさんかかるうえにシステム統合に関する問題を削減できないのであれば(これがたいてい実情となるだろう)、大人になってそれを認め、自分のやっていることを変更しなければならない。経歴の長い開発者ほど古いやり方から抜け出せず、変化を拒むものだ。なぜなら必然的に自分たちが間違っていたことを暗に認めることになるし、これまでの凡庸さのために会社や自分の経歴に傷がつくからだ。開発者の賢さを本当に確かめる方法の一つは、自分のことであれ他人のことであれ、それまでの尊大な考えが全くの失敗作で、捨て去るべきものだということをどれくらい進んで客観的に認めようとするか確認することだ。さて、要約するためにここで覚えておかなければならないキーポイントを挙げておこう---スクリプト化しよう。ソース管理しよう。トラッキング可能にしよう。ローカルに配置しよう。環境と環境の間に大きな太い境界線を描こう。アプリケーションコードよりもさらに徹底してデータベーススクリプトの昇格を制御しよう。いつでもどこでもデータベースを再作成可能にしよう。実行環境ごとにデータベースを分離しよう。特にローカル開発環境は必ず分離しよう。政治的な問題に注意し、その外側からベストを尽くそう。ただし、そこへ引きずり込まれてはならない。開発者が変更をどのようにマージするか明確にルール化しよう。これを可能な限り強制させるためにビルドーサーバーを大いに活用しよう。手作業を強制させるプロセスは誰も従わないプロセスになるからだ。


There are a million ways to approach this, some of them good, most of them not, but only you can determine what will fit your organization. So no matter what, keep working at it constantly. Like the rest of your code base and the rest of your development processes, you are either constantly working to improve it, or you are letting it get worse. Start small, take on responsibility yourself, make some minor improvements, lead by example, show people how much easier things can be. Good luck


こうしたアプローチは星の数ほどある。良いアプローチもいくつかあるが、大半はそうではない。しかし、自分の組織に何が合うのかを決定できるのはあなただけだ。それが何であれ、それを常に守って作業しなければならない。コードベースや開発プロセスと同様、あなたは常にそのアプローチを改善しているか、ほったらかしにして悪化させているかのどちらかだ。小さいことから始めよう。責任を引き受けよう。小さな改善を起こそう。手本を示そう。これまでの問題がどれだけ簡単になるかみんなに教えよう。Good luck。