子供の成長の片鱗

娘がたくましくなっている。親バカエントリですが、お暇な方はお付き合いください…(^_^;)

 

 

家では甘えん坊。

注意するとすぐに泣く。

弟と喧嘩するとすぐに泣く。

 

通っている学童のスタッフさんたちに聞いた出来事。ふたつ。

 

娘と友人が喧嘩した。

いつも仲が良くて一緒の二人。

原因は、友人にあった模様。

喧嘩して5分経過…

友人「…ふん。」

娘「…ごめんね。」

友人「いいよー!」

娘から謝ったらしい。

スタッフさん、なぜ先に謝ったのかを聞いたそうな。

娘「学童での時間もあんまりないし、楽しい方がいいでしょ。喧嘩していても楽しくない。先に謝ったほうが得だし!」

そんな考え方を出来るようになったんだなあ、としみじみ。

 

 

ラスト出来事。

娘と、友達二人が勉強タイムのときに席につこうとしたときのこと。

友人二人が喧嘩していて、娘の隣を争っていたらしい。

そこで、娘の一言。

「仲直りするまで座らせない!」

友人たちは仲直りするタイミングを逸していただけのようで、速攻お互いに謝って爆笑しだしたとのこと。

また、スタッフさんが娘になんでそんなことを言ったのか聞いたところ。

「3人って面倒くさいことが多いから、これが一番でしょ。楽しいのが一番好き!」

と、のたまったらしい。

言葉の背景にはいろんなことが入っているのかもしれない。

私には推し量ることしかできない。

 

家では見せない姿を聞くことができて感謝。

ちゃんと見ていてくださっているスタッフさんがいることに感謝。

 

子供はやっぱり親だけが育てているわけではない。

それを実感した一コマでした。

 

ありがとうございます。

 

 

 

娘からのdis

昨夜。

娘は、一昨日内緒でしでかしてしまったことを謝ってきた。言わなければわからなかったことを、ちゃんと正直に。そして、最後にはオチをつける働きをしてくれました(^_^;)

その会話、一部始終をご覧ください…(T_T)

 

 

一昨日。

娘が、赤鉛筆がなくなったというので、買っておいで、と一人でイトーヨーカドーへ行かせた。

 

次の日。

学童から帰ってきた娘が。突然泣きながら台所に居る私に向かって告げてきた。

 

「ごめんなさい、お母さん…私、余計な…無駄なものを買ってしまった…お金無駄にしちゃった…(T_T) 黙っていてごめんなさい…(T_T)」

 

意味がわからず何も把握できないので、一つづつゆっくり聞いていくことにした。

母「ええと、いつの話?」

娘「昨日、赤鉛筆買いに行ったときのこと。。」

母「無駄なものって何?」

娘「これーー。。」(動物が型どられた消しゴムが沢山入った瓶を見せてきた)

母「ええと、それは、どこからお金を出したの?」

娘「お小遣い。」

母「なんで、無駄だと思ったの?」

娘「消しゴムたくさん持っているのに、可愛いから、つい買ってしまったの。」

 

複数の問題がここに入り混じっている。

・無駄なものを買ってしまった

・お小遣いで買った

・黙っていた

それぞれの点で、話してみた。

 

母「まず、無駄なものを買ってしまったこと。これは、見たときには可愛い!って思ったんだよね?だから買ったんだよね。そしたら、次からは、一度家に帰って同じものがないかチェックしてから買うようにしたら?そうすれば、本当にほしいものかどうかわかるかもしれない。」

娘「うん!」

 

母「次に、黙っていたこと。今日一日、昨日から苦しかったでしょ。言う日にちが伸びると、更にもっと苦しくなるよ。今日言えて良かったね。ちゃんと言ってくれてありがとうね。

今日朝から学校で、辛かったでしょ。これからは、すぐにいいなね。自分も楽だし、お母さんもそのほうが嬉しいよ。」

娘「うん。」

 

母「最後に…使ったお金のこと。お小遣いで買ったんだよね?それなら、謝る必要もないし、無駄なものを買っても自分の責任だから、報告しなくてもいいんだよ。」

娘「え?」

母「あなたが自由に使えるように、お手伝いをするたびに渡しているお金でしょ。あなたが働いて稼いだお金だよ。何に使ってもいい。無駄だと感じたら、次からはやめればいい。」

娘「うん、そうする。。」

母「おかあさんたちも、自分の働いたお金は自由に使ってるよ。無駄なときもあるけどね。」

 

娘「飲み会に使ったお金とか?」

母「…?!…それは…ヒツヨウケイヒトイウモノデ…」

娘「何?!聞こえない!」

母「」

 

最後に娘からのdisをいただき、オチがつきましたようです…

 

小学生まだ低学年の娘。

でも。そろそろ年齢二桁が見えてきて。

怖いです。。。

 

「クソッタレ!」 ~あなたの職場のイやな奴を読み終えて~ 後編

尊敬する方から紹介された本、後編。

前編は、こんな内容でした。

 

okandayo.hatenablog.com

 

後編。ドラッガーからみたクソッタレ、またクソッタレをうまく活用した事例についてのご紹介をしていこうと思います。と前編でも言及させていただいた通り、ここを中心に書いていきます。

いや、もう本当にクソッタレは・・・・このやろー。

私たち人間は、”思い込み”と”言葉”という二つのレンズを通して世界を見ている。

他人に対してどのような態度をとるかは、この二つのレンジによって決まってくる部分が大きい。 

 

組織の色に染まらず、やばいとおもったらすぐ逃げる!それでも・・・・・。

 

ささいな言葉の違いがひとを変えてしまう

囚人のジレンマ」という実験を例にして、ここでは書いてありました。

思い込みがどれだけ人に影響を与えるか、を説明するために事例が挙げられていました。

 プレーヤーはお互いに協力し合うことでともに勝利を分け合うこともできるし、競争しあって一人勝ちすることもできる。

 「生活共同体だ」「家族だ」となれば、支えあい、補い合い、幸せな方向へ行こうとする。

もしかすると、大きな枠でとらえると、引用の前者は社会主義、後者は資本主義の考えのような・・・。

一つの国を家族とみなすか、発展するためには?に主眼を置くか。

 

ここで言いたいのは、そんなささいな言葉一つでやる気もそがれてしまうということ。

やる気・能力のある人たちを利己的で不正直で陰険に変えてしまう、と書かれていました。

 

ドラッガーの言葉

「協調性に目が向くフレーム」が紹介されていました。ウイン・ウイン・ゲームを目指して、だれにとっても満足のいく結果に導くことを最優先して考えること。

わたし、か、わたしたち、か

利己的か、そうでないかを見抜く一番大きい違いは、自分たちのチーム内で話すときによく出る会話の中で、その人が一人称を「私」というか、「私たち」というか、ということだと書かれています。

見回してみましょう。

上司。どうですか?どっちで語っていますか?

私の上司は幸いにも、「おれら」「わたしたち」という言葉を必ず使っています。

自分たちのことだけでなく、周りのことはどう呼んでいますか?

「彼ら」「あそこの人たち」?あまりにも敵視しているのがにじみ出ている言葉ですね。一つの組織の中であれば、「we」で話しましょう、とあります。

これは意識して気を付けて使っていきたいと思いました。

 

そうあるには、本にも書かれていましたが、

「他人の目で自分を見てみよう。」

クソッタレにならない秘訣だそうです。

以前、こんなエントリを偶然にも書いていました。

 

okandayo.hatenablog.com

 第三者の目で自分を見たり、組織を見たり。利己的にならないように、常に初心にかえり、ふりかえる。

これは心がけないと忘れてしまいがちですね・・・。

 

会議の例

自分の欠点をオープンにしたり、自由な意見を言い合える「心理的安全性」を確保しよう、そう書かれていました。

誰かが、「私は、よくミーティングをこじらせるような発言をするが、もうやめようと思う。」という発言をしたとします。

この発言一つで、その彼が同じような発言をしそうになったら止めることができるし、ほかの人がやりそうになっても止めることができる。

 

生産性の上がらない会議。めっちゃくちゃ、おおいですよね。

クソッタレが、自分の意見を出したいがために道筋・本質と関係ないことを話し出して横道にそれて終了~。

いみねーじゃん!!!

そんな時は、自分を盾にして、

「よく外れた話をしちゃうんですけど、そうなったらとめてくださぁ~い!」

ということで、意識が変わるかもしれない。

毎回は通じないですが、時間がない中で論点をはっきりさせて議論すべき時には使い分けるのも手かもしれませんね!

 

イやな奴だらけの職場をサバイバルするには

会社はなかなか辞められない。では、どうすればいいか。

何個か紹介しましょう。

  • フレーミング
  • 無関心を心がけ、感情を遮断してみる
  • 小さな勝利を重ねてみる
  • 安らぎを得られる場所を見つけよう

これらを実践するには、自分を鍛える必要があるかもしれません。

自分の心を。そのあたりは、「嫌われる勇気」を読むと参考になると思います!

 

リベンジリスト

こうタイトルに書いてしまうと、ちょっと怖いかもしれませんが・・・

これも、大事なサバイバル術です。

クソッタレに標準を当て、しっかり観察をする。しかるべき時を選び、一か八かしかけるという意思が自分にあるかどうかを確認しておく。

この勇気がないのであれば、リベンジはしないほうがいいでしょう。

しっぺ返しが来ます。

なにかを行動することによって、「小さな勝利」を得ることができるかもしれません。

 

あまりにもひどいクソッタレにはどうしたらいいか。

 あなたのまわりの虐げられた同僚と団結して対抗すれば、クソッタレも態度を変えるかもしれないし、うまくすれば永遠に職場から去ってくれるかもしれない

 ちょっと、ぞっとすることが書かれていましたが。。。

この言葉を思い出すような話を聞いたことがあります。現実に、起こるんですよね。

でも、そうしないと組織はおかしくなってしまう。

杭は熱いうちに打て!

 

クソッタレ成功者たちの教訓

うらやましいことに、クソッタレでも成功することもあるんですね。

その最たる例が、スティーヴ・ジョブズだ、と書いてありました。

どういうところが成功者なのか?

  • 言葉はひどいが、部下から驚くほどのやる気と創造性を引き出す
  • 性格の悪輪を帳消しにするほどの才能がある
  • 攻撃やいじめを戦略的に使う
  • 効果的に威嚇する
  • 恐怖を鞭に、飴も使う
  • やる気のない人間を動かす

 

だれでもができうることではありません。特に、2番目。

クソッタレであるかもしれない。でもそれを優位に使うことができるのは、ほかで認められるほどのものを持っている時だ、と書かれていました。

よって、「うぬぼれは厳禁」とも・・・^^;

 

総じて

クソッタレはかなりな数、いらっしゃると思います。

自分もそうなることがかなりあります。特に子供たちを注意するとき。

感情的になってしまうこともあります。

でも、そうならないように、「わたしたち」というようにしたり、常に第三者の目で見ることができるようにしたり、はじめにクソッタレにならないように、

「自分はこの場をこうしたい!」と宣言し、皆で協力したりする試みをしたりしています。

例は、こちら^^;

 

okandayo.hatenablog.com

 

毎日できるわけではありません。

でも、振り返ることができたときに少しずつチャレンジすることで、クソッタレ率・・

クソッタレ項目のカバレッジも減っていくかもしれません!

 

そう思うと、自分も悪くないな。そうおもいますね!

 

ここまでお付き合いいただき、ありがとうございました!

 

Naite#19 数学を学ぼう ~数学の知識を利用したソフトウエアテスト~ 番外編

こんにちは!あさこです。

1か月くらい前に開催した勉強会、「Naite#19 数学を学ぼう ~数学の知識を利用したソフトウエアテスト~」の際に説明しきれなかった部分についての解説を少しブログでしていこうと思います。

番外編、です。

勉強会の中で使用した資料は、こちらです。

 

www.slideshare.net

 

 

この中では、「探針テスト」という日立グループが製品試験の中で採用しているテストの内容に触れて、数式の理解をしていきました。

この勉強会では、探針テストには二項分布の概念が使われていますよ、というところで終わりにしました。

しかし、区間推定の式にしっかり持っていくには、

中心極限定理

大数の法則

という定理も使用しなければいけません。

その部分について少し解説します。

 

この概念を利用して、勉強会で使用した資料のP33の式を導きます。

 

さらに、

大数の法則を利用して、

 

 

この区間推定の式が成り立つのは、

「サンプリングしたテストケースが十分に大きいとき」ということになります。

実際の探針テストがどうなっているかはわかりませんが、20~30%をテストすると参考資料には書いてありました。

その値が「十分に大きい値だ」という仮説に対する検証がちゃんとされたうえで実施されているのでしょう。

 

数式を導いくうえでは、このような条件のもとにやっているのだろうなぁと想像できます。

 

逆に言えば、この定義が成り立たない場合には、この区間推定の式も

「使ってはいけない」ということになると思います。

 

ちゃんと、数式の成り立つ条件を踏まえたうえで利用されることが大事です、ということをお伝えして終わりたいと思います。

 

使用方法と分量をお間違えなきよう♪

 

 

「クソッタレ!」 ~あなたの職場のイやな奴を読み終えて~ 前編

尊敬する方から紹介された本。

いやー、興味深かったです。

いろいろと海外の事例や、鉄則が載っていました。

その中でも、とても興味を引いた部分をご紹介していきたいと思います。

詳細は、どうぞ、本を手に取って読んでみてください。

明日からあなたも「クソッタレ」という言葉が頭から離れなくなりますよ・・・

 

「クソッタレ!」 

「卑劣で底意地の悪い人間に出くわしたとき、私は心の中で、

「ゲッ、こいつは底抜けのクソッタレだな!」と叫ぶ。

「あなたの職場のイやな奴」はこう始まる。

 

いやいやいや・・・

どきっ!ずきっ!

そう思いながら、「はじめに」を読んでいるだけでひきつけられていく。

「本書を読めば、いけ好かない奴らから受けるダメージを最小限に抑えるヒントが、きっと見つかるはずである。

 
クソッタレの二つの基準

基準1 クソッタレと目されている人間と会話を交わした後で、”標的”となった人間が憂鬱になったり、屈辱を感じたり、やる気を失ったりするか?

特に重要なのは、標的となった人間が卑屈な気分になるかどうか、だ。

 

基準2 クソッタレと目されている人間が悪意を向ける対象が、自分より力の弱いものであるか?

 

シャレになりませんね、この基準を読んでいると・・・

いじめっ子というより、人間として明らかにおかs(ry

こんな人間のいる場所にいたら、そりゃ、鬱にもなります。仕事も嫌いになります。

何もする気が起きなくなり、やがてそのクソッタレは、人間クラッシャーになっていくのです。

 

私はこう叫びたい。

「死にさらせ!!!!」

 

前半では、こういう人間がいる場合は、とにかく会社に入社させないようなルールを作れ!と言われています。

 

クソッタレ撲滅ルールを導入するには

グーグルの会社事例が紹介されています。

「クソッタレにならない」契約書を交わすそうです。

まぁ、でも契約書を交わしたからといっても、人間は時間がたち、その組織にどっぷりつかっているうちにかわっていく。

それが人間の摂理ってもんです。。。さみしい。

けれども、そこを、なんとしてでも契約書を守ってもらう。

そうならない文化を作っていくことが大事、と書かれていました。

当たり前ですけどね・・・。

 

クソッタレなクライアントには?

社員を守る施策を敷いている会社もあるそうな。

明らかに横柄な、文句をいうことで人生を謳歌しているような顧客。

そんなやつらから身を守るには、会社の方針として掲げていないと排除できない。

本当にそうだよなぁ、と思います。

しかし、ここでの事例は、サービスを不特定多数に提供する会社の事例のみ。

 

ソフトウエア業界ではどうでしょうか・・・

苦労する営業・・客先に入ることになる技術者・・・

派遣の身だと、どう防いでいけばいいか。

クソッタレが、プロパーにいたら。

ちょー、上から目線の顧客の要求を聞いて、仕様を確定していくには・・・・・

 

偉くなると人は変わる

会社の役員や管理職は、高い給料を得ているだけではなく、待遇もよく、周囲からは絶えずお世辞を言われる。

 あー、確かにそういうひともいるかなぁ・・・。

クソッタレな顧客と同じ対応をしてくるやつ。

他人の発言や意向を無視し、目下の人間の批判には耳を貸さず、無礼なふるまいを重ね、その場の状況や周囲の人間を

”自分の望みをかなえるための手段”

とみなすようになる。

 いやですね~、こういうやつら。

 

・・・でも・・・・自分がそう思われていないとも限らない・・・・(TT

 

あなたの中にもクソッタレはいる

 

人は周囲に影響され、時にはイライラし、クソッタレに変化してしまうこともある。

予防策1 ダ・ヴィンチ・ルール

クソッタレの巣窟だとわかったら、たとえどんなに魅力的な待遇や条件であったとしても、その仕事に就くべきではない。

「最初に抵抗するほうが、あとから抵抗するよりも楽」である。

鬼になる前に・・・においをかぎ取ったら、初めに抵抗しとけ。

ほんま、そうですね。

へらへらして自分を偽りながら居場所を見つけようとした挙句、クソッタレだらけの環境に身をうずめ、人への対応がおかしいということにも気が付かなくなってしまう・・・。

これこそが、クソッタレの巣窟の一番の原因なのでしょう。

そんなところは、早く出てしまえ!

 

とはいえ、そんな権限もない・・・そんな時は・・・。

 

予防策2 逃げろ、無理なら近づくな! 

「現在の職場をやめることができない。もしくはやめるつもりがない場合には、最悪のクソッタレと接触する機会を最小限にとどめるために最善を尽くす」という戦術である。

 これしかないでしょう。

私がこの本を紹介されたときに、この予防策について一番興味を持ちました。

戦術とはいえ、どう手を回すか。政治的に立ち回るか。

 

具体事例については・・・

お会いした時に飲みながらお話ししましょう。

後編は、ドラッガーからみたクソッタレ、またクソッタレをうまく活用した事例についてのご紹介をしていこうと思います。

 

それでは、それまで皆さん、クソッタレになりませんように・・・・。

 ふふふ・・・・。

テスト計画の中でのサブプロセス管理の考え方の紹介

12/8分 担当の、@acha_821 です。

アドカレ初参戦です。

一つの大きなテーマの枠の中で自由に書きたいことをかける。そして、バトン形式。世の中には面白いものがたくさんありますね。

さて、前置きはこのくらいにしますね。早速、バトンを受け取ります!

 

ポイント

プロジェクトゴール達成のための計画を立てるのがプロジェクト計画。

その達成に必要なプロセスを構成するサブプロセス単位も視野に入れて計画すると、選択したプロセスの目的、尺度等についても考えます。

その際に考慮するといいと思うポイントを少しご紹介。

 

ということで・・・スタートっ!

 

 プロジェクト計画とサブプロセス管理

言葉の定義

登場する単語、この記事の中での定義を書いておきます。オレオレな内容なので、他と違っていましたらすみません。

 

プロジェクトゴール

代表的な例として、QCDが挙げられると思います。

今回の記事の中では、テストについて記載したいので、とあるソフトウエアの品質の定量的な目標値をゴールとして想定してみます。

 

 

サブプロセス

プロセスというのは、インプットとアウトプットをつなぐところにある「過程、工程、方法」を意味します。

その定義に基づき、ひとつのプロセスを構成する小さなプロセスの単位をサブプロセス、と定義して話を進めていきます。

CMMIの中では、サブプロセスと言うものもよく出てくるので、馴染みの深い方もいらっしゃると思います。

プロジェクトゴールに「品質」を設定しているので、品質を測る工程・方法がプロセスとなります。

設計工程ですと、設計書が成果物。その設計書の品質を測るプロセスはレビュープロセスと考えることができます。レビューを構成するサブプロセスには、インスペクション、ピアレビュー等が一般的に挙げられています。

 

 サブプロセス管理を行う目的 

 「プロジェクトゴール達成する」ためには、プロセスごとの「やり方」を「今までの成功していたやり方」といかに近似させていくかを管理する、ととらえることもできると思います。(ちょっと発想が飛躍してすみません)

より小さな単位で、「過去の成功経験と同じように」行っていることを監視していくことによって、ゴール達成を阻害する要因を小さなリスクの段階から把握することができます。ここに、サブプロセス管理を行う一番の目的があると思っています。

”従来のうまくいっているやり方”とのズレが少しずつ生じ、発見できないままでいることにより、リスクが大きくなっていきます。

プロセスを小さく管理することで、工程の中で実施するそれぞれのサブプロセスを行う目的が見えてくることがあります。

例えば、ピアレビューのあとにイスペクションを実施すると計画します。ピアレビューとインスペクションでは、それぞれレビュー観点が異なるものとします。そういった、特性の異なる小さなプロセス、これがサブプロセスになります。

異なる特性のものをサブプロセスとして扱うのは、同じ特性・性質のものを管理しても、ズレを生じさせた原因を特定しにくくなるからです。

 

実施するプロセスを選択する

 プロ計では、何を計画していますか?

計画の内容次第で、プロジェクト成否の8割はきまるといわれます。ステークホルダとゴールやスコープ、役割等を共有し、成功への道筋を描く…と言うと言いすぎかしら(^_^;)

プロジェクトを実行するには様々なプロセスがあり、それ毎に計画を立てます。

レビュー計画、構成管理計画、リスク管理計画、作業計画、テスト計画・・・

テスト計画に至っても、「テストは下流だから・・・」ではありません。

プロ計でスコープや役割、成果物等が決まっていればテスト計画もたてられます。

ということで、今回はプロジェクトの初期で立てるテスト計画にフォーカスして書いていきたいと思います。

 

テスト計画におけるサブプロセス

何を計画しますか?

ステークホルダ、スコープ、役割、体制、工程、成果物…プロ計と同じです。

工程(テストレベル)には、単体、結合、システムテスト・・・等があります。

テストレベルごとに、何を検証するのか、何を検証したいのかを計画していきます。

その「検証したいこと」「検証するもの」によって、プロセスも変わってきます。

注:これは、V字モデルでも説明できます。詳細については、以下を参照ください。

V字モデルとは? – ソフトウェアテスト・第三者検証ならウェブレッジ

 

性質・特性の異なるものをサブプロセスとして扱っていきます。

では、テストではどのようなものをサブプロセスと定義すればよいか。

テストレベルごとに検証したい・検証する対象・目的が異なるので、その目的にあった特性・観点を割り振り、尺度を決めて管理を行う

簡単な例でいうと、品質特性モデルが挙げられます。「異なる特性を分類し体系的にまとめられ規格になります。これは、まさに別のサブプロセスとして扱うことができると思います。

ここまで読んでくださっている方はピンときた方もいるかもしれません。

テストにおけるサブプロセスは、管理したい単位(テストコンテナ、テスト観点、テスト条件・・・)の一つの軸になりうるものだと考えています。

サブプロセスにて測定する尺度は、GQMによって落とし込み、メトリクス管理をしましょう(いつか、このGQM・メトリクスについての記事を書きたいと思います)。定量的に管理を行うことで、KKDでは得られない、プロジェクトゴール達成への試みが待っていることでしょう。

 

まとめ

  • 過去の特性が類似した「成功」プロジェクトを層別して、「ゴールを達成するサブプロセス(注★)」を定義・導出しておく
  • ★を指標値なり目標値として持っておくことで、サブプロセス管理を行うことにより、リスクの早期発見ができる
  • 以上の理由から、サブプロセス管理では定性的な管理ではなく定量的な管理がもとめられている
  • プロセスの目的(ゴール)から尺度を落とし込む。(GQM)

 

サブプロセス管理、試してみませんか?

リーダブルコード読書感想文 (小並感版)#2 Last

 

リーダブルコード読書感想文 (小並感版)#1 

 

okandayo.hatenablog.com

 

 の続きです。

だいぶ時間がたってしまいました・・・・

#1では、第Ⅰ部について、書きました。

今回は、Ⅱ~Ⅳ、最後までを対象としています。

いきなりまとめから入るという荒業を今回はしちゃいます!

 

[まとめ]


この本はコードの書き方テクニックだけでなく、目的が明確にかかれており、その目的がソフトウエア開発の中で用いられているモデルなどと容易に関連つけて読むことが出来ます。もちろん、読み手にも必要最低限の知識が必要です。


モデルなどの名前ばかりが先行しがちな中、

こういうもっと根本にある目的からそういうモデルが生まれているのだという事実を知るきっかけにもなる いい本ですね。

 

では、#1の続きを・・・

「序」では、「リーダブルコードとは?」という本の題名の定義・目的について書かれた部分の紹介をしました。

続いて、「破」ではその序の内容の応用編、

「急」では、”リーダブルコード” であることを貫くと、こんなことにも関係しますよ、という流れについて紹介します。

自己流の解釈なので、ご容赦くださいませ。

 

リーダブルコードとは、「読みやすさを備えており、誤解されず、一貫性を持った美しさを持ったもの。」でしたね。

読みやすさ・単純さを求めていくと、コード複雑度などは低いものになっていきます。

そういった 複雑度・単純さを追求する内容が書かれていて、「複雑度」に関するメトリクスが頭に浮かんできました。

複雑度の閾値を用いて、値の高いものから優先的にコードレビューをしたり、単体テストのテストケース設計を考慮したり、という工夫を知り合いが行っているのを耳にします。

本書の内容から、それが妥当であることが読み取れます。

一方、メトリクスに振り回されるプロジェクトを見かけることもあるので、複雑度メトリクスの使い方を間違わないように、本書内容を参考に改善事例等の展開をしていく必要性を感じています。

 

急 

コードについて

しつこいですが・・・この本では、リーダブルコードは、読みやすく、 誤解されず・・・というものと定義されていました。

リーダブルであることを保ちつつコードのメンテナンスを行うこと。

XDDP、SPL等の目的が、ここに書かれているように思いました。

極論ですが、

できるだけコードをかかない。(=最小の量で済ます)

新しいコードには文書・テスト・保守作業が必要になる。

そのために、コードの定期的なメンテナンスが必要である。

それは、以下のような試みを続けていくことだ、とかかれていました。
・不要なコードの削除
・要求の変更などをトリガーにコードの簡素化(リファクタリングなど)を検討する
・使用しているAPIや関連する最新情報のトレースをする

上記の内容を実行していくことで、派生開発する際、どれだけ楽になるか想像できますね!

 

テストについて


テストと読みやすさについても書かれていました。

 

コードを保守するということは、テストも保守する必要がある。

テストコードを「いつ書くか」には言及していないが、テストコードを書くことは必要で、そのテストを読み書きしやすくすることが、この章の目的として書かれています。

 

テストコードがあることで、文書・テスト・保守作業等を安心して実行することが出来ます。テストできる状態のものが既にあることで変更の妥当性チェック、デグレード等のリスクを早期に検知することができるからです。

そのためには、テスト資産を変更に合わせてメンテできている必要があることは言うまでもないでしょう。(変更などの作業のリスクが高すぎます。)

リスクを減らすためにも、テストコード(not試験手順書)を書いて、実行できる環境を常に持っていることが大切だと思っています。


最後の小並感

今後は、文書をどのタイミングで保守し続けるのか?ということについて考えていきたい。

開発手法によっていろいろあるかもしれないけど、必要な情報がちゃんと残ること、が目的で、この本に書かれている内容を文書にも適用していくことも大事だなと

いう小並感なしめくくりでおわります。

 

最後まで読んでくださった方、ありがとうございました(*^-^*