設計からコーディングまでの「距離」：An Agile Way：オルタナティブ・ブログ
私の立場は「コーディングは設計（の一部）だ」(by Jack Reeves)である。ここでは、コーディング以前のラフな設計（例えばUMLのクラス図やシーケンス図レベルのアイディア、それがホワイトボードに描かれていようが、紙であろうが、JUDEであろうが、日本語であろうが）を、ここでは設計と呼ぼう。 設計とコーディングの距離が増えれば増えるほど、ムダが増える。私の主張は、できるだけ、１つの関連部分の設計とコーディングは、「一人の人」が「少しずつ」行ったほうがよい、ということだ。昔見た「詳細設計書」という細かい実装の詳細を日本語である人が書き、それを見て別の人がコードを書く、ということは避けたい。ここでの距離とは、 頭脳間距離。 時間的距離。 の２つ。 頭脳的距離は、物理的に書く人の頭脳の距離だ。1人の人が設計からコーディングまでを含めて担当すれば、この距離は0だ、別の頭脳が担当するならば同じ
「車輪の再発明をするな」の流行は孔明の罠 - きしだのHatena
なんかの実装がオープンソースで公開されているときに、同じ機能の実装を行うのは「車輪の再発明」で無駄な行為だといわれた時期がありました。 でも、それは「再発明」ではなく「再実装」であって、とても大切な行為です。 車輪にしたって、ブリヂストンも横浜ゴムもタイヤの開発をいまもって続けてるわけです。タイヤだけでなく、ホイールからベアリングからドライブシャフトから、「車輪」の部品については、いまだにいろいろな会社が切磋琢磨して再実装を続けているのです。 世の中に出ているライブラリを自分で実装してみるとわかることは、自分の実装を持っているという強さです。 たとえ世の中のライブラリに機能的に性能的に負けていたとしても、自分の実装というのは自分のニーズに合わせるという点でとてもいい。特に、処理の途中の値を使えるというのがいいのです。ライブラリでは、入力したら出力が返ってくるまで中身が見れないですからね。
フリーランスが請けたくないプロジェクトの特徴:Geekなぺーじ
「7 Signs Your Project Will Never Make it to Production」 という記事がありました。 フリーランスとして働いている著者が、プロダクトとして発表されるに至らないプロジェクトの特徴を述べています。 このような特徴を持つプロジェクトに参加しても、自身のポートフォリオに新しい製品を追加する事はできないそうです。 面白かったので要約してみました。 全てにおいて真であるとは思いませんが、何と無くありそうな話だと思いました。 1. クライアント側でUIモックアップを制作したことが無い クライアントは自分が何を制作したいのかを良くわかっていません。 2. クライアントは、ドキュメントではなく電話越しに内容を伝えようとする かなり危険な状態です。 何らかのドキュメンテーションが出来上がるまでは仕事を請けるべきではありません。 3. クライアントの個人的欲求
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
