私はこの2年仕事で、幅広く言語、フレームワーク、プラットフォームを使って開発してきました。そしてその大半が初めて触るものでした。*は開発を始めるときに初めて使ったものです。
- Kotlin*でAndroidアプリ開発
- Python* + Django*でサーバーサイド開発
- C++*でUE4*のプラグイン開発
- C#*でUnity*アプリ開発
開発はいつも3、４ヶ月ほどの納期のものが多いので、開発をしながら学習を進めて製品化することが必要になってきます。
そうすると必然的に、新技術の最速学習法に書かれた最速の学習方法になります。
中でも4. 分からない事はひたすらググるが、最も大事かつ難しい部分です。この記事では、新しい言語、フレームワーク、プラットフォームを使うときに、より効率よく、より良い情報を収集する術を紹介します。
情報収集は、かならずこの３つを意識します。
- 公式ドキュメントをみつける
- ちゃんと設計がされたコードをみつける
- ２つ以上の回答をみつける
公式ドキュメントをみつける
とにかくまずは公式ドキュメントをブラウザのタブに常駐させます。そして悩んだらまずは公式ドキュメントから情報を集めます。Stackoverflowで回答を見つけたら公式ドキュメントで関連する項目を探し、その回答の用法は正しいか、各処理や変数、引数の意味を必ずチェックします。
ワケワカランままStackoverflowの回答をコピペするのは強く禁止しましょう。コピペする前に必ず公式ドキュメントで用法用量を確認するのです。
ちゃんと設計されたコードをみつける
公式ドキュメントの次に大事なのがこれです。最高の教則本になります。最初のディレクトリ構造が決まらない？どこにどのような責務を持たせるか悩む？より良い書き方が知りたい？全部コードを読みましょう。つらつら書かれた文章を読むより、しっかり作り込まれたコードを読むほうが10倍理解が進みます。
例えば、KotlinでAndroid開発ならDroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo、Unity開発ならグローバルゲームジャムでクラス設計をやった話2020 - Qiitaといった具合です。
ここで注意しなければならないのは、公式ドキュメントのサンプルコードはちゃんと設計されたという要件を満たさないことが多いということです。公式ドキュメントのサンプルコードはひとつの製品として設計されていることが稀なので、あまり当てにしないでおきましょう。
コードは手元にクローンして、横に並べて開発しながら逐一参照できる状態にしておくのが良いです。
2つ以上の回答をみつける
最後に、公式ドキュメントでもちゃんと設計されたコードでも悩みポイントの回答が得られないときは、ひたすらググります。StackoverflowやQiita、Zenで回答が得られるでしょう。ただし、悩みポイントの回答は2つ以上見つけましょう。特に日付が新しいものを２つが望ましいです。
日付が古いものは、今となっては良くない解決方法の可能性があります。また、たったひとつの見つけた回答も良い解決方法とは限りません。比較的新しい日付で同じ回答が多いほど、良い解決策の可能性が上がります。
違う回答が複数見つかる場合は、それぞれの回答の違いを掘り下げ、理解し、どれが最適かを見極めましょう。
決してたったひとつだけ見つけた解決方法を、訳のわからないまま使うのはやめましょう。
Discussion