233
217

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

新人エンジニアAdvent Calendar 2016

Day 12

新人エンジニアこそちゃんと調べてちゃんと知りちゃんと考える

Last updated at Posted at 2016-12-12

本稿について

本稿は、

  1. 学生時代にHTML,PHP,Javaくらいなら触った事あるかな程度の配属4ヶ月目の新人である自分が、
  2. ほぼ初めてJavaScriptや、色んなフレームワークに触れ技術の荒波に揉まれながら、
  3. ちゃんと調べてちゃんと知りちゃんと考える事が大事だなーとぼんやりと思ったこと

を書き記すものです。

出来るだけ上流のソースを読む

分からない事に出会った時

分からない事に出会った時、まずググりますよね。
そこでまず目に留まるのは**「非公式かつ目的の用途に限定された」**ものです。
しかも日本語だから読みやすい!やったぜ!

ぐぐる

先人達の知恵と努力の結晶はありがたく活用させて頂きたい所存です。
細かいことは考えず解決!しかし…

鵜呑み型ケーススタディの問題点

  1. その解答例が自分の環境で上手く動作するのか
  2. 似たようなケースに流用出来るのか
  3. その解答例の内側ではどういったやり取りが行われているのか説明出来るのか

ただ調べてちょっと変形させたらコピーして解決!しているだけではこの3つの問題に直面し…

「調べる⇒使う⇒調べる⇒使う⇒…」の無限ループ

しばらくして、
調べて出てきた事を使っているだけでは、いつまでたっても応用することが出来ない事に気付きました。
**「(同じような事を)調べる⇒使う⇒調べる…」**の無限ループに陥ってしまいます。
これでは「業務の効率が悪く」なっていく一方で…(申し訳程度のテーマ意識)

まずは公式を読む!

自分は「使えたら良いや」でコーディングをしていたせいで、無限ループに陥っていました。
今日も分からない事を先輩に聞きに行きます…

ぼく:「こうこうこういう事が分かんなくて…調べても上手く行かないんですよ」
先輩:「君、ちゃんと調べたの?」
ぼく:「はい、このサイトとこのサイトと…」

キャプチャ.PNG

先輩:「いやそうじゃなくてさぁ…この1番上に出てるサイトなんで見てないの?」
ぼく:「えっ…

  1. 公式サイトってなんか使いづらそうだし
  2. 知りたい事がピンポイントで書かれているわけでもなさそうだし
  3. 英語ばっかりのもあるし
  4. 文章長いし

    見てないです…」

これが大きな間違いでした。

実際に公式サイトを開いてみると、はじめはその情報量の多さに辟易するも、欲しい情報はちゃんと書いてあるし(当たり前)、中でどういった処理が行われているから分かるようになるので、似たようなケースに応用出来るようになりました。
「ケース専用のコーディングから自分が出来るコーディングへ」
となったわけですね…

何もかも分からなかったらまずは公式、分かってきたら有志の記事で学ぶのが良いみたいです。

英語というだけで拒否反応

はじめは公式サイトの読み方が全く分からず、時間をかけてばっかりでした。
特に英語のサイト!英語というだけで初心者は拒否反応が出てしまうものです。

そこでめんどくさがりの僕は、英語を勉強するのを諦めました。(これが業務効率化だ!)

英語の技術系サイトはプログラミングの知識と翻訳機で読める

  1. 英語とはいうが日常的に使っているプログラミング言語が沢山書いてある
  2. その他分からない事は翻訳機を使えばほぼ完璧に翻訳出来る

ということで、Chrome拡張機能の翻訳機に甘えながら読むことにしたのでした。
翻訳機
ヒエログリフ級難易度の文章もこの通り

そう。始めっから英語バリバリ出来るイケてるエンジニアになろうなんて思うほうがお門違いなのです。
自分の程度に合ったレベルまで難易度をロス無く落としていくことが重要なのです…()

よく考えたら英語っていろんな国の人が読むから可能な限り簡単に書かれているのも頷けます。

結構考える時間も必要

なんとなくで動いてしまうのがプログラム

ここまで読んでくださった方は、僕がいかに面倒くさがりなのかが分かって頂けているかと思います。
そんな僕が次に犯した間違いは
「自分で作れたし、動いたし、触った感じバグも無さそうだから完成!」

このコードが説明できない

ぼく:「いや~めっちゃテストしましたよ。完璧なコードです。どうぞ。」
先輩:「これとこれなんだけど。なんで同じような実装が二箇所あるのよ」
ぼく:「そういえば…。気付きませんでした」
先輩:「なんでこうしたの?共通のコードに出来るよね?」
ぼく:「うーん…(適当だとは口が裂けても言えない)」

こういうことに限らず、変数一つにしても変数名から始まり、スコープ、宣言の型等、説明できなきゃいけない事はいくらでもあるんですよね。

考える時間を取らなければ、考える時間は短くならない

説明するためには、考えた結果が必要です。でも考えるには時間が必要です。

「今日のこのタスク、昼までに終わらせるって言っちゃったしなぁ…」
「知らない分野だから何を考えたらいいのか分からないぞ…」
「見た目は出来てるんだし、なんかめんどくさいし」

こういう気持ちから、自然と形として体を成した成果物を出す事だけに力を注いでしまうことがよくありました。
でも、それで良い訳がないのです。適当にやったしっぺ返しは必ず来ます。

最初のうちは業務に影響が出そうなくらい考える時間を取っても良いんだと思います。(実際に出たら問題ですけど)
必要なコスト(時間)はしっかり払っておかないとですね。

新しく学んだ事は、初めに「何故」「どうやって」を考え、調べる習慣を付けることで、
手癖になり、その手癖はどんどん早くなっていく
ということです。

まとめ

技術的な効率化は他の方が書いてくださっているので、
本稿では自分が学んだマインド的な部分を書いてみたつもりです。
エンジニアとして、が記事の途中からプログラマとして、になっていたような気がしないでもないような…

いつかは技術的な事も書けるようになりたいなー
ご高覧ありがとうございました。

233
217
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
233
217

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?