魔法使いになりたいプログラミング奮闘記＃１－２

wahukusweet
2020/07/20 14:13

７月２０日

早く魔法使いになりた～い！ども！魔法使いになりたい文系の濱口幹久です！

一週間ぶりの投稿ですが、進捗はあまり芳しくないです（笑）というのも、なんとcode studioがコース３で終わらず、コース４が存在していたことですね（笑）

そして今回はなんとウィンガーディアムレビオサーを学びました（作品作ったよ）

なので今現在進行形でコース４を奮闘しています。

では今回も目次を書いていきます

①すごいぞ関数！！

②へのへのもへじを作りました！

③プログラミングで初めて作品を作って意識したこと、わかったこと

①すごいぞ関数！！

まず初めに語らせてください。

関数めっちゃ便利！！

ビビりましたね。それまでも、whileだったり、繰り返しのvar countなどでもすごい！！って思っていたところに関数に出会ったときは感動を覚えましたね！というか、関数の意味を初めて知りました。テンプレ化されたソースコードのことを言うんですね。もっと早い段階で知っておきたかったですね（笑）

ブロックチェーンでもハッシュ関数という関数があったものの、関数が何なのかはさっぱり知らずに覚えてたので、計算式で理解していました。

この関数をしってから、点と点がつながりましたね。プログラミングは、共通点を抽出し、パターン化することが大事って勉強しましたが、まさに腑に落ちましたね！なるほどな！と。このパターン化がいわゆる関数のことであり、これを広く使えるように設計することで大幅な効率化を図ることができる。業務の効率化とやり口全く一緒ですね。暗記するときも、共通点を洗い出して、共通点をしっかり暗記し違うところを別途覚える。

これを意識しながら練習できるのは非常に素晴らしいことですね！！プログラミング的な考え方と揶揄されますが、プログラミング学習を一言で説明するなら「方法論」を学ぶと説明します。これ意識的に身に付けれるのであれば、めちゃくちゃ役に立ちますね！応用範囲がめちゃくちゃ広いですから。そしてめんどくさがりやな自分にとっては天啓ですね。

なので今後プログラミング学習で重視していきたいのは、すでにある関数の理解と使い方、関数の作り方、これに重点をおいて学んでいきたいです。

いわゆる、「巨人の肩にのってしまおう」作戦ですね（笑）

いまではｎｏコードなんていう言葉も存在するくらいですから、そういう学習方針でいきます。

②へのへのもへじを作りました！！

ホグワーツにはいって二週間程度で、ようやくウィンガーディアムレビオサー、初めて魔法を使いました。

ただ作品を作っただけなのですが、これがまぁ大変でしたね！！１時間から２時間かかりましたね。

関数を知った直後なので、パターン化されたものを作りたいと思ったんですけど、絵心がないので何するか正直迷いました。

そこで思いついたのがへのへのもへじでした。ぶっちゃけいうと、プログラミングには全く向かない代物でした。作ってみて一番苦労したのが、微調整ですね。関数を作るのは簡単でした。こんなにも微調整が大変で地道な作業なのかと驚きましたが、できたときの達成感は半端ではなかったです！！本当に感動しましたね。

これは子供どハマりしますよ。子供の時にやりたかったな～

③プログラミングで初めて作品を作って、意識したこと、わかったこと

作品を作って感じたのが、闇雲にソースコードを書き始めるのは非常に非効率的であると感じました。プログラミング入門の本にも書いてありましたが、ソースコードを書く時間よりも、解決策や、工程を考える時間が多いと学習しましたが、まさにその通り。何を作るか決まってない状態、つまり曖昧の状態では一切ソースコードに手を付けられません。しかも、準備が甘いと、手直しの回数が爆上がりします。実際、一番苦労したのは関数を作成していない「じ」が一番苦労しました。

今思えば、あれも先に小さく「じ」を作っておいて、そのあと拡大させる処理をすればよかったです(;´･ω･)

へのへのもへじを作ると決めた後の自分の思考回路は以下の通りです

アイデア出し➡現状把握➡工程の作成➡共通点の抽出➡関数作成➡組み立て、微調整

紙とペンを使って大まかな図面を作成➡現在のキャンパスの大きさを測定（横２００ピクセル➡その後共通点の抽出➡「へ」「の」「も」の関数をつくり、あとで組み立てる➡「へ」と「の」を使った目に当たる部分の関数を作成➡実際に組み立て、微調整を施し、「じ」を作成　ここ改善点

これが自分の思考回路でしたね。意識したことはクラウドソーシング、いわば指示ができるレベルで行うことを意識しました。今回であれば、「へ」と「の」と「も」の関数は同時並行で作成することが可能ですし、組み立ても別の人ができる。こうした工程の可視化と調整を行うのが、自分が今後身につけねばならないスキルだからです。さらにいうとボトルネックを見つけるために、評価基準などを作ることですね。

これができると、アイデアを一人で実現するのではなく、ソースコードを書くのが得意な人にお願いができますし、思考を共有しやすく良い協力関係を築くことができます。そして、一人で作業する分にも、効率化が図られ、パフォーマンスが高くなります。準備をいかに早く精密に行うかが、良いプログラミングの鍵だと感じました。

そしてプログラミングにおける効率化とは何か？今回分かったのは、トライ＆エラーの回数を減らすことですね。当たり前なんですけど、やり直しを減らしたほうが効率的です。