Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

設計

気づく工程、考える工程

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

生産性を上げるとはどういうことなのか?

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

適度な抽象度

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

書こうとしなければわからない ~プログラミングとは何か~

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

仕様書とコードの大事な関係

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

社内勉強会のふりかえり(「設計力」とは?篇)

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

書く能力、話す能力 -仕様書の書き方(3)

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

ソフトウェアとは

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

DDDとはこういうことなのか

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

まずは「箇条書き」でしょ! ~仕様書の書き方~

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

仕様書の書き方はどうやっておぼえるのか

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