こんにちは@fukufukumarimoです。
これはPerl入学式Advent Calenderの21日目です。
perl入学式校長と同じ会社にてエンジニアとしてのインターンをしています。
エンジニアとしてのインターンをし始めたきっかけはとってもささいなことです。
わたしがエンジニアを目指し始めたのもささいなことです。
わたしが初めて勉強する言語をPerlにしたのもささいな流れです。
ささいなことが何回も重なって、勉強し始めた日から半年経った今があるわけですが、
いつも感じるのは
「コードをかけばかくほどわかるようになる、質問をすればするほどわかるようになる」
ということです。
質問の大切さ
インターンを始めた頃、わたしに渡されたのは席とPCとメンターです。
出勤のたびに、席に座り、PCを開いて、Perl入学式の資料を読んでこなしていく日々が続きました。
「わからないことがあればきいていいよ」というメンターがいる、とっても優しい環境に恵まれながらも、
わたしはあまり（エラーが出すぎてどこから手をつければいいのかわからなくなった時以外）質問するほうではありませんでした。
質問をするという習慣がなかったのです。
そもそも質問の仕方がわかりませんでした。
こう書いたら、こう動くはずなのに、そう動いたか、、、なぜだろう？と一人で考えてばかりで、
「あともう少し考えれば、解決できるかも」という気持ちで、
5分が1時間になることもありました。
何が原因か特定の仕方すらわらないので、効率的に調べることもできなく、
ただ単に「できない」と嘆くようになりました。
でも、エラーがでるのは自分の書いたコードのどこかがその原因になっているわけで、
自然発生的にプログラムから不具合をおこしてるわけではないのです。
毎回「書いたプログラム通りにしか動かないんだよ」と教えられていました。
そうして、何時間も自分で考えてもわからなかったことが、質問をすると、
たったの何分かで解決し、わかるようになりました。
自分で考えることも大切だし、自力で解決するところまで持っていくことも大切だけど、
知ってしまえば一発で解決するようなことで
時間を永遠と消費するのは良くないことに気づきました。
コードレビューの大切さ
わたしの悪い癖のひとつが、わからない部分があっても、他のコードの例をみてよんで
自分の（間違った）仮説の中でわかったフリになっているだけというのがありました。
質問したり、資料について直接口に出して話したりすることがなく、
多くのことを読み間違えているのに気づかないまま、最終課題まで来てしまいました。
最終課題は、（たぶん世の中で一番簡単な）簡易的なTwitterでした。
コードレビューで「ここをhashで処理してみて」といわれても、
hash自体や、なんでここはhashにしたほうがよいかも理解できるけど、
データをどう設定して取得して渡していくのか？というデータフローが、
全然頭の中で整理できなかったのです。
ここに来てようやく気付いたのは、わたしの最大の弱点は「データフローの認識の甘さ」でした。
データがどう渡されて、どう展開されればよいのか？というような、全体の流れを読みきれてなかったのです。
コードレビューで「なんでこの処理にしたの？」に対して、話せば話すほど、
いままでなおざりにしていた細かい認識不足、データフロー、構文読み違いに気付きました。
勉強し始めて4,5ヶ月経った頃やっとでした。
振り返ってからの反省点
- わからないと思った時に質問しなかったこと
- 自分の解釈で自分の中で納得してしまったこと
- コードレビューの機会を短いスパンで設けなかったこと
- データフローを直接書き出して確認せずに進めたこと
以上を踏まえてAmon2で簡易Twitterを作り終え、自分で何度かMojoliciousなどを触ってから、
いまは弊社のなかで蔵書管理を目的として作られた「しょこたん」という管理ツールの
機能追加をしながら、チーム単位での開発に取り組んでいます。
いまも試行錯誤の日々ですが、常に心がけていることは
5分考えてわからなかったことは質問する
- 「目的：〜したい！」→「方法：そこためにこれを考えてしてみた！」→「結果：だけどこうなってしまった！」→「対処：なのでこうしてみた！」→相談or質問
- 一連の流れを説明すると◎
新しく実装する時はデータフローを紙に書いてからにする
- 例：追加ボタンをおしたら
POST /addでsub addにパラメータを送り、sessionからall_booksをgetし、パラメータを加えたものをsetし、GET /newでsub newへパラメータを渡す。
- 例：追加ボタンをおしたら
とりあえずコードを書いてみる
- データフローができたらコードを書いてみる
- 「こっちがいいかな？あっちがいいかな？」と迷わずにとりあえずコードを書いてみる
- もしダメな場合も書いてみることでエラーがみれる
- エラーをみることでなんでこの方法ができなかったのかが明確になる
コードレビューの機会を設ける
- 自分のなかでは最善でも他人（読む側）には最善ではないかもしれない
- 他の書き方があるかもしれない（知見の共有）
これを繰り返し続けていくことで、意識的に手を止めずにコードを書いて検証する癖がつきました。
Perl入学式の強さ
またこれらの要素が自然に揃っているのが「Perl入学式」だと思います。
資料があって、その場で質問に答えてくれる人がいて、話す相手がいて、、、
しかもサポーターの方々はとっても理解ある人たちばかりです。
初心者の人がはまりそうなことも、わかってくれていて、
もし自分がはまることがあっても、恥ずかしがることはありません。
どんな質問にも、詳しく答えてくれます。
そもそも質問の仕方がわからなくても、まずそれを聞いちゃいましょう。
開発している時間のなかで、悩む時間やハマる時間があると次につながる！と
いうこともあると思うんですけど、変なループに陥って、
時間と見合わない結果を目の当たりにして、さらにループに陥るより、
さっさと質問して自分の実力をあげていくことができる環境だと思います。
わたしもいま、蔵書管理ツールの追加機能作成に携わっていますが、
コードを書く前から、結果をあれこれ懸念するより、
トライアンドエラーを繰り返してどんどん書く！どんどん質問！を繰り返すようにしています。
（昔よりよくなったつもり。。。w）
どこかで誰かに教える側の人へ
初心者に近い人にプログラミングを教える際は、
絶対に「デバッグの方法」も一緒に教えてください！
この変数にちゃんとデータが渡っているかどうかをみるための方法を
知るだけで、エラーの原因を特定しやすくなり、
初心者特有のコードとにらめっこの時間は少なくなります！
わたしは「デバッ...グ...？」ってなっている期間が長かったので、
知った時にはもっと早く知っておけばなあという印象でした。
あと、すこしずつコード書いたら実行してエラー出ないかどうか確認する、
ということも忘れがちで、大量に書いて大量にエラーということもあるので、
（has too many errors...というエラー文を出したことが多数ある！）
はじめに教えておくとスムーズかなと思います！
さいごに
最初のわたしは
- 質問できない
- 自分の書いたコードも説明できない
- 簡単な構文すら正しく理解できていない
のコード負債三冠王でしたが、いまとなってはこの三冠が弱点だと知ったので、
これからももっと人よりもコードを書いて動かしていきたいです！！！
なにはともあれ、わたしのはじまりはPerl入学式の資料を勉強し始めたことからのスタートです！
いまでも資料を見返す時はいっぱいあります。
ブックマークバーに入ってます。ワンクリックで資料までとべます。
ライブラリよりも実際にどのように使うか書いてあるので使いやすいです。
最初に勉強した資料がPerl入学式の資料で必要な知識を高速に勉強できたのだと思います。
Perl入学式のような手厚い資料と手厚いサポータでの勉強会は
ぐぐっと実力をつけることができる貴重な機会だと思いますので
ぜひ一回参加してみてくださいね！
