日々常々

ふつうのプログラマがあたりまえにしたいこと。

いい名前が思いつかないときは変な名前をつける

プログラミングは名付けの連続です。しかし、いつも「いい名前」が見つかるわけではありません。付けたときはいい名前と思っていても、時間が経って知識が増え、ブレイクスルーが起こると、それまでいいと思っていた名前も途端に微妙に感じたりします。

このように「いい名前は見つからない」とか「どうせ変わる」とか思うと、名前を考えるのが無駄に感じたりしなくもありません。でも名前は重要です。名前の重要さは割愛します。プログラマが知るべき97のこととかを読んでください。

名前を付けるときは、誤魔化さずに付けるように意識しています。と言うと、「いい名前をスパッと決められている」ように捉えられるかもしれませんが、そうではないです。私は名付け能力の低さには自信があります。それはさておき、誤魔化さずに付けると言うのは、「誤魔化しなしに理解できていないことがわかる名前を付ける」と言うことです。この名前を「変な名前」と呼んでいます。この手の名前は大抵長々としてたり、回りくどかったり、ドメインモデルなのにユビキタス言語にない言葉だったり、システムハンガリアンだったりします。でもその名前をつけます。誤魔化した名前を付けたい衝動にしばしば駆られますが、意識が保ててる間はなんとか抑え込みます。衝動を抑えきれないときは、もっと変な名前にします。例えば hoge とか xxx とか。

ここで言う「誤魔化した名前」の典型的なものとしては XxxInfo とか XxxManager などが挙げやすく、その同系統のものです。同系統と言うのは「短くて、それっぽくて、でも何も表していない」もの。そんな名前こそが「誤魔化した名前」です。短い名前が適切な場合もありますが、いい名前が思いつかないときの短い名前はよくありません。いい名前が思いつかないのに短い名前を付けてしまうと、いい名前がつけれていないと言う情報が消え去ります。そして短いものは埋もれ、スルーされがちです。

一番最初に名前を付けるのは、そのコードを初めて書く瞬間です。初期理解です。いい名前を付けられる準備はできていなくて当然とも言えます。ブレイクスルーは必ず起こります。名前が変わらないとしたら、よほど最初から理解できていたか、名前変更をサボったかのどちらかな気はします。ですが最初に名前を付けるのは、もっともその対象のことだけを考えている瞬間でもあります。俯瞰した理解は持っていないかもしれませんが、間違いなく名付ける対象のことだけを考えています。その時の知識や感覚が失われるのは勿体ない。いい名前はそれを表現できますが、それが思いつかないのであれば、せめて「変な名前」でも情報を残したいとか思ったりしています。

まとめ

いい名前が思いつかないときにシンプルな名前を付けるとそれっぽく見えてしまいます。これは避けるべきです。長々とした変な名前をつけるのがいいのではないかと思っています。目に入るたびに「もっとマシな名前があるんじゃないか」と思わせるくらいが丁度いいです。

蛇足

もちろん、コードが自分の手を離れる前には掃除します。そのときは誤魔化した名前にするかなー。万人に受け入れられるとは思ってないし、前提条件も多いですしね。

年末感とか全くないのだけど

2018年が終わろうとしてるのでブログでも書こう。

おしごとがたごと

一昨年の年末に勢いで会社を辞めて、去年の年始から個人事業主という無職になって、2年目が終わりになります。まだ2年か。

良し悪しで言うのも難しいのですが、色々と得られるものが多くあった年でした。しっかりお返ししていきたいなと思っています。なんだかんだで一応生きてるので、まあ良しかなー。

アウトプット

去年の「コードをどまんなかに」から続く感じで、「あるエンジニアがプログラムを紡いでいく様を見てみる」をさせてもらったり、JIGを育てつつ、JJUG CCCで話させてもらった「コードをどまんなかに据えた設計アプローチ」になっています。

来年どうなるかは知らない。

なんか関西でアウトプットしてない気もするので、来年は少し増やそうかなーと思ったり。今年は関ジャバで話したのも1回でしたしね……。

そうそう、レビューさせてもらった本が出版された

今年の出来事といえば、レビューさせていただいた「いちばんやさしいGit&GitHubの教本」が無事発売となりました。

Gitの本は数多くあり、玉石混淆ではありますが良書も多くあり、情報が不足しているわけではありません。それでも@ihcomegaさんと@syobochimさん、お二人ならではの本に仕上がっていると思います。特徴を言うならば「現場密着のハンズオン」ですかね。書かれている内容も著者があまり使用していないものはバッサリ切り捨てられており、Git自体の勉強をする本ではなく、実務でGitを使うための本になっていると思います。使い方によっては載っていない知識が必要な場合もあるでしょうが、それらが必要ならば入門書ではなく、しっかり勉強してください。と言うものです。

レビューに際しては「間違いにならない」を意識したこともあってか、見返すとレビューのコメント件数は結構すごいことになっていました。 イジメとか言うな。 お二人の努力により、ありがちな「わかりやすく感じるけれど誤っている」や「正しいけど伝わらない」などにはならず仕上げられているとは思うのですが、いかがでしょうね。

おすすめの対象は、これからGitを使う方もそうなのですが、なんとなく使っている方がドンピシャになると思います。今日にでも実務で使う人向け。って年末年始は使わないか。

そんなわけで年末らしいのだけど

別に年末感を感じず、ふつうにコード書いたりしてる大晦日です。餅くらい買ってこようかな。

Spring Security研修を受けてみました

カサレアルさんのSpring Security入門を受けてみました。

https://www.casareal.co.jp/ls/service/openseminar/java/j120

とてもよかったです。

受ける前Spring Securityの知識

ベースがPro Spring Securityです。そこにソースと実務経験、Spring徹底入門を加えた感じです。 なので3.xが土台で、そこから大きくは更新されてない状態。

Pro Spring Security

Pro Spring Security

受けていいのかどうか迷いましたが、

Spring Securityは初めてという方から、利用経験がある方まで幅広いレベルを対象としています。

という一文があったので、きっと対象。大丈夫。

受けた目的

Spring Securityに限ったことではないですが、自分の知識は断片的なんじゃないか、邪道なことをやっちゃってないか、なんてことをたまに思います。

あと、自分がSpringSecurityと同じ程度「わかってる」と思うものは、実際どの程度わかってるのかを測ってみたいというのもありました。

受けた結果

少人数だったこともあってか、特にトラブルもなく講義はサクサクと進みました。 おかげで質疑が多く取れて、突っ込んだり脱線したりした話しもできてお得感がありました。

f:id:irof:20181024210241p:plain たまたま持ってたし・・・。

内容は期待通り、断片的な知識がリンクされ、抜け漏れや曖昧なものが補強されていくのが実感できました。 これまでやってきたのも、そう間違ったものではなかったのはちょっと安心(これを確認するのはちょっと怖かった)。

f:id:irof:20181024210339p:plain (たまたま一緒に受講した かずひら さん)参加者が参加者だったので休憩時間の会話は休憩になってない感は酷かったですが、それは完全に予想外の何かです。

自分の理解の現在位置が確認できたし、Spring Securityに関して一段階以上レベルアップしたと思います。

(昨日までの私のような)研修を自分の意思で受けたことがない人は、ためしに受けてみるのもいいんじゃないでしょうかね。 今回は講師が多田さんだから安心して申し込んだというのもありますが、機会があったら他も受けてみようかなー。

おまけ

f:id:irof:20181024212326p:plain f:id:irof:20181024212334p:plain

ツイート時間参照。なお、9:30-17:00のコースです。

関連リンク

masatoshitada.hatenadiary.jp kazuhira-r.hatenablog.com

こういうのも、コミュニティで知り合った方と仕事で関わる一つの形かも。

Javaエンジニアからみた最近のJava事情

5/9(水) 大正GeekNight Vol.1で話しました。 https://taisho-geek.connpass.com/event/85508/

4ヶ月前のスライドです。 Javaのサポートについては続報も出てきていますし、思い込みで騒がないのが吉です。

いよいよ今月本命のJava11がリリースですね。どうなるかな。

ISBNを記録しておくChrome拡張つくった

f:id:irof:20180501103629p:plain

GWなのでこんなの作りました。

chrome.google.com

開いたページに載っている「ISBNっぽい数字」を雑に集めます。やってみたらすごく集まりました。慌てて消す機能つけました。

タイトルがわかるだけでもいいのですが、とりあえずAmazonを開けます。(買っても私に一銭も入りませんけど。) 他の検索がしたかったらタイトルを選択して右クリックから検索したらいいんじゃないですかね。Chromeなんだし。

適当に調べ物とかした後とかに見返すと、なんかいい感じかもしれません。積読タワーの肥料にどうぞ。

タブを整理するChrome拡張を作ってみた

TabutlerというChrome拡張を作って、Chromeウェブストアで公開しています。

chrome.google.com

Chromeのタブをお片づけしてくれる子。 完全に自分用なので、他の方の役にたつかどうかはわかりませんが、よろしければどうぞ。

作った経緯とか

今月のLT祭りの資料を参照ください。

ソースコード

ソースはGitHubに置いています。我ながら統一感のカケラもなくて笑える(笑えない)。

煮るなり焼くなりお好きにどうぞ。

アイコンのセンスは諦めてますが、ポップアップのHTMLはなんとかしたいというお気持ちはあります。お気持ちだけ。

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

「遅れ」なんてない

「頑張って遅れを取り戻す」

綺麗な言葉ですが、私は嫌いです。その中でも次の言葉が特に嫌いです。

  • 頑張る
  • 遅れ
  • 取り戻す

全部。これらが嫌いな理由をそれぞれ説明していきます。順番は「頑張る」→「取り戻す」→「遅れ」です。

なお、「頑張って遅れを取り戻す」に期待される結果は「他に一切の影響を与えず、遅れだけが綺麗になくなる」だと思われます。

頑張る

「頑張ってなかったん?」と言うと「頑張っていましたが、もっと頑張ります。」みたいなのが返ってきます。でもこれって多分「頑張る」と言われることが求められているからそう返してるだけで、もともと手なんて抜いていない。仮に手を抜いていたとしたら「頑張る」は「手を抜いていました」の宣言になるので、それを許容してる状態が問題になるんじゃないかな。

とか言葉遊びは置いておいて、現実の話をします。こういう文脈での「頑張る」は「長時間連続労働」に他なりません。そこでは「成果=労働時間」の等式が成り立つので、長時間連続労働たる頑張りが成果に直結するわけです。つまり「頑張る」とは「労働時間を稼ぐために長時間連続で労働します。」ということ。実にわかりやすい。

そのようなコンテキストであっても、直接言ってしまうと「成果は労働時間ではない」と返されます。じゃあ長時間連続労働以外の「頑張る」ってなにかを教えてもらいたいところです。仮に他の頑張り方があったとして、それは「頑張る」と表現されるものでしょうか。

私が「頑張る」が嫌いな理由は、言った側が言わされている言葉だから。 言った側は「自分の頑張りが足りなかった」と懺悔し、言わせた側は「懺悔を受け入れる代わりに罰を受けろ」と罰を与えるわけです。そして罰とは長時間連続労働。長時間労働の当然の結果として、イマイチなものが生まれるけれど、それはイマイチなものとは認識されません。「頑張って作ったもの」は聖域化するので、スバラシイものとして扱われます。実際は技術的負債を負って生み出した技術的資産なので、計画的に負債を返済すべきなんですが。

取り戻す

取り戻せない。不可能に挑むのはやめましょう。

取り戻せたシナリオ、つまり「遅れ」が「頑張る」で取り戻せたとして。それならば、遅れてなかった状態から同じことをしてれば、もっと進んでいることになります。それと比べれば遅れているので、永久に遅れはそのままです。

「いやいや頑張り続けることはできないので、それは机上の空論だ」というのはあるでしょう。これも頑張りが長時間労働の文脈だから成り立つ主張。長時間労働以外の頑張りを持ってきてください。それは遅れてない状態では不可能なんでしょうか。

続けられないものは、要するにリソースを消費するものです。例えばお金とかですかね。「遅れを取り戻すためにお金を使う」は一見もっともらしいのだけれど、やっぱり遅れてない状態でそのお金を使ったものと比べれば遅れたままなので、取り戻せてない。この辺りまで拡げてしまうと、遅れが取り戻せても資金は減ってるって話になる。

私が「取り戻す」が嫌いな理由は、言った側が言わされている言葉だから。 つまり「遅れなどなかった。いいね?」に対して「はい、遅れなどありませんでした!」と答えさせるのと同義なのが「取り戻す」という発言なのです。不可能を可能とする、虚偽の強要ですね。ひどい話だ。

遅れ

さて、本丸の「遅れ」です。「遅れ」なんてない。

あるのは遅れではなく、見積もりと現実の差分です。見積もりと現実の差分はただの差分でしかありませんが、きっと「現実が遅れている」よりは「見積もりが違っていた」と捉える方が建設的です。見積もりの正確性などの話は別にしたいところですが、見積もりと呼ばれる未来予測の精度を上げるには、見積もり(訪れるであろう未来)と現実(訪れた未来)の差分を計測することからはじまります。これを「現実が遅れている」とすると、見積もり精度の改善機会を逸することになります。見積もり精度を上げる必要がないなら、別に「現実が遅れている」のままで構わないと思います。

「遅れ」は比較対象がなければ存在できません。私は「遅れ」や「時間がかかっている」と聞くと、「それは何と比べて?」と聞いてしまうことがあるのですが、返ってくるのは「スケジュールと比べて」とか「他の人がやる場合と比べて」とかがほとんどです。

スケジュールとの比較による「遅れ」は「見積もりと現実の差分」です。見積もった人とその見積もりの影響を受ける人に差分を伝えれば有効活用できるかと思います。他者の見積もりと現実の差分を「遅れ」とするのは、見積もり精度の改善機会を奪います。自身の見積もりと現実の差分を「遅れ」と扱う先にあるのは、見積もりに合わせる技術の向上です。見積もりに合わせる技術には問題を隠蔽したり迂回したりする技術も多分に含まれます。これらは非常に役立ちますし、そういう仕事も重要なのですが、技術者として軸に置く技術としては微妙かなと思います。

他の人との比較による「遅れ」は・・・・比較対象の人が実施した現実は存在しないので、ただの妄想でしかありません。仮に具体的な人がいたとして、その人がその仕事を全く同じ条件でできたでしょうか。できるわけがないのです。だってやらなかったんだから。この手の発言は「自分がやった方が早い」という発言や、仕事を引き取った人があっさり片付けてしまったことなどから導き出されたものでしょう。ですが、起こっていない現実はどうなるかわかりません。なのでこれも「見積もりと現実の差分」として扱えます。見えている差分は、見積もり条件が「その人がやったら」に対して、現実は「自分がやった」になります。差分を分析すれば、見積もり精度の改善に活用できるかと思います。

比較対象の質問には、たまに「なんとなく」が返ってきます。こういう時ほど要注意だったりするのですが、状況がさまざまなので別の機会にします。

私が「遅れ」が嫌いな理由は、言った側が言わされている言葉だから。 言った側が「自分の不足で予定通りできなかった」と、言わせた側の責任を自発的に背負いこみます。この儀式は「見積もりは正しく、現実が間違っている」という状態を作り出します。言わせているのが見積もった側で、見積もりと現実に差分があると都合が悪いようなことをしているので、現実が間違っていることにしているのです。

現実を疑うのもたまにはいいかもしれませんが、休み休みやってほしいものです。

ようするに、私のために

「頑張って遅れを取り戻す」

頑張る、遅れ、取り戻す。いずれも言った側が責任を一身に背負おうとする言葉。英雄願望は他所でやってください・・・と思う気持ちもなくはありません。まあそれはそれとして。

私がこれらの言葉を嫌うのは、言った側が言わされている言葉だから。そんな言葉を3回も使っているので、すごくとてもかなり嫌いです。言わされる言葉が嫌いな理由も色々あるのですが、その中でも特に重要なのは「自己責任」にすべてがラッピングされることです。

自己責任に閉じられた世界は強固です。内側のものは容易に外に出てこなくなります。持ち主はまず中のものを外に出そうとしなくなり、出すにしても申し訳ない感じか、渋々と言った感じで出すようになります。持ち主だけでなく、外部からも干渉しづらくなります。お願いしないと出てこなくなるのでそもそも手間ですし、「その人が自分の責任でやろうとしているのだから手を出すのは失礼だ」とか色々理由をつけて視界を閉ざしてしまうことも、私はよくあります。

なので、自己責任にラッピングする前に、一度晒してみて欲しい。私のために。 その問題が改善の機会などの宝物じゃないかを確認してからでも遅くないと思うんですよ。

おまけ: それはそうとして、現実問題の「遅れ」はどうすんの?

その責任をとるのが、見積もりを使った人の仕事です。

もしあなたが見積もりを使う側でないのであれば、あなたに責任はないです。もし責任を引き受けたければ、その権限を得るのがいいと思います。権限もなしに、勝手に取れない責任を取ろうとしないでください。とはいえ、一技術者として「見積もりと現実の差分」にアプローチはできると思います。例えば検出したら即アラートをあげるとか、早期に検出できるように不確実なところから先に手をつけるとかですかね。その辺は矜恃に従ってやればいいと思いますが、責任の所在は別の話です。

もしあなたが見積もりを使う側であるならば、甘んじて受け入れてください。そして自身のできる最大限のことをしてください。「できること」の中には見積もった人や実施者を叱責することや、「遅れを取り戻す」ために何かを強要することも含まれるかもしれません。その結果がどうなるかもご自身の責任ですが。個人的には「「現実と差分があった見積もり」を使ってしまう自分」にアプローチするのがいいと思います。まあそれができる人は「この遅れどうするんだ!」なんて言わない気はするけれど。

追記: 綺麗事

「悪者なんていない」と綺麗事を書いておきます。

基本的に「頑張って遅れを取り戻す」は自発的に出てくるので、他者の意図は介在しません。私は嫌いな発言のことを考えるより、その発言が出た事象をどう見るかを考えるほうが好きです。

もし言わせた側に悪意があるのであれば、言わせた側が悪者でいいと思います。対処はその人(往々にして権力者なのだけど)をすげ替えるとか、面倒なんでとっとと脱出するとか、それも面倒なんで時間が過ぎるのを待つとか、色々あるので好きなように。まあ言わせる意図があったとしても、悪意があるのではなく、策がないだけだったりするのだけど。だって責任取れない人に責任押し付けても何も解決しませんから・・・。