Errorを読んで、どの部分でエラーが発生しているのかを理解し、適切なワードで検索をできるようになりましょう。 検索したワードでヒット件数が少なかったら、検索する部分が間違っている可能性が高いです。
例えば以下のようなエラーが表示された場合
docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock.
Is the docker daemon running?.
See 'docker run --help'.
英語が得意でない人も、流し見をせずににエラー文を読めば、
Is the docker daemon running? と言われていることから、「dockerのdaemonっていうものが動いていないかもしれない」と考えることができます。
また、このエラー文の場合は
"Cannot connect to the Docker daemon at unix:///var/run/docker.sock" あたりが検索するのには良さそうなキーワードです。
長いエラー文の中からどこを検索したらいいのか、というのはだんだんわかってくるようになりますが、一番最初か最後か、errorというワード後に大事なことを言ってることが多いので、特に注意して読んで見るようにしましょう。
Errorを読んでも理解できなかったり、わからなくなってしまった場合は、どんどん周りに相談しましょう。
ただし、
Step4-1が動かないんです
と言っても質問された人は、どういう状況で・何を理解できていないために動かないのか 把握することは難しいです。
Step4-1で、
~~のコマンドを実行したんですが、以下のエラーが出てしまいます。...エラー文...
このエラーは
**という意味だと思うので、@@で検索して出てきた解決方法XやYをやってみたんですが、解決できないので教えてもらえませんか？
この情報があれば、質問された人は以下の情報を質問から掴むことができます。
- 環境に問題があるのか
- プロジェクトのコードに問題があるのか
- 質問者が勘違いしている部分があるのか
- 質問者にタスクをするために足りない知識が何なのか
また、「こんな簡単なこと、聞いたら恥ずかしいかも...」と思う必要はありません。 15分調べても解決の糸口が見えてこないような場合は、メンバーやメンターさんにヒントをもらうようにしましょう。 まわりのメンバーとコミュニケーションを取りながら問題を解決する力も、エンジニアリング力のひとつです。
公式(英語)を理解できるのがもちろんベストだけど、わからないことを英語の硬い文章から理解するのは難しいですよね。 Qiitaなどの「これで動いた」という記事を最初に見るとしても、概要がわかったら最終的にはオフィシャルドキュメントを参照するようにしましょう。
例: Dockerfileの書き方なら 公式リファレンス や 日本語版リファレンス を参考にする
これができるようになると、開発の流れがこのように変わります。
before
似てるコードをコピーして変えてとりあえず動かす
→ うごかない
→ トライアンドエラー (ここで時間を消耗)
after
まず理解する(ここである程度時間かかる)
→ 理解して書く
「公式ドキュメントを読め」というのはよく言われることですが、基礎知識や周辺知識がないとドキュメントは読んでも理解できません。 例えばDockerを理解するには、Linuxの知識やネットワークの知識が必要になります。 まずはUdemyや本を活用して、こういったコンピューターサイエンス基礎力を高めましょう。
📖 Reference