プログラミング教育が学校教育でも始まるということや、人手不足だからスキルを身につけると稼げるとか、未経験から数ヶ月でエンジニアにとか、プログラミングが話題になってますね。
学習していた記録を思い出しながら早めに知りたかったことや詰まった点を思い出していく。
何をやってきたのか
25歳の時に転職したかったのでそこから本格的に始めて、趣味ではWebのフロントエンド/バックエンドを書いて、仕事ではVBAやフレームワークのプラグインを書いたりしてます。それ以外だと中学生の時にHTMLとCSSで使って個人サイトを作っていました。
本格的にやり始めてから最近までの履歴はこんな感じです。
- 転職のためにプログラミングスクールでJavaでECサイト作成
- RailsのためにRubyを学習してWebフレームワークでMVCやHerokuを使ったデプロイを学ぶ
- フロントエンドの開発に興味が出てVue.jsを学ぶ
- Reactを書き始めてComponent志向や状態管理の必要性を学ぶ
初めての言語のJava(半年ぐらい)
無料のプログラミングスクール(実質は自習会みたいな感じ)に入って言語選択するとき、求人が多かったから、という理由でとりあえずJavaを学ぶ。
詰まった点は
- 引数と戻り値を使うタイミング(関心の分離)
- 同一クラス内の関数と別クラスの関数(スコープと呼び出しと設計面)
- 環境構築(Javaが悪い)
- 自分が詰まっている場所の言語化とググった結果の取捨選択
- MySQLとJavaをライブラリでつなぎこみ
引数と戻り値は分かったけど、「繰り返し動作をまとめる」だけでなく「関心を分離させて可読性を上げる」という観点まで飲み込むのに時間がかかった。
スクールの方針が「フレームワークを使うと手抜きに見られたり、技術力がないと思われる」という方針のため2017年にJSPとServletというレガシーなものを使っていたせいで情報が少なすぎて厳しかった。
今でもJavaはプログラミング初心者が扱うにはハードルが高すぎると思っていて「とにかく動く」「ライブラリを使ってみる」というのがやり辛いのでAndroidアプリを作るとかじゃない限りは開発コスパが悪いと思う。
NullPointerExceptionはガッで直らないことも学んだ。
Web開発のためのRuby(1年程度)
昔はTwitterもRailsで作られていたと聞いてRuby on RailsをRubyの学習と並行して学ぶ。
このあたりから「どのOSでもインストールせずに動作するWebアプリって開発コスパ高いな」ってことでWebアプリ開発を中心に学んでTodoアプリとか筋トレ記録アプリとか作って壊してました。
rails new my-app
コマンドを打ったらドカッとファイルが作られてrails s
と打ったら一気にブラウザで動くWebアプリが動作してすっげー!ってなった思い出がある。
詰まった点は
- Railsの問題なのかRubyの問題なのか(並行して学習したため、どっちの問題か分からなかった)
- データベースの正規化が分からず、RDBMSに配列や重複する値を突っ込む
- 開発環境と本番環境の違い(データベースや画像のアップロード用ストレージ)
- ライブラリ1つ追加しただけで大混乱
少し前に「今どきのスクールはRailsは教えるけどRubyを教えないから使い物にならないエンジニアが量産される」というのが言われていたけど、初心者がいきなりRailsを学ぶと魔法みたいに見えてしまうのでその中間を想像したり、MVCの責務を意識するのは難しいと思います。
Railsも大量のライブラリや自作クラス・メソッドの積み重ねで作られているので、自分の手で単品のライブラリでHTTPリクエストをしてみるとか、画像処理とか、そういうのをやればよかったと思う。
フロントエンドのためのJavaScriptとNode.js(1年ぐらい)
このあたりでだいぶこなれて来て、GitHubのライブラリの説明を見ながらライブラリを組み合わせてミニツールを作るぐらいはできてきた。
プログラムも「Node.jsで書いたコードは、Node.jsをインストールした実行環境で解釈され、OSのコアな部分を利用しながら動作していく」という意識するようになった。
詰まった点は
- フロントエンドとバックエンドで分ける意義の理解
- Railsで凝り固まった偏見の脱却
- ブラウザ実行するJavaScriptとNode.jsで実行されるJavaScriptの違い
- Callback
- ES6以降のJavaScript(スプレッド演算子やasync/await)
Railsの密結合のアーキテクチャに慣れていたので、バックエンドをJSON形式のAPIサーバー化させてフロントエンドでAPIを叩いて整形する、というのは手間だと思ったけど、Webアプリで始めたサービスをスマホアプリでも展開する場合はそういうアーキテクチャだと便利だろうなというのは企業の採用例を見ながら理解した。
ES6以降のJavaScriptで追加された構文が糖衣構文と聞いてもピンとこないのでひたすらNode.jsのREPLで実行しながら理解した。
早めに知りたかったこと
楽しみながら自分のペースで進めること
「未経験から数ヶ月で転職」という投稿と自分を比較して成長速度の遅さに嫌気がさしてしまった時がありました。 理解力の早さは個人差が強いので、相対的な早さよりも、自分が理解した事柄を意識した方がいいです。
一気に複数の新しいことをやらない=新しいことは小さく始める
新しい概念やライブラリを理解するときは、出来るだけ他の依存がない、シンプルな環境で挙動を確認してみます。 俗に言う素振りです。使い方を覚えたら出来る範囲でいじり倒して、徐々に習得したい実装に近づけていきます。
Typoは機械的なツールで減らす
人間は間違える生き物なので、機械的なツールに依存できる場合はそれに頼ります。そうすることで余計な仕事を減らして本質的な部分に集中できます。
単純なスペルミスはCheckerを、コード整形や構文エラーはPrettierやESLintを頼ります。
サンプルコードをいきなり写生せずコピペして確認
コードを書く練習には写生がいいと聞いたときはググって出てきたサンプルコードをひたすら写生しましたが、殆どがtypo探しになってたのでやめました。 なので先にサンプルコードをコピペしてそのコード自体が動く事を確認して、徐々に挙動を変えて確認しながら働きを理解します。
飽きたり詰まったら、別の言語やツールをやってから戻る
学習した時は分からなくても別の概念やツールを学習したうえで再び取り組むとすんなり理解できる事があります。 ActiveRecordはどうやってデータを取り扱っているのか分からなかったのですが、MySQLを学んでから読むと「こんな感じのSQL文を実行してそう」という勘所が身に付いてきます。
まとめ
プログラミングで詰まった点を自分で解決できない時点でプログラミングに向いていないのでは、というのはある意味真だとは思うのですが、習得する順序が間違っていたり、問題の言語化能力がまだ身についていないだけの可能性もあり、安易に「向いてない」と断ずるのは判断が早いと思っています。
また「作りたい物が無いとモチベーションを維持しづらいのでプログラミングは上達しない」というのもよく言われますが、別にオリジナルでは無くて既存の物の劣化コピーでもいいですし、サンプルコードを別の書き方を考えるのでもいいと思います。 「測量のために計算する」のが好きなタイプもいれば、単純に「数式を解く事自体」が好きなタイプもいると思うので。