表示順
様々な言語をベースとしてオブジェクト指向を説明している。
入門と銘打っているだけあって、内容は比較的簡単であるが、
プログラミング言語ベースで話が展開されてしまうため、
オブジェクト指向の本質とも言える、設計手法についてあまり触れられていなかったのが残念。
「プログラミング言語でオブジェクト指向チックに書くとこんな感じ〜」
っていう印象です。
個人的な内容としては正直物足りなさがある。
コマンドラインでのデバッグとGUIでのデバッグ技法についてまとめられた本。
GDBでの設定をDDDやEclipceでやった場合は？
という感じの書き味である。
GDBはマニュアルを読めば良いのですが、取っ掛かりがないと難しいかと思うので初めてコマンドラインでデバッグを行う人であれば良いかと思います。
IDEでのデバッグは何を今更って感じもあるのですが、ちょっと複雑なことをやろうとすると大変かもしれませんね。
例えば、リモートで動作しているアプリケーションにアタッチしてデバッグを行うとか。
Eclipseであればgdbserverと連携してリモートデバッグ可能です。
遠隔地で作業している人のアプリケーションをのっとってデバッグするのをGUIでやろうとすると
ちょっと大変ですね。CUIであればsshあたりで裏から入ったら、あとはプロセスにアタッチしてカリカリとデバッグできますが。
なので、私はGUIが嫌(ry
ゲフンゲフン
本書で数行だけ紹介されていたcgdbは使い勝手のよいCUIベースのフロントエンドです。
最近はvimgdbでデバッグするので…使うことが少ないですが。
デザインという分野ではかなり知られた書籍である。
まず、良いデザインとは何だろうか？
こんな言葉を聞いたことがないか？
「私は機械音痴だから・・・」
・・・果たして、これは本当にその人だけの問題なのでしょうか？
実はデザインのせいかもしれません。
「直感的ではないデザインは人を混乱させて、エンドユーザに遠慮させるきっかけすら与えてしまう」
本書の中では電話のボタン（数字）の並びや文字を例に上げている。
「電話本体の周りに文字が記載されていたら・・・」
「使われていないボタンがあったら・・・」
「何を行うか分からないロゴのボタンがそこにあったら・・・」
などなど。
身近にあるものだけではない、
デザインでの失敗は
本書ではスリーマイルの原発事故はデザインにも問題があったということが記載されている。
スリーマイルの事故では現場の作業員が危険を察知して、
停止（だったか忘れてしまったが）ボタンを押した時にランプが点灯した。作業員は安心したが
事故が起きた。ランプの点灯は停止が正常に完了したことではなく、停止ボタンが押されたことを示すランプであり、
実際は停止処理は動作していなかった。
デザインが人へ与える影響は絶大である。
配置、配色、ロゴ、動作。
アプリケーションや産業機器、家具等のデザインを行う時に
ユーザビリティを意識したデザインとは何か？という部分のスタートラインとして立つには
古いが非常に良い書籍である。
著者はサックス奏者からプログラマへ転身したという変わった経歴の持ち主。
そんな著者がプログラマへ贈る本。
そんな中でも心に残ったセリフは
「自分が一番下手でいられる環境へ常に身を置け」という言葉である。
一番下手であるということはそこが底辺であり後は上に上がるしかない。
そしてレベルの高いところに身を置くことで周りから吸収できる情報量も増えるということである。
また、もうひとつ気に入っている言葉は「保守、運用」という業務に腐っているのではなく、
むしろチャンスだと思ったほうが良いということ。保守、運用は既に動いているアプリケーションへの対応である。
その中で「更に良くする方法が無いのか？」ということを考えることができる。もっといわば「自分の思った通りの運用に作り変えることができる」
顧客有りきであることはあるが、そこには提案もできる。動いているソフトウェアを更に良くすることもできる。
自身はこの本を読んで積極的に海外のコミュニティにて情報収集を行うようになった。
IEEEコンピュータ学会への参加もその一つである。レベルの高いエンジニアの会話やソースコードはそれだけで自分の血となり、肉となる。
プログラミング初心者にはおすすめの一冊♪
2012-12-13 15:25:38基本的にはプログラミング作法だったり、コードコンプリートの抜粋っていう印象を受けるが、
とっつきやすさという面では非常に良かった
例えば、
変数名の付け方
関数名の付け方
モジュール・クラス・関数の分割
スコープ
等、
メンテナンスしやすいコードを書くためには当たり前の技術ですが
プログラムを初めて間もない方が読むと良い指針になるかと思います。
この本を読んだ後にコードコンプリートを読むとより理解が深まりますね。
何かの文献で読んだ言葉を引用すると、
「コメントアウトを書かなければならないコードは書きなおしたほうが良い」
つまりは、変数名、関数名、クラス名自身が意味を持っているのであれば、
コメントアウトはこれらからだいたい想像ができる。
例：
bool flg = false;
と書くくらいであれば
bool isExist = false;
のほうが明瞭だし、
for(int i = 0 ; i < 100 ; i )
とするくらいであれば
static const int STORAGE_MAX_COUNT = 100;
for( storageCount = 0 ; storageCount < STORAGE_MAX_COUNT ; storageCount )
にすれば良いし、もっと抽象的にするなら
List<Storage*> storageList = StorageContainer.getAvailableStorageList();
for( List<Storage*>::Iterator stIte = storageList.begin() ; stIte != storageList.end() ; stIte)
とIteratorを利用して有効なストレージの数分だけループさせたほうが100回ループさせるよりも安全だし、処理の少なくすむ。
仮に100が200に増えようとも修正が必要ない。上のはIteratorでしたがforeachのほうがメジャーかもしれませんね。
小さなことかもしれませんが、柔軟なコードとは変更に強く、明瞭なコードです。
そのことを再認識させてもらっただけでも非常にありがたいです。