Techいつもコードのことばかり考えている人のために。2018-03-31「ベタープログラマ」を読んだ原著が出てたときから割と気になっていた「ベタープログラマ」を読んだ。第I部はコードスタイルや、不要なコードの存在、テストコードを書く話など、非常に実践的な内容が多かった。第II部は割と考え方というか、思想的な話になっていって、第I部をきちんと読んで危機感を持って行動を変えられる人であれば自然とそこに到達するのでは?と思った。第I部をしっかり読んで、自分の置かれた環境との差異や、これから行動することを書き出す、みたいな読み方をすると良い。第III部以降は、もう完全に生き方というか、エンジニアとしての振るまいや、哲学の話になってくるので、一気に通読する、というより少し間を置いて拾い読みしながら読み進めて行くと良いかも。流し読みしても全然役に立たないタイプの内容なので、読書メモは必ず書いた方がいいと思うし、書かれていることが万人にとって正解、といった類いのものでもないので、その辺はあまり感化されすぎず、「考えるきっかけ」くらいに捉えた方がいい。第I部「you.write(code)」について冒頭にも書いた通り、第I部は実践的な内容が多い。中でも冒頭の4つの章はお勧め。コードベースの過去の幽霊2章はコードスタイルの話、ここは1つ1つについて根拠が示されているので、分かりやすい。コードスタイルが趣味の話ではなく、コミュニケーションの話であることが明示されていて良い。コードは書く以上に読むもの。最近はどの言語でもフォーマッタが用意されているので、とにかくフォーマッタを通して一貫性を保つことが良いプラクティスとして広まっているので、どんどん使っていきましょう。個人個人で悩むところではないですね。3章と、4章はなかなか自然とその考えに至るのは難しい内容、特に3章は分かりづらい、冗長なコードを書いてしまう話なのだけど、実際のコードでは単独のコードだけを見ても分かりづらい話だし、たいていは将来の機能追加に向けた保守性の低下という観点なので、なかなか本質的に理解するのが難しいところ。本の中で言及されているコード例は、かなり分かりやすい事例なので、実際のコードを書くときに、果たしてどこまで意識できるか?というのは難しいかもしれない。誰も分かりづらく、余計なコードを書こうと思って書く訳では無いので、そこには必ず認知の差が有るわけで、その差をどうやって埋めるか?という話までは当然書かれていないので、そこから先はもう教育の話となってくる。これは悪いコード例と、良いコード例を比較し続けるしかないし、ひょっとしたらIDEがもっと賢くなって等価でもっとシンプルなコードにリファクタリングしてくれる方に期待した方がいいのかもしれない。4章はコードを削除する話。ソフトウェアの機能追加は新しい価値を提供するために行われるため、既存の機能を消すということはなかなか無いけど、それはコードの保守性を低下させ、迅速な機能のリリースを妨げる存在であるため、削除した方が良いということが書かれてる。5章はイデオムについて触れられている。どんな言語やフレームワークでもイデオムは有って、それを身につけないと「らしくない」書き方となってしまい、保守性を低下させる。おわりに誰だって悪いコードをわざわざ書きたい人はいなくて、そこには認知の差異や、組織としての方針(投資の優先順位)が有るだけなので、この本に書かれているような悪い事例が目の前に有ったからといって、一方的に批判するのは良くないし、なぜそんな状況が(無知以外の理由で)存在するのか?と考えることが大事なんじゃなかと思いました。いえ、2章から5章あたりは「言われないと分からない」レベルの話ばかりなので、まずはこの辺をしっかり読むことをお勧めします。後半はどんどん抽象的な話になってきますが、考えるきっかけとしては良い本だと思います。Programmer」を考えると、割とそうね、という感じでした。Classi」というイベントで、「設計...2018-10-06Scalafmtのコメントスタイルについて調べたこんな事を教えていただきました。DevOpsを読んだ買ったはいいけど、なかなか読む時間が取れなかった「Effective...2017-11-12「テスト駆動開発」を購入し、Scalaで写経を始めた最近話題の「テスト駆動開発」を購入した。Type-Sを買った月別アーカイブはてなブログをはじめよう!magnoliakさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。