曲がりなりにもWEBサービスを公開した中で、いわゆるプログラミング言語技術以外で身についたんじゃないかなーということを書きたいと思います。
対象読者
駆け出しエンジニア
インプットが大好きな人
総論
とにかく手を動かさないと身につかない！し、動かしてたら身につくよ。
身についたこと
Gitでのバージョン管理
今まで切った貼ったで適当に上書き保存をしたり、別名で保存したり、気になった箇所を条件反射で修正したりしていましたが、今回意識してGitを使ってみるととても便利、というか気が楽になりました。
GitHub Flowはモチベーションを保つのに良い
導入が簡単そうだったのでGitHub Flowを参考にしました。
GitHubを中心にして管理するわけですが、シンプルで分かりやすいというのと、草が生えるのはモチベーション的にとても助かりました。
タスクごとにブランチを切る
タスクごとにブランチを切ることで今すべきことに集中できました。ブランチ名をタスクに沿った名前にするとターミナル上に表示されて意識しやすく良かったです。
コンフリクトは怖くない
コンフリクトは今までどう対処したらいいのかが分からなくて、コンフリクトが起きる前までとにかく戻ってなかった事にする、みたいなことしかできていなかったんですが、VSCodeを使うととてもわかり易く対処できました。
VSCodeをちゃんと使う
今回Git周りではVSCodeにかなり助けられてます。
VSCodeの組み込みのGit画面も便利で、常に表示しておくとこまめに労なくコミットができました。今までが疲れたらまとめてコミットみたいなひどい状態だったので、幾分かましになったんじゃないかと思います。
使わない(かもしれない)コードを気兼ねなく消せる
新しい実装を思いついた時に今までは古い実装部分をコメントアウトをして残していました。
特に気にしていなかったんですが、コメントアウト部分を思い切って消してしまうとコード上がとてもすっきりし、こんなに散らかったところでコード書いてたんだなぁと、机を掃除したような気分になりました。
Gitをちゃんと使ってると、もし必要になってもまたすぐ戻せるってのは安心できるもんですね。
プログラミングの組み立て方
小さく、簡単なものをまずは動かす。
これはプログラミングの学習においてどこでも言われることかと思いますが、やっとできてきたように思います。
実際のコード上で新しいことを試すのではなく、ダンドboxとして別のファイルを作ってそこで試してみると、原因の究明や仕組みの理解がしやすかったです。
今まではライブラリの設定など、本番と同じ環境にするのが面倒くさかったり理解できてなかったため、本番のソースコード上で新しいこと試してました。そうすると影響の範囲が広くて全然理解できないんですよね。その上進捗も無いので自信も無くなるという悪循環。
テスト駆動的に作る
厳密なテスト駆動とは違うんですが、console.logで希望する返り値を横に書いとくと便利でした。
console.log(tagging()) //"TAKI183"
console.log(tagging(pubkey)) //"CSDM398"
のように実装する前に先に書いとくって感じです。
本当はJest等の自動テストツールを使ってちゃんと作りたかったんですが、これでも割と助かりました。
上から作るか下から作るかみたいな話だと思うんですが、今までは最初からロジックを組み立ててました。
そうじゃなくて、上から、というか関数を作ってとりあえず欲しい返り値をreturnしちゃう。文字列なのか数値なのか、オブジェクトならどんなパラメータがあるのか。consoleで先に出してはっきりさせとくと、返り値の定義もしやすくロジックも作りやすかったです。
技術のこだわりを一旦捨てる
Qiitaはめちゃくちゃ読んでます。だからなのか最新の技術はこれ！どうせやるならこの技術！といった最先端病とても言うような思考に陥っていました。
一番効率的な技術、最先端の環境にばかり興味が言って、技術調査でどんどん時間が溶ける…
最先端病から脱せたのは締切を作ったことと、完成を第一にしたのが良かったんだと思います。
最初はVue CLIを使って単一コンポーネントで作り、ScopedCSSで効率的に！とか思ってたんですが、最終的にはCDN版のVueになりました。
それでも愚直に動くものを作ることを第一にすることで、やっとひとつ完成させる事ができました。
自分で実装してみないと結局わからん
上記とも関連しますが、Qiitaやはてブロ、書籍など、情報はたくさんあふれています。スマホでどこでも情報を読めます。
でもそれでできる気になってしまっていたのがはっきりわかりました。やっぱり自分で動かして、実装してみないとちゃんとは理解できないもんですね。
今回ですと、WebSocketやPromise周りが全然理解できてなかったです。正直今でも怪しいんですが、ちゃんと理解が怪しいと自覚できたのも収穫です。
やってよかったこと
サービスの周辺知識を広く調べる
今回作ったサービスはストリートグラフィティをモチーフにしました。
とにかくコードを書き実装をしたかったので、ストリートグラフィティについては画像を検索し、なんとなくの知識で作り始めました。が、いまいちかっこよくならない。
そんな行き詰まった時に改めてストリートグラフィティの歴史から意味、書き方を調べてみると、今まで実装方法だけでしか考えていなかったものが、血が通ったアイデアが湧いてきました。今考えるとUXデザイン的なことなのかも知れません。
ここ最近プログラミングの事ばかりQiitaやら本やらで調べていたので、全然違う勉強が単純に楽しかったのもあります:)
プログラミングの勉強だけじゃなく、そのサービス自体の知識を直接関係ないかもしれない周りのことまで知ると、実際のサービスにもとても良い影響があると思います。
まとめ
独学で勉強している方、プログラミングの学習方法について不安も多いかと思います。僕も独学でやっているので、本を読み漁り、Qiitaに張り付き、「一番のやり方」をずっと求めてしまっています。
でも「一番のやり方」を探すよりも、手を動かすとホントに意外と身につくってのがここ最近の一番の収穫です。
それこそ、この記事を読んでもプログラミングが速くなるわけでも、ソースコードが綺麗になるわけでもありませんが（笑）この記事を読んで下さった方の、少しでも励みになれば嬉しいです。