サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
www.system-sekkei.com
InfoQに、「技術的負債を解剖する」という記事が出ています。 翻訳したのは、Domain Driven Design Quickly を翻訳した徳武聡さん。 徳武さんとは一緒に仕事をしていますが、頭が速くて手も速く、good senseです。 SEマネージャからみて、とても頼りになるエンジニアです。 数ある翻訳候補の中から、「技術的負債を解剖する」を選ぶところも、なかなかgood senseです。 —- そもそも、「技術的負債」というのはワード・カニンガムがメタファーとして作ったものだとのこと。 マーチンファウラーのBlikiから引用すると 「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は(ファイナンスの負債と同じく)技術的な負債が発生する、ということになる。
実際にシステム開発に携わるエンジニアには超おすすめの本をご紹介します。 ThoughtWorksアンソロジー あのマーチン・ファウラーも所属する、ThoughtWorks社のエンジニアのみなさんによるエッセイ集です。 この本では、システム開発の様々なシーンについて、とても実践的に書かれています。 また、当然かもしれませんが、それぞれ書かれている内容はとてもレベルが高いです。 ここに書いてある内容を一つ一つ実践していくだけでも、自分たちのチームはすごくよくなるのではないかと思えるほどです。 まずは、創業者兼会長のRoy SinghamとMichael Robinsonによる、”ビジネスソフトウェアの「ラストマイル」を解決する”について書いてみます。 ビジネスソフトウェアは「稼働」しなくてはいけません。文字通り、「働いて」「稼ぐ(価値を提供する)」という段階に入って、開発プロジェクトはゴールと
お客様の事業への貢献 私たちは、お客様の事業を発展・成功させるための情報システムづくりのプロ集団です。 事業の目的、事業の構造、業務のやり方を徹底的に理解するところから出発し それにふさわしい情報システムを提供いたします。 俊敏(アジャイル)な行動 俊敏(アジャイル)な経営のために、俊敏にITシステムを開発し、発展させます。 事業の発展、事業環境の変化に俊敏に対応できるシステムが、もっとも価値のあるシステムだと考えます。 システム設計のプロ そのために、設計、特に、ソフトウェアの基本構造の設計に力を注ぎます。 設計の良し悪しが、ソフトウェア価値の最大化、維持・修正コストの最小化に直結することを知っているからです。 設計の良し悪しは、外からは見えません。だからこそ、プロ意識をもって、最善の設計を提供することが、われわれの使命であり、誇りです。 継続的なサポート 情報システムは、実際に動いて、
私の今のお仕事は、ひとつのインスタンスを複数のユーザが利用する「ASPサービス」の保守・運用・開発です。 ですが、最近はこの「共用仕様」に飽き足らないお客様のために、個別にインスタンスを立ててカスタマイズする案件が複数並行しています。 そういうわけで、最近は営業やユーザからのヒアリング内容をうまくまとめて、「要件定義」として記述するという作業シーンが多くなっています。 — そもそも要件定義って、みなさんどうしていますか?プロジェクトが終わった後で、 「要件定義があいまいだったために、多数手戻りが発生した」 なんて反省をしていませんか? 私見ですが、要件定義が失敗しやすい理由としては、 ユーザからのヒアリングが上手にできない(対機械の作業ではなく、対人間での「情報を引き出す力」が問題) スケジュールがタイトで、気づいたら要件定義のフェーズを終了させられた。(まだできてないってば。) そもそも
今日、CNET Japanを見ていたら、こんなものを見つけました。まだ未評価なのですが、いい感じのにおいがするので、とりあえず載せておくことにします。 UIデザインのガイドラインは、実際にシステム開発を行う際に案外後回しにされがちな分野です。また、実際にUIをデザインするデザイナー(エンジニア?)も意外と無頓着に作成してしまうケースも多いように感じます。私も評価してみますので、みなさんも評価してみて感想をもらえるとありがたいです。 以下、builder by ZDNet Japanの「UIデザインガイドラインのまとめ」からの引用です。 Introduction to Apple Human Interface Guidelines 個人的に UI デザインガイドラインといえばこれ。日本語訳も大変便利です Apple User Experience Guides ソフトウェア開発向けですが、
近頃はドメイン駆動に興味の中心があるせいか、RDBの論理設計についての話をあまり聞かなくなってきた。 では、みんなよい設計ができるようになったのか?いやいやそんなことはない。よくひどい設計に当たったりもする。 よいデータベースの論理設計って何か?という問いに対しては、「データベース・リファクタリング」の「データベースの不吉な臭い」がとても参考になる。今まで見てきたひどいデータベース設計のほとんどがこのアンチパターンに入っているように思います。 複数の目的に使われるカラム データベースリファクタリングで挙げている例は、顧客の場合には誕生日を、従業員なら雇用開始日を格納する開始日付項目。「そんなことしないよ」と思われるかもしれませんが、経験上、この手は以外に多い。 たとえば、テーブルにありがちなシステム管理上の「データ作成日時」を、運用上一致するからといって「申込日」といった業務上の日付として
このページを最初にブックマークしてみませんか?
『システム設計 -system design-』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く