愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
iPhoneアプリ
author:えふしん
photo_20.jpg
藤川真一について


初代モバツイ開発者
想創社再創業 / KMD博士課程
著書〜100万人から教わったウェブサービスの極意―「モバツイ」開発1268日の知恵と視点 [Kindle版]
お求めやすい夏休み特価!
AMN sponsor rolls
このカテゴリ[会社活動]の最新30件
2013年からのWeb関連ビジネスの方向性と、「100万人から教わったウェブサービスの極意」kindle版 320円キャンペーンのお知らせ 3Dプリンターに対する単純な疑問 会社を辞めるまでの期間、1.5ヶ月以上は会社の甘え エンジニアの評価が4以上にならないワケ 嫌な夢を見た シャープの液晶は成長技術や否や 決断力がある人の弱点 うだうだ書く ブラックという言葉から逃げるな 若い奴が抱く年齢への恐怖なんてどうせわかってないで言ってるから気にするな。 人は見たい現実しか見たくないという問題 プレーヤーとして戦い続けるための意志力 エンジニアの未来サミット 2012 for Studentsで話をしてきました。 Amazonの企業理念「Every day is still Day One」が素晴らしすぎる。 「エンジニアの未来サミット for students 2012」に登壇します。 責任フリーのイノベーション 想創社 version2.0を設立しました。 世界は勝手に変わるのではない、誰かの手で変えているのだ。 Webのベンチャーが目指す先はカンバン オワコンのガイドライン ブラック企業の定義 家入さんのラジオ番組に出演した件と、WebSig1日学校で講師をやる件 技術力、ソフトウエア発想共に最もアップルに近かったシャープ…X1/X68の思い出 Twitter api ver1.1、痛いところ、痛くないところ IMJの上場廃止の文章に思うこと。 フリーエージェント社会の到来は、そのまま企業体の没落を示すわけではない。 ミッション・クリティカルについて考える〜AndroidよりiPhoneの方が好きな理由 社員は本当に経営者視点を持つべきなのか。 三木谷社長のインタビューは終わりの始まりになるのか?! ScanSnap+プリンタを1万円で代替するクラウド対応のインクジェット複合機の話
[このカテゴリをもっと見る]
Powered by
Movable Type

March 13, 2007

スポンサーリンク

「先祖返り」ってご存じでしょうか?
せっかく作っていたデータを、古い日付のもので上書きしてしまい、古い状態に戻してしまうことを言います。

よくWeb制作で起きがちで、複数人で一つのフォルダのソースをいじくっていたり、不注意な人がざっくり古いファイルを上書きしてしまったりすることでおきます。特に忙しい納期直前ほど起きる現象です。

不注意な人のやることと言ってしまえばそれまでですが、人は必ずミスをするものです。

不注意な人のミスをいかになくすか?というのが、世の中の生産管理の肝と考えれば、単純にソースコードの管理手法がなっていないと考える方が僕は自然だと思います。

世の中には、バージョン管理システムという名前で、CVSとかSubversionとか便利なシステムがあるのですが、これがちょっと難しい。何が難しいというと、まず用語が難しい。コミットだのチェックアウトだの聞き慣れないキーワードがついていてとっつきにくくて、そこからバージョン管理システムを使う気が起きなくて変えられないという人はいると思います。僕もそうでした。

ということで、CVSやSVNを使いたいと思いつつも腰が重いあなたに、それなら最低限これやっといた方が良いですよという書き込みです。先祖返りが一番起きる可能性が高いWebの制作行程をターゲットにしてみたいと思います。

- ・ -

■そもそも先祖返りを呼び寄せるデータ管理手法とは?

(1)一つのフォルダをみんなでいじくる。
特にHTMLはリンクがあってファイル間の関係が複雑なので、開発のようにいじるソースコードのエリアを分担するというのが結構難しいように思えます。(commonとか、CSSとか)なので、一つのフォルダをいじくるのは結構仕方ないかなと思うので、Webの制作においては、そもそも先祖返りがおきやすい環境であることを認識した方が良いです。

無理矢理フォルダを分担してしまって、制作中に沢山のデッドリンクを放置するのも無駄だと思うし、マージするときの先祖返りの危険性を考えると、ただ分ければ良いってものでもないと思います。

(2)ローカルで作って最新の反映をするためにフォルダ丸ごと上書きをする行程がある。

外の人にお願いしたりするケースでは必ずありうるのではないでしょうか?

上書きしちゃいけないデータを上書きするタイミング、ナンバー1って感じですね。
上書きは、そもそも危険だということを認識すべし。

後述するファイル差分ツールを使って、必ず上書きして良いか確認しましょう。
上書きされる側のバックアップも重要です。

(3)PSDやFlaファイルを作るときに、○○_new.flaなどというファイル名もしくは、○○_2.flaというファイル名をつける。

なんとか_newなどという相対的なファイル名はつけてはいけません。100%何に対してのnewかがわからなくなります。

Flashファイルなどで_newという名前をつけたくなるファイル名は、結構、忙しい時にテストなどで使う試作のデータだったりもします。そういうデータがフォルダに残ってしまうと最悪。結局、古い方が本流のファイルになって、タイムスタンプが更新され、_newは何に対してのnewかわからぬまま誰も消せなくなります。3ヶ月もたてば作った本人も何のnewかは覚えていません。

じゃぁ日付なら良いだろうと、○○_0313.flaなどとつけるのも危険です。まず、1年経ったらこのファイル名は新旧がわからなくなります。うかつに保存して更新日付を最新にしてしまったら、もはや何がなんだかわかりません。

しかも、何のファイル名のポリシーもない場合は、何故か最初は、○○_newとつき、さらにnewのnewを作りたくなった時に、○○_new0313などと非論理的な枝番がつくことがあります。これも結局、どっちが本当のnewかがわからなくなる原因です。どうしてもやりたいなら○○_new_newとしてもらった方がわかりやすいですね。

また場合によってですが、日付によるファイル名は、「前後のバージョンのファイルがあるのかないのか」がわからなくなります。仕様書のリビジョン管理などでは気にした方が良いかもしれません。

(4)ゴミデータを残してしまう。
そここそ○○_temp.htmlとか○○_new.htmlなどという使われないファイルが、納品すべき本番のファイルの横にあるのは、間違えて消してしまう原因です。

ゴミはその場で整理整頓。整理整頓したくなる環境を作ることが大事です。
製造業時代、先輩から「良い仕事をするには整理整頓からだよ」って言われた物です。

こういう名前のファイルを作りたくなるのは、ずばりソースコードの管理ができていないからです。こういうことをしなくても元ファイル名のまま古いデータを残しておけるようにすることがソースコード管理では重要なことと言えます。

- ・ -

■先祖返りを起こさないデータ管理手法とは?

(1)ソースコードが入ってるフォルダのに年月日をつける。

そのサイトデータが入っているルートのフォルダ名に「○○○○_20070313」という年月日をつけましょう。

(2)このフォルダを毎日コピーして全部のサイトデータコピーを毎日作っていく。
朝、ディレクターの人が出社したら、今日の分として昨日のサイトフォルダをコピーして増やしましょう。フォルダ名は今日の日付がつきます。もし、そこにあるフォルダが最新と言い切れる運用ならば、最新のデータは固定のフォルダ名でも構いません。(プレビュー用にバーチャルホストを切ってる場合なども)

いずれにせよ可能な限りのコピーを作っておくことで、古いファイルに戻したくなったら、1日前や2日前のフォルダからコピーしてくれば良いのです。

先祖返りをやりそうな人に限って、何故かこういうところが貧乏性というか几帳面だったりして、同じようなフォルダが増えていくのを嫌う人がいるんですが、「消しちゃうよりマシ」です。

コピーされた昨日の日付のフォルダは、もういじってはいけません。それは昨日までの作業ファイルなのです。過去の物なのです。

なので、oldというフォルダを作ってコピーが終わった古いフォルダを毎朝そこに移動してしまいましょう。万が一、HDDの容量がなくなったら、oldフォルダを丸ごと消してしまえば良いだけのことですし、oldと書いてあることで編集してはいけないことがわかります。(「new」ではなく「old」であることが重要)

もし、それでも古いフォルダをいじりそうなうっかり者がいるなら、古いフォルダをアーカイブしてしまうのも手です。

この管理手法に慣れると、oldフォルダを丸ごと消して大事なファイルが消えたらどうしよう、などと削除することが結構怖くなります。

そう思うようになることが、先祖返りを防ぐ重要な気持ちの持ち方です。

本番にリリースするとか、お客様のプレビューの直前には、何かそれとわかる目印をフォルダ名につけておくと良いですね。こういうクセをつけておくと後で役に立ちます。

(3)古いフォルダとの差分を意識する。

あなたのプロジェクトフォルダは、初回リリースのソースコードを再現できますか?

例えばアップロードした後で、10日前の状態に戻してよと言われて、正しく戻せますか?

以前、クライアントの意向で、古いバージョンの方が良いと言われて、以前のバージョンに戻すために再度、制作作業をするという寒いケースを見たことがあります。まともなソースコード管理をしていないからこそ起きる現象です。

また、リリースしてから、これは出してはいけない情報だった。
もしくは、来週リリースする新製品情報を先にリリースしてしまった。

これらは全てソースコード管理ができていないのが原因です。

日付によるフォルダ名とバックアップができていることが前提で、これからアップするデータが本当に今アップして良い物なのか?を認識するために差分管理ツールを使いましょう。

Macに入れたい7つのWindowsソフトでも紹介した、DF.exeをオススメします。

parallels_thumb.jpg
上の写真は、2つのソースコードをドラッグしたときの表示です。ソースコードで同じ場所は白くなり、違う場所は色が変わります。
これにより一目で、二つのソースコードの違うところがわかります。

フォルダ毎の比較にも対応しているので、一ヶ月前のフォルダと、今日のフォルダをdf.exeにドラッグすると、何のファイルが更新されているのかが一目でわかります。ファイルの中身で比較するので、例えば何も変更しないのに保存してタイムスタンプだけが更新されたファイルが変わっていないこともすぐにわかります。

これで効率的に更新された部分だけを確認し、リリースして良いものかを確認するクセをつけましょう。本番環境は、あなたの身勝手な行動で汚染させてはいけない神聖な場所なのです。

時より、本番からデータをダウンロードしてきて、制作環境と比較してみましょう。思わぬアップし忘れが発覚するかも?!

(4)flaファイルやpsdもバージョン管理しましょう。
元データと呼ばれるフォトショップのpsdや、Flashのflaファイルなどは、バージョン管理システムなどを使っても忘れられがちなデータです。何故なら置き場所が違うケースが多いから。こういうデータは仕様書と同じようなところに置いてしまい、バージョンがわからなくなる筆頭です。

出力されたswfやjpegは正しく管理されているのに、元ファイルが何が何だかわからないというのは何の意味もありません。

flaやpsdは、○○○_20070313.flaなどとしておくのも良いですが、もしwikiなどを利用してリリース管理をするなら、バージョン名で管理した方が便利です。

例えば、○○○○_ver0.1.flaなどとしましょう。

なお、リリース時をバージョン1にしたいので、初期値は0.1とか0.01から始めましょう。これは某一部上場のSIさんから教わりました。

仕様書は0.01から書き始め、お客様のレビュー毎に0.1ずつ増やしていく。これによってどういう行程のファイルかが一発でわかるという次第。正式リリース版で、バージョン1.0にリネームする。以降のメンテではまた同じようにして次回のメジャーリリースでは2.0などと行った具合です。


- ・ -


■まとめ
これらの作業を人手で正しくやれるようにしましょう。
この方法は、ソースコードを管理する「たった一人の作業」でカバーすることができます。他の作業者は最新のフォルダを使うだけで、特に運用ルールを意識する必要はありません。

大事なのは意識の問題で、フォルダを日付で管理し、差分を意識することを覚えると、むやみに上書きするような行為が段々怖くなってきます。

リリースするときに、本当に必要なファイルだけをアップロードすることを心がけ始めたら最高です。

SVNなどのバージョン管理システムの導入は、これらの運用ができてからでも遅くはありません。

バージョン管理システムを使っても、ゴミファイルを作って、むやみやたらにコミットするのは避けたいのです。

例えば、なんとか.php.bakなど、うっかり拡張子を変えたファイルをバージョン管理システムに登録してしまい、他の誰かがうっかりリリースしてしまったとしたら、それがきっかけでセキュリティホールにもなりかねません。結局、バージョン管理システムを使っても、ファイルの管理意識が高いことは求められるのです。

とまぁ僕的ソースコード管理手法を書いてみました。僕はソースコードはSVNとかCVSで管理し、Flash や仕様書のようなデータをここで書いた手法で管理しています。近いうちに全部SVNに移行しようかなと思っていますが、既存の管理領域との絡みで、なかなか面倒なことが多いです。

バージョン管理システムに移行するのは、運用ルールが変わるので精神的に結構大変な作業です。せめてそれまでのタイミングまででも、少しでも先祖返りのリスクを防ぐことを思っていただければ幸いです。

もし、みなさんが実践されてる良い方法があったら是非コメントなどででも教えてください。


##あえて書きませんでしたが、これはバージョン管理システムがやってることを、人手でやるにはどうしたらいいの?というのと同じことであったりもします。

##というか長文すぎて多分、読まれてない(w

##「今日から使えるバージョン管理手法」とタイトルをつけるべきだったかも。

【PR】BASE エンジニア、デザイナー、経理!一緒に仲間になってくれる人を探してます!
スポンサーリンク
■同じカテゴリ[会社活動]のエントリー
<<前の記事 ユーザーが使いたいと思うものを使えるようにデザインすること
>>次の記事 悪いところより良いところを見ろ。
■このblogの書き込み最新3件
本ブログは移転しました インターネットの遊び方を身につけよう トトロが陽なら、『風立ちぬ』は陰?〜『風立ちぬ』の感想