チームへの公開

複数のプログラマが参加するプロジェクトでは、１つのソースファイルを同時に別のプログラマが編集してしまう可能性がある。これを避けるため、ソース管理用のサーバを設置するのが普通である（※１）。

このサーバには、プロジェクトで開発しているソースコードなどのファイルを全て登録しておく。サーバは、どのプログラマが、どのファイルを編集しているかということを管理し、衝突を防ぐのである（※２）。

このような仕組みを使うということは、プロジェクトに参加しているプログラマ全員が、サーバからソースコードを取得して、自分のコンピュータでコンパイルし、実行させるということである。

★

システムの開発中、ソース管理サーバから、最新のファイルを取得してくると、コンパイルエラーが発生して、仕事にならなくなってしまった、という経験はないだろうか？

特に、外注プログラマを大量投入したようなプロジェクトでは、プログラミングの開始時に、こういったことがよく起こる。中には、多人数での開発経験がない人も混じっているのだろう。

しかし、そんなことは、言われなくても分かっていてほしいのだ。

コンパイルが通らないということ自体よりも、「自分の書いたコードは他の人も使う」という認識がないことが問題である。

ソースをサーバに登録するということは、開発チームに向けて公開するということである。作成途中だろうがなんだろうが、最低限コンパイルが通る状態にすること、実行させてもエラーが起きにくい状態にしておくことがマナーであろう。

※１
有名なところでは、CVS とか、Visual Source Safe といったものがある。

※２
１つのファイルを同時に１人しか編集できなくする方法もあるし、複数の人の編集を許可しておいて、後から編集内容を合成させるような方法もある。

CVSによるオープンソース開発

posted with amazlet on 06.04.01

カールフォーゲルバーモシュ竹内里佳(訳) でびあんぐる(訳)
オーム社 (2002/06)
売り上げランキング: 42,463

おすすめ度の平均:

CVS本ではこれが一番よかった

ＣＶＳの理解に必要十分

CVSについての本格的な本

Amazon.co.jp で詳細を見る

Microsoft Visual Source Safe 6.0

posted with amazlet on 06.04.01

マイクロソフト (1998/10/23)
売り上げランキング: 10,845

おすすめ度の平均:

必要だが値段が高すぎる

Amazon.co.jp で詳細を見る

メモ帳でプログラミング？

Windows 付属の「メモ帳」でコーディングしているプログラマを見つけたときには、驚いた。メモ帳は機能が貧弱すぎるので、普通はプログラミングには使わないからだ。どうやら、彼は、世の中に、もっと便利なエディタが沢山あることを知らないようだった。

多くのプログラマには信じられないことだと思うが、Visual Studio や eclipse のような統合開発環境しか使ったことがないような新人プログラマなどには、稀にあることなのかもしれない。

★

プログラマたるもの、愛用のエディタくらいは持っておきたいものだ。

ここでいう「エディタ」はテキストファイル（※１）を編集するソフトで、厳密には、テキストファイル・エディタというべきものである。プログラムのソースコードは、ほとんどの場合、テキストファイルとして保存するので、プログラマにとってエディタは最も重要なツールだといってもいいだろう。

エディタには、無料のものから市販品まで、様々なものがある。初心者には、どれが良いのかを判断することが難しいかもしれないが、実際に使ってみて、自分が使いやすいと思うものを選ぶのが一番いいだろう（※２）。

★

エディタ選びの観点は色々ある。プログラミングを重視した場合なら、

・各種プログラミング言語のキーワード等を別の色で表示出来ること
・タブ、改行、全角スペースなどが目に見える形で表示できること
・タブの桁数（４桁, ８桁）が設定できること
・検索・置換に正規表現が使えること
・複数の外部ファイルを検索（GREP）できること
・多くの文字コードに対応していること
・印刷機能の充実（２段組、４段組など）
・他のツールとの親和性

などがあるだろうか。

あとひとつ、検討に値すると思われる観点を紹介しておこう。

それは、そのエディタが、フロッピーディスクや USB フラッシュ・メモリなどに入れて、持ち運ぶことができるかどうか、ということである。

職業プログラマは、自分のものではないコンピュータで、一時的に作業するようなことも多いはずだ。お客さんのコンピュータに、気軽にソフトをインストールするわけにはいかない。そこで、エディタのような利用頻度の高いツールは、簡単に持ち運べ、そのまま実行できるものがよいのである。

具体的には、設定などを Windows のレジストリに保存しないこと、実行ファイルのサイズが小さいこと、などを考慮するとよいだろう。

★

エディタ選びは、人によって好みが大きく分かれるところでもある。ここに書いてある意見も含め、他の人の意見を参考にする場合は、なるべくいろいろな人の意見を聞いてみるといいだろう。

※１
テキストファイルは、文字や改行や「タブ」が入ったファイルのこと。それ以外の物が入っていると、バイナリファイルと呼ばれる。

※２
Vector などで探せば、無料のものも沢山見つかる。

■関連記事
・ファイラのすすめ
・最低限の道具でどこまでできるか

MIFES for Windows Ver.7.0

posted with amazlet on 06.04.01

メガソフト (2005/02/18)
売り上げランキング: 2,793

おすすめ度の平均:

使い込めばいい道具

高いだけのことはあります

Amazon.co.jp で詳細を見る

EmEditor Professional 2004

posted with amazlet on 06.04.01

エムソフト (2004/04/23)
売り上げランキング: 1,282

おすすめ度の平均:

パワーユーザーにはお勧め

さくさくと軽快

シェアウェアのエディタソフトのパッケージ版

Amazon.co.jp で詳細を見る

簡単フレームワーク・プログラミングの罠

最近のシステム開発では、アプリケーション・フレームワークと呼ばれる仕組みが使われれる機会が増えてきた。

フレームワークは枠組みという意味である。あらかじめ決められた枠組み（設計や部品）を使うことで、開発効率を高める方法だ。言葉は違うかもしれないが、他の工業製品や建築でも、同じような方法で効率化が図られているのではないだろうか。

アプリケーション・フレームワークには、アプリケーションが動作するため基本的な機能が最初から用意されている。このため、プログラマは、そのアプリケーションの一部だけを作成すればよい。極端な話、顧客ごとに要求が異なる部分（ビジネス・ロジックと呼ばれるもの）だけをプログラミングすればよいのである。

このような方法なら、比較的経験の浅いプログラマでも、簡単にそれなりのシステムを作ることが出来る。

しかし、良いことばかりではない。本来、プログラマが持つべき知識は、ビジネス・ロジックばかり書いていては身につかない。むしろ、フレームワークに収まらないような、規格外のプログラムを作ってみないと得られないものである（あるいはフレームワーク自体を作成する側に回るか、だ）。

つまり、プログラマのスキルの低下をアプリケーション・フレームワークの導入でカバーしようとすると、いつまでたってもスキルが上がらない、という悪循環が発生するのである。

もし、あなたがこうした悪循環に巻き込まれているならば、早いうちに自力で脱出するしかない。そのまま放置していると、近いうちに「プログラマなんて誰でもいい」と言い出す人が出てくるはずだ。そして、安価な海外プログラマに仕事を奪われるだろう。

■関連記事
・簡単コピー・プログラミングの罠
・最低限の道具でどこまでできるか

エンタープライズアプリケーションアーキテクチャパターン

posted with amazlet on 06.04.01

マーチン・ファウラー長瀬嘉秀株式会社テクノロジックアート
翔泳社 (2005/04/21)
売り上げランキング: 10,264

おすすめ度の平均:

原書を読むべきだった。。。

訳さえまとなら…

待望の１冊。ただし帯に偽りあり。

Amazon.co.jp で詳細を見る

RailsによるアジャイルWebアプリケーション開発

posted with amazlet on 06.04.01

前田修吾
オーム社 (2006/02/25)

Amazon.co.jp で詳細を見る

簡単コピー・プログラミングの罠

既存の処理とよく似た処理を作成する場合、ソースコードをコピーして流用することがある。リーダーからそういう指示が出された経験のあるプログラマも多いだろう。

しかし、そういう場合は注意してもらいたい。

コピーしてきたコードは、何箇所か修正すると思う。しかし、そのうちのいくつかを修正し忘れてしまう、というミスが本当に多いのだ。

修正作業自体は、変数名や関数名を置き換えるとか、条件式をちょっとだけ変更するとかいった簡単なものだろう。しかし、そういう簡単なものほど、漏れがあっても気がつきにくいものである。

また、このようにコピーしたコードは、直し忘れがあっても、コンパイルエラーや実行エラーが出にくい場合が多い。あるいは、動作実績のあるソースを流用している、ということで、作業者の気が緩んでしまうということもあるかもしれない。

ゼロの状態からプログラミングする場合には、コードを少し書いてはコンパイルし、動作を確認していく。少しずつ確認することで、品質の高いものが出来るのである（※１）。しかし、ソースコードを流用する場合、そうした地道な確認作業は発生しない。これもケアレス・ミスが発生しやすい原因かもしれない。

★

コピー・プログラミングの危険は、流用の際のミスだけではない。本当に危ないのは、その後である。

コピーされた処理にバグが見つかったり、仕様変更などでその処理を修正しなければならないときのことを考えてほしい。コピー部分の処理を修正する場合には、当然、コピーされた全ての処理を同じように修正する必要がある。

過去にコピー・プログラムに悩まされたことのあるプログラマであれば、他にもコピーされた箇所がないかどうかを疑い、検索して全てを修正してくれるかもしれない。しかし、あなたの周りにいる全てのプログラマが、必ずそのような措置をしてくれるだろうか？

★

一般に、同じ処理を流用したいような場合、その処理を共通化させて、複数の箇所から呼び出せるような形に変更（リファクタリング ※２）するほうがよい。ここでは詳しくは書かないが、共通化する技法は、色々ある。同じシステム内の共通化であれば、それほど難しくはないし、違うシステムであっても、ライブラリ化すれば可能である。

また、似たような機能を大量生産するようなシステムでは、最初から「どうすればソースをコピーせずに量産できるのか」ということについて頭を悩ませるべである。さもなくば、コピーだらけのソースコードになってしまうだろう。

★

とはいうものの、コピー・プログラミングを撲滅することは難しい。

既存のシステムを修正する場合などでは、稼動実績のあるソースを変更したくない、ということもある。また、緊急のバグ対応などでは、リファクタリングをするほどの時間が取れない、ということもある（※３）。

このような場合には、やむをえずコピーによる流用を行うこともあるだろう。しかし、そういった場合でも、流用したことコメントに残しておく程度の配慮はしておきたい。

間違っても、「コピーすれば簡単だ」などという安易な考え方は持たないほうがいい。むしろ、新しく作り上げる時よりも、慎重に作業をしてもらいたいのである。

応援のクリックお願いします →

※１
全く動かさずに全てのコーディングする人もいるが、個人的にはあまりおすすめしない。

※２
「リファクタリング」はプログラムの動作を変更せずにソースコードを変更すること。

※３
これは、「テスト・ファースト」を導入すれば、改善することが出来る。

■関連記事
・ソースコードの盗み方
・簡単フレームワーク・プログラミングの罠

アンチパターン―ソフトウェア危篤患者の救出

posted with amazlet on 06.04.01

W.J. ブラウン 3,Hays W. McCormick Raphael C. Malveau
Thomas J. Mowbray 岩谷宏(訳)
ソフトバンククリエイティブ (2002/07)
売り上げランキング: 70,471

おすすめ度の平均:

面白くて勉強になります

開発者～管理者まで参考になる

良い本だと思うけど星３つの訳

Amazon.co.jp で詳細を見る

STL―標準テンプレートライブラリによるC++プログラミング第2版

posted with amazlet on 06.04.01

ディビッド・R. マッサーアトゥルサイニギルマー・J. ダージ滝沢徹(訳) 牧野祐子(訳)
ピアソンエデュケーション (2001/12)
売り上げランキング: 29,555

おすすめ度の平均:

文句なしに良書

Amazon.co.jp で詳細を見る

これ、フラグじゃないの？

フラグ（flag）とは旗のことである。プログラミングの世界では、「真」と「偽」のように２つの状態をとるものを、旗の揚げ下げに例えて、フラグと呼んでいる。

プログラム言語によっては、２つの値しか取らない型があり、フラグを変数としたい場合は、その型を使う。例えば、C++ の bool や Java の boolean がそうである（※１）。

　boolean flag = true;

　flag = false;

といった感じだ。

言語に boolean のような２値の型がない場合は、整数型などで代用する。例えば、Ｃ言語がそうだ。この場合、変数に０か１（場合によっては、０か-1）のどちらかの値しか入れない、というルールを決める（※２）。

そして、この場合、その変数がフラグであることが分かるように、変数に flag という名前を付けるのである。

　#define BOOL int

　#define TRUE (1)

　#define FALSE (0)

　

　/* BOOL である flag には TRUE か FALSE しか代入しない */

　BOOL flag = TRUE;

　flag = FALSE;

このような習慣があるので、逆に変数名に flag という名前をつけるのであれば、２つの値しか入れないでほしいのである（※３）。

ソースを読んでいるときに、

　int flag = OK;

　...

　flag = NG;

　...

　flag = ERROR;

とかいう記述が出てくると、あれ？　と思う。これまでフラグだと思って読んでたのに、これ、フラグじゃないの？　ということになってしまう。

心当たりのある方は、以後、気をつけていただきたい。

※１
boolean は「ブーリアン」と読む。たまに「ブーリーン」と読む人がいるが、間違い。

※２
言語に enum という考え方がある場合はそれを使う場合もある。

※３
実際には、「偽と真」は、「０とそれ以外」と定義されることが多い。しかし、それは値を判定をするときの話で、「真」の値を代入する場合は決められた値だけを入れるべきである。また、変数の各ビットをフラグとみなすような場合には、３つ以上の値を代入することになるが、そのような場合には、変数名を工夫をすべきだろう（例えば、「flags」と複数形にするとか）。