新着記事

TORICOでは、開発者のエディタは JetBrains のもの (PyCharm, WebStorm, PHPStorm 等) を使うことにしています。今回、最初に必ず覚えたいショートカット・機能を紹介します。

かなり使うキーボードショートカット

Shift 2回 なんでも検索 (神検索)

Shift をダブルクリック でなんでも検索ができます。クラス、ファイル、関数などなんでも検索できます。

Shift 2回のあとさらに Shift2回 (つまり Shift4回) で、プロジェクト外のファイル ( Django や Vue などの依存ライブラリのコード)も対象に検索します。

このなんでも検索時、ファイルパスの末尾に :行数 が入っている場合、例えば auth/index.html:20 のような文字列で検索した場合、検索該当結果を開いた時その行がすぐに表示されるため、スタックトレースのログから該当箇所を開きたいとき重宝します。行数ごとコピーしてそれで検索すれば一発で見たい行が表示されます。

そのほかの検索

調べる対象が絞り込めている場合は、特定のカテゴリで検索したほうが検索結果を絞り込めるため見やすいです。

⌘+O … クラス名で検索

⌘+Shift+O … ファイル名で検索

⌘+Shift+F … ファイルの中身で検索

複数のファイル(プロジェクトに含まれる全ファイルや、特定のディレクトリ以下のファイル)から、内容にマッチするものを検索します。

⌘+Shift+A … アクション検索

エディタの機能を検索できます。ショートカットキーを忘れた時のチートシートとしても使えます。いくつかの設定項目の変更も、このショートカットから行えます。

⌘+[ … 戻る

コードの関数実行箇所などで ⌘+クリック することで定義にジャンプして、コードを読み進めていきますが、そのナビゲーションを戻る時に使います。ブラウザで戻るようにコードを戻ることができます。おそらく、マウスを使っている場合は戻るボタン(第4ボタン)がそのまま使えるはずです。

Control+Tab … スイッチャー

ブラウザのタブ切り替えと同じショートカットキーになっているはずです。

押し方によっていくつかの使い方があります。

Control を押しながら Tab を押してすぐに両方離す と、「1つ前に編集していたファイル(タブ)」に戻ります。⌘+[ の「戻る」とは違い、ファイル単位での行き来しかできません。

連続で押すことで、2うのファイルを交互に見比べられます。

このショートカットでファイルを切り替えた場合は戻るスタックに積まれるため、さきほどの ⌘+[ の戻るショートカットで戻れます。

Control を押しながら Tab を2回押すことで2つ前のファイルに戻れます。

閉じてしまったタブには移動できません。

Control を押しながら、Tab を押して離し、Control は押しっぱなしにする にすることで、Switcher が開きっぱなしになります。右側のペインにはタブ一覧が表示され、左側のペインには ウインドウが一覧表示されるので、直接クリックして選択したり、ショートカットキー(⌘+数字)を確認するチートシートとしても使うことができます。

このショートカットキーはJISキーボードではめっちゃ押しやすいのですが、USキーボードだと少し押しにくいので、Macの設定で Caps Lock キーをControl にしてしまうのがおすすめです。とにかく押しやすいため、タイピングが得意でなくても、キーボードを見なくてもミスらないという利点がありますので、積極的に使ってほしいです。

⌘+E … 最近使ったファイル

さきほどの Switcher と似ていますが、こちらはキーを放しても閉じません。なので、「最近使ったけど何個前に使ったかは覚えていない」ファイルであれば、このショートカットで一覧から探す。明確に 1つ(もしくは2)前に使った、と理解しているファイルであれば Control+Tab の Switcher で切り替えると良いでしょう。

タブを閉じてしまったファイルを選択した場合、新たにエディタタブで開いて表示します。

⌘ を押しながら、E を2回押す と、最近修正したファイルに絞って表示します。

⌘+Option+L … コードの整形

設定した整形ルールに応じてコードを整形します。

プロジェクトルートに .editorconfig がある場合、その内容に従ってフォーマットします。

あくまで簡易的なものとわりきり、本格的なコードのフォーマットは別途ファイルの保存時に行ったほうが良いです。

TypeScript なら eslint --fix (設定の ESlint 内にチェックボックスがある), Python なら autopep8 (file watcher  で), PHP なら csfixer (file watcherで) をファイル保存時に自動整形をかけることが簡単にできるので、設定してください。

⌘+Shift+N … New Scratch File

新しいスクラッチファイルを作ります。スクラッチファイルとは、プロジェクトに含めないメモ的なファイルを瞬時に作れる機能です。

新しい Python や TypeScript ファイルを作って即時実行させたり、SQLファイルを作ってDBを検索したりできます。中でも便利なのが、http 入力することで出てくる HTTP Request ファイルで、Postman ほど高機能ではないですが、簡単な HTTP リクエストをスクリプト化して実行できます。ターミナルから curl コマンドを実行するより簡単でパラメータも読みやすく、ログも残るため使い勝手が良いです。

開発環境を Docker で構築している場合、Python ファイル等を実行する場合はスクラッチファイルのディレクトリを Docker でマウントしてパスマッピングを設定することで実行できます。

HTTPリクエストファイルの解説記事

pleiades.io の翻訳記事: IntelliJ IDEA コードエディターの HTTP クライアント

私が前に書いた Qiita 記事: .http で簡単HTTPテストリクエスト

ショートカットキーでは使わないけど便利な機能

Find Usages

指定したワードの出現箇所を検索して表示します。ショートカットキーはデフォルトで設定されていますが、Option+F7 と若干複雑なため、もっぱら右クリック(二本指タップ)→コンテキストメニューから Find Usages を選択することが多いです。

リファクタリングする際、メソッドがどこで使われているか、とか、クラスをどこで継承しているかを調べる時によく使います。

Select Opened File

Project ウインドウの中にある、ライフル銃のスコープをモチーフとしたボタンです。押すことで、今エディタで開いているファイルをProject ウインドウの中心に持ってきます。検索や ⌘+クリックで掘り進んでいったファイルがどこにあるかを調べたり、その周りのファイルを読む時に使います。

Open In Github

エディタで該当行をドラッグして選択→二本指タップ(コンテキストメニュー)→ Open In → Github

すると、ブラウザが起動し指定行が Github で表示されます。

URL を Slack で他のメンバーに送ることで、課題箇所の共有ができます。

Enter Presentation Mode

部門会議などで共有スクリーンにコードを表示する時は、

View -> Appearance -> Enter Presentation Mode を行うと、コードが大きな文字で表示され、コードレビューがしやすくなります。

デバッガの「Evaluate Expression」

エディタでブレイクポイントを設定し、ブレイクさせた時にデバッガウインドウが表示されます。
このデバッガウインドウの上部に、電卓のようなボタンがあり、これを押すと小さなウインドウ (Evaluate ウインドウ) が表示されます。

Evaluate ウインドウの中の、Expression フィールドの中に Python のコードを書くと、それが評価されて Result に結果が表示されます。単純に変数の中身を見たり、メソッドのリターンを確認したりと重宝します。

デバッガの Pythonコンソール

ブレイク中に、デバッガウインドウ内にある Python ロゴボタンを押すと、Python コンソールが起動してデバッグプロセスにアタッチされた状態になります。

できることとしては、先程の Evaluate Expression とほぼ同じなのですが、こちらは Python の対話コンソール上で評価されるので、不足している import を実行したり、関数を定義したりもできます。 Evaluate Expression と合わせてデバッグ時には必須の機能なので、活用していきましょう。

Alfred から プロジェクトを開く

Alfred から プロジェクトを横断的に検索して開けると便利だと思ってるのですが、Alfred 内から JetBrains のプロジェクトを横断的に検索できるワークフローは、期待通り動くものが現状無く、作るのも難しそうです。

ただし、単純に何かのホットキー(例: Control + ⌘ + スペース ) で JetBrains Toolbox を起動するようにすると、起動した瞬間にプロジェクト横断検索のテキスト入力にフォーカスが移動するため、そのままキーボードでプロジェクトを検索して開けるので便利です。

関連記事

以前に、エディタの複数行同時編集の記事も書いているので参考にしてください。

テキストエディターの複数行同時編集で仕事がはかどる

開発者は、日々進行する業務を「タスク」や「課題」「イシュー」という単位にして、管理します。

ディレクションチームから、新たな機能開発の課題が生まれた時、それを課題トラッキングツールに作り、完了になるまでその業務をすすめていくことになりますが、この時ディレクションチームと開発チームで「完了」状態のイメージを揃えておかないと、この課題だけではなく、その次の課題の進捗にも遅延が発生します。お互いに、「完了」とは何かをより具体的にイメージしておくことが、開発をスムーズに進めることに繋がります。

「完了」とは何か

完了の定義は組織によって少しずつ変わってくるものだと思いますが、私が開発者に強くイメージしてほしい完了のイメージは、「もう作業をしなくていい状態」です。その課題に対して、もう何も考えなくてよくなったら、その課題は完了しています。

開発の進め方として

1. 何か業務課題が見つかる
2. 業務課題を解決させるために開発課題が生まれる
3. コードを書いてテストする
4. プルリクエストしてレビューする
5. レビュー指摘箇所を直してマージする
6. 検証環境に反映する
7. 検証環境で動作検証し、不具合箇所の修正や調整をする
8. 本番環境にリリースする
9. 本番環境で動作検証する
10. ディレクションチームに説明する

チーム編成や動作環境・開発手法の違いにより細かい所で違いはあると思いますが、おおよそこのような流れになります。

この中で、開発者は2-10まで担当することになると思います。動作検証に関しては、専用の検証チームや外注がいるかもしれませんが、検証中は開発者がのんびり待ってるわけでもなく、発見された不具合箇所の修正をしたり、サーバ側のデータを見て動作の確認をしています。

見積もりとタスク量

1. で業務課題が見つかり、2. で開発課題が生まれた時、ディレクションチームは業務課題の解決のために必要なコストの見積もりをします。コストの多くは開発時間で、開発には仕入れや材料が不要なため、単純な時間コストだけ聞く場合がほとんどです。「どれぐらいでできる？」と聞いてくるやつです。

その時、開発者は完了の状態をイメージしますが、そこでイメージするのは、多くは 3. が終了し、4. プルリクエストを出すタイミングでしょう。実際にそれで問題無い組織環境もあるかもしれませんが、TORICO や私がいままで所属していた企業では、「プルリクエスト出したら完了」とイメージするのは、関係者の考えている完了とは一致していないため、危険です。

ディレクションチームの完了条件

ディレクションチームが考える開発の完了した状態というのは、「開発成果が業務課題の改善に対して効果を発生し始める」時です。つまり、本番反映が終わりお客さんが使える状態になっている状態、ということです。

ディレクションをしている方は、開発者に「どれくらいでできる?」と聞いた時に「3日」と回答をもらったら、念の為に一度「開発着手してから3日で、お客さんが不具合なく完全に使える状態になっているか」を改めて聞いたほうが良いでしょう。開発者もそれを汲み取って、「本番環境で完全に動作する」と保証できる日程を答えなければなりません。必要以上に急いだり背伸びをする必要はな無く、大事なのは「本番環境で完璧に動作し、業務課題の改善に効果を発生している」状態を作ることです。そして、その状態にするためにどれだけの時間コストがかかるかの意識をなるべく正確に共有し、遠慮せずに伝える必要があります。

開発者の次の課題

コードを書いてプルリクエストを出した所で、開発担当者は一旦の区切りとなるため、そこまでを開発期間とイメージしがちです。わかります。実際はプルリクエストを出したら次の開発課題に着手することになると思うので、実際そうとも言えます。

ただし、次の開発課題を始めた後も、前の課題進捗は進むため、レビュー指摘箇所の直しだったり動作検証の不具合修正だったりで時間を使います。その対応を行っている時は、新しい開発課題は停止するので、新しい開発課題についても概ねのスケジュールを伝えているとしたら、遅延の原因になります。

別のタスクの開発時間を奪うような状態の課題は、「完了している」とは言えません。

そのため、「開発課題の完了」とは、その開発課題について何かを考慮することが無くなり、新しい開発課題に全力で集中できる状態をイメージすると良いでしょう。

本番環境て完全に動作する

さきほど、本番環境で完全に動作すること、ということを完了条件とする、と書きましたが、「完全に動作する」という文言に嫌悪感かある開発者もいるかもしれません。Windowsにも脆弱性があり修正パッチが月に何度も出ている、だから完全なんて保証できるものではない、という実例を話したくなるかもしれませんが、そういうことではないんです。本番リリースしたコードに不具合などのリスクがあることは、チーム全員もう知っています。

そうではなく、本番リリースにあたり自分の責任範囲でやることを全部かったか？ということを考えてほしいのです。もし、そこで「本番環境特有のある条件下でのある動作が検証できておらず、不安がある」と感じているのなら、検証するかチームに共有してください。リスクと時間を考慮して、チーム全体で対応策を考えられます。それらの細かい残件の対応を行い、もう確認すべき所は無い状態になり、「残課題はありません」と胸を張って言える状態が、もう作業をしなくていい状態であり、完全に動作する(かもしれない)状態です。機能リリースにはリスクがあり、不安があるかもしれませんが、検証を十分にやっているなら、具体的な理由のない不安は考えるだけ時間の無駄です。ダメな所がなければOKです。気にせず早くリリースしましょう。

実際のタイム感

おおよそですが、ウェブサービスの開発の場合は、プルリクエストを行うまでが、実際の開発進捗の半分ぐらいのイメージで良いと思います。コードを書きはじめて、プルリクエストまで3日だったら、検証と調整と本番リリースであと3日ぐらいかかる感覚です。

逆に、リリースしたい日がすでに決まっているのであれば、開発着手からリリース日までの半分のあたりで、一通りコードが書き終わってないといけません。リリース直前にコードが書き終わるイメージをしているのであれば、その開発課題のリリースは遅延します。

予定通りに完了できなさそうな時どうするか

完了タイミングを関係者に伝えているにもかかわらず、予定通りに計画が進まずに、進捗が遅延しそうな時はよくあります。

特にアプリケーション開発は、予期しない計算(計画)の連続であり、現代のアプリケーション開発で開発終了時刻を正確に見積もることは、正直に言うなら困難です。

現代のアプリケーション開発は、業務が十分に抽象化(自動化)されている現場であれば、作業時間を見積もれるような定形作業はまずありません。

もし、開発作業内に定形作業があるとすれば、それはロボット(スクリプト)にやらせることだからです。

アプリケーション開発というのは、誰もやっていない新しい課題への挑戦です。具体的には、他の開発者が開発したコードを目的のために計算して組み合わせ、求める計算結果を出させ、それを出力し記録する。というのがおおまかな流れです。他の開発者が開発したコードが、今求めているビジネス領域にどれぐらいマッチするかは誰もやったことが無く誰にもわからないため、未来に発生するトラブルを事前に知ることは不可能です。それどころか、ビジネス課題を解決するプロダクトの完成イメージさえ、開発着手時には十分決まっているわけではありません。コードを書いて、動作をチーム全員で試してから、ブラッシュアップしていくのが現代のアプリケーション開発です。

アプリケーション開発が実際にどのようなものか、未経験者に伝えることは難しいですが、例えば問題集のようなものだと考えています。達成するには全問正解する必要がありますが、問題集を開くまでは中にどのような問題が書かれているかはわからず、設問自体が自分の理解できる言語で書かれていない可能性もあります。ただし、問題集の厚みだけは見えます。その問題集を全問正解するまでの時間を、開発者は毎回見積もります。なので、見積もりはけっこうテキトーですし、楽観的に答えがちな人、悲観的に答えがちな人など、答え方に個性も出ます。(もし、それと似た問題集を解いたことがあるようであれば、似た問題集を全問正解するための見積もりはしやすでしょう。)

アプリケーション開発は、実際に書き始めてみないと難易度を理解するのは難しいため、開発途中で未知のトラブルに遭遇したり、方針の変更により、予定通り完了できない時もよくあります。

長期の開発案件でプロジェクトが予定通り進んでおらず、途中から助っ人を追加するとしたら、追加する人をよく考えて選ばないといけません。作業者より上位の人(部署リーダー等)であれば、大抵はうまくいきます。同僚の場合、(通常は別の課題を担当しているなどで) 現在の具体的な課題まで把握できていないとしたら、情報共有だけで1-2週間かかりそうです。実状をまったく知らない部外の開発者であれば、現状把握に1-2ヶ月程度かかることも考えられます。新規参加メンバーに情報共有をする場合、教えられる側はもちろん、教える側も大きな作業工数がかかりますので、新しい人を参加させ、開発のスタート地点に立たせるだけで大きな時間を使いますし、もし新規参加の方であれば、実状を把握してコードを書けるようになってから、支払った時間を回収できるだけの成果を出すことは非常に難しいです。

そのため実際にスケジュールの遅延がありそうな時は、スケジュールの計画を関係者で共有し、現行のメンバーで問題無い品質を達成するまで開発し続けるのが、おそらく最も合理的です。

予定通りに完了できなかった時にどうするか

次回の見積もり時に今回の反省点を活かした見積もりをするのは当然として、開発者はどうすれば早く開発できるかを常に考えていかなければなりません。自分の実力が 100 として、今回の開発は 99 しか出せてなかったのではないか? を自問自答してみて、 99 だったかも…ではだめです。 100 出せなかった原因を取り除き、次回は 100 を出してください。

最後に

開発課題の「完了」とは、「もう作業をしなくていい状態」であり「開発成果が業務課題の改善に対して効果を発生できる状態」です。