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

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

3分でわかる!robots.txtとは?

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

今日はrobots.txtについてまとめます。


先日React.jsを学ぶために公式チュートリアルを始めました。アプリの土台を作るためにコマンド(npx create-react-app sample-app: sample-appをアプリ名とする)を叩くと、色々なファイルとともにrobots.txtも生成されました。

「えっ?なにこれ?」となって今に至ります。

robots.txtとは?

これは、検索エンジンのクローラに対して、サイトのどのURLにアクセスして良いかを伝えるものです。

基本的にはクローラのサイトへのトラフィックを管理するために使用しますが、ファイル形式によっては、Googleでファイルを非表示にするために使用することもあります。 サイト上の重要でないページや、類似したページのクロールを回避することにも使用します。

あるウェブページをrobots.txtファイルでブロックしている場合、検索結果にそのウェブページのURLが表示されることはありますが、説明は表示されません。 HTML以外のファイル(画像ファイル、動画ファイル、PDFなど)は除外されます。

検索でページを完全に非表示にする方法は、参考文献その②をどうぞ。

robot.txtの作成方法やその書式に関しては、参考文献その③をどうぞ。

参考文献

『TCP / IP』を大雑把に理解する

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

配属されてはや2ヶ月、やっとエンジニアのひとりとして働く実感を持ちつつあります。

日々、呼吸をしていると意味のわからない言葉に囲まれる、という生活をしています。


今回はそんな言葉の一つ、TCP / IP」についてです。

TCP / IPとは?

TCP / IPとは、世界標準として利用されている通信プロトコルのことです。 インターネット・プロトコル・スイートとも呼ばれます。

TCP / IPにより、機器やOSが異なる端末間でも共通のプロトコルを通じて通信を成立させることができます。

私たちがインターネットでWebページを見るときに利用する通信プロトコルは、TCPとIPです。


TCP (Transmission Control Protocol):的確に信号を送信できる通信の規格を定めたもの

IP (Internet Protocol)IPアドレスと呼ぶ数値情報を用いて通信先の指定、または呼び出しを行ってネットワーク通信を実現すること


TCP / IPは、「アプリケーション層」「トランスポート層」「ネットワーク層」「リンク層」の4つの階層に分かれており、仕様変更があった場合は該当の層のみを改修するような仕組みになっています。

この4つの階層のプロトコルが正常に機能してやっと、通信ができます。

感想・まとめ

今回はざっくりこれだけ。 - TCP / IPは、「通信におけるルール・決まりごと」である。 - TCP / IPは、「アプリケーション層」「トランスポート層」「ネットワーク層」「リンク層」の4つの階層に分かれているらしい。

私はまだTCP / IPという言葉を知っただけで理解できてないので、下記の書籍を買って勉強します!

今後詳細の内容記事を投稿するかもしれません。

参考資料

www.itmanage.co.jp

www.otsuka-shokai.co.jp

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

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

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

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

  1. 並行処理に有効なメッセージパッシング(No. 55)
  2. 未来へのメッセージ(No. 56)
  3. ポリモーフィズムの利用機会を見逃さない(No. 57)

 

①並行処理に有効なメッセージパッシング

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

「共有メモリを使わずメッセージパッシングを使ってプログラミングをすることが、現在のコンピュータハードウェアにはどうしても必要な並行 / 並列処理にとって最も有効な方法である。」

ということです。

 

以下、要約です。

並行処理(特にその一種である並列処理)は、非常に難しいものと考えられています。

また「変数へのスレッドセーフな並行アクセスは難しい」といったこともよく話題になります。

 

この問題の根本は、「共有メモリ」であるという結論に達します。

共有メモリ:色々なプログラムからアクセス可能になっている、メモリ領域のこと)

並行処理に関する問題には、競合状態、デッドロック、ライブロックなどがありますが、そのほとんどが可変メモリの共有に関係しています。

デッドロック:複数の実行中のプログラムが、互いに他のプログラムの結果待ちとなり、待機状態に入ったまま動かなくなる現象のこと

ライブロック:複数の実行中のプログラムが、お互い相手のプログラムを完了させるために待機状態に入ってしまい、その後再開し、またお互いに待機状態に…という無限ループのこと)

 

この問題を避けるには、並行処理、メモリ共有のどちらかをやめましょう

並行処理を止めることはあり得ないでしょう。

なので、メモリ共有をやめましょう

代わりにプロセスメッセージパッシングを使うのです。

(プロセス:ここでは、他から保護され独立した状態の実行コード、という意味)

 

現在システム開発の主流となっているC、C++JavaPythonといった言語はどれも、共有メモリ、マルチスレッドのシステムに対応した言語です。

なので、プロセスモデル、メッセージパッシングに対応したライブラリやフレームワークを利用(なければ作る)ことが重要です。

 

可変メモリの共有をいかに抑えるか、がポイントですね。

 

 

②未来へのメッセージ

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

「自分の書くコードは、全部、未来の誰かへのメッセージだと思うべき。」

ということです。

 

以下、要約です。

「取り組む問題が難しければ、その解決策も難しくてわかりにくいものになる」と考える人が多いでしょう。

問題が難しいから、そのソリューションは難しく、保守も難しいものになって仕方がない、という考えです。

 

しかし、確かに解決策は難しいかもしれませんが、それを『伝わりやすいコードで表現する』ことは可能でしょう。

自分の書いたコードは、それが使われている限り、誰かの目に触れます。

そのため、自分の書くコードは、全部、未来の誰かへのメッセージと思って書くべきなのです。

 

 

ポリモーフィズムの利用機会を見逃さない

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

「コードの中にif-then-elseブロックになっている箇所があるのなら、その全てについてポリモーフィズムが使えないか検討するべき。」

ということです。

 

以下、要約です。

ポリモーフィズムとは、「同じクラスのオブジェクトやメソッドが、複数の形を取り得ること」を意味します。

ポリモーフィズムをうまく活用すると、オブジェクトやメソッドの特性、動きを、コンテキストに応じて細かく変えることができるのです。

さらに、そのために冗長なif-then-elseブロックを書く必要がなくなります。

 

例えば、「商品を物理的、またはダウンロードで配送する」という場合…

ポリモーフィズムではない表現

if (shippingType == .surface) {

    // 物理で配送する処理

} else if (shippingType == .download) {

    // ダウンロードで配送する処理

}

 

ポリモーフィズムの表現

・Itemクラス(正確にはインタフェース)にshipメソッドを呼ぶ処理を委譲する

・物理かダウンロードかは、Itemクラスが決定する

 

public class SurfaceItem implements Item {

    public boolean ship(Shipper shipper, Customer customer) {

       shipper.ship(this, customer.getSurfaceAddress); // 物理で配送する処理

    }

}

 

public class DownloadableItem implements Item {

    public boolean ship(Shipper shipper, Customer customer) {

       shipper.ship(this, customer.getEmailAddress); // ダウンロードで配送する処理

    }

}

 

 

まとめ

①並行処理は重要であるが、それ固有の問題があるのは事実です。これを抑えるために、プロセスやメッセージパッシングを駆使して「可変メモリの共有」を無くしましょう!

②解決策が伝えにくいような難しい問題でも、その解法のプログラムコードを書く際は、相手に伝えることを念頭に置くべきです。

③if-then-elseのあるところをポリモーフィズムに置き換えて、if-then-elseブロックの削減、ひいてはバグ削減可読性向上に努めよう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

 

ポリモーフィズムわからなかった、という人のために

webpia.jp

3分でわかる!プログラミング〜DRY原則について〜

読み終えるまで約3分

 

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

今回はこの本の内容を元に投稿します!

『プリンシプル・オブ・プログラミング』

 

 

*内容は抽象的であり、どう解釈するかは皆さんにお任せします。

 

DRY原則とは

DRY:Don’t Repeat Yourself.(同じことをするな)

 

どういうことか?

『同じロジックを複数箇所に書いてはいけない』

同じ関数・条件文・定数リテラルを複数箇所で書いてる場合は排除しましょう。

 

どうして排除するべきなの?

重複箇所があると、『コードの改善が困難になるから』です。

その理由は主に下記の3つ

  1. コード量が増え、また複雑になり、読みにくくなる
  2. 一つの改善作業のために、複数箇所のコードを修正する必要が出てくる
  3. 重複してる部分はたいていレガシーコード*であり、テストがない

*レガシーコード:テストのないコードのこと

 

DRY原則をどうやって実行するか

『コードを抽象化する』

抽象化:同一処理を関数やモジュールに閉じ込めること、データであれば定数化してそれを使い回すこと

 

抽象化のメリット

  • コード量減少→読む時間短縮
  • ロジックやデータに名前が付き、読みやすくなる
  • コードの修正が容易になり、品質が担保しやすくなる
  • 再利用しやすくなり、新たな機能実装の際に最小限のコード量で要件を記述できる

抽象化のデメリット

  • 時間がかかる
  • デグレード(前より悪くなること)の可能性がある

 

③その他

WET:Write Every Time(同じことがたくさん書かれている)

皮肉にもDRYの対義語として定義されたらしいです笑

(DRY:乾燥してる⇆WET:湿っている)

 

まとめ

DRY原則は、Don't Repeat Yourself(同じことを繰り返すな)ということです。

コーディングの際に、重複する処理があればそれを抽象化し、関数やクラスに切り出すようにしましょう!

 

 

この本から得られるもの

いいコードを書くための『プリンシプル』

(プリンシプルとは原理・原則のことで、これを知ることがプログラマとして成長するための『王道』『近道』である)

 

本書の目的は、『プリンシプル』を通して良いコードを書けるようになることです。

 

『プリンシプル』は抽象的な内容であり、本書にはプログラムコードによる具体例もありません。

そのため、自分なりに内容を咀嚼し、自分なりの具体例を考えようとする姿勢が大切です。

 

 

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

書籍情報 

プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則 [ 上田勲 ]

価格:2,420円
(2021/8/28 14:24時点)
感想(2件)

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則【電子書籍】[ 上田勲 ]

価格:2,178円
(2021/8/28 14:24時点)
感想(1件)

【書籍名】プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

【著者名】上田勲

【出版社】秀和システム

【出版日】2016年3月

【ページ数】303p

 

著者紹介

f:id:Chan-Naru:20210828142858p:plain

著者:上田勲

横浜国立大学経営学部卒。キヤノンITソリューションズ勤務。Webアプリケーション自動生成ツール「Web Performer」の開発に、立ち上げ期より関わる。現在、テクニカルリーダー、スペックリーダー、アーキテクト、デザイナーを担いつつ、自らもプログラミングに携わる

上田勲|プロフィール|HMV&BOOKS onlineより)

 画像は上田勲に関する記事一覧 - ログミーより

3分でわかる!プログラミング〜KISS原則について〜

読み終えるまで約3分

 

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

今回はこの本の内容を元に投稿します!

『プリンシプル・オブ・プログラミング』

 

 

この本から得られるもの

いいコードを書くための『プリンシプル』

(プリンシプルとは原理・原則のことで、これを知ることがプログラマとして成長するための『王道』『近道』である)

 

本書の目的は、『プリンシプル』を通して良いコードを書けるようになることです。

 

『プリンシプル』は抽象的な内容であり、本書にはプログラムコードによる具体例もありません。

そのため、自分なりに内容を咀嚼し、自分なりの具体例を考えようとする姿勢が大切です。

 

 

①KISS原則とは

KISSとは、

Keep It Simple, Stupid.(シンプルにしておけ、愚か者よ。)

または

Keep It Short and Simple.(短くシンプルに保ちなさい。)

です。

 

どういうことか?

コードを書く際に意識する最良の価値を、『単純性』『簡潔性』にしましょう。

 

 

②KISS原則をどうやって実行するか

「コードに余計なことをしない」「同じ動作をするために、もっとシンプルに書くことはできないか?」を考えながらコーディングしましょう

 

新たに覚えた技術が使いたい時でも、闇雲にそれを使ってはいけません。

ユーザーに価値を提供するのがプログラムコードを書く目的であり、その達成のためにシンプルな技術を採用すべきです。


「将来必要そう」と思えるコードは書く必要がなく、今必要なものだけを書くべきです。


要件を決めるのはユーザーで、彼らが定義した要件だけを完璧に満たすような機能を実装すれば良いのです。

 

 

③その他

KISS原則に関連するものとして、下記のものがあります。

  • Less is more:より少ないことは、より豊かなこと
    これはプログラミングに限った話ではありませんね。
    「物や情報に溢れてしまっても対処することが難しいので、必要なものを選別しよう」といったニュアンスです。
    日頃の生活でも意識できるといいでしょう。
  • オッカムの剃刀:「ある事柄を説明するために、必要以上に多くの前提を仮定するべきでない」という考え方です。
    言い換えると、「何かについて説明する方法が複数あるなら、最もシンプルなものが正しい」ということです。

 

 

まとめ

KISS原則は、抽象的で、具体的なコーディング手法を言っているわけではありません。

シンプルに書くことが最良のコードである、という概念です。

 

Simple is the best!!!

を念頭においてプログラムを書きましょう。

 

 

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

書籍情報 

プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則 [ 上田勲 ]

価格:2,420円
(2021/8/28 14:24時点)
感想(2件)

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則【電子書籍】[ 上田勲 ]

価格:2,178円
(2021/8/28 14:24時点)
感想(1件)

【書籍名】プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

【著者名】上田勲

【出版社】秀和システム

【出版日】2016年3月

【ページ数】303p

 

著者紹介

f:id:Chan-Naru:20210828142858p:plain

著者:上田勲

横浜国立大学経営学部卒。キヤノンITソリューションズ勤務。Webアプリケーション自動生成ツール「Web Performer」の開発に、立ち上げ期より関わる。現在、テクニカルリーダー、スペックリーダー、アーキテクト、デザイナーを担いつつ、自らもプログラミングに携わる

上田勲|プロフィール|HMV&BOOKS onlineより)

 画像は上田勲に関する記事一覧 - ログミーより

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ページ

3分でわかる!プログラミングの普遍的な事実

読み終えるまで約3分

 

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

今回の内容は、この本と自分の経験を元に書きます!

『プリンシプル・オブ・プログラミング』

 

 

この本から得られるもの

いいコードを書くための『プリンシプル』

(プリンシプルとは原理・原則のことで、これを知ることがプログラマとして成長するための『王道』『近道』である)

 

本書の目的は、『プリンシプル』を通して良いコードを書けるようになることです。

 

『プリンシプル』は抽象的な内容であり、本書にはプログラムコードによる具体例もありません。

そのため、自分なりに内容を咀嚼し、自分なりの具体例を考えようとする姿勢が大切です。

 

①プログラミングに特効薬はない

 ソフトウェア開発の場では、日々のプログラミングが突如混乱に陥る場合があるが、その際の特効薬がないということ。

 

理由は、ソフトウェアには下記の4つの困難性があること。

  1. 複雑性:開発規模によっては数千、数万行の規模のコードも珍しくない。
    構成要素間の依存関係は、規模が大きくなるほど非線形に増大する。
  2. 同調性:ソフトウェアは、ハードウェア、ネットワーク、他のソフトウェア、人間の行動習慣などの実世界の様々なものと関係を持つ(同調)。
    実世界は困難であるがゆえ、プログラミングも困難であると言える。
  3. 可変性:環境は刻々と変化しており、ユーザーのニーズを満たすためにソフトウェアは常に変化し続けなくてはならない。
  4. 不可視性ソフトウェアは概念の集積であり、製品そのものやプロセス、意思決定の経緯など全体を見ることができない。

 

では、混乱に陥らないようにするには、どうしたらよいのでしょう?

 

ソフトウェア開発の際の偶有的な部分改善することです。

(ここでの偶有的とは、副次的、付随的、を意味する)

 

ソフトウェアの偶有的な部分とは、それがなくてもソフトウェアが成り立つような性質のことです。

例えば、ビルド環境、プログラミング言語、ライブラリ、フレームワークなどが挙げられます。

 

ソフトウェアにおいて偶有的要素はとても重要であり、本質的な開発部分とは対照的に、容易に改善できます。

例えば、適切な言語やライブラリを選択することで生産性が劇的に向上します。

 

偶有部分の改善で、過去大きな実績を上げてきたのが『自動化』です。

テスト、ビルド、環境構築などを『自動化』して、作業の効率や品質が大きく向上しました。

 

偶有的部分を適切に改善することで、私たちのソフトウェア開発における生産性を高めましょう。

 

 

②プログラムコードは設計書である

 システム開発を行う際、設計という工程があります。

設計は、今後システム開発を進めるために重要な計画を立てる工程のことです。

その際に作成されるドキュメントを、設計書と言います。

 

エンジニアにとってプログラムは設計であり、コンパイルやビルドが製造ということになります。

そのため、ソフトウェア開発の中で作成されるあらゆるドキュメントの中で、真にエンジニアリングドキュメントと言えるのがプログラムコードになります。

 

プログラムコードは最重要のドキュメントである、と認識しましょう。

 

 一般的な設計書は、自然言語(私たちが普段使う日本語とか)で書かれています。

しかし、プログラムはプログラミング言語で書かれています。

将来の保守担当者に向けて、プログラムコードというドキュメントをいかに理解しやすいかという視点を意識して書くべきです。

読みやすいコードであること、コメントを適切に記載すること、保守・運用のための手引書を別途用意することなどをしましょう。

 

 

③プログラムコードは必ず変更される

『コードは変更される』という事実を、コードを書く際の様々な『判断』『選択』『決断』において最優先で考慮するべき、ということです。

 

なぜ変更を余儀なくされるのか?

それは、そのコードで作っているソフトウェアを使うユーザーがおり、そのユーザーの要求はいつ何時も変化し、その変化した要求に対応するためです。

 

必ず変更されるということは、変更に強いコードを書けばいいのです。

変更に強いコードに必要な要素はいくつかありますが、『コードは書いてる時間よりも読まれる時間の方が長い』という点で、読みやすいコードを書くべきです。

 

読みやすいコードを書くには知識や経験が必要になり、時間もかかります。

ですが、変更されるという前提に立つと、『書くのにどれだけ時間がかかっても、読む時間を短縮できるなら十分に元を取ることができる』と言えるでしょう。

 

 

まとめ

下記の3つのポイントを紹介しました!

  1. プログラミングに、「これさえやればOK」という特効薬はなく、さまざまな要素を考慮して取り組むべきである。そのため、適切な技術の選択や、要素の自動化などを駆使するべきである。
  2. 将来の保守担当者に向けてプログラムコードを書くべきである。
    コードは私たちプログラマにとっての設計書である。
  3. コードは必ず変更されるので、変更に強いコードを書くべきである。

 

感想:

私も、いいコードを書くために日々試行錯誤をしています、、、難しい。

いいコードを書くための具体的な要素については、下記の書籍をおすすめします!面白く具体的なので、すぐに真似して実践できる内容でした!

 

 

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

書籍情報 

プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則 [ 上田勲 ]

価格:2,420円
(2021/8/28 14:24時点)
感想(2件)

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則【電子書籍】[ 上田勲 ]

価格:2,178円
(2021/8/28 14:24時点)
感想(1件)

【書籍名】プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

【著者名】上田勲

【出版社】秀和システム

【出版日】2016年3月

【ページ数】303p

 

著者紹介

f:id:Chan-Naru:20210828142858p:plain

著者:上田勲

横浜国立大学経営学部卒。キヤノンITソリューションズ勤務。Webアプリケーション自動生成ツール「Web Performer」の開発に、立ち上げ期より関わる。現在、テクニカルリーダー、スペックリーダー、アーキテクト、デザイナーを担いつつ、自らもプログラミングに携わる

上田勲|プロフィール|HMV&BOOKS onlineより)

 画像は上田勲に関する記事一覧 - ログミーより