職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;
Code Completeの上下巻を読んだ。 CODE COMPLETE 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCODE COMPLETE 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 読んだ感想としては、職業プログラマーなら必ず読むべき本だなと感じた。 この本ではソフトウェアコンストラクションに関する話題を扱っている。この本の中でソフトウェアコンストラクションとは、詳細設計、コーディングやデバッグ、単体テストなどなど、要求定義が終わった後、ソフトウェア製作に必要なプロセス全般のことを指している。 主なテーマとして、どうやってソフトウェアにおける複雑さを減らすことが出来るのか、について書かれている。そのテーマをいろいろな観点から説明されている。例えば以下の様な観点がある。 上流工程の欠陥による
組み込みもけっこう末路なのかもしれない
業務系SEの末路的なお話でして - 急がば回れ、選ぶなら近道 業務系に限らず、組み込み系もけっこう先行きは明るくないと思う。 メーカーの下請けでやってるようなところだと ・メーカーの予算削減で人員は減るが仕事量は変わらない ・むしろシステムの高機能化でアーキテクチャは複雑になる ・しかし一つの製品の納期はどんどん短くなる ・メーカー側もコスト面から製品に対して人員を割かなくなるので、メーカー側の社員が手が回らず下請けに丸投げしだす ・請け側の会社も仕事が少しでもあるところにスキルをあまり考えずに要員を投入する はい、デスマ。 発注側も受け側も余裕が無くなっていて、それでも請けるほうは仕事無いから請けるしか無くて、だいたい当初の想定通りのフェーズや要因で炎上する。で、年中残業やら休日出勤やらで疲弊するエンジニア。 請ける側にも多分に問題はあって、マネジメントできない人がマネジメントをし、設計
「達人が語る こんなデータベース設計はヤダ！」へ参加してきました - 虎塚
あの『達人に学ぶDB設計 徹底指南書』を書かれたミックさんが講演されると聞いて、Club DB2さんの勉強会に初めてお邪魔してきました。 「第146回 達人が語る こんなデータベース設計はヤダ！」 https://www.ibm.com/developerworks/wikis/display/clubdb2/146 非常に面白く、勉強になりました。せっかくなので、備忘メモをupしておきます。 （内容に誤りがあったり、もし掲載自体に問題があったりしましたら、修正・削除しますのでお知らせください。＞関係各位） 本編 （追記）発表資料にリンクしました。 http://d.hatena.ne.jp/mickmack/20120714/1342246442 ミックさんが「これだけは覚えて帰ってください」とおっしゃった3つのポイントを引用します。 トレードオフ うまい話には裏がある。 物理 vs 論
【インタビュー】クックパッドのUIデザイナー：「エンジニアの仕事が０を１にする仕事なら、デザインは1を100にする仕事 」 | Startup Dating
Startup Datingでインタビュー連載を始めてみることになりました。さて連載の初回は、2011年に新卒としてクックパッドに入社し、現在UIデザイナーとして活躍する片山育美さん（@monja415）。片山さんが現職に就くまでの道のりや、クックパッドのUIに関する考え方、片山さんが手がけた具体的なUI改善の事例やヒントなどをたっぷりお伝えします。 美術大学で勉強、もともと職人になりたかった もともと絵を描くのが好きだし得意、高校のときから職人になりたいと思っていたと話す片山さん。美術大学に進学し、ファイン系とデザイン系でデザイン系を学ぶことを選択。ファイン系とは、絵画や彫刻などいかにも“アート”というもの。ファイン系が芸術だから、どこか自分の中で完結してしまうところがある。でも、職人って誰かのために技術を使える人なんじゃないか、と。情報デザイン学科を専攻し、サービスデザインやUXと言わ
設計審査の超定番「安全率」をごまかすな！
「5N」と言えば、「灯油ポンプの設計書を書こうじゃねぇかい！」を公開して以来、企業規模を問わず、いろいろな企業から当事務所に問い合わせをいただきました。多少の批判はありましたが、ほぼ賛同という意見でした。その内容とは……。 以下の設計「5N（5“ない”）」は、企業規模の大小とは関係なく発生しています。 競合機分析やらない 強度、安全率、累積公差計算しない 特許出さない コスト見積もりしない 設計審査やらない 長年この状況を許してきたために、現在は、「やらない」が「できない」にまでなってしまいました。これは昔からあった現象ですが、3次元CADが急激に導入された「3次元CAD元年」と呼ばれる2001年ごろから急加速したのです。このころ設計された家電や自動車に“設計品質が原因のトラブル”が集中しています。 多くの日本企業が改善を目指しているということは、筆者も大変うれしく思います。問題は、何も気
SEとPG vs プログラマ2人 - ITコンサルの日常
階段状になってるスケジュールをぼーっと見てたら、このネタを思い付いた。 前提 SE: 設計はするが、コードは書かない人。 PG: コード(だけ)を書く人。 プログラマ: 設計も実装もする人 既に稼働中のシステムがあり、変更案件やバグが課題として一覧管理されている。 あるリリース（xxリリースとする）では、変更Ａと、バグＢの課題を改修し、リリースしようとしている。 各課題に対しては、設計／実装／テストの作業が必要である。（レビューとか、リリース作業とかは省略） 各作業に対しては、1週間かかるという見積りが出ているとする。 お題 このときのスケジュールを書け。 SEとPGが1人ずついる場合 工程ごとに分担するので、中項目は工程になる。（垂直分割） PGは、SEの設計が終わらないと何も出来ないので、1週間アイドル状態になる。 SEは、PGが誤解しないよう、細心の注意を払って設計書を書く必要がある
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
Objective-Cを書く人も書かない人も必読『iPhoneアプリ設計の極意』 - ninjinkun's diary
@fladdictさんが監訳されたことで話題の、オライリー本『iPhoneアプリ設計の極意 ―思わずタップしたくなるアプリのデザイン』、早速会社で購入してもらって読みました。読み終わってまず思ったのは、これはiPhone開発に携わるすべての人に必読の本になるだろうということです。エンジニア、デザイナー、企画者と分担が分かれている場合は、全員が読むといいのではないでしょうか。この本はiPhone開発に必要な共通言語を提供してくれます。それも、コードを使わずに。 本書から得られる内容としては大きくふたつあると思います。ひとつはiPhone開発のプロセスを解説書としての側面。もうひとつはiPhoneのUIカタログとしての側面です。 アプリ開発プロセスの解説書 この本に書かれている開発プロセスは、ベストプラクティスと言えるものになっていると思います。ユーザーニーズを探ること、シンプルさを追求するこ
いまさら聞けない.NET テクノロジの例外管理の設計および実装のガイドライン その１ - Bug Catharsis
例外管理ポリシー アプリケーションの内部で発生した例外を管理する際には、いくつか考慮すべきことがある。 まず、「発生した例外をどのタイミングで捕捉するのか」、「捕捉した例外をどのように処理するのか」、 そして、「捕捉した例外をどのように伝播させるのか」などである。 こういった例外に対するポリシーは、システムの要件や規模によって変化するのが常で、 例外管理システムを担当する設計者の思想と過去の経験などが大きく影響してくるが、 一般的にベストプラクティスとして知られる基本的なポリシーがある。 例えば、例外を捕捉するタイミングは、以下のいずれかの例外処理を行うケースが考えられる。 １．ログの記録のために情報を収集するケース ２．例外に何らかの関連情報を追加するケース ３．リソースの解放などのクリーンアップ・コードを実行するケース ４．復旧を試みるケース 逆に言えば、これらの条件に合致しないような
例外処理とロギングのベストプラクティス
はじめに システム開発において例外処理は重要なポイントですが、あまりに軽視されているのが現状ではないでしょうか。本稿では、これまでの著者の開発経験の中から培った汎用的な手法を説明します。 この記事は「美しい設計」ではなく「現実的な設計」、現場に適用できる「できるだけ手間の少なく、汎用的な設計」を目指しています。 対象読者 J2EE開発者・アーキテクト。特に業務システムの開発現場の方が対象です。 必要な環境 概念の説明が中心ですので、開発環境は必要ありません。 エラーの分類 実装時に考慮すべきエラーは2つに大別できます。 想定内でトランザクションの実行開始前にチェックするエラー。主に入力エラー。 異常な状態としてトランザクションの続行が不可能なエラー（例外）。 前者については、例外を使うべきではありません。入力チェックエラーを表現するには、ステータスコードを使うべきです。理由は次のとおりです
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
言語設計者たちが考えること
C++、Python、APL、FORTH、BASIC、AWK、Lua、Haskell、ML、SQL、Objective-C、Java、C#、UML、Perl、PostScript、Eiffel、そしてRuby。世界に多くの影響を与え、またソフトウェアの基盤を支えているさまざまなプログラム言語の設計者たちへのインタビュー集です。彼らが何を考え、どんな考えに基づいて言語を設計したのか。伝説的かつ著名な言語設計者たちが登場し、背景、動機、哲学、信念、秘話、教訓、課題を語ります。対話を通してパイオニアたちの飽くなき探究心と思考プロセス、情熱、そして底知れぬエネルギーが見えてくるはずです。 日本語版には、Rubyのまつもとゆきひろ氏へのインタビューを追加収録しています。 目次 本書推薦の言葉 まえがき 1章 C++（ビャーネ・ストラウストラップ） 設計上の意思決定 C++の使用 オブジェクト指向プロ
フレームワーク――物事を分けて考えよう − ＠IT自分戦略研究所
ユーザー企業がシステムの設計・開発を依頼するとき、そこには経営的な判断が存在する。顧客の「経営戦略」をとらえたうえでシステムを設計・開発できるITエンジニアになろう。 前回は、経営戦略が全社戦略と事業戦略の2階層になっていることを学んだ。 全社戦略：会社の事業として何を選択し、どう組み立てるかを決めていくこと 事業戦略：選択された各事業の方向性をより具体的に決めていくこと 全社戦略と事業戦略のいずれについても、戦略を立てるに当たって便利な道具が2つある。「思考ツール」と「思考方法」だ。「切り口」と「考え方」とも呼べる。今回は前者の「思考ツール＝切り口」について学ぼう。 ■ 家を買うためには、どう考え、どう決断すればよいか？ 例えば、借家住まいのあなたが一戸建ての家を買うことを考えよう。家を建てることを自分自身という会社の事業の1つだと考えれば、これも立派な事業戦略である。さて、何を考えれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
言語の設計判断