技術書の読むタイミング
リーダブルコードは以前にも読んだがまったく覚えていなかった。
今回読んでいて、凄く身に染み込んでいる感じがある。
本に書かれていた方法で実際にコードを書き直してみたら、今までになくスラスラと読みやすいコードに書き直す事が出来た。(まだ人に見せてないけど。)
技術書読んでて苦しい(書かれている事が難しくて、理解に凄く時間がかかったりする時)っていうのは、まだ自分がその域に達していない場合なのかもな、と思った。
無理に読み込んでも時間がもったいない。
こういう本があった事だけ気に止めて、自分が理解できる所から進んでいけばいいと思った。
リーダブルコードを買った。
以前会社で借りて読んだが、全く内容を思い出せなかったので再度購入した。
しっかりと記憶に残すため「リファクタリング・ウェットウェア」で読んだ方法で再読しようと思った。
まず、なにを学ぶかを目次から洗い出す。
読んだあとに、何を学んだかをまとめる。
技術書はどんな感じか借りて読むのはいいが、
やはり手元においておかねばならないと思った。
プログラミングの設計のわかりやすさ
プログラミング設計のわかりやすさについてずっと悩んでいる。
昨日、会社の先輩プログラマからこんな事を言われた。
「パッと思いつくイメージの形のまま実装されているのが一番わかりやすい。」
当たり前やんと思うが意外に出来ていない。
プログラム設計をする時、まずベースの設計を考える。
そこに色々条件が加わってくる。
その条件にどう対応するかを考えるが、少しベースの設計を崩して対応したりする。
そんな事が繰り返されるうちに、もはやベースの設計が見えない状態になってしまっている事が多かったと思った。
最初に考えたベースの設計をもっと意識して設計を行おう。