7月20日
早く魔法使いになりた~い!ども!魔法使いになりたい文系の濱口幹久です!
一週間ぶりの投稿ですが、進捗はあまり芳しくないです(笑)というのも、なんとcode studioがコース3で終わらず、コース4が存在していたことですね(笑)
そして今回はなんとウィンガーディアムレビオサーを学びました(作品作ったよ)
なので今現在進行形でコース4を奮闘しています。
では今回も目次を書いていきます
まず初めに語らせてください。
ビビりましたね。それまでも、whileだったり、繰り返しのvar countなどでもすごい!!って思っていたところに関数に出会ったときは感動を覚えましたね!というか、関数の意味を初めて知りました。テンプレ化されたソースコードのことを言うんですね。もっと早い段階で知っておきたかったですね(笑)
ブロックチェーンでもハッシュ関数という関数があったものの、関数が何なのかはさっぱり知らずに覚えてたので、計算式で理解していました。
この関数をしってから、点と点がつながりましたね。プログラミングは、共通点を抽出し、パターン化することが大事って勉強しましたが、まさに腑に落ちましたね!なるほどな!と。このパターン化がいわゆる関数のことであり、これを広く使えるように設計することで大幅な効率化を図ることができる。業務の効率化とやり口全く一緒ですね。暗記するときも、共通点を洗い出して、共通点をしっかり暗記し違うところを別途覚える。
これを意識しながら練習できるのは非常に素晴らしいことですね!!プログラミング的な考え方と揶揄されますが、プログラミング学習を一言で説明するなら「方法論」を学ぶと説明します。これ意識的に身に付けれるのであれば、めちゃくちゃ役に立ちますね!応用範囲がめちゃくちゃ広いですから。そしてめんどくさがりやな自分にとっては天啓ですね。
なので今後プログラミング学習で重視していきたいのは、すでにある関数の理解と使い方、関数の作り方、これに重点をおいて学んでいきたいです。
いわゆる、「巨人の肩にのってしまおう」作戦ですね(笑)
いまではnoコードなんていう言葉も存在するくらいですから、そういう学習方針でいきます。
ホグワーツにはいって二週間程度で、ようやくウィンガーディアムレビオサー、初めて魔法を使いました。
ただ作品を作っただけなのですが、これがまぁ大変でしたね!!1時間から2時間かかりましたね。
関数を知った直後なので、パターン化されたものを作りたいと思ったんですけど、絵心がないので何するか正直迷いました。
そこで思いついたのがへのへのもへじでした。ぶっちゃけいうと、プログラミングには全く向かない代物でした。作ってみて一番苦労したのが、微調整ですね。関数を作るのは簡単でした。こんなにも微調整が大変で地道な作業なのかと驚きましたが、できたときの達成感は半端ではなかったです!!本当に感動しましたね。
これは子供どハマりしますよ。子供の時にやりたかったな~
作品を作って感じたのが、闇雲にソースコードを書き始めるのは非常に非効率的であると感じました。プログラミング入門の本にも書いてありましたが、ソースコードを書く時間よりも、解決策や、工程を考える時間が多いと学習しましたが、まさにその通り。何を作るか決まってない状態、つまり曖昧の状態では一切ソースコードに手を付けられません。しかも、準備が甘いと、手直しの回数が爆上がりします。実際、一番苦労したのは関数を作成していない「じ」が一番苦労しました。
今思えば、あれも先に小さく「じ」を作っておいて、そのあと拡大させる処理をすればよかったです(;´・ω・)
へのへのもへじを作ると決めた後の自分の思考回路は以下の通りです
紙とペンを使って大まかな図面を作成➡現在のキャンパスの大きさを測定(横200ピクセル➡その後共通点の抽出➡「へ」「の」「も」の関数をつくり、あとで組み立てる➡「へ」と「の」を使った目に当たる部分の関数を作成➡実際に組み立て、微調整を施し、「じ」を作成 ここ改善点
これが自分の思考回路でしたね。意識したことはクラウドソーシング、いわば指示ができるレベルで行うことを意識しました。今回であれば、「へ」と「の」と「も」の関数は同時並行で作成することが可能ですし、組み立ても別の人ができる。こうした工程の可視化と調整を行うのが、自分が今後身につけねばならないスキルだからです。さらにいうとボトルネックを見つけるために、評価基準などを作ることですね。
これができると、アイデアを一人で実現するのではなく、ソースコードを書くのが得意な人にお願いができますし、思考を共有しやすく良い協力関係を築くことができます。そして、一人で作業する分にも、効率化が図られ、パフォーマンスが高くなります。準備をいかに早く精密に行うかが、良いプログラミングの鍵だと感じました。
そしてプログラミングにおける効率化とは何か?今回分かったのは、トライ&エラーの回数を減らすことですね。当たり前なんですけど、やり直しを減らしたほうが効率的です。
なので、事前の顧客とのヒアリングと、エンジニアさんとのヒアリングは迅速かつ共有可能かつ分かりやすいかつ徹底すべきである。トライ&エラーが多いと時間かかってしょうがないですね。微調整が一番めんどくさかったです。
今はブロック調なので理解しやすいですが、ソースコードになると視認性がくっそ悪くなります。なので今のうちに、ここまではこいういう動き方をするっていうイメージ、名前をつけながらやっていくべきやと感じたね。やから、フレームワークも学ぶ必要があるね。
まとめ、入念に準備を行いトライ&エラーの回数を減らす。そのためには➡工程を細分化し、イメージ、もしくは名前をつけて分かりやすいようにする。
今後➡従来通り、入念に準備を行い、図面化と工程の細分化を意識する。
知識は集約と展開をイメージ
会計士試験で勉強した管理会計の知識も活かせるかもしれん
まだまだ道のりは長いですが、着実に成長している!!早くボードゲーム作りたい!!
進捗