jfluteの日記 このページをアンテナに追加

2018-08-11

デバッグパターン: うごかない、ほかうごくなら、ただひかく

|

ありがちなパターン

「動かないんですけど、原因が...」

という相談を受けまくるjfluteですが、
一瞬解決パターンが、よくあります。
その典型例が...

他のクラスでは動いてるんです
他の書き方では動いてるんです
他の環境では動いてるんです

などなど、他では動いているというパターン。

ただひたすらに比較

もちろん、

"エラーメッセージを読んで推測する"

これが真っ先にやることです。
jfluteの日記でも、何度も何度も
そういうブログを書いてきました。

それでもパッとわからないとき...

「うーんうーん、さらに推測、
機転をきかせて、仮説を立てて、
うーんうーん」

じゃなくて!

動いてるのがあるんだったら、
"動いてないもの" と "動いてるのもの" を、
比較してみよう!

試してから逆算

ほら、これが違う。

「でも、それって関係あるんですか?」

関係あるかどうかわかんないけど、
結果が違うんだから、とりあえず、
そこを同じにして試してみようよ。

ふむぅ、とくに変わらないな。
これは関係ないかもしれない。
もう一つ違うところがある。
これを同じにして試してみると...

あっ、結果が変わった。

ってことは、これこれこういうことだから...
だから、こうするとこうなって、
これが違うと動かなくなるんだ、
あーなるほど。

...

試した結果から、逆算して、
その原因の仕組みがわかることもあります。

動いてる似たものを探す

なので、動かないものがあったとき、
似たもので動いてるものがないかを探します。
それを聞いたりします。

「原因はなんだろう!?うーんうーん」

いいから似たもので動いてるものない?

あった瞬間に "ほぼ終わったな"
って思ってしまうくらいです。
比較できるものがあるとないとでは、
あまりに難易度が違うからです。

でも、それをやらずに、
壁の前で立ち止まっている人が多い、
という印象です。

立派な機転はほとんど要りません。
ただひたすら比較して検証するのです。

使う脳みそが違う

って聞くと、
あまりにも当たり前のことではないでしょうか?
なぜそれをやらずに突き進んでしまうのでしょう。

ひとつ思うのが、
"機転を利かせてアイディア待ちのデバッグ作業" と、
"二つをひたすら比較して検証するデバッグ作業" とでは、
ストレスが違うからかも!?

前者は、楽しいですし、できるとかっこいいでしょう。
でも、後者は多くの人にとってたぶんつまらないです。
あんまりやりたいことじゃないし、
そこに求められる能力も違うのではないかと思います。

自然と目を背けてしまうのかなぁ...とか。

仮説は検証の上にある

jfluteは、ここぞというとき、
一時間二時間ひたすら後者をやり続けることもあります。
試しづらい環境もあったり、違いがたくさんあり過ぎたり、
どうにもこうにも手がかりが
まったくないような現象もありますしね。

一時間二時間、雲をつかむような
アイディアのひねり出しをするのであれば...

一時間二時間、ひたすら比較分析をして、
雲の切れ間を探します。

到達して解決したとき...
「おおぉ、さすがjfluteさん、
これよくわかりましたね、すごい!」
とか言われたりもするのですが、
地味なことをただひたすらやっただけで、
あまり頭が良いわけではありません。
でも問題は解決した、良かった。

jfluteも "仮説検証" を強く推していますが、
"仮説検証" の "仮説" ばかりに気を取られてはいけません。
"検証" という工程があるからこそ "仮説" が生まれるのです。

どっちにも楽しみましょう(^^

...

// 逆にテーブルスキャンもできなきゃね
http://d.hatena.ne.jp/jflute/20150112/tablescan

// 問題分析と問題解決を分けることがハマらない第一http://d.hatena.ne.jp/jflute/20170712/analysissolving

f:id:jflute:20180709193600j:image

2018-06-28

セルビア、ブラジルにまさかの完敗

うっうっうっ...

ストイコビッチの好セーブ!
コラロフの献身!
ミリンコビッチ・サビッチの安心感!
タディッチの技!

も、虚しく、ブラジルに完敗です。
もう、ブラジルらしい攻撃されて、
ブラジルらしいパス回しで振り回されて...

いや、もうこれ以上思い出したくないです。
頑張りました。

若い選手が、育っています。
四年後、また新時代の選手が伸びて、
セルビア旋風が起きることを期待しましょう。

がんばれ、セルビア

2018-06-25

オートマティックおうむ返しコメントより背景や理由を

|

まさにおうむ返しコメント

講演で、ソースコードのコメントに関して、
話をするときのお約束パターンがこちらです。
// ライターを閉じる
writer.close();
見ればわかります!

writer が .close() してますから。 
writer, close という単語も
ほとんどの人が知っていますし、
知らなくても調べれば良いレベルです。

仮に、変数名とかメソッド名に文字数制限が
あったとしたら、意味があるかもしれません。
// ライターを閉じる
w.cl();
確かに...時にそういう場面があって、
そういうコメントを書くこと自体は
問題ではありません。ちゃんと理由があるから...

ただ、少なくとも今の時代、
そのような制限はあまりないでしょう。

...

さて、もうひとつ。
// 年齢に0を設定
setAge(0);
見ればわかります。

しかも、"0" って値までおうむ返ししているので、
こんな未来を想像してしまいます。
(仕様変更やバグ修正が発生して...)
// 年齢に0を設定
setAge(1);
具体的な値をコメントに書くのは、
さすがにやめるとします。
// 年齢を設定
setAge(0);
戻ってきました、
やはり見ればわかります。

...
...
...

オートマティックおうむ返し

まあ、時に、変数名やメソッド名から
やっていることが読み取れないようなケースで、
おうむ返しっぽいことをするのは仕方ないでしょう。

時に "自然言語業務名" とプログラム上の処理が、
直感的に結びつかないケースもあるかもしれませんし、
どうしてもそれを直すことができない、
という状況もあるかもしれません。
別にそれはそれで良いです。考えて判断してますから。

そうではなく...

必要かどうかを考えずに、
機械的にただひたすらおうむ返しする

というコメントがポイントです。

そういったコメントは、不要なだけでなく、
"ソースコード上のノイズ" になるので、
可読性に悪影響すら与えていると言えます。
なので削除した方が良いです。

それよりも、

「0 を設定するというのは、
業務的にどういう意味があるのか?」

「なんのために、
ここで 0 を設定しているのか?」

の方が知りたいことです。

背景や理由を書こう

月並みですが、
コメントは背景や理由などを書きましょう。
それってつまり...

コードから読み取れないもの

(もしくは、読み取りにくいもの)
を書くということです。

...

例えば、writer.close() において、

「通常、そのタイミングで close() は、
あんまりしないものだけど、なぜだろう?」

というように読み手が思うような
特殊な呼び出しであれば...
writer.close(); // 驚かせたくてこのタイミング
ということが書いてあれば、
「ああ、驚かせたかったんだ」と理解できます。

...

また、setAge(0) であれば...
setAge(0); // ここで生まれ変わる
ということが書いてあれば、
「ああ、また人生やり直すのか」と理解できます。

ただ、なんでここで生まれ変わるんだろう?
という疑問も生まれたりもするので...
setAge(0); // キャンペーンで永遠の命を得たので、ここで生まれ変わる
ということが書いてあれば、
「ああ、火の鳥サービスなんだ」と理解できます。

...

コメントは、人間のために書いています。
その人間が何を知りたいのか?
それを想像しながら書くものです。

オートマティックなおうむ返しコメントは、
本当に大切なコメントを、
意味のないコメントで埋もれさせてしまう
可能性があります。

# クラスやメソッドでうまくカテゴライズするなど、
# あまりコメント書かなくてもわかるようにする、
# という工夫もそれはぞれで心がけることですが、
# スキルの問題、時間の問題、費用対効果の問題、
# 色々と事情はありますから、
# どうせコメントというソリューションを使うなら、
# 知りたいことを書きましょうと。

機械的にできることに価値なし

「何も考えずに "コメントはこう書けばいい"
という機械的なルールが欲しい、あるべきだ」

という声も時々聞きます。

ですが、先ほどの通り、
コメントは人間のために書いています。
後でソースコードを読む人間の要求は、
なかなか定型化できません。
コメントはデザインなのです。
 => プログラマーに求められるデザイン脳

もし、機械的なルールでコメントが書けるとしたら、
そのコメントを書くのは人間である必要はないでしょう。
そういった機械的に導出できるのであれば、
自動生成するなどした方が良いでしょう。

プログラマーは、単なる作業員ではありません。
考えた結果に対してお金をもらっていると言えます。

考えることをやめたプログラマーに価値はありません

初心者時代の習慣が残ってる!?

しかしながら、
なぜこのようなおうむ返しコメントを
よく見かけるのでしょうか?

ひとつ思ったのは、
初心者時代の勉強用のコードにおいては、
そのようなコメントを書くことがあります。

まだそもそもプログラムの理解が浅く、
つどつど何をやっているのか解説しないと、
すぐにわからなくなってしまうからです。
解説を入れることで覚えるというのもあります。
英語の勉強をしているようなものです。

それがそのまま習慣化して、
業務プログラミングにおいても、
おうむ返しになってしまうのかもしれません。

jfluteは初心者の方のレビューをする機会も多いのですが、
必死に学ぼうとするためのコメントをよく見かけます。
研修のコードであれば、それ自体の指摘もしません。
ただ、ある程度進んできたら、
もうそろそろ要らないんじゃない?
って、言うように...しようかなって思い始めました(^^。
(もうそろそろっていつだろう...!?)

言い訳コメントも良い訳

時に、どうしても様々な事情で、
"普通" の実装ができなかったとしたとき、
言い訳のようなコメントを書きたくなることがあります。
// 開発期間がワールドカップ真っ最中で、
// セルビアがスイスに逆転負けをして、
// 残るブラジル戦で勝たないといけない状況になり、
// チーム全員へこんで集中できなかったので、
// もう無理やりなロジックでいったんリリース。
// (本当は、ああしてこうしたほうが良いと思う)
//  by jflute (2018/06/25)
logic.executeMuriyari();
すごく言い訳がましいですし、
世の中の「そんなコメント書くくらいなら...」
的なプレッシャーもあって、
ちょっとためらってしまうかもしれません。

でも...

一番良い解決ではないかもしれませんが、
七番目の解決よりは二、三番目の解決の方が良いです。
後からコードを読む人からしたら、
言い訳でも何も情報がないよりは100倍マシです。
仮にその言い訳が納得いかないものだとしても、
状況を知る上で、その後何かを判断する上で、
その言い訳コメントはなんだかんだ役に立ちます。
何も書いてなかったら疑いしか発生せず、
身動き取れなくなる可能性があるわけですから。

...

ちなみに、jfluteは、
こういういった言い訳コメント書くとき、
しばしば名前と日付を入れたりします。
(特に別の人がメンテするだろうコードにて)

こういうときは技術以外の事情も絡みやすいので、
誰が書いたか?ってのも判断要因の一つになりがちです。
いつ頃の話なのか?ってのも同様です。

gitの履歴を見ればわかることもありますが、
そんなコメントを読むということは、
切羽詰まっている可能性も高いですから、
履歴を探しに行く手間を省くのもそうですし、
わざわざ履歴を見に行ったりしないかもですし。
"悩むようだったら、すぐ俺に聞いてね" って感じで。

...

また、チケット管理システムの方で、
あれこれやり取りがある場合なんかは、
もうチケットへのURLをまんま貼り付けたりします。
最悪、それだけあれば読み手は状況を把握できます。
// https://.../WOLRDCUP_SERBIA-623
logic.executeMuriyari();

強調はあるかもしれない

強調という意味合いで、
おうむ返しっぽいことをすることも
あるかもしれません。

そこで、その処理をしていることが重要で、
目立たせないために書いてあるときなど。
(周りの処理に比べて特に重要で、
読み手にその処理があることを主張したいとき)
try {
    serbia.moveToStatium();
    serbia.warmingUp();
    serbia.winBrazil(); // ブラジルに勝つ!
    serbla.returnToHotel();
    serbla.sleep();
    serbla.wakeUp();
} catch (BoroBoroException ignored) {
    // ショックすぎて何事もなかったかのように振る舞う
}
確かにおうむ返しなので、
別に無くてもいいものではありますが、
まあ、これはこれでデザインです。

"コードから読み取れない強弱" を、
コメントの存在自体で表現しているので、
機械的なものではありません。
(ソースコードは、HTMLみたいに、
フォントサイズやフォントカラーで
装飾できないので)

「書きましょう」というほどのものではないですが、
「消しましょう」というほどのものでもないです。

読み手のことを考えた結果であれば、
この辺のデザインは自由で良いと思います。
jfluteも時々書きますよ。
(もうちょい派手に書くかもだけど)

カテゴリはあるかもしれない

カテゴライズしたくて、
おうむ返しっぽいコメントを書くことも
あるかもしれません。
// W杯でブラジルと試合をする
serbia.moveToStatium();
serbia.warmingUp();
serbia.winBrazil();

// 試合後にホテルで休む
serbla.returnToHotel();
serbla.sleep();
serbla.wakeUp();
serbla.goodMorning();
三つの処理をまとめて何々...
四つの処理をまとめて何々...

完全におうむ返しとは言えませんが、
コードから読み取れなくもない情報です。
でも、読み取るのにわずかに時間が掛かりそうです。
個々の処理を読んで抽象化をする必要があります。

読み手の読む労力を少し軽減させるための
コメントと言えるでしょう。
それを狙って書いているのであれば、
価値のあるコメントと言えます。

# メソッドにして表現するというやり方もありますが、
# ひたすら細かくメソッドにするのもキリがなく、
# それはそれで見づらくなる要因と考えて、
# バランスを取ってコメントで表現することもあるでしょう。

どちらかと言うと話

だんだん、"おうむ返しかどうか?" が問題というより、
"オートマティックで価値のないコメントかどうか?"
ということがポイントだと思えるようになってきました。

"価値がある、ない" というのは、
そのコメント自体の特性で決められるものではなく、
そのソースコード全体の特性、想定される読み手の状況、
などなど、コメントが置かれている状況が左右すると。

おうむ返しでも価値がある場面なら別に良いわけです。
価値を考えずにオートマティックに書きまくって、
ノイズコメントになってしまうと良くないわけで。

また、時間の問題もあります。時間は有限です。
おうむ返しコメントも書くの大変そうです。

その労力を背景や理由を書く方に使おう

そういうニュアンスでもあります。
例えば、背景や理由などがちゃんと書いてあった上での、
おうむ返しコメントであれば、そこまで問題にしません。

(でも、"そのコメントを書く時間省略して先に進んでいいよ"
くらいは言うかもしれません...)

(また、"そういうコメントを書かないといけない"
と勘違いしてるかもしれないので、"別に無くてもいいですよ"
くらいは言うかもしれません...)

...

こちらの記事もすごく参考になりました。
今回のブログを書くきっかけになった一つです。

Rubyコミッター・Yuguiに学ぶ、
コードに書くべき「適切なコメント」と「適切な場所」
 | エンジニアHub
 
...
 
そのコメントで伝えたいことはなに?

と聞かれて、些細な理由でもいいので、
明確に答えられるコメントを書きましょう。

f:id:jflute:20180625135635j:image

2018-06-23

セルビア、後はブラジルに勝つしかないぞ!

|

コスタリカに勝って、

やったーーーーーーーーーーー

スイスに前半1/0リードで、

やったーーーーーーーーーーー

もうグループリーグ突...

と思ったら、
後半すっかり足も止まって、
オフサイドラインもバラバラ...

これ絶対やられそうムードバリバリ、
と思ってたらお見事に。。。

...はぁ。
ちょっと、20年前のダヴィッツにグランダー
決められた時を思い出してしまいました><。

...
...

しかたない。
もうブラジルに勝つしかない!

がんばれセルビア!

...

タディッチのプレー見てて楽しいな。

2018-05-27

あれもこれもやらなきゃプレッシャーが集中力を阻害する

|

「あれもやったほうがいいよ」

「これもやったほうがいいよ」

「いろいろなことやらなきゃね」

うわーーーーー(><

...

って、気分の方いらっしゃいませんか?

定番のお悩み教室

jfluteは立場上、
様々な方のメンタリングをやらせて頂く機会が
多いのですが、これは本当に定番中に定番です。

特にここ数年 (4,5年くらい!?) は、
どんどん激しくなってきている気がします。
プログラミングの世界では技術が多様化し、
Webサービスにおけるエンジニアの役割が多様化し、
目指すキャリアも多様化しています。
世の中みんなそうかもしれません。

「いろいろなことやったほうがいいよ」

こういった声が先輩の口から、
物理的に聞こえてくることもあるでしょうし、
頭の中でその声を勝手に作り出すこともあるでしょう。

役に立たないことはない

まず、ひとつお伝えすること。
いまやってることでも...

ちゃんと追求していれば

それが役に立たないことはないよ、と。

追求した内容が直接役には立たないかもしれない。
でも、追求する過程での...

o スキルアップのための判断や行動力
o 追求したものを捉える論理性とバランス感覚
o 追求の壁を乗り越える経験

実は、追求した内容以外のスキルが
たくさん身に付いているのです。
しかも、追求したことによって、
それらを高いレベルで得られています。

野球一年だけ、サッカー一年だけ、
バスケット一年だけ、バレーボール一年だけ、
それはそれで得られるものもあるでしょうが、
高いレベルの悩みを経験できてない可能性があるのです。

あと、に追求した内容自体も
予想外役に立ったりしますよ。
何年も後に「役に立ったー」ってびっくりします。
思ったよりも、そのもの自体の価値を
理解していないもので。

こんな人は成長しない?

例えば、プログラミング言語Java,

「Javaばかりやっていたら、
全然成長しないよね」

それでは、こんな人はどうでしょう?

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
自分はJavaばっかりだ...Java人間と呼んでくれ。
今月は、ConcurrentHashMapのコードを読んで、
そのメカニズムを全部理解してみよう。
来月は、javax.crypto.Cipherを使いこなそう。
再来月は、マニアックなGeneric追求してみよう。
再再来月は、簡易なWebサーバーを自作してみよう。
再再再来月は、DIコンテナのコードを読んでみよ...
再再再再来月は、簡易なJDBCドライバーを自作し...
再再再再再来月は、O/Rマッパーのコードを読ん...
再再再再再再来月は、Webフレームワークのコード...
再再再再再再再来月は、Dukeの着ぐるみを作っ...
Javaの勉強終わんねー。
_/_/_/_/_/_/_/_/_/_/

さて、この人が Ruby のお仕事をやることに
なりました。全然使えないエンジニアでしょうか?

そりゃまあ、追求した内容自体は、
直接的には役に立たないでしょう。
ただ、その追求するパワーが Ruby に向けば、
ほんの数ヶ月で最低限の仕事では困らないくらいになって、
一年後には「ほんとにJava人間だったの?」って、
そうなる可能性は十分あります。

そういう方、たくさんたくさん見てきました。

追求は縦割りではない

また、追求というものは、
一つのものに固執するのが追求ではありません。
というか、「一つのものってなに?」って疑問も。

「Webサービスを一人で作れるようになりたい」

そういう追求であれば、
Javaをある程度、RDBはもちろん、
インフラも学んで、Swiftもちょこっとやって、
デザインも少し、利用規約など法的なことも...

一人のWebサービスの開発という、
一つのことを追求するわけです。

結局、どういう自分になりたいか?
どういう自分がいま求められているか?
それが "一つのもの" と言えるかもです。

一つの世界の中に色々なものもあります。
どの粒度に自分が立っているのか?
どの視点に自分を置きたいのか?

目の前の道具の表面だけで、
"一つに固執" とか "色々なもの" とか
議論してはいけないのでしょう。

...

もし、自分がどうなりたいのか?
まだよくわかってないようであれば、
気にせず目の前のことを追求しましょう。

誰が成長しないのか?

立ち止まってる人です。

一つのことばかりやってるとか、
色々なことをやっているとか、
あまり関係ありません。

種類数がいくつだろうが、
立ち止まってボーッと生きていたら同じです。

色々なことをやっている人はキラキラ見えます。
でも実はあたふたしてるだけかもしれません。

あれもこれもというプレッシャーで、
いま追求すべきものに集中できないこと

それが、成長を止めます。

...

「確実に自分が安心して成長できると
証明されたものじゃないと行動できない...」

このように考える人もいるかもしれません。
残念ながら証明できる人は地上には存在しないので、
その心の足かせを解くメンタリングが必要でしょう。

...

さあ、

「ボーっと生きてんじゃねえよ!」

と叱られないように。

集中力が自分を助ける

さて、この悩みは、
jflute自身も例外ではありません。
いまでもそのプレッシャーに襲われます。

DBFluteばかりやってきました。
JDBCにはめちゃ詳しくなってきたけど、
でも全然実務じゃ役に立たない。
働きながらもプライベートはDBFluteばかり、
知識は非常に偏ります。

それはコンプレックスありました。
いまもあるっちゃあります。
もともと初心者からの社会人でしたしね。

でも、ひとつ言えるのは...

集中力は切らさなかった

ということでしょうか。

...

こんなことがありました。

jfluteがフォロー先のオフィスにいて、
とあるWebデザイナーの方から相談を受けました。
珍しいので、ちょっとびっくりしながら、
jflute「何でしょう?」
デザイナーIEでこのデザインが...CSSで...」
jflute (知らねー><)

まあ、色々と技術的な相談を受けるという立場で、
「なんかすごい人いる」という話だけ伝わってたようで。
まあ、業務上のスコープが正式に違うので、
「ちょっと専門外で...」って言えなくはないのですが、
「なーんだ」って思われるのもなんか怖くて(><、
話を聞いてしまいました。

わりと複雑な話になっていて、
その方も解決の焦点が定まってなかったので、
ヒアリングもして、質問の分析と問題の分析をして、
いま何を調べてどうアプローチすれば、
その答えに辿り着きやすいか?
そこをまとめてアドバイスをさせて頂きました。

そこで話は終わって、その後しばらくすると...
「jfluteさんの通り調べたら解決しましたー。
助かりました、ありがとうございます!」

jflute (ふおぉぉぉぉぉー、あぶねー)

これは少し極端な例でしたが、
こういったことが実はたくさんあります。
プログラミングの世界の中だって、
様々なレイヤがありますから。

技術のアドバイスをしているんじゃなくて、
問題分析と問題解決のアドバイスをしている、
ということなのかもしれません。

でも、jfluteは別に、
コンサルタントだったわけじゃありません。
それができるのは、集中力を切らさず、
DBFluteの問題ばかりひたすら解決する中で、
そのイベントで考えたプロセス抽象化し、
汎用的な問題分析や問題解決セオリーを意識し始めて、
それをずっと積み重ねてきたから、と言えるかもです。

そういったスキルが昔よりもアップしたことで、
別の技術を習得するときに、
昔よりも効率良く吸収できてると実感します。

また、追求するというパワー自体を衰えさせなかったことで、
追求すべきものが変わってもすぐに追求できるのだろうと。

# でも、ドキドキするから、
# あんまりぼくの知らないこと
# 聞き過ぎないでください笑。

だから、だいじょうぶだよ

なにか積み重ねてるなら、あんまり心配ないですよ。
積み重なってるかどうかに気付いてないのであれば、
それは一緒に見つけましょう。

...

こんなブログも書いてましたね:

// まず何より、目の前の道具を使いこなしてください
http://d.hatena.ne.jp/jflute/20180223/mastercurrent

// プログラマー多様化の時代に教える難しさ
http://d.hatena.ne.jp/jflute/20140909/diversity

f:id:jflute:20171204213156j:image

にゃんだむにゃんだむ 2018/05/27 19:44 JDCGはお疲れ様でした!
イベントは行けなかったのですがjfruteさん登壇を前日に知りすごく悔しかったです(笑)

今日のエントリーもすごく参考になりました。今、色々なところからあれもこれも勉強したほうがいいと言われ優先順位が全て優先!→何から手をつければいいんだ〜💫状態になっていたので
今回のエントリーを読んで、目的を持って一つ一つ掘り下げて進んでいけばやがて実を結ぶんだという勇気を貰いました。
DBflute自体を使えるほど自分のスキルが追い付いていないのが悔しいですが、年内には触れるようになります(>_<)

jflutejflute 2018/05/27 20:15 にゃんだむさん、嬉しいコメントありがとうございます!(^^。
登壇のお知らせが直前で申し訳ありませんでした。またの機会にぜひ!

> 優先順位が全て優先!
そうなってしまいますよね。今回のエントリーが少しでもお役に立てば幸いです。

> DBflute...年内には触れるようになります(>_<)
ありがとうございます!応援してます、がんばってくださいー。