DBをGUIで操作するツールとして、phpMyAdminを便利に使っています。
ターミナルからmysqlにログインして、直接SQLを実行しても良いのですが、ちょっとしたSELECT文を試したいくらいのときにはおおげさです。
しかし、サーバの設定の都合上phpMyAdminをインストールできない場合があります。
あるいは、phpMyAdminをインストールすることが手間な場合もあります。

上記のような場合、がんばってターミナルからSQLを実行するしかないのでしょうか？
もっと、便利な方法があるはずので、探してみました。

Macならsequel pro

Mac環境の場合は、Sequel Proが定番のDBクライアントとなります（他にあったら教えてください！）。
基本的にMySQLのためのクライアントとなりますが、見た目のUIなどはphpMyAdminに似ているため、違和感なく移行できるかと思います。
テーブル操作やSQLの実行まで、一通りのことができるため、Mac環境であればSequel Proがあれば問題なく使えそうです。

WindowsではA5:SQL Mk-2, MySQL Workbench

普段仕事をする環境はWindowsなのでSequel Proを探してみましたが、Windows版がありません。
ただ、類似のアプリケーションとして、A5:SQL Mk-2, MySQL Workbenchがあります。
両方ともphpMyAdminに似たことができますが、A5:SQL Mk-2はどちらかというとDBのモデリングが主な機能であり、MySQL WorkbenchはMySQL専用でテーブル操作にはあまり向かないという印象があり、実際に業務で使用するならば使い分けることになりそうです。

Linuxでがんばるならmycli

上記はGUIでDBを操作できるものを取り扱いました。
しかし、どうでしてもターミナルから操作しなければならない場合もあります。
GUIに慣れていると、SQLのコマンドが思い出せずに検索して時間がかかることがよくあります（筆者がそうです……）。
そこで少しでもSQL入力を楽にする方法として、mycliがあります。
mycliはデフォルトのmysqlコマンドを代替するもので、mycli -u root -pなどとしてログインすると、コマンドやテーブルの補完機能を使うことができるようになります。
SQLの文法が思い出せいない場合、何文字かを入力してタブキーを押せば、それらしいコマンドをサジェストしてくれるので、いろいろはかどります。

まとめ

主要な環境で使えるDB操作アプリケーションを紹介してみました。
DBは１つ操作を間違えると大変な結果になるため、素早く正確に（しかも簡単に！）できるようにしておきましょう。

日々多様化・複雑化していくあらゆるシーンに於いて、シームレスにアテンドするソリューション事業部はこちら

●Wantedly掲載情報(本当にやりたいことに辿り着きたい技術大好きエンジニア募集！)

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

●Wantedly掲載情報(Angular/Reactを極めたいフロントエンジニア大募集！！)

開発をする上で、どうしても発生するのがバグです。
バグのない開発ができれば言うことありませんが、実際はいろいろな原因で問題が発生するものです。
発生してしまったバグをどのようにデバッグすればいいのか、普段気をつけていることを整理してみたいと思います。

バグの再現

バグを発見すると、反射的に修正したくなるかもしれません。しかし、ここを我慢しましょう。
修正しようとする前に、まずそのバグが確実に発生するのかを確かめましょう。
バグが発生したりしなかったりする状況は、なにを修正するのかすらあいまいになってしまうため、無駄な時間を使うことになりかねないためです。
再現させるための前提として、サーバや開発言語を可能な限りバグが発生した環境と同じに揃えるなどして、１つ１つ不確定要素を潰すようにすると良いでしょう。

原因の特定

バグを再現できるようになったら、次は原因を特定しましょう。
原因を特定する方法はエンジニアの数だけやりかたがありますが、おおむねのところ共通する手法は以下になるのではないでしょうか。

01．仮説を立てる
02．ログなど事実（データなど）を収集する

実際のデバッグにおいては、２つのうちどちらか１つを使うというものではなく、両方の組み合わせになるかと思います。

注意すべきは、なにを調べたら良いのかわからず、闇雲に原因を調査することです。
とはいえ、実際に調査する方針がつかめないこともあるため、闇雲に調べる場合はせめてどのようなことを調査したのかを書きだしておくと、１つ１つ原因を追いこんでいくための助けになるかと思います。

用途に応じた修正

原因が特定できたら、いよいよ実際の修正を行いますが、ここでも考慮したいポイントがあります。

01．簡単で根本的な修正
02．難しくて根本的な修正
03．簡単で場当たり的な修正
04．難しくて場当たり的な修正

※根本的な修正とは、今後の変更や拡張性などを考慮した修正であり、場当たり的な修正とはとりあえず問題が解決していれば良いものとする修正を表します。

基本としては根本的な修正を行うべきですが、実際は１から４のうちどれを選ぶかは状況に左右されます。

場当たり的な修正が良くないとわかっていても、時間的な制約で選ばなければならないことがあります。
そのような場合はコメントを残したりチケットに登録したりと、後に対応することになったとき、少しでも楽になるようにすると良いかもしれません。
なにしろ自分で記述したコードであっても、１カ月後には忘れていることもあるためです。

修正の確認

問題が修正できたら、実際に修正できているのかを検証しましょう。
修正したての状態だと、特定の条件下のみでは意図通りの動きをするが、条件を変えたとたんに動かなくなる場合が多いためです。
特に、場当たり的な修正を実施した場合は、修正したことの副作用として別の場所でバグが発生するということすらありえます。
ここでハマると、場当たり的な修正→別の場所でバグが発生→場当たり的な修正……というループにハマってしまわないように気をつけたいところです。

まとめ

デバッグ方法を整理しましたが、書かれていることは当たり前のことかもしれません。
しかし、どのような状況でも上記ステップを着実に踏んで進められるかとなると、話が変わってきます。
ハマってしまうと、気がつくと闇雲に原因を探してしまっている……、ということは良くあります。

上記ステップを踏んでデバッグを行い、その上でどうしても解決できないバグがある場合はどうすれば良いものでしょうか？

答えの１つとはしては、その日は切り上げて帰って寝てしまうことです。

身も蓋もない答えかもしれません。しかし１日かかって解決しなかった問題が、次の日すっきりした頭で取り組むと１０分で解決するということが意外とあるためです。
だいたいの場合、解決方法は複数あるものだったりします。
頭がすっきりしているときに改めて取り組むことも、立派な解決策の１つであることを思い出せるようにしておきましょう！

日々多様化・複雑化していくあらゆるシーンに於いて、シームレスにアテンドするソリューション事業部はこちら

●Wantedly掲載情報(本当にやりたいことに辿り着きたい技術大好きエンジニア募集！)

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

●Wantedly掲載情報(Angular/Reactを極めたいフロントエンジニア大募集！！)

データベースのパフォーマンスを考える上で、本でいう目次に相当する機能であるインデックスを適切に設定することは重要です。
インデックスはデータベースの検索速度に大きく影響し、引いてはWebサービスの快適さに直結します。
今記事ではインデックスについて整理してみましょう。

インデックスのメリットデメリット

先ほども記述しましたが、インデックス機能を使うメリットは検索速度の向上です。
使いかたによっては10倍以上も速度向上が見こめるため、適切なインデックスの使用は必須と言えるでしょう。

逆に、デメリットもあります。
インデックスはINSERT, UPDATE, DELETEを実施するたびに再生成されます。
そのため、変更の多いテーブルにインデックスを作ると、逆に動作速度が低下することもあります。
また、巨大なテーブルにインデックスを作ると、インデックスのファイルサイズが大きくなるという問題もあります。

インデックスをどこに使うか？

実際にインデックスを設置するには、どのようにすれば良いでしょうか？
もちろんデータベースのテーブル構造ごとに異なりますが、おおまかな指針を考えてみます。

01．WHERE句
インデックスは検索速度を向上させるため、実際にWHERE句に使うカラムに設定すると効率化が見込めます。
ただし、データ量が多く変更が多いカラムの場合は、インデックスの再生成が何度も実施されてしまうため、かえってパフォーマンス低下の怖れがあります。

02．結合条件
これは上記WHERE句と同様に、絞り込みを行う条件であるため、インデックスを効果的に使用できるためとなります。

03．カラムの値の種類が多い
区分などで0か1など、条件しかデータがない場合は、インデックスは効果を発揮しません。
名前など、データが複数あるもののほうがインデックスを使用するものとしては望ましいものとなります。

まとめ

データベースの速度はサービスの快適さに直結します。
ユーザに使いやすいサービスを提供するため、常に速度を意識したデータベースを構築しましょう。

●Wantedly掲載情報(本当にやりたいことに辿り着きたい技術大好きエンジニア募集！)

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

●Wantedly掲載情報(Angular/Reactを極めたいフロントエンジニア大募集！！)

大規模なシステム開発をしていると、そこそこの頻度で使用するコマンドがあるかと思います。
そのなかでも今回は、定義ジャンプを紹介します。

定義ジャンプとは

コーディングをしていると、メソッドの内容や使用時に必要な引数がどのようになっているか思い出せないことが発生します。
そのとき、都度メソッドがどのファイルのどこに記述されているかを探すのは手間となってしまうでしょう。
そんなとき、定義ジャンプ機能があれば簡単にメソッドなどの定義先に移動して、内容を確認することができます。

EclipseやといったIDEや、Atomなどのモダンエディタであれば大半の言語で実行可能な標準機能となりますが、歴史的なおさらいも兼ねて今までのやりかたも紹介してみたいと思います。

検索を容易とするインデックスを作成するtags

tagsとはメソッドや変数などの定義箇所のインデックスを作成するためのプログラムです。
そのなかでも複数の言語に対応したctagsが有名（Google検索でたくさんヒットする）なので紹介します。
以下のようなコマンドを実行すると、tagsというインデックスファイルが生成されます。

ctags -R –languages=PHP –langmap=PHP:.php.inc –php-types=c+f+d -f ~/tags

生成したファイルを読み取り、定義ジャンプを実現します。
元々がUnixプログラムである関係上、vimやemacsなどのCUIエディタで実行可能でしたが、近年はwindowsでも秀丸エディタなどで対応しています。

プログラムを解析して情報を提供するlanguage-server

tagsを使ってインデックスを作成する方式は、安定しているとはいえ古いやりかたなのは否めません。
そこで、MicrosoftがVisual studioとは対照的に、軽量なモダンエディタとして発表したVisual Studio Code（以下VSCode）ではどのように実現しているのかを紹介します。

2016年にMicrosoftはlanguage server protocolという仕様を公開しました。
これはプログラムを解析してコード補完、変数やメソッドの定義参照、コードのエラーチェックなどの機能を統一的に提供するプロトコルになります。

機能ではなくプロトコル（規約）であるところがポイントで、プロトコルの形式を守ればどのようなエディタであっても同じ定義ジャンプ機能を実装可能となります。
実際にはVSCodeで使われていますが、vimやEmacsでもlanguage-serverを使用した言語ごとのプラグインが各種公開されており、ctagsなしでの定義ジャンプが可能となuものがあります。

まとめ

昔ながらのctagsを使用する例は減りましたが、VSCodeなどモダンエディタが使えない環境においてはまだまだ現役です。
既存のコードを検索する時間をtagsやlanguage-serverでなくして、新しいコードを書くことに集中できるようにしましょう！

システム開発時のよくあるパターンとして、機能を追加しようとすると既存のコードの複数箇所に修正をしなければならない、ということはよくあります。
修正をすることで別の箇所でエラーが発生して……、という頭の痛い展開を防ぎたいものです。

では、どのようにすれば良いでしょうか。

OCPのクラス設計方針とは

拡張に対して開いている（Open）
修正に対して閉じている（Closed）

上記方針を守った、クラスの設計方針のことです。
仕様変更に対して、機能追加は簡単にできるように、かつ既存のコードを変更しないでいいようにすることを指します。
巨大なシステムであるほど、既存のコードに対する修正はリスクが高まり、機能追加時に修正が不要になることは大きなメリットがあります。

OCPをどのように使うのか？

どのような方針で設計をすれば良いのでしょうか。
『アジャイルソフトウェア開発の奥義』の著者ロバート・C・マーチンがあげる例によれば、呼び出すクラスに依存させるのではなく、インタフェースや抽象クラスに依存させることを指針とすべきだ、というものです。
直接クラスを使用すると依存箇所ができてしまうため、インタフェースを実装したクラスを使用することで、インタフェースを実装したクラスであれば差し替え可能にすることで、変更を防ぐというものです。
差し替え可能にすることで柔軟性を保つという発想は、依存性の注入（Dependency Injection）とも重なります（ここでは割愛）。

まとめ

複雑なシステムを構成するには、機能追加に柔軟な設計になっていることが必要となります。
『アジャイルソフトウェア開発の奥義』には他にも有用な考え方が多数掲載されており、筆者も勉強中となります。

ところで、上記内容を解決するための根本的な発想はもう１つあります。
コードを書かないでいいようにすることです。
コードがなければバグもない、そんなの当たり前と考えるかもしれませんが、クライアントと相談するなどすれば意外とコードを書かないでも解決できてしまったりすることがあるのです。
OCPに沿ったコードそのものが本当に必要なのか、書かないでいい方法はないか、ここから問うようにしましょう。

●Wantedly掲載情報(エンジニア想いの環境でJavaやPHPにチャレンジしたいエンジニア募集！)

株式会社CPR ソリューション事業部はこちら