僕もエジプトの壁画にRedmineが描かれているのを（夢で）見た記憶がある。
自分も何故か頭で考えてると止まっちゃうんですよね。タスクをExcelに全部書き出して、着手順を決めて、やっと始まる。
一度煮たらの話
かぼちゃ🎃の足速いよね。あの図体で東京〜大阪間二秒ぐらいだからね。ホントに早いから、みんな気を付けてね。
それは卵焼きじゃないかな。最近だとおくらの輪切りを混ぜて、星の模様にするのが流行ってる。
前のプロジェクトが以下の方針だった。
・コメントは減らす。
・変数名を説明的にする。長くても許容する。
その癖が今も続いている。何も言われない現場なので、矯正の機会がないまま、書き続けてる。
南京大虐殺は無かった説、自分が日本人であることにより、逆に言及しにくくなってる説
離任、ですかね
安心してください、眠れますよ！
企業の面接マナー本に「儲け話を最低ひとつは持っていこう」とか書いてあったらどうなるんだろう。
こういう話って具体例に対して検討するときは割と結論が出る気がするけど、頭に思い浮かべてるシステムが企業の受注システムとゲームのRPGだと要件が違い過ぎたかもしれん。
プログラミングのパラダイムは有効な場面で適用できればそれでいいと思う。関数プログラミングも画面作るときには使えないし。
それはそうですね。
オブジェクトに対してCRUD操作ができるように作ってあげれば大抵の用件はそれで済んでしまうかもしれない。
別に一つのオブジェクトが他のオブジェクトを参照しててもいいのか。伝票が顧客と商品を参照するのは当たり前か。
伝票が操作対象として画面上にあるのは自然だけど、商品も顧客も普通はオブジェクトとして管理するよな。伝票一覧、顧客一覧、商品一覧は、それぞれのクラスのオブジェクトのコレクションの可視化として自然だと思う。UI設計とデータベースの正規化をごっちゃにしているから混乱しているのかもしれない。
僕はオブジェクト指向を真剣に検討してシステム組んだことないな。オブジェクト指向言語のオブジェクト指向機能？を一生懸命使ってみただけだ。何かオブジェクトなのかというのを真面目に考えてなかった。
逆に言うと、パフォーマンスチューニングするような場面でオブジェクト指向考えても意味がない気はする。
注文、とか、会員、とか、オブジェクトを決めて、オブジェクトを操作する体系としてプログラムを作る設計がオブジェクト指向なのではないでしょうか？
ファイルシステムなんかも、ファイルがオブジェクトで、それを操作できるシステムがファイルシステムでしょ？
なるほど、なるほど、おめでとうございます。
開発規模による。
一人のプロジェクトはクリティカルパスの分析はほとんど要らない。二人はたまに要るので気をつける。三人以上は、図を描くかも。四人を超えたらクリティカルパスをしっかり分析したほうが良い。