Hatena::ブログ(Diary)

杉風呂2.0 - A Lifelog -

2014-11-03(月)

[]エンジニアが事業計画を知らなくてモノが作れるのか?

駄文ポエムです。

  • 先のことなんてわからないし、事業計画通りにいくわけがない。だがしかし
    • 何ヶ月後にどのくらいのユーザを集めたいのか、それがどれくらいのトランザクションを発生させるのか知らなくて作れる?
    • たとえYAGNIといっても直近作るfeatureぐらいは知っているべき
  • 事業規模に合わせて段階的にスケールさせていけばいいが、そのタイミングがいつなのか知っているか?
    • プロトタイプレベルの実装とプロダクションレベルの実装は違う
    • 機能が変われば最適なデータモデルやアプリケーションアーキテクチャも違う
    • チーム体制だって違う
  • エンジニアは、トレードオフを都度判断し、決定する
    • エンジニアリング上の判断がサービスの成長や企業の収益に直結する時代
    • 設計を統合したり、ビジネスサイドや経営層にリスクを説明したり諸々提案、交渉する役割を担う人が重要
  • プログラミングできればそれで満足なエンジニアなんてほとんどいない
    • サービスが提供する価値は何か、自分のやったことが会社にどういった利益をもたらすのか、世の中にどう役立つのかを知らないで仕事できないよね
    • にんげんだもの

2012-05-08(火)

[][]『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』

GW中の2日間でいっきに読んだ。よくまとまっている。いろいろ触れていない項目もあるけど、論理設計では業種やプロジェクト運営に依存するし、物理設計では、ターゲットのRDBMSを固定しないと詳細に入れない部分もあるから仕方ない。本書の態度として、論理設計と物理設計を明確に境界を持たせずトレードオフを意識することを挙げていて、それなりのシステムを扱う人にはこれが基本的な態度になるだろうなと思う。読みどころとしては、7章「論理設計のバッドノウハウ」8章「論理設計のグレーノウハウ」で、それなりに経験の積んだエンジニアは該当事例に出会ったことがあるはず。で、その中には自分の現場では上手くいったということさえあると思う。なぜそれで上手くいっていたのか、逆にダメだったのか、どうすればよかったのかということを考えながら読むと面白い(にがい記憶が思い出される?)と思う。他、akipii さんによると、8章「一歩進んだ論理設計」で扱われている入れ子集合モデルがRedmineで採用されているらしい。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

2011-04-13(水)

[][]実装パターン

2010年12月頃読んだ。Kent Beckの本。とりあえずロジックは書けるんだけど、どう書けばベターになるのかの判断ができてすぐに役に立つ感じ。本書を読んでいたらP75-76に以下のid:yojikさんのツイートに関連した事が書いてあって印象に残っている。Kent Beckの考え方が揺れていて面白い。

Javaや他の強い型付き言語における1つの特徴は、変数の型を宣言する必要があることだ。(中略)変数がどのように実装されるかではなく、どのように使用されるかを伝える型を選択するようにしよう。(中略)最初のドラフトを書いたとき、私は教条主義的な表現をしていた。すべての変数はできるだけ汎用的に宣言すべきであるという厳格な規則を打ち立てようとしていたのだ。しかし、すべての型を一般化しようと試みても、それだけの効果は得られないことがわかった。(中略)今なら当時よりも穏やかに言いたい。変数やメソッドをできるだけ汎用的な型で宣言することは役に立つ、と。一貫性を維持するために、正確さと汎用性を若干欠くようになることは、合理的なトレードオフである。

しかし、まぁ、ツイートの検索って難しい。会話が全部は復元できず。「自分のツイートで」「誰とのインタラクションで」「時期はいつ頃で」って指定できる検索サービスはないものかと。

実装パターン

実装パターン