こんにちは、もっちーです。
今回は「プログラマー脳」を読んだ感想を書いていきます。
それでは見ていきましょう！
記憶は互いに関連づけられた状態で保存される（p47）
脳の中に保存されている情報は階層構造になっています。
たとえばコードのフォルダ構造で考えると、以下のようなイメージです（MVCフレームワークの構造）
- src
- Model
- View
- Controller
- config（設定系）
- webrooot（公開ファイル）
全体の構造をぱっと見ただけでも、何が入ってるフォルダか理解しやすいですよね。
それぞれのフォルダに各機能のファイルが入っていて、必要に応じて階層をたどりながら情報を取り出しています。
また、プログラマー脳に書かれていた分かりやすい説明に
リスト内包表記を覚えようとするときに、forループの方法を知っていることが助けになる
という例えがありました。
このように覚えたいことを単体で頭に入れるのではなくて、何かしら関係ある別のことに結びつけるのが大切だということが分かりました。
これはプログラミングに限らず、日常生活で何かを思い出すときにも役立ちそうだと感じました。
長い時間をかけて勉強したほうが記憶に残りやすい（p49〜）
下のようなグラフを見たことがある人は多いのではないでしょうか？
これは「エビングハウスの忘却曲線」と言われていて、いったん覚えた内容は時間が経てば経つほど忘れてしまう…という意味のグラフです。
もし1週間でがっつり勉強したとしても、1日後には30%くらいしか記憶に残ってないんです…
つまり短期間で一気に勉強するのは、効率的な方法ではないわけですね。
また、人間の脳は「思い出そうとすることで記憶が定着する」という性質があります。
たとえば
配列を分割する関数ってなんだっけ…？
思い出した！array_chunkだ！
このような感じで、頭のどこかに入ってる記憶を思い出そうとすることにより、どんどん記憶が強くなっていきます。
プログラミングをする上で活用できそうなことでは、上記の例のように
ネットで調べる前にまずは自分の記憶から取り出そうとしてみる
ことが大切だと思います。
インターネットの普及で気軽に調べられるようになった今、このような自分の頭を使う機会が減っているのではないでしょうか？
つまり、短期間で集中して一気に覚えようとするのではなく、少しずつ長い時間をかけて記憶を思い出しながら勉強するのが効率的というわけです。
もっちーいわゆる徹夜はNGですね・・笑
どのような状態が「読みやすいかどうか」は読む人によって変わってくる（p67〜）
プログラムの書き方に関するコツは多くありますが、どれが正解でどれが不正解という決まりはないと思います。
コードを読む人の予備知識やレベル感で変わってくるので、読む人の立場になって考えることが大切です。
分かりやすい例を２つ書いておきます。
- 三項演算子
- リスト内包表記
どちらも使いこなせれば便利な文法ですか、人によっては理解しにくいコードになってしまう可能性があります。
それぞれ見ていきましょう。
三項演算子
これはどの言語でも使われることが多いと思います。
if〜elseで書いていたコードを1文にまとめられるので、可読性もよくなり使いやすい文法だと思います。
$max = ($a > $b) ? $a : $b; ただ、条件のところが複雑だったり長すぎると、コードの横幅が長くなってしまうデメリットも…
そのプロジェクトに慣れている人であれば、条件のコートが長くても問題ないかもしれません（過去の経験から何がやりたいか理解できるので）
でも初めてプロジェクトに参加する人には、コード全体の仕組みを理解する上での障壁になる可能性があります。
ただ、業務委託などでエンジニアの入れ替わりが激しいプロジェクトでは、新しく入ってきた人にもコードの意味が伝わるように、あえてif文で書くという方法も良いと思います。
リスト内包表記
いわゆるループ処理を1行にまとめられる文法。
squares = [i ** 2 for i in range(10)]自分も初めてPythonでデータ分析をしたときは、リスト内包の書き方を理解するのに時間がかかりました。
これも三項演算子と同じで、条件のループ処理が複雑になればなるほど、慣れてない人には読みにくいコードになってしまうというデメリットがあります。
シンプルな条件（１つのカラムに対する比較など）であればリスト内包表記の方が良いですが、少しでも複雑になりそうな条件のときはif文を使う方が良いでしょう。
ちなみに個人的な意見としては、三項演算子やリスト内包表記はあまり好きではありません（笑）
コードが長くなってしまうのを妥協してif文で条件分岐を書いて、その上で必要な粒度に共通化（メソッド化したりファイルを分けたり）するのが、自分の好きなやり方です。
もっちーみなさんの意見も教えてください！
理解できたコードにはチェックを、わからないコードには疑問符をつける（p101〜）
これは開発で使えそうなアイデアだったので、自分用のメモとして残しておこうと思います。
このように自分の理解度を監視することで、2回目にコードを読む時に、分からないコードだけに注目して理解を深めることができる
プログラマー脳より引用
自分の会社はエンジニアの人数が少ないので、1人で担当するプロジェクトが多いんですよね。
その中でも規模が大きくコードが複雑なプロジェクトの場合、隅から隅までコードを理解するのが難しい状態です…
そんな時に「理解できたコードと分からないコードに印をつけておく」という方法が使えそうだと思いました。
いずれすべてのコードに理解できたマークがつけばOKってことですね。
プログラミングに限らず別の仕事においても
やることが多くて混乱する〜
って感じる人に向いてるのではないでしょうか？
理解できたこと・分からないことをしっかり区別することで、何が分からないが分からない、とにかく不安でモヤモヤする、といった悩みを減らせるはずです。
慣れている問題に直面したときは、解決するというより過去の再現をしているだけ（p195〜）
エンジニアとして経験を積んでいくと、これまでは苦戦していたことでも簡単に解決できるようになったりします。
これは成長しているような感覚だと思いますが、実際には「思考停止で過去にあったことを再現しているだけ」とプログラマー脳では解説されていました。
新しい解決策を発見するのではなく、以前に同じような問題でうまくいった解決策を使っている
プログラマー脳より引用
なぜそれをすべきかよく分からないまま、何をすれば良いのかだけ分かる
つまり思考停止で過去の解決策を繰り返しているだけで・・といった意味になります。
エンジニアとして成長するためには、ただ過去と同じことを試すのではなく、その場その場でベストプラクティスになる解決策を考えることが必要だと思います。
このように新しい方法を考えることを繰り返すことで、さまざまなケースに対応できる技術が身につくはずです。
すべての記憶は抽象的なクラスのインスタンスであると考えられる（p201〜）
最後に良い表現だと感じたことを共有しようと思います。
方程式を解いたり文字を読んだりといったタスクを実行すると、新しい記憶が形成される。
プログラマー脳より引用
そのタスクに関する記憶をクラスに見立てると、そのインスタンスであるといえる。
これまでの経験をひとつずつクラスとして頭の中に入れておいて、必要なときに取り出す（プログラミングで例えるとnewする）という考え方です。
もう少し範囲を広げてみると、経験自体はメソッドになっていて、それを内容ごとに分類したクラスがある感じでしょうか。
すべての記憶は「より抽象的なクラスのインスタンスである」と考えることができる
プログラマー脳より引用
最後に
いかがだったでしょうか？
エンジニアとして働いているときの脳の仕組みがよく理解できました。
これからも仕事を頑張って強いエンジニアを目指していきます！！
最後に・・最近読んだエンジニア向けの本では、マイクロソフト牛尾剛さんの「世界一流エンジニアの思考法」も面白かったです。
感想を記事にまとめているので、興味のある人はぜひ読んでみてください。
