あまり勉強会に参加できてないですが、ときどき帰りの電車で聞き流ししています。 www.youtube.comDRY原則は、単に「コードの重複を許さない」ではなくて 「意図や目的の単位で重複を許さない」ということ なので、目的特化型モデル を設計するただ意図や目…

最近やることが少し多くて時間が足りない感じ。読んでる時間が足りない。読んでることに集中できていない。 ポッドキャストが少しラク。 おもしろいしたのしいし。気になったときが集中しているときのようだ。https://automagic.fm/post/190779575505/design…

冒頭に少し長く、 エンジニアリングをマネージメントするとは何か、のような話があって、 プロジェクトマネジメントしようと思うんなら設計をするんだ、 ということだと思うんですよね とおっしゃってて、つまりは、開発プロセスと、アーキや設計は密接に絡…

qiita.com例年この時期には、新入社員が入ってきて 「コメント書きなさいよー」って話をするわけですが、でも そのうちなれてきたら、 「コメントなくても読めるコードを書けよー」と言いたいです！ 最初のうちは "コードを説明するためのコメント" を書いて…

うまく名前をつけることは、「究極の設計」ではある（と私は思う）けれど。 ここではもっとカンタンなお話として。 （上位の）設計書からそのまま名前を引用しようとすると、 コードにうまくマッチしないときがある。 なぜならば、設計書に書かれるものは「…

なんでもかんでもコメント書けばいいわけじゃない。 見ればわかるじゃん、ていうことまで書く必要はない。 でもそのさじ加減は、少し経験を積まないと、わからない。 それは言葉にしてもなかなか伝わらない、・・・ように思える。 コメントがいるってことは…

https://twop.agile.esm.co.jp/what-do-we-need-for-growth-of-future-65c43b5a8fe2twop.agile.esm.co.jp とにかく良記事！ だいじなことが書いてあると思うので、しっかり引用。 （赤文字は私がかってにやってます。大事なことばを太字にしました。） 和田…

設計とは、 「なぜそうなのか」の理由付け・意味付けになるもの、だと思う。だから、自分のコードに対して 「なぜそうなのか」が答えられないようでは、プログラマとは言えないと思う。 そこに意思はあるのか？と思う。ただ単に動くものが作れるだけで、それ…

www.infoq.com ソフトウェアの妥協とトレードオフは避けられず、「すべての大規模システムがうまく設計される訳ではない」ことを、誰もが受け入れるように、Evans氏は励ました。「よい塀がよい隣人を作る」ような境界のある状況が、システムの悪い部分からよ…

ソフトウェア開発はハードウェアの生産工程のように同じ作業を大量にしないので、抽象的な手順に留めておかなくてはならないからです。そして、ソフトウェア開発は「気づく」工程「考える」工程であり、気づくこと考えることのガイドはなかなか書きにくいか…

以下、答えなし、深掘りなし。そして進歩なし？単位時間当りのステップ数とか、作業時間や人数を増やすとか いまだにそういうことでプロジェクトの体制を考えたりしてるのが すごくイケていない。かといって、周りを納得させる尺度や数値は何もない。 イライ…

先日、本を読んでて出会った言葉、適度な抽象度。「これだ！」と思ったね。いい言葉だと思った。抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、と書いたけども、 これは、考えるのに適度な抽象度があるっていうことだね。カメラが、寄ったり…

設計時は、システムを俯瞰的に見ており、 大きなふるまいのほうに目が行きがちである。 そして、コードになるときの姿を思い描きながら設計するのは、 かなり粒度が小さくなってからだ。しかしそれでも、実際にプログラムに落とし込むのとは違うのだ。コード…

関数をつくるということは、 システムの中の／世の中の「こと」「もの」をどう捉えてどう表すか、ということだ。処理の複雑さ・煩雑さや、量の多少ではなくて、 抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、ということだ。大きくとらえて…

仕様書に書いてあることは、そのままコードに落としたい。そのためにも、仕様書とコードを１対１で対応させたい、と思う。つまりは、「仕様書のここは、このクラス／モジュールに書いてあります」としておきたい。そして、その中身は、 「2-3章の機能は、こ…

「設計力」について、というのをずいぶん前からやろうと思っていたが、今頃になってしまったよ。 「会をうまく進行できただろうか？」今回はブレストやディスカッションの形で行なってみた。想定外だったのは、都合で若手が参加できなかったこと。経験の浅い…

仕様書の書き方のことを何度か書いたが、 まず出発点は「口で説明できること」なんだと思う。話し言葉でちゃんと伝えることができるということは、 話す前に、あるいは話しながらでも、 話す内容がきちんと整理できていて、伝えるための言葉の用意ができてい…

ソフトウェアというものは、 人間が頭の中で考えていることそのものであって、 頭の中で起こっていることをそのまま表現したものである、ということを 一体どれだけのひとが意識しているのだろうか、と思う。ひとの考えが全てなのだ。 概念や観念の世界なの…

♪今年のブクマ、今年のう・ち・に！ ← 書いてるうちに年こしちゃったねというわけで、もうひとつの ”長くてほったらかしだったやつ” を読む。ドメイン駆動設計入門 - Digital Romanticism正直これまでドメイン駆動設計って「言葉を知っている」という程度の…

仕様書の書き方、第２弾です。漏れ抜けのないようにと、あれもこれもと盛り込みたくて、 ついつい長文になってしまうこと、けっこう多いように感じています。しかし、仕様書は、まずは「箇条書き」です！要素をきちんと分解し、１つのことを１つの項目として…

（仕様書というよりは）資料を書くときにごく普通に意識していること。■言葉を統一する 同じものを指すのなら、常に同じ言葉で書き表す。■初出のものには説明を 重要なもの・ことについては、章を割いて説明する。 読み手の前提知識がどの程度で、どこまで説…

アジャイルラジオ ～IT系エンジニア応援番組！～さっそく第２回目がＵＰされていましたねっ！私は第１回放送の感想なぞを。「ハンドメンドの手ざわり感を大切にした」番組になってるのかと思いましたら、 なんだか「すげー本格的」な構成で、作り手のみなさ…