捨てるべきときには潔く

「このソースコード、どうしてこんな変な作り方してるの？」
「途中で仕様変更が入ったので、設計方針が変わってしまって...」

★
システム開発では、突然、仕様が変更されるようなことは日常茶飯事である。設計が終り、プログラミングが終り、テストが終わっていても、お構いなしである。

仕様変更が発生すると、それまで作っていたプログラムを修正しなければならなくなる。場合によっては、自分の作成していた機能を全て破棄して、作り直さなければならないようなこともあるだろう。

時間をかけて作ってきたプログラムを破棄することは難しいことである。スケジュール的な面で難しいのはもちろんのこと、心理的な意味でも難しい。

自分の作ったプログラムには愛着が出てくるものだ。それを破棄するのは忍びない。それに、今までの作業時間がもったいないし、最初から作り直すのも面倒なことだ。

そんな時、これまでに作ったプログラムをなるべく変更せずになんとかできないか？　などと考え、「後つけ」の改造を行ってしまいがちだ。

しかし、そのような後つけの改造を行ったために、ソースコードが不自然な構造となってしまうようなことがよくある。愛すべきソースコードが、イビツで読みにくく、保守しにくいものになってしまうのである。

★
仕様変更が発生したとき、既存のプログラムを改造すべきか、作り直すべきかは状況次第である。もちろん、改造したほうが良い場合もある。作り直す時間がなくて、やむをえず改造を行う場合もあるだろう。

しかし、客観的に考えて、作り直したほうがよいと判断され、その余裕もあるのなら、迷わずにそうしよう。今までのソースコードを無理に生かすよりは、潔く破棄したほうが、後々のためである。

自分の書いたコードに執着しすぎないことも、職業プログラマとして必要な条件なのである。

プログラムの育てかた現場で使えるリファクタリング入門

posted with amazlet on 06.04.16

長谷川裕一斎川博史
ソフトバンククリエイティブ (2005/02/01)
売り上げランキング: 176,298

おすすめ度の平均:

リファクタリングについて楽しく学べる

入門書として最適

初心者向けなのに初心者には見せられない・・・

Amazon.co.jp で詳細を見る

プレファクタリング―リファクタリング軽減のための新設計

posted with amazlet on 06.04.16

ケンパーク
オライリージャパン (2006/01)

Amazon.co.jp で詳細を見る

お互いに知り合いでないこと

次は、あるシステムの設計書の一部を要約したものである。

データベースに登録されている商品の名前を表形式で表示する「一覧画面」と、その中から選ばれた１つの商品について、詳細な情報を表示する「詳細画面」がある。

一覧画面
・画面を開くときの処理
　データベースから全ての商品の ID と名称を取得し、表形式で表示する。
・一覧の行がダブルクリックされたときの処理
　「詳細画面」を開く。

詳細画面
・画面を開くときの処理
　「一覧画面」から、ダブルクリックされた行の ID を取得する。
　その ID をキーにして、データベースからその商品の詳細情報を検索し、表示する。

ここで、詳細画面と一覧画面の関係に注目してほしい。何か変な感じがしないだろうか？

一覧画面は、詳細画面を開いている。言い換えると、一覧画面は詳細画面のことを「知っている」。一方、詳細画面も、一覧画面から ID を取得しているのだから、一覧画面のことを「知っている」ということになる。つまり、一覧画面と詳細画面は、お互いに「知り合い」だということになる。

日常的な感覚では、こうした関係は何もおかしくない。しかし、システム設計という視点から見ると、このような関係は好ましくないのだ。

★
結論から言えば、このような「知っている」という関係は、できる限り一方通行にすべきである。

上記のような、いわゆる親画面（開く側）と子画面（開かれる側）の関係では、「親画面は子画面のことを知っているが、子画面は親画面のことを知らない」という関係にするのが一般的だ。

詳細画面に必要な機能は、「ID に該当する商品の詳細情報を表示する」ということである。「一覧画面から開かれる」という前提は全く必要ない。

例えば、将来、「在庫管理画面」だとか、「見積書作成画面」といった他の画面を作ることになったとしよう。そうした場合、それらの画面からも、「詳細画面」を開きたくなるのではないだろうか？　しかし、上記のような設計では、詳細画面は一覧画面以外の画面からは開くことが出来ない。つまり、再利用できない画面になってしまう。

また、このような「知り合い」関係があると、プログラミングを行う場合にも問題が発生する。この設計書をそのままの形でプログラミングしようとすると、ソースが「循環依存」してしまうのだ。循環依存とは、「A を作るには B が必要だが、B を作るには A が必要だ」ということである（※１）。いったい A と B のどっちから作ったらいいのだろうか？

循環依存に寛容なプログラミング言語もあるし、循環依存を回避するテクニックもある。また、理由があって、あえて循環依存させるような設計をすることもある。しかし、積極的にそうすべき理由がないのであれば、循環依存するような設計は避けるべきである。

こうした考え方が当てはまるのは、ここで上げたような「画面」同士の関係だけではない。関数やクラス、パッケージやライブラリなど、プログラムを構成する要素は小さな単位から大きな単位までいろいろとあるが、どこにでも当てはまるのである。

★
さて、詳細画面と一覧画面を「知らない」という設計にしようと思うと、詳細画面の設計書に「一覧画面」という言葉は出てきてはならないということになる。つまり、冒頭の設計書はこうなるだろう。

一覧画面
・画面を開くときの処理
　データベースから全ての商品の ID と名称を取得し、表形式で表示する。
・一覧の行がダブルクリックされたときの処理
　ダブルクリックされた行の ID を渡して、「詳細画面」を開く。

詳細画面
・画面を開くときの処理
　呼び出し元から渡された ID をキーにして、データベースから商品の詳細情報を検索し、表示する。

※１
A が B を必要とし、B が C を必要とし、C が A を必要とするというように、３つ以上の機能が循環することもある。

■関連記事
・オブジェクトの気持ち

Head Firstデザインパターン
―頭とからだで覚えるデザインパターンの基本

posted with amazlet on 06.04.16

エリックフリーマンキャシーシエラエリザベスフリーマンバートベイツ
オライリージャパン (2005/12)

Amazon.co.jp で詳細を見る

C言語関数の使い方+作り方完全制覇

posted with amazlet on 06.04.16

柏原正三
技術評論社 (2001/09)
売り上げランキング: 70,338

おすすめ度の平均:

関数について学ぶならこの本！

Amazon.co.jp で詳細を見る

もしも君がプログラマなら、英語のソフトも使えるはずだ

eclipse という開発環境（開発者向けのアプリケーション・ソフト）がある。このソフトは、まず英語版が公開され、日本語対応版は遅れて公開されることが多い。

しばらく前のことになるが、同じ開発プロジェクトのメンバーが、eclipse の古いバージョンのものを使っていたので、新しくしてはどうか、という話をしたことがある。

「そのバージョンはまだ日本語対応していないから使いません」

との答え（※１）。

まったく予想していなかった答えだったので、驚いた。

★
彼は日本人だから、その答え自体が意外だというわけではない。私が驚いたのは、私自身が、自分で使っているにもかかわらず、新しい eclipse が英語版であるという意識がなかったということだ。

私は以前から eclipse をずっと英語のまま使っていたので、メニューやダイアログの説明（ラベル）の意味もすっかり覚えてしまい、それらが外国語で書かれているという感覚がなくなってしまっていたのである。

アプリケーションのメニューを選択するとき、そこに書かれている単語を毎回「読む」わけではない。それが何をするメニューであるかが識別できればよいわけだ。使い込んでいるうちに、それが日本語であるか英語であるかということなどは、どうでもよくなってしまったのだろう。

★
誤解のないように言っておくが、私も英語は苦手である。全く喋れないし、ほとんど聞き取れないし、書けない。時間と辞書があれば、なんとか読むことは出来るが、結局意味が分からないことも多い。

しかし、英語のアプリケーションを使うだけであれば、そのような英語のスキルは、ほとんど必要ないのである。

アプリケーションのメニューやダイアログのラベルに書いてある「英単語」の意味が分かればそれでいいからだ（※２）。その程度であれば、一度調べれば、だいたい覚えられるはずだ。

また、プログラマ向けのアプリケーションでは、英単語といっても、日頃からカタカナで使っている業界用語が、そのまま英語表記になっているだけのものも多く、新しく覚えるべき単語は意外と少ないものである。

★
そもそも、アプリケーションのメニューに登場する程度の英単語が覚えられないような人は、プログラミング用語も覚えられないのではないだろうか。プログラミング言語に登場する単語は、ほとんどの場合、英語だからだ。

逆に言えば、プログラマとして立派に仕事が出来ている人であれば、英語のアプリケーションを使うことができるはずである。

問題は、それを使おうという姿勢があるかどうかということなのだろう。

※１
eclipse は、英語版でも、日本語のデータ（ソースコードなど）は編集することができる。ここでは、eclipse のメニューなど（ユーザー・インターフェース）が英語であることを言っている。ただし、アプリケーションによっては、日本語のデータが扱えない場合もあるので、注意が必要。

※２
英語のソフトはマニュアルや「ヘルプ」も英語だろうと心配される方もあるかもしれない。しかし、プログラマの多くは、アプリケーションのマニュアルや「ヘルプ」は読まないので、日本語だろうが、英語だろうが関係ないのである（･･･俺は読むぞ、という人がいたらごめんなさい）。

90分で学べるSEの英語力

posted with amazlet on 06.04.16

小坂貴志
日経BP社 (2005/06/02)
売り上げランキング: 38,597

Amazon.co.jp で詳細を見る

コンピュータ英語情報辞典

posted with amazlet on 06.04.16

朝尾幸次郎
研究社 (2001/09)
売り上げランキング: 81,914

おすすめ度の平均:

発見がいっぱいの辞典

Amazon.co.jp で詳細を見る

回線が遅いとプログラムは意外と大変

今週の "IT" のトラックバックテーマは「光ファイバー VS ADSL 頂上決戦」。光のほうがよいのは確かだが、導入するかどうかは、費用対効果の問題もある。また、当然だが、開通していない地域では利用することができない。単に変更するのが面倒だという理由で乗り換えをしない人もいる。

これは光と ADSL だけの問題でないだろう。同様な理由から、未だに ISDN やダイアルアップを使っている環境もある。携帯や PHS からの接続なども考えると、非常に多くの接続環境が存在していることになる。

★
インターネットを通じてデータを送受信するようなアプリケーション（プログラム）を作る場合、接続の仕方が違うこと自体はあまり関係ない。接続方法の違いは、基本ソフト（例えば、Windows のような OS）が吸収してくれるため、光ファイバーでもダイアルアップでも、同じようにプログラミングすることができる（※１）。

しかし、通信速度が違うということが、問題となる場合がある。同じプログラムを使うにしても、速い回線と遅い回線では、ユーザーの通信中の待ち時間に大きな差が出てしまうからだ。

大量のデータを送受信するようなプログラムでは、遅い回線での待ち時間が非常に長くなってしまい、使い勝手が悪くなってしまう。このため、プログラムには、待ち時間を少しでも短くするための工夫をしなければならなくなる。具体的には、送受信データを圧縮したり、キャッシュ機能（※２）をつけたり、非同期通信（※３）を行ったり、といったことが行われる。

こうした機能を追加すれば、プログラムは複雑化する。当然、開発工数も増加する。開発に必要なコストが高くなるわけである。

また、データの圧縮や非同期通信といった「工夫」は、通信回線の遅さを別の処理で肩代わりすることでもあるため、コンピュータに高い性能が必要とされる。コンピュータの性能があまりに低い場合には、逆に待ち時間が長くなってしまうだろう。しかし、遅い回線を使っているような環境では、コンピュータの性能が低い場合が多く、プログラムにこのあたりの「工夫」を施すかどうか、ジレンマになることもある。

★
このように、プログラムを開発する立場からすれば、接続方法が色々あるということは、悩ましいものである。というわけで、低速回線のユーザーから通信の待ち時間が長いというクレームが入ったときなどは、とりあえず回線速度を上げてくれ、と真に願うのである。

※１
ただし、ダイアルアップ接続環境では、アプリケーションに、電話を掛けたり切断したりする処理を作成する場合もある（プロバイダの課金を少なくするために、接続時間をなるべく短くしたいような場合）。

※２　キャッシュ
　一度受信したデータを繰り返し受信しないようにする仕組み。

※３　非同期通信
　通信中にユーザーが他の作業を行うことができるようにすること。

ネットワークの教科書 2006年版

posted with amazlet on 06.04.16

月刊NETWORKWORLD特別編集
IDGジャパン (2006/03/03)

Amazon.co.jp で詳細を見る

Javaネットワークプログラミング第2版

posted with amazlet on 06.04.16

エリオット・ラスティハロルド Elliotte Rusty Harold 戸松豊和田和勝
オライリー・ジャパン (2001/10)
売り上げランキング: 153,540

おすすめ度の平均:

ちょっと古い

そこそこでした。

Javaでネットワークプログラムを書くための参考書

Amazon.co.jp で詳細を見る

プログラミングのおまじない

コンピュータには不似合いと思われるかも知れないが、「おまじない」というコンピュータ用語（？）がある。この言葉は、初心者にプログラミングを教えるような場合に使われることが多い。

例えば、Ｃ言語の入門プログラム（ソースコード）の最初に出てくる、

　#include <stdio.h>

という１行などは、典型的な例だろう。

このプログラムを初心者に説明する場合、

「１行目の "#include" ナントカというのは、プログラムを動かすためのおまじないだと思ってください。とりあえず、この行は無視して、次の行を見てください...」

といった感じで進めて行く場合も多いと思う。

つまり、「おまじない」とは、ソースコードの中で、説明したくない記述をうやむやにするときに使われる言葉である。

プログラムの処理の説明をする上で、その行にそれほど重要な意味があるというわけではない。しかし、その行を書かないとプログラムが作れない。とりあえず、意味が分からなくても、その通りに書いてくれ。そういった意味で「おまじない」と呼んでいるのだろう。

なぜ、説明をうやむやにするのか？　それは、初心者に説明するにはレベルが高すぎるためである。また、説明すると話が長くなりすぎて、本筋が見えなくなったりするということもあるだろう。

★
会社の研修のような限られた期間の中では、「おまじない」の正体について、最後まで解き明かされずに終わってしまうことも多い。

だからといって、勘違いしてはいけない。「おまじない」は、決して理解しなくてもよいというわけではない。初心者のレベルに合わせて、説明が棚上げにされているというだけであって、プログラミングをする上で、決して不要な知識だというわけではないのだ。

つまり、自分が受けた研修中に教わらなかったとしても、いつかは自分で勉強して、理解しなければならない事柄なのである。

逆に言えば、「おまじない」の真の意味が理解できるかどうか、ということは、初心者のレベルを脱出できたかどうかのひとつの試金石になるだろう。

■関連記事
・簡単フレームワーク・プログラミングの罠