【ちゃんなるぶろぐ】社会人1年生が日々の学びをアウトプット!

>>> 読書・遊び・プログラミング・アプリ開発などを通して学んだことを、文章という形で出力 <<<

5分でわかる!「プログラマが知るべき97のこと」その①⑧

読み終えるまで約5分

 

 

どうも、ちゃんなるです! 

今日も”デキる”プログラマになるべく勉強していきましょう!

 

今回は、次の書籍の一部を要約します。

プログラマが知るべき97のこと』

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

今回選択した3つのテーマ

本書はタイトル通り97のことについて書かれています。

今回は、52~54番目の項目についてまとめます。

  1. 「その場しのぎ」が長生きしてしまう(No. 52)
  2. 正しい使い方を簡単に、誤った使い方を困難に(No. 53)
  3. 見えないものを見えるように(No. 54)

 

①「その場しのぎ」が長生きしてしまう

このテーマで述べられていたことは、

「『後』で修正しようと思って行ったその場しのぎは、実際に『後』になると他のタスクをするのに時間を取られてしまい、結局修正されない場合が多い。」

ということです。

 

以下、要約です。

プロジェクトの中で、『暫定ソリューション=その場しのぎ』を作った人は多いでしょう。

なぜ『その場しのぎ』は必要になるのでしょう?

おそらくそれは、「一刻も早く解決しなきゃならない問題があるから」でしょう。

『その場しのぎ』は、その作成時点では、『後で修正する』ことが前提になります。

しかし、その『後で修正する』時は来ないことがほとんどです。

後になると、他の問題の解決に追われるためです。

結果的に、暫定と言いながらいつまでも生き続けるソリューションとなってしまいます。

 

「ソリューションをいったん暫定ソリューションにしてしまうと、後で修正するのが困難になる」ということです。

では、一体どうすればいいのでしょうか?

 

対応は次の3つに大別できます。

  1. 『その場しのぎ』を最初から作らない
  2. 『その場しのぎ』修正の優先度が上がる仕組みを作る。プロジェクトマネージャーが、『その場しのぎ』の問題を認識し、それを優先してなくそうとする体制を取ること。
  3. 現状のまま何も変えない

最初から作らないことは難しく、現状のまま何も変えないこともプロジェクトに進展がないです。

『その場しのぎ』をなくす体制作りは重要ですが、開発規模が大きくなるほど体制を変えるのは至難の業となるでしょう。

 

この状況を変える最善の方法は、暫定ソリューションに修正を加えるのではなく、不要にしてしまうことです。

後から改めて、より優れたソリューション、より有用性の高いソリューションを作るのです。

(本書105ページより)

 

 

②正しい使い方を簡単に、誤った使い方を困難に

このテーマで述べられていたことは、

「不適切な使い方がそもそもできないようにするのが大切。」

ということです。

 

以下、要約です。

インターフェース仕様を決定する作業は、ソフトウェア開発プロジェクトには必ず必要です。

いいインターフェースは、次の2つの条件を満たします。

①正しく使用する方が操作ミスをするより簡単

インターフェースの設計が良ければ、ユーザは、ほぼ間違いなく正しく使用できます。それは、正しい使い方が「一番易しい使い方」になっているからです。

(本書106ページより)

GUIなら、アイコン・ボタン・メニュー項目の位置や表示が適切で、直感的に理解できること。

APIなら、どのパラメータに渡す値も一目でわかること。

正しく使用することが簡単なら、物事は全てスムーズに進みます。

 

②誤った使い方をすることが困難

優れたインターフェースというのは、使う人間がどういう間違いをしそうか、あらかじめ予期した作りになっているものです。そして、そういう誤りが起きにくいよう対策を講じてあります。

(本書106ページより) 

 GUIなら、それをユーザーが実行しても、不適切な処理なら自動的に使用不能になるようになっています。

APIなら、引数をどの順序で指定しても同じ結果が返ってくるようになっています。

誤った操作をしても、誤った結果にならないということです。

 

どうやったら、簡単でミスのしにくいインターフェースを作れるのでしょうか?

それには、「作る前に使ってみる」が有効です。 

GUIなら、紙やホワイトボードでいいのでモックアップを描いてみましょう。

APIなら、そのAPIの関数を定義する前に呼び出しのコードを先に書いてみましょう。

 

使い方を間違えにくいインターフェースを作るには、次の2つの方法が有効です。

  1. ユーザーがしそうな間違いを事前に予測し、それを防止する策を講じること
  2. リリース後の早い時期に実際にインターフェースがどのように誤用されているかを観察し、素早く改良版をリリースすること

観察の結果、取り消し不可能な操作を何度も取り消ししようとしてるユーザが多いなら、取り消し可能にするべきです。

APIに誤った値が渡されることが多いなら、その値を正とするような実装にしてしまうことも手です。

 

インターフェースが存在するのはユーザーのためであり、開発者のためでは決してありませんよ!

 

 

③見えないものを見えるように

このテーマで述べられていたことは、

「ソフトウェア開発を行う際はいつでも、『目に見える要素がたくさんある状態』を維持すべき。」

ということです。

 

以下、要約です。

 

ソフトウェアは、それ自体形がなくて目には見えないものであり、それを開発する過程で何が行われているかも見えにくいものです。

 

プログラムを実行すれば現実世界に物理的な影響を与えることもあるので、その時はプログラム、またそれから作られるソフトウェアの実体を認識できます。

しかし、プログラムを実行したからといってプログラムのソースコードが可視化されるわけではありません。

 

コードの9割が書き終わると、つい「仕事が9割終わった」と考えがちです。

しかし、残り1割のデバッグ作業に時間を取られ、なかなか仕事が終わらないといった経験をした人もいるはずです。

私たちは「目に見えない」漠然としたものが苦手で、そういったものは具体的なものに比べて深く考えない傾向にあります。

もしも存在や変化が目に見えれば、それにうまく対処できるはずです。

 

「目に見える」状態にするための方法には、下記のものがあります。

  • ユニットテストを書く』
    対象のコードのテストが容易か困難かがはっきりと目にみえるようになります。
    また、開発中のコードが持つべき特性を実際に持っているかどうかが明確になります。
    (特性:疎結合性、高凝集性など)
  • ユニットテストを実行する』
    コードの動きが目にみえるようになります。
    定められた使用通りに動くか、エラーや例外によって予期せぬ動作をしない『堅牢性』を持っているかが明確になります。
  • 『プロジェクトの進捗を、掲示板やカードを駆使して可視化する』
    作業一つ一つが「未着手」、「進行中」、「完了」なのかが一目でわかります。
  • 『インクリメンタル開発の手法をとる』
    開発の進捗が目に見えやすくなり、目にみえる成果によってお互いの進捗を確認しやすくなります。

 

ソフトウェア開発を行う際はいつでも、目に見える要素がたくさんあるという状態を維持すべきです。

 

 

まとめ

『その場しのぎ』は想定しているよりも長く生き延びでしまいます!これを忘れずに!

②そもそも間違った使い方ができない仕組み作りをしましょう!

③ソフトウェア開発では『目に見えない』要素が多いが、それを少しでも多く『目に見える』ようにすることが大切!

 

*より深く知りたい方は、ぜひ本書を手にとってみてください!

書籍情報

プログラマが知るべき97のこと [ ケブリン・ヘニー ]

価格:2,090円
(2021/5/13 11:12時点)
感想(1件)

【中古】 プログラマが知るべき97のこと /ケブリンヘニー【編】,和田卓人【監修】,夏目大【訳】 【中古】afb

価格:825円
(2021/5/13 11:12時点)
感想(0件)

【書籍名】プログラマが知るべき97のこと

【著者名】ケブリン・へニー、夏目大(訳)

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ