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

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

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

 

chan-naru.hatenablog.com

 

 

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

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

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

  1. API設計の黄金律(No. 34)
  2. 超人の神話(No. 35)
  3. ハードワークは報われない(No. 36)

 

API設計の黄金律

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

APIを提供するときは、API自身のテストだけでなく、『APIを利用するコードのユニットテストも書く』。これを黄金律にするべし!」

ということです。

 

以下、要約です。

 

APIの設計は、特にその規模が大きいときに困難になります。

将来API変更を加えた際の影響について考慮する必要があるからです。

 

またその一方で、APIユーザがAPI開発側に与える影響についても考慮する必要があります。

例えば、ユーザがAPIのクラスを継承してサブクラスを作り、メソッドをオーバーライドする場合があるということです。

こうなると、API開発側は、そのメソッドに変更を加えることができなくなります。

 

このようにユーザの使い方によって、その後の開発側の内部実装に制約が加えられてしまうことがあるのです。

 

これを防ぐ方法の一つには、APIクラスをオーバーライドできないようにすることがあります。(Javaだとfinal宣言、C#だとsealed宣言など)

 

 

昨今、開発作業におけるユニットテストの重要性が高まっています。

上記のようにオーバーライドできないAPIを提供すると、APIになりすます方法がないためユニットテストが難しくなります。

「自分のコードがAPIクラスとどういうやりとりをしているか」、「テストに必要なAPIからの戻り値」がわからないとなりかねません。

 

このような状況が起きないように、APIを提供するときは、APIを利用するコードのユニットテストも書いておくようにしよう!

これにより、APIの利用者がユニットテストに際してどのような問題に直面するかを事前に検知できるのです。

 

 

②超人の神話

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

「『超人』と思われている技術者も人間であり、詳細な情報を与えられないと問題解決はできない。『超人』に聞けばすぐになんでも解決するとは思うな!」

ということです。

 

以下、要約です。

ソフトウェア業界で働く人なら、こんな質問受けたことはありませんか?

 

「○○○という例外が発生したんですが、何が問題なのでしょうか?」

 

質問をした人が、スタックトレースやエラーログを提示してくれたり、問題の起きた状況を詳細に説明してくれることなく、ただ質問だけ投げてくる場合が多々あります。

 

こんなとき、質問に適切に答えられるでしょうか?

一部のエキスパートや同じエラーに直面したことのある人を除き、答えられないでしょう。

 

多くの人が、情報や資料を持たない人に対して質問をし、まともな答えが返ってくることを期待してしまうのです。

『超人(身近な優秀な人)』に聞けば、すぐに解決する、と思っている人が多いのです。

しかし、『超人』も人間であり、適切な情報と知識がなければ返答できないでしょう。

 

 

『超人』は神話である。

エラーやバグで困って質問をする際は、その状況を事細かに説明する

これらを心がけましょう!

 

 

③ハードワークは報われない

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

「長時間働くことは、プログラマにとっては非効率であり、会社への貢献も薄い。仕事のできる人ほど働く時間が短いのが真のプログラマである。」

ということです。

 

以下、要約です。

 

長時間働いていると自分がプロジェクトに貢献しているような錯覚に陥る場合があります。

また、そのような人を見て「あいつは頑張っている!」と評価する人もいます。

しかし、彼らは本当にプロジェクトに貢献しているのでしょうか? 

 

 

プログラミング、ソフトウェア開発という仕事の特徴として、次のものがあります。

 

『取り組みながら絶えず学ぶことができる仕事である』

 

仕事をするほど問題領域についての理解は深まり、同じ目的を達成するために必要な労力、時間は減っていくのです。 

 

ただ、闇雲に働き続ければ仕事が効率化されるわけではなく、仕事が効率化されるように自己研鑽をし続ける必要があります。

そしてそれは仕事以外の時間で行うことが多いでしょう。

 

毎日夜まで残業し、休日出勤もバンバンする。

これでは仕事以外の時間なくなるはずです。

 

 

仕事には長い時間をかけず、集中して短時間で終わらせることを目指す。

より効率の良い働き方を常に探し続ける。

プロジェクトに貢献するとはそのようなことでしょう!

 

 

まとめ

APIを提供するときは、APIを利用するコードのユニットテストも書いておこう!

 

②質問をする際は、その質問の背景・理由・状況を丁寧に伝えましょうね!

 

③常に仕事を効率化して早く終わらせられるように試行錯誤しましょう!

これがプロジェクトに貢献することに繋がります!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

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

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

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

  1. 状態だけでなく「ふるまい」もカプセル化する(No. 31)
  2. 浮動小数点数は実数ではない(No. 32)
  3. オープンソースプロジェクトで夢を実現する(No. 33)

 

①状態だけでなく「ふるまい」もカプセル化する

 

*このテーマの内容は抽象的で難しいと感じたため、別途解説記事を投稿する予定mm

 

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

「状態だけカプセル化しても、振る舞いをカプセル化できていなければオブジェクト指向をうまくいかせてない!振る舞いのカプセル化を忘れずに!。」

ということです。

 

まず、カプセル化とは、『あるオブジェクトの情報(変数や関数のこと)を、外部から直接アクセスできないようにすること』です。

 

状態は変数を、ふるまいは関数を表します。

外部からアクセスできないようにするとは、プライベート変数やプライベート関数にすること、と理解するといいと思います。

 

状態のカプセル化とは、例えばProductクラスのprice変数をプライベート変数として用意することです。

priceの値を変更するには別途、setPrice関数を用意してその中で行いましょう。

 

priceをカプセル化することのメリットは主に2つあります。

①priceの値を外部から変更できなくすることで、誤った値を代入するバグがなくなる

②setPrice関数内で値のバリデーションなどを行うことにより、誤った値がprice変数に入るリスクを減らせる、かつバリデーションをProductクラスの外部で行う必要がなくなる

 

カプセル化予期せぬバグをなくし、あるオブジェクトに関する処理はそのオブジェクトのクラス内で完結させられるのです!

 

 

浮動小数点数は実数ではない

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

浮動小数点数は厳密な実数と違って誤差が出る。これを踏まえた上で活用すべき!」

ということです。

 

以下、要約です。

浮動小数点数は、言語によっては『実数』と表現されるが、厳密には『実数』ではない

実数は『桁落ち』がなく、精度が無限である。

しかし浮動小数点数の精度は有限である。

 

たとえば、「2147483647」という数(符号付き32ビット整数の最大値)を、32ビットの浮動小数点型変数(仮にxとします)に代入し、xの値を出力したとします。すると、その結果は「2147483648」となります。x-64を出力しても、結果はやはり「2147483648」になり、x-65を出力すると、結果は何と「21483520」になってしまいます。なぜでしょうか?

 それは、この範囲では、数の間隔が「128」になっていて、浮動小数点数の演算では、最も近い数値への「丸め」が行われるためです。

(本書64ページより)

 

浮動小数点数は実数の近似値、と認識しましょう。 

誤差が生じることは避けられないと思ってください。

 

もしあなたが金融関係のアプリケーションを開発することになった場合、少しの誤差が大きな問題になり得る場合があるため、浮動小数点数は使うべきではありません。

 

浮動小数点数を使うときは、『どんな時に丸め誤差が出るか』を知り、それを踏まえた上で活用しましょう!

 

 

オープンソースプロジェクトで夢を実現する

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

「大きなプロジェクトに関わりたい!GoogleAppleのような大企業の開発するソフトに貢献したい!という夢を、オープンソースプロジェクトで叶えよう。」

ということです。

 

以下、要約です。

仕事でソフトウェア開発している人は多いでしょう。

しかし、自分の希望通りのソフトウェアを開発している人は少ないでしょう。

 

あなたは次のような夢を持っていませんか?

  • GoogleAppleMicrosoftなどで働いてみたい!
  • 次世代の中心を担うような斬新なソフトウェアを作ってみたい!
  • 超有名なライブラリのコントリビュータとなり、ドヤ顔で街を歩きたい!

そして、夢はあるけど今は別の仕事をしていませんか?

 

この夢の実現に近づく方法があります。

それは、オープンソースプロジェクトに参加する』ことです。

 

参加するにあたって注意することがあります。

  • 自分の時間を無償で提供しなければならない
  • 自分の頑張りが受け入れられるとは限らない

ですが、次のようなメリットは得られるでしょう。

  • ハイレベルな既存のコードやコントリビュータに触れ、知識を吸収することができる
  • 大好きなプロジェクトに貢献しているので、喜びを感じられる
  • 何かしら貢献できれば、それが自分の功績になる

 

その気があればぜひオープンソースプロジェクトに貢献してみてはいかがでしょうか!

 

OSSに貢献する方法は↓の記事でわかりやすく書かれていました。

qiita.com

 

 

まとめ

オブジェクト指向開発のメリットを活かすカプセル化を活用しよう!

そのときは状態だけでなく『ふるまい』もカプセル化することを忘れずに!

 

浮動小数点数は誤差を生む

どんなときに誤差が出るかを調べ、それを踏まえた上で活用しましょう!

 

③「イケてるプロジェクトを開発したい!」という夢は、オープンソースプロジェクトに貢献することで実現しましょう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

 

***参考資料***

jpazamu.com

xtech.nikkei.com

 

3分でわかる!『GRIT やり抜く力』

読み終えるまで約3分

*注意:途中のテストを含めると、3分を大幅に超えますmm

 

 

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

今回紹介するのはこの本!

『GRIT やり抜く力』

 

あなたの身近に『天才』だと思う人はいますか?

確かに、『天才』って響きはかっこいいし、正直憧れます。

 

でも自分にはそんな恵まれた才能はない。

じゃあ、自分は成功できないのか…

 

そんなことありません。

たとえ『天才』でなくても、成功することはできるのです!

この本から得られるもの

正しく努力を行い、成功する方法

 

『努力』『天才』を上回ることができる!

これが科学的に証明された!

 

この本の3つの要点

①成功には『才能』よりも『GRIT』が必要

②『GRIT=やり抜く力』とは?

③『GRIT』の伸ばし方

 

 

①成功には『才能』よりも『GRIT』が必要

結論、

才能<やり抜く力

 

著者が米国陸軍士官学校の生徒に調査をした結果、厳しい試験にくぐり抜け無事卒業をした人は『やり抜く力』があったことがわかりました。

 

この学校にはまず全米から数万人が志望し、あらゆる試験をくぐり抜けた1000人程度の生徒が入学を許されます。

試験は勉強だけでなく、部活動の成績や身体能力、筋力なども考慮されます。

 

しかし、やっとの思いで入学しても最初の7日間で5人に1人やめてしまいます…

確かに、最初の7日間は『ビースト』と呼ばれる最も過酷な訓練があるそうですが、、、2年以上かけて準備してやっと入学できたのになぜでしょうか?

 

著者はここに着目し、「退学する人と卒業する人は何が違うのか」を調査しました。

普通に考えると入学試験の成績がいい(能力の高い)生徒の方が最後まで頑張りそうです。

しかし、身体能力や知能が高くとも途中で脱落する人もいるし、能力が低くても最後までやり切った人がいたのです。

調査の結果、能力の高さよりも『情熱』『粘り強さ』を持って最後まで諦めないことが重要であるという結論になりました。

 

 

私たちは『才能』に惹かれます。

何かすごい功績を収めた人や、能力の高い人を見ては、「あいつには才能がある」思ってません?

 

ここで、哲学者ニーチェの思考をかります。

天才は神がかった存在だと思えば、それに比べて自分が引け目を感じる必要がありません。

「あの人は超人的だ」=「張り合っても仕方ない」

能力の高い人を神格化してしまった方が楽なのです。

「あいつは天才だ」と思えば、その人が裏で重ねている努力を見る必要がなくなるのです。

 

 

②『GRIT=やり抜く力』とは?

GRIT(やり抜く力)とは、最後まで諦めず1つのことに向き合う力です。

なかなか計るのが難しい能力ですが、著者は『グリット・スケール』というテストを作りました。

 

以下の10個の問題に回答し、平均点を出してみましょう!

質問 全く当てはまらない - 非常に当てはまる

①新しいアイデアやプロジェクトが出てくると、

ついそちらに気を取られてしまう

 5点 ←→  1点

②私は挫折をしてもめげない。

簡単には諦めない

 1点 ←→  5点

③目標を設定しても、

すぐ別の目標に乗り換えることが多い

 5点 ←→  1点
④私は努力家だ  1点 ←→  5点

⑤達成まで何ヶ月もかかることに、

ずっと集中して取り組むことがなかなかできない

 5点 ←→  1点
⑥いちど始めたことは、必ずやり遂げる  1点 ←→  5点
⑦興味の対象が毎年のように変わる  5点 ←→  1点
⑧私は勤勉だ。絶対にあきらめない  1点 ←→  5点

⑨アイデアやプロジェクトに夢中になっても、

すぐに興味を失ってしまったことがある

 5点 ←→  1点

⑩重要な課題を克服するために、

挫折を乗り越えた経験がある

 1点 ←→  5点

 

いかがでしたか?

アメリカ人の成人の平均は3.8だとか。

(私は3.5でした…汗)

 

この点数が高いほど、GRITが高いということになります!

GRITが高いことは成功しやすいことを意味します。

 

「え、私めっちゃ低いんだけど…」って人も心配ありません。

GRITは伸ばせるのです!  

 

 

③『GRIT』の伸ばし方

 GRITを伸ばすには、次の4つの要素が重要です。

  1. 興味
  2. 練習
  3. 目的
  4. 希望

【興味】 

興味とは、変化と多様性を探し求めたいという欲求のこと

 

『興味』を持てるものに出会えるかは偶然の要素も大きい。

何に『興味』を持つかは自分にもわからないし、気づいたら持っている場合もある。 

『興味』は、外の世界と交流する中で生まれる⇨新しいことにどんどん挑戦しよう!

 

 研究結果によると…

・自分の『興味』に合った仕事をしている方が、仕事への満足度が高い

(例えば、人と交流するのが好きな人は、デスクワークよりも営業職や教職の方がいい)

・やってる仕事を面白いと感じている時の方が、業績が高くなる

 

エキスパートは初心者よりも、1つのものに対して興味を持つ部分が広く深い!

まずは色々なことに挑戦してまず『興味』を持つ。

そして『興味』を持ったもの1つに対し、「面白い」と感じる部分をたくさん探していくことが『やり抜く力』につながります!

 

【練習】

『やり抜く力』には、興味のあることに取り組んだ時間の長さだけでなく、時間の質も関係する。 

意図的な練習をしなければ上達しない。

 

エキスパートと呼ばれる人は、次の3つの流れで『練習』します。

  1. ある一点に的を絞り、ストレッチ目標(自分がまだ達成してない困難な目標)を設定する
  2. ストレッチ目標の達成を目指して行動し、得たフィードバックを次の行動に活かす(次の行動に必ず工夫を入れる)
  3. 改善すべき点がわかったら、ひたすら繰り返し『練習』する⇨身に付いたら次のストレッチ目標を立てる

 

『意図的な練習』にはストレッチ目標やフィードバックが不可欠で、これを意識して練習することで『やり抜く力』につながります!

 

【目的】

『やり抜く力』の強い人は、そうでない人と比べて『多くの人の役に立っている』と感じる『目的』を持っていることが多い。 

もちろん「自分が楽しいから」という利己的な目的もあるが、それと並行して「誰かの役に立っている」という利他的な『目的』も持つべきである。

 

『天職』は見つけるものではない。

急に出会うのではなく、試行錯誤して『目的』を見出して働いているうちに、「この仕事は天職かも」と思うことによって見つかるものである。

 

自分が「やりたい」、「楽しい」と思うこと『目的』にすると同時に、「誰かが笑顔になる」、「みんなが喜んでくれる」という『目的』も持って仕事に取り組もう!

そうすることで『やり抜く力』がUp!

 

【希望】

 『やり抜く力』の強い人は、楽観主義者である場合が多い。

楽観主義:苦痛の原因は一時的なもので、どうにかすることができると考える

悲観主義:苦痛の原因は変えようのない継続的なもので、自分にはどうにもできないと考える

 

また『やり抜く力』の強い人は、『成長マインドセット』を持っていることが多い。

『成長マインドセット』とは、「人の能力は後天的なもので、努力次第で伸ばすことができる」という考え方のことです。

 

『やり抜く力』を伸ばすには、「どうにかなるだろう!」、「練習すればいけるだろう!」と楽観的に物事を考えることが大切です!

 

まとめ

①成功・達成できるかどうかは、才能や能力よりも『GRIT』が重要

②グリット・スケールで今の自分の『GRIT』がわかる!

GRITは次の4点を抑えることで伸ばせる!

  1. 興味:色々と挑戦して興味を持てるものを見つける⇨それに対して興味をどんどん掘り下げていく
  2. 練習:ストレッチ目標を掲げ、練習し、フィードバックを得る⇨次の練習で必ずフィードバックを考慮して練習し続ける
  3. 目的:利己的な目標を持つと同時に、利他的な目標を意識するべき
  4. 希望:「どうにかできる!」と前向きに物事を捉えるべき

 

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

書籍情報

[書籍のメール便同梱は2冊まで]/やり抜く力 人生のあらゆる成功を決める「究極の能力」を身につける / 原タイトル:GRIT[本/雑誌] / アンジェラ・ダックワース/著 神崎朗子/訳

価格:1,760円
(2021/6/1 22:11時点)
感想(0件)

【書籍名】GRIT やり抜く力

【著者名】アンジェラ・ダックワース

【出版社】ダイヤモンド社

【出版日】2016年9月9日頃

【ページ数】374ページ

 

著者紹介

アンジェラ・ダックワース

ペンシルベニア大学心理学教授。

近年アメリカの教育界で重要視されている『GRIT』の研究の第一人者。

TEDトーク「成功のカギは、やり抜く力」の動画がとても有名です。(下に貼っておきます)

youtu.be

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

 

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

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

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

  1. 「魔法」に頼りすぎてはいけない(No. 28)
  2. DRY原則(No. 29)
  3. そのコードに触れてはならない!(No. 30)

 

①「魔法」に頼りすぎてはいけない

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

「自分の知らない仕事は無意識に簡単と思ってしまい、まるで「魔法」のように錯覚してしまいます。しかし、その魔法を見せてくれているのは他人の仕事ぶりであり、もしその魔法が溶けてしまえば他の誰かが直さなくてはならない。」

ということです。

 

以下、要約です。

 

他人のする仕事は、遠くから見ていると実際より簡単に思えてしまうものです。

自身が開発を経験していないマネージャは、プログラマの仕事を簡単だと思ってしまいます。

反対に、プログラマはマネージャの仕事を簡単だと思ってしまいます。

 

プロジェクトには必ず、我々プログラマが関わらない作業もたくさんあります。

例えば以下のようなものでしょう。

  • ユーザの要件を確認する
  • 予算を申請する
  • ビルドサーバーをセットアップする
  • QA環境や本番環境へのアプリケーションのデプロイをする
  • 業務プロセスやプログラムを新しいバージョンに移行する

自分の関わらない仕事は無意識のうちに簡単だと思ってしまい、まるで「魔法」のように自動的に行われているように錯覚してしまうのが私たち人間です。

その裏では担当者が必死に動き回っていることを知らずに…

 

全て順調なときはいいのですが、問題は『魔法が解けたとき』です。

途端にプロジェクトは滞り、混乱し、誰か別の人がその魔法を直さなくてはいけません。

 

自分の知らない仕事、自分の直接関わってない仕事をする人を敬いましょう!

これをチーム全体でお互いが意識することが大切です。

そして、忘れてならないのは、「魔法が解けてしまったら、誰かが直さなくてはならない」ということです。

 

 

DRY原則

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

DRY原則はシンプルかつ高品質で、保守もしやすいアプリケーションが作れるルールである。必ず守るようにしよう!」

ということです。

 

以下、要約です。

 

『DRY(Don't Repeat Yourself : 繰り返しを避けること)原則』は、プログラミングに関して守るべきとされている原則の中で、最も重要なものと言えます。

これはAndy HuntとDave Thomasが、著書『達人プログラマーの中で提唱した原則です。

 

開発者は、アプリケーションの中に何らかの『重複』があれば、それを排除する必要があります。

そのための以下の方法を知り、より綺麗なコードを書きましょう!

 

重複は無駄である

すべてのコードには保守が必要です。

どのコードも将来バグになる可能性を秘めているからです。

『重複』があると、コードベースが大きくなり、バグの危険性も高まります。

そうなると、開発に携わる人間がすすテム全体を把握することも難しくなるでしょう。

また、どこかに変更を加えた場合、それとロジックが同じ箇所も同様の変更が必要かどうかを確認しなければいけません

 

DRY原則を守れば、こういった問題を抑えることができます。

DRY原則を守ることは、「全ての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」という条件を満たすことを意味します。

 

作業の重複は自動化で防ぐ

開発作業の多くは『同じことの繰り返し』です。

DRY原則は、アプリケーションのソースコードだけでなく、開発作業にも適用すべきです。

そこで役立つのが自動化です。

例えば、テストは同じ作業の繰り返しになることが多いので、テストは自動化するべきです。

同様にソフトウェアのビルドも同じ作業の繰り返しかつ時間がかかります。

したがってビルドプロセスも自動化し、頻繁に走らせましょう。

手作業だと負担が大きいものは、自動化の対象になります。

 

ロジックの重複は抽象化で防ぐ

この重複にはたくさんの種類があります。

if-thenやswitch文が重複しているだけなら発見・解消は容易でしょう。

 

デザインパターンの多くは、アプリケーション内の重複を減らす、あるいは排除することを目的としています。

あるオブジェクトを使用するために整える条件がほぼいつも同じなら、Abstract FactoryパターンFactory Methodパターンを使用すればいいでしょう。

オブジェクトの振る舞いに様々な種類があり得る場合には、Strategyパターンを使用しましょう。

 

デザインパターンについて知りたい!」方は下記の記事を見てみてください。

*** デザインパターンについて記事を書く ***

 

また、DRY原則は、データベーススキーマなどの構造にも適用できます。

 

関連する原則

DRY原則に関連するものがいくつかあるので、下記に示します。

  • OAOO(Once and Only Once : 1度、ただ1度)原則:これはコードの機能、振る舞いについてのみ適用される原則。
  • OCP(Open / Closed Principle : 開放 / 閉鎖原則)原則:クラスなどのプログラム単位は、拡張に対して「開いて(open)」なければならず、修正に対しては「閉じて(close)」いなければならないという原則。
  • SRP(Single Responsibility Principle : 単一責任原則)原則:クラスに変更を加える理由は2つ以上存在してはならない(1つの変更の理由は常に1つでなければならない)という原則。

 

 

③そのコードに触れてはならない!

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

「たとえシステムのどこかが壊れても、本番環境でそれを修正しようとしてはならない。」

ということです。

 

以下、要約です。

 

開発システムをステージングサーバでテスト中に自分の書いたコードに問題が見つかってしまった。

それをテストマネージャから知らされる。

 

プログラマなら誰もが経験あると思います。

このときプログラマが思うのは、「どこが悪いか見当ついてるから、修正させて欲しい!」でしょう。

 

しかし、開発者がステージングサーバを触ってはいけないのです。

 

Webシステム開発プロジェクトの環境は、次のようにアーキテクチャ分割されているのが普通です。

  • 開発者のマシン上の、ローカル開発 / ユニットテスト環境
  • 統合テストを手動、あるいは自動で行う開発サーバ
  • 品質保証(QA)チームや顧客が受け入れテストを行うステージングサーバ
  • 本番環境

(本書60ページより)

大まかに、実務は上記のようになっているでしょう。

 

このような場合、開発者は開発サーバより後の環境に触れてはいけません。

開発者はローカルマシンで最善を尽くしてコーディングをします。

SCMへチェックイン後は開発サーバに配備させて、そこでテスト・修正を行います。

ここ以降、開発者はプロジェクトの進行を『傍観』しましょう。

コードをパッケージングしてQAチーム向けのステージングサーバに配備するのは、ステージングマネージャの仕事なのです。

 

まとめ

①私たちは、自分の知らない仕事を軽視しがちです。ですが苦労しているのは相手も同じ。自分の関わらない仕事をしている人を敬い尊重しましょう!

②アプリケーションの中から『重複』はすべて排除しましょう!DRY原則は徹底するべき!

③開発者が手を加えていいのは自身のローカル環境、ユニットテスト環境のみ!ステージングサーバ以降でも修正できると思ってはならず、ローカル/ユニットテスト環境の内側で最善を尽くそう

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

 

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

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

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

  1. 見られて恥ずかしいデータは使わないこと(No. 25)
  2. 言語だけでなく文化も学ぶ(No. 26)
  3. 死ぬはずのプログラムを無理に生かしておいてはいけない(No. 27)

 

①見られて恥ずかしいデータは使わないこと

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

「コメントであれ、あるいはログ、ダイアログ、テストデータであれ常に「これがもし公になったら問題にならないか」と自問せよ。」

ということです。

 

以下、要約です。

 

プログラミング中の「いたずら」や「武勇伝」は珍しい話ではありません。

「誰も見ないから」と言ってコメントやログにしょうもないことを書き込んでしまうのです。

 

しかし、油断していると思わぬタイミングで多くの人の目に触れてしまうことがあります。

本書ではいくつか例が示されていましたが、どれも面白かったので載せます。笑

  • 進捗会議中、まだ機能が実装されてないボタンを顧客がクリックしてしまう。すると「二度とクリックすんじゃねーぞ、バーカ!」と言うメッセージが表示される。
  • レガシーシステムの保守を担当するプログラマが、エラーダイアログの追加を指示される。そこで彼は、既存のログ機能の出力を利用しようと考える。しかし、元々は裏で動いていて出力がユーザの目に触れることはなかったログ機能だったために、保守作業によって「おい、バットマン、データベースのクソ野郎がヘマをしやがったぜ!」と言ったメッセージが画面に表示され、ユーザから見えるようになってしまう。
  • 誰かが、テスト用の管理インタフェースと、製品版の管理インタフェースを混同してしまい、ふざけたデータを入力してしまう。その結果、オンラインストアの顧客が、「等身大ビル・ゲイツ型マッサージロボット、価格100万ドル」と言った商品が売られているのを目にすることになる。

(本書50, 51ページより)

 

一人で黙々と実装をしていると、ふとした瞬間にふざけたくなってしまうでしょう。

しかし、コードに何かテキストを入力する際は、くれぐれも注意してください…!笑

 

 

②言語だけでなく文化も学ぶ

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

「新たな言語とその文化を学ぶことで、従来から使っていた言語でも、より美しいコードが書けるようになる。」

ということです。

 

以下、要約です。

 

ジェームズ・ジョイスの大作『フィネガンズ・ウェイク』は、40ヶ国語を超える言語を駆使した言葉遊びの連続であり、文体という点でも言語という点でも驚異的な作品です。

彼は、外国語の単語やフレーズを多数織り交ぜることにより、自分の表現の幅を広げているとも言えます。

 

これは、プログラマにも言えます。

Andy HuntとDave Thomasは、名著『達人プログラマー』の中で「毎年新たな言語を1つ以上学ぶこと」を勧めています。

 

多くの言語を学ぶ中で、「言語を学ぶと言うのは、ただ文法や構文を覚えるのではなく、その背景にある文化も学ぶこと」であると気づきました。

Rubyを学ぶとC#delegateがうまく使えるようになったり、.NETのGenericsの潜在力を理解することでJavaGenericsを活かせるようになったり、LINQを学んだおかげでScalaを楽に理解できるようになったり…

 

フィネガンズ・ウェイク』を真似て、1つのプロジェクトにPythonJavaErlangC#などを持ち込めば大変なことになるでしょう。

そうではなく、新たな言語から新たな発想を得ること、それにより同じ問題に対して違った解決策を見つけられるようになることが重要なのです。

 

 

③死ぬはずのプログラムを無理に生かしておいてはいけない

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

「「例外が起きたら握りつぶす」は危険。問題が跡形もなく消えてしまうだけである。」

ということです。

 

以下、要約です。

try-catchブロックをコードベースに大量に入れれば、「例外が発生しても絶対に止まらない」と言うアプリケーションを作ることが可能なはずです。 

ただ、これは、もう死んでいる人の体を釘か何かで固定し、無理やり立った状態にしているようなものですが……。

(本書54ページより)

不謹慎ですが、これは一種の風刺です。

 

あるアプリケーションの基底クラスを開発している時のことです。

そのクラスには、発生後どこでも処理されない例外を一手に引き受けるコードが含まれていました。

そこであらゆる例外を処理し、このクラスのインスタンスは自らの意思で死なない限り、永遠に生き続けられるようにしました。

何か予期せぬ事態が起きた時は、何度でも同様のパラメータが渡され、例外処理のコードが繰り返し呼び出されるようにしました。

すると…

この規定クラスを継承したアプリケーションで何か問題が起きても、その問題は跡形もなく姿を消してしまいます。

どんなことが起きたのか、そのわずかな手がかりも残りません。

 

後々改修が困難になって大変な状況になったことは想像に難くないでしょう。。。

 

そしてその以上なメカニズムを破棄し、代わりに最小限の例外処理と通をするだけの堅牢なメカニズムを組み込みました。

もちろん、そうするとクラッシュが頻繁に起きるようになってその対策をしました。

 

例外を握りつぶすことは危険です。

その時はアプリケーションがクラッシュせず問題ないように思えるかもしれませんが、後々改修不能になってしまう場合があります。

エラーが出た時にそれがどこで、何が問題で出たエラーなのかわからなくなり、手のつけようがなくなってしまうのです。

 

まとめ

「誰も見ないから」と言ってテキストで遊んでしまうと、それが公になった時に大変困ります。気をつけましょう!笑

②複数の言語を学ぶことで、いつも使っている言語の表現力が磨かれることがあります!一つの言語に固執せずたくさんの言語、またその背景を学んでいきましょう!

③例外処理を多用してアプリケーションを延命させてはいけない。エラーが起きてクラッシュするのは普通であり、そのクラッシュを元にエラーを対処していくべきである。

 

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

書籍情報

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

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

 

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

3分でわかる!SPRINT 最速仕事術

読み終えるまで約3分

 

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

今回紹介するのはこの本!

『SPRINT 最速仕事術』

 

この本から得られるもの

『スプリント』と呼ぶ、Googleが開発した『たった5日間で課題を解決する』方法についてです。

 

この本の3つの要点

①『スプリント』とは?

②『スプリント』のやり方

③『スプリント』をやる際の注意点

 

 

①『スプリント』とは?

月曜から金曜の5日間で、課題を解決する、または解決するためのヒントを得ること。

 

5日間で「新規サービスを開発&リリースをしよう!」という訳ではありません。

 

目的は、『対象課題を解決することが顧客にどれだけ求められているか?』を知ることです。

顧客のフィードバックを5日間で得るということですね!

いい感じの手応えやフィードバックが得られたら、対象課題を社内全体で扱うことも検討できます。

「このアイデアダメだったね」で終われば、次のスプリントで対策を打つことができます。

 

 

『スプリント』は、およそ7人くらいのチームで行います。

様々なアイデアが出るように、メンバーは異なる分野の専門家を集めて作れるといいです。

次のようなメンバー構成がおすすめされていました。

  1. 決定者:決定権を持つ人。マネージャやCEOなどが望ましい。
  2. 財務の専門家:お金の流れがわかる人がよい。
  3. マーケティングの専門家:顧客のターゲティングができる人がよい。
  4. カスタマー業務の専門家:顧客の声を知っている人がよい。
  5. 技術 / ロジスティクスの専門家:エンジニアのような、プロダクトが作れる人がよい。
  6. デザインの専門家:デザイナーのような、見た目を作れる人がよい。
  7. 進行役:誰でもいいが、物事を公平に俯瞰して眺められる人物がよい。

 

 

②『スプリント』のやり方

5日間の概要を超カンタンに説明します。

詳細は省くので、「5日間はどんな流れか?」を大体知ってください。

  • 月曜:目標を固める
  • 火曜:思考を発散させる
  • 水曜:決定する
  • 木曜:幻想を作る
  • 金曜:テストする

 

【月曜:目標を固める】

午前中:解決したい問題を挙げ、それを解決するためにどんな課題があるか列挙する

午後:専門家に各課題について話してもらい、最後に1週間で答えが出せそうな課題を決定する。 

 

【火曜:思考を発散させる】

火曜はソリューションを考える日。

月曜に出した課題を解決するアイデアを、チームメンバーが各自出しまくる。

 

社内外問わず、業種業界にかかわらず、既存のサービスやプロダクトからアイデアを引っ張ってくる。

 

【水曜:決定する】

火曜までに出た数多のアイデアやソリューションから1つ決定する日。

午前中:出したアイデア・ソリューションを品評する

午後:チーム全員で投票して決める

   一人1票、決定者は3票という形で、みんな好きなとこに投票

 

1つに決まれば確定、複数のアイデアが候補として出たならば、組み合わせられないかを考える。

もし組み合わせられないなら、決選投票する。

 

【木曜:幻想を作る】

この日は、金曜のテストに向けてプロトタイプを作成する。

実際にリリースするようなものの開発は、間違いなく1日では終わらない。

 

だが、金曜にテストができればいいので、フェイクを作る。

例えば、Webサイトを開発する必要があるなら、キーノートやパワーポイントを使い、写真・動画を駆使してそれっぽい見た目を作ればよい。

 

【金曜:テストする】

 あらかじめ選定しておいた顧客5人に実際にインタビューする。

インタビューは顧客とインタビュアーの1対1で行うが、他のチームメンバーはカメラ越しにインタビューの観察をする。

顧客の反応や発言をチーム全員でメモする。

 

金曜日の終わりにはインタビューで得た情報を整理し、今回選んだソリューションをどうするかを決める。

 

顧客の反応が良かったのならば、そのソリューションは新たなプロジェクト・ビジネス・事業とできるかもしれない。

まだ検討する課題があるならば、もう一度『スプリント』をしてもいい。

反応が悪かったのならばそのソリューションは却下し、別のソリューションを『スプリント』してもいい。

 

 

③『スプリント』をやる際の注意点

  • 『スプリント』中は、対象の課題だけに集中すること
    5日間で課題を解決するには、チームの全員が対象の課題に専念する必要がある。
    他のタスクやミーティングが入ってる人は、それをキャンセルして臨むべき。

  • 休憩時間や調査時間以外は、デジタルデバイスを使わないこと
    他のタスクの連絡が来てたりしたら、集中力が持っていかれてしまう。
    『スプリント』中は、ホワイトボードや付箋、タイムタイマーなどアナログなものを使うのがおすすめ。

 

 

まとめ

『スプリント』は、たった5日間で重要な課題にヒントを見出す仕事術です!

異なる専門性を持った7人(程度)でチームを構成し、曜日ごとに1つ1つタスクへアプローチしていきます。

  • 月曜:解くべき課題を決める
  • 火曜:どうやって解くかアイデアを出しまくる
  • 水曜:アイデアを決定する
  • 木曜:プロトタイプを作成する
  • 金曜:5人の顧客にテストをし、インタビューする

本書では、数社分の『スプリント』実際に行った具体例、スプリントを行う際のチェックリストFAQ(よくある質問)が書いてありました!

 

本書1冊だけでスプリントを実践できるので、気になった方はぜひ本書を手にとってみてください!

 

書籍情報

SPRINT 最速仕事術 あらゆる仕事がうまくいく最も合理的な方法 [ ジェイク・ナップ ]

価格:1,760円
(2021/5/29 11:58時点)
感想(1件)

SPRINT 最速仕事術 あらゆる仕事がうまくいく最も合理的な方法【電子書籍】[ ジェイク・ナップ ]

価格:1,584円
(2021/5/29 11:59時点)
感想(0件)

【中古】【全品5倍!5/30限定】SPRINT最速仕事術 / KnappJake

価格:650円
(2021/5/29 11:59時点)
感想(0件)

【書籍名】SPRINT最速仕事術

【著者名】ジェイク・ナップ、ジョン・ゼラツキー

【出版社】ダイヤモンド社

【出版日】2017年4月13日頃

【ページ数】360ページ

 

著者紹介

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

ジェイク・ナップ氏

ジェイク・ナップ

2001年にワシントン大学総合視覚芸術の学位を取得。

オークリー、マイクロソフト、グーグルでデザイナーをし、GVのデザインパートナーへ。

2017年からIDEO客員研究員。

グーグルにて、革新的な開発プロセスである『スプリント』を完成させた。
(参考:ジェイク・ナップ | TUTTLE-MORI AGENCY AUTHORS

 

ジョン・ゼラツキー

YouTube、グーグルなどのテクノロジー企業で、デザイナーとして「時間」を再設計するミッションに没頭してきた。GVのデザインパートナーを経て、現在は「ウォール・ストリート・ジャーナル」「タイム」「ハーバード・ビジネス・レビュー」「WIRED」他で執筆。ハーバード大学IDEOなどの舞台に100回以上にわたって登壇するなど、スピーカーとしても活躍している。

(引用元:ジョン・ゼラツキー | 著者ページ | ダイヤモンド・オンライン

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

読み終えるまで約3分

 

 

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

今日も一流のプログラマーになるべく知識を磨きます!

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

 

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

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

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

  1. 1万時間の訓練(No. 22)
  2. ドメイン特化言語(No. 23)
  3. 変更を恐れない(No. 24)

 

①1万時間の訓練

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

「スキルを高めるには集中・反復・そのための時間が必要である。エキスパートは才能を持ち合わせているかもしれないが、時間をかけずにエキスパートになった者はいない。多くの時間を自己研鑽に費やそう!」

ということです。

 

以下、要約です。

『学び』と言う言葉があります。

この目的は、自らの能力を高めること、すなわち「スキル」や「テクニック」を身につけることです。 

『学び』で重要なのが『反復』です。

身につけたい能力をいくつかの小さな要素に分割し、それぞれについて反復訓練を繰り返します。

 

お金をもらって開発をする場合は、その目的は『製品を完成させること』です。

対して『学び』の場合、その目的は『自分の能力を高めること』です。

 

自問してみましょう。

「仕事で開発作業に費やしている時間はどのくらい?」

それに対し、「自己研鑽している時間はどのくらい?」

 

「エキスパートになるためには、1万時間努力する必要がある」という『1万時間の法則』があります。

Peter Norvigは、何かでエキスパートになるには約1万時間の訓練が必要と述べている*。いわばこの1万時間というのが「マジックナンバー」ということになる。

Mary Poppendieckも、著書『リーンソフトウェア開発と組織改革』**の中で「どんな専門的職業であれ、入念に計画された、集中的な訓練を最低10,000時間積み重ねることで専門家になると言う」と書いている。

(本書44ページより)

norvig.com

 

仕事で成果が出ない人は、学びの時間が足りないのではないでしょうか?

逆に成果が出ている人は、学びの時間が生活の一部になっているのではないでしょうか?

 

 

ドメイン特化言語

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

ドメイン特化言語(DSL)は、ある分野に固有の語彙や誤報を使用して現象を表現できるように作られたプログラミング言語であり、内部DSLと外部DSLの2つに大別できる。」

ということです。

 

以下、要約です。

 

ドメイン特化言語DSL : Domain Specific Language)はご存知でしょうか?

 

各分野(ドメイン)には、それぞれ固有の事象があります。

固有の事象を表現できるように作ったプログラミング言語DSLです。

ある分野に特化している言語ですね。 

 

DSL『内部DSL『外部DSLの2つに分けることができます。

 

【内部DSL

汎用のプログラミング言語の書き方を工夫して、見かけ上の構文を自然言語に近づけた言語のこと。

ホスト言語(元になった言語)のAPI、ライブラリ、ビジネスコードなどはラッピングされるのが普通です。

ラッパが提供され、技術的知識がなくてもその機能を容易に利用できるようにしてあるのです。

(本書46ページより)

具体例を挙げるとすれば、Rubyのテスト記述FWであるRspecがあるでしょう。

 

【外部DSL

汎用のプログラミング言語とは全く別の構文を持ったDSLのこと。

具体例を挙げるとすれば、データ操作に特化した言語であるSQLがあるでしょう。

Webページ作成に特化したPHPもそうです。(JavaScriptもWebページ作成に強いですが、特化しているわけではなくネイティブアプリやGPU計算など色々なことができるので、DSLではありません。)

 

 

③変更を恐れない

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

「大切なのは、積極的にシステムを改良していく姿勢である。」

ということです。

 

以下、要約です。

 

ひどいプロジェクトに関わったことはありませんか?

ひどいプロジェクトとは、コードベースが低品質であり、どこかに変更を加えると関連のない他の部分が壊れてしまうようなものを言います。

 

こういったプロジェクトを生んでしまう背景には、『できる限り他の部分を破壊しないように、なるべく変更を加えない』という実装者の姿勢があります。

これはまさにソフトウェアという『プログラムコードを積んで作るジェンガをプレイしているようなものです。

 

ジェンガはいつかは壊れます。

ですが無闇に変更を怖がるせいでひどいプロジェクトになっている可能性が高いのではないでしょうか?

勇気を出してリファクタリングをすればいいのです!

もちろん時間と労力はかかりますが、その後プロジェクトが進行する中でその投資は回収できますし、何倍もの利益となって返ってきます。

 

また、ひどいプロジェクトを改修した経験はその後の実装にて役に立ちます。

その経験を通して、どうしたらひどいコードベースにならないのか?を考え、その後実装するコードベースの品質が上がるはずです。

 

よくないのは、変更を怖がる姿勢です。

良いのは、変更を怖がらない姿勢です。

 

積極的に変更を加える姿勢を持っていきましょう!

 

まとめ

『学び』は私たちにとって重要であり、その目的は能力を高めること!

スキルの習得には多くの時間が必要となるので、日々自己研鑽を続けましょう。

目指せ、1万時間!

ドメイン特化言語DSL)とは、ある分野に特化した言語のことです!

③他の部分に影響が出そうだからといいプログラムに変更を加えるのを怖がる人が多いです。しかし、変更を避ける姿勢が積み重なると改修困難なプロジェクトを生んでしまいかねません…積極的に手を加える姿勢を持ちましょう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ