設計や技術選定に影響を与えている記事・書籍たち
概要
ソフトウェアの設計や技術選定についての僕の考え方や指針に影響を与えている記事や書籍をちょろっと紹介
今でもこの記事や書籍の内容をよく思い出しながらコードを書いている
実際にはこれらの記事や書籍を読む前に, そこで紹介されている概念を自分で発見していることもある
いつの間にか身についていた仕草に実は名前が付いていた! みたいなの, ありますよね
ただそうした場合でも, 記事や書籍を読むと自分の知らない知識が得られることが多いので, 敢えて紹介してる
プログラミング入門編
関数は「重複コードを共通化する」ためだけでなく, 「処理に名前を付けて抽象化する」ためにも利用でき, そちらのほうがより重要であるという話 よく大学では「処理を共有化するために利用する」と説明されるが, 実際に演習などで重複コードに出会うことはなく, 意味を見いだせないまま終わってしまう
この記事では関数を「処理に名前を付け, 抽象化する」ために利用する方法を紹介している
「具象と抽象」の考え方についても丁寧に解説されている
プログラミングしていればその内自然と身につく概念だけど, それがプログラミング初心者にも分かりやすい語り口で説明されている点が最高
関数というものを初めて知ったら是非読んで欲しい記事
分かりやすいコードを書くにはどう書けば良いか, が書かれている
プログラミング入門して暫く経って, 自分の書いたコードが読みづらて困ってきたら絶対に読むべき1冊
書いてあることの多くは当たり前の事のように見えるのだけど, 実際には意外と身に付いていなかったりする
書籍を通してそれをはっきりと理解することが出来る
プログラミング入門以後
関数などの仕様を決める時に「契約による設計」という考え方を用いて事前条件と事後条件を設定することで責務を明確にする話 ユーザに事前条件を守らせる責務を持たせることで, 関数はそれに対する事後条件を守る責務に専念することができる
ところで原典はまだ最初のほうしか読めてないので, 早く全部読みたい 関連資料
無理して汎用的にしすぎない, 無理して抽象化しすぎない, 無理して堅牢にしない, といった考え方が時には重要であるという話
「賢いやり方」や〇〇原則といったものにこだわりすぎないこと。実装の単純さはとてもとても重要で、そのためにはレイヤ分けの一貫性や完全性、コード重複の少なさを、リーズナブルな範囲で犠牲にしてもよい。
ブコメも良いコメントが沢山付いているので読んでみると良いかも
テスト駆動開発 (TDD)と呼ばれる開発手法を紹介する本 落ちるテストとテストが動く最小限の実装を書いて, それからテストが通る実装を書く
小さく始めて, 徐々に作り込んでいく
テストが通るようになったら実装を振り返り, リファクタリングを行う
TODOリストを用いてやるべきことを忘れさせず, 何が終わったかをはっきりさせ, 目の前のことに集中する
この本を読むことでTODOリストの重要性, 小さく始めることの良さ, テストがもたらす心理的安全性, そしてTDDの開発サイクルの利点などを理解できるようになる
関連資料
HDDとは一言でいえば、技術選定という重要なプロセスを他人任せにしてはならないという啓蒙です。
誰かが良いと言っているという理由で技術選定をしてはいけません。
これを読んで以降, 自分の意思で明確な理由を持って依存するライブラリやアーキテクチャを決定するようになった
関連資料
いかにメンテナンス性を維持してAngularアプリケーションを開発していくかという話
Angularの話だけど, ReactやVue.jsなど任意のフレームワーク/ライブラリに当てはまる
これを読んでから, フレームワークのアップデートを阻害しないためにフレームワークに依存しないライブラリを使って, 自分でフレームワークへのアダプタやブリッジを書くよう努力するようになった
まだ読んでないけど気になっている記事・書籍たち
DDD, 概念とかは断片的に知っていて興味を持っている 似たような仕草を自然とやっている自覚はある
Kindle版半額の時に買ったので読みたい
さっき言っていた契約による設計について書かれている書籍
部で購入したやつがあるので読みたい