5/9(水) 大正GeekNight Vol.1で話しました。 https://taisho-geek.connpass.com/event/85508/
4ヶ月前のスライドです。 Javaのサポートについては続報も出てきていますし、思い込みで騒がないのが吉です。
いよいよ今月本命のJava11がリリースですね。どうなるかな。
ISBNを記録しておくChrome拡張つくった
タブを整理するChrome拡張を作ってみた
TabutlerというChrome拡張を作って、Chromeウェブストアで公開しています。
Chromeのタブをお片づけしてくれる子。 完全に自分用なので、他の方の役にたつかどうかはわかりませんが、よろしければどうぞ。
作った経緯とか
今月のLT祭りの資料を参照ください。
ソースコード
ソースはGitHubに置いています。我ながら統一感のカケラもなくて笑える（笑えない）。
煮るなり焼くなりお好きにどうぞ。
アイコンのセンスは諦めてますが、ポップアップのHTMLはなんとかしたいというお気持ちはあります。お気持ちだけ。
本
初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発
- 作者: Ethan Brown,武舎広幸,武舎るみ
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/01/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「遅れ」なんてない
「頑張って遅れを取り戻す」
綺麗な言葉ですが、私は嫌いです。その中でも次の言葉が特に嫌いです。
- 頑張る
- 遅れ
- 取り戻す
全部。これらが嫌いな理由をそれぞれ説明していきます。順番は「頑張る」→「取り戻す」→「遅れ」です。
なお、「頑張って遅れを取り戻す」に期待される結果は「他に一切の影響を与えず、遅れだけが綺麗になくなる」だと思われます。
頑張る
「頑張ってなかったん？」と言うと「頑張っていましたが、もっと頑張ります。」みたいなのが返ってきます。でもこれって多分「頑張る」と言われることが求められているからそう返してるだけで、もともと手なんて抜いていない。仮に手を抜いていたとしたら「頑張る」は「手を抜いていました」の宣言になるので、それを許容してる状態が問題になるんじゃないかな。
とか言葉遊びは置いておいて、現実の話をします。こういう文脈での「頑張る」は「長時間連続労働」に他なりません。そこでは「成果＝労働時間」の等式が成り立つので、長時間連続労働たる頑張りが成果に直結するわけです。つまり「頑張る」とは「労働時間を稼ぐために長時間連続で労働します。」ということ。実にわかりやすい。
そのようなコンテキストであっても、直接言ってしまうと「成果は労働時間ではない」と返されます。じゃあ長時間連続労働以外の「頑張る」ってなにかを教えてもらいたいところです。仮に他の頑張り方があったとして、それは「頑張る」と表現されるものでしょうか。
私が「頑張る」が嫌いな理由は、言った側が言わされている言葉だから。 言った側は「自分の頑張りが足りなかった」と懺悔し、言わせた側は「懺悔を受け入れる代わりに罰を受けろ」と罰を与えるわけです。そして罰とは長時間連続労働。長時間労働の当然の結果として、イマイチなものが生まれるけれど、それはイマイチなものとは認識されません。「頑張って作ったもの」は聖域化するので、スバラシイものとして扱われます。実際は技術的負債を負って生み出した技術的資産なので、計画的に負債を返済すべきなんですが。
取り戻す
取り戻せない。不可能に挑むのはやめましょう。
取り戻せたシナリオ、つまり「遅れ」が「頑張る」で取り戻せたとして。それならば、遅れてなかった状態から同じことをしてれば、もっと進んでいることになります。それと比べれば遅れているので、永久に遅れはそのままです。
「いやいや頑張り続けることはできないので、それは机上の空論だ」というのはあるでしょう。これも頑張りが長時間労働の文脈だから成り立つ主張。長時間労働以外の頑張りを持ってきてください。それは遅れてない状態では不可能なんでしょうか。
続けられないものは、要するにリソースを消費するものです。例えばお金とかですかね。「遅れを取り戻すためにお金を使う」は一見もっともらしいのだけれど、やっぱり遅れてない状態でそのお金を使ったものと比べれば遅れたままなので、取り戻せてない。この辺りまで拡げてしまうと、遅れが取り戻せても資金は減ってるって話になる。
私が「取り戻す」が嫌いな理由は、言った側が言わされている言葉だから。 つまり「遅れなどなかった。いいね？」に対して「はい、遅れなどありませんでした！」と答えさせるのと同義なのが「取り戻す」という発言なのです。不可能を可能とする、虚偽の強要ですね。ひどい話だ。
遅れ
さて、本丸の「遅れ」です。「遅れ」なんてない。
あるのは遅れではなく、見積もりと現実の差分です。見積もりと現実の差分はただの差分でしかありませんが、きっと「現実が遅れている」よりは「見積もりが違っていた」と捉える方が建設的です。見積もりの正確性などの話は別にしたいところですが、見積もりと呼ばれる未来予測の精度を上げるには、見積もり（訪れるであろう未来）と現実（訪れた未来）の差分を計測することからはじまります。これを「現実が遅れている」とすると、見積もり精度の改善機会を逸することになります。見積もり精度を上げる必要がないなら、別に「現実が遅れている」のままで構わないと思います。
「遅れ」は比較対象がなければ存在できません。私は「遅れ」や「時間がかかっている」と聞くと、「それは何と比べて？」と聞いてしまうことがあるのですが、返ってくるのは「スケジュールと比べて」とか「他の人がやる場合と比べて」とかがほとんどです。
スケジュールとの比較による「遅れ」は「見積もりと現実の差分」です。見積もった人とその見積もりの影響を受ける人に差分を伝えれば有効活用できるかと思います。他者の見積もりと現実の差分を「遅れ」とするのは、見積もり精度の改善機会を奪います。自身の見積もりと現実の差分を「遅れ」と扱う先にあるのは、見積もりに合わせる技術の向上です。見積もりに合わせる技術には問題を隠蔽したり迂回したりする技術も多分に含まれます。これらは非常に役立ちますし、そういう仕事も重要なのですが、技術者として軸に置く技術としては微妙かなと思います。
他の人との比較による「遅れ」は・・・・比較対象の人が実施した現実は存在しないので、ただの妄想でしかありません。仮に具体的な人がいたとして、その人がその仕事を全く同じ条件でできたでしょうか。できるわけがないのです。だってやらなかったんだから。この手の発言は「自分がやった方が早い」という発言や、仕事を引き取った人があっさり片付けてしまったことなどから導き出されたものでしょう。ですが、起こっていない現実はどうなるかわかりません。なのでこれも「見積もりと現実の差分」として扱えます。見えている差分は、見積もり条件が「その人がやったら」に対して、現実は「自分がやった」になります。差分を分析すれば、見積もり精度の改善に活用できるかと思います。
比較対象の質問には、たまに「なんとなく」が返ってきます。こういう時ほど要注意だったりするのですが、状況がさまざまなので別の機会にします。
私が「遅れ」が嫌いな理由は、言った側が言わされている言葉だから。 言った側が「自分の不足で予定通りできなかった」と、言わせた側の責任を自発的に背負いこみます。この儀式は「見積もりは正しく、現実が間違っている」という状態を作り出します。言わせているのが見積もった側で、見積もりと現実に差分があると都合が悪いようなことをしているので、現実が間違っていることにしているのです。
現実を疑うのもたまにはいいかもしれませんが、休み休みやってほしいものです。
ようするに、私のために
「頑張って遅れを取り戻す」
頑張る、遅れ、取り戻す。いずれも言った側が責任を一身に背負おうとする言葉。英雄願望は他所でやってください・・・と思う気持ちもなくはありません。まあそれはそれとして。
私がこれらの言葉を嫌うのは、言った側が言わされている言葉だから。そんな言葉を3回も使っているので、すごくとてもかなり嫌いです。言わされる言葉が嫌いな理由も色々あるのですが、その中でも特に重要なのは「自己責任」にすべてがラッピングされることです。
自己責任に閉じられた世界は強固です。内側のものは容易に外に出てこなくなります。持ち主はまず中のものを外に出そうとしなくなり、出すにしても申し訳ない感じか、渋々と言った感じで出すようになります。持ち主だけでなく、外部からも干渉しづらくなります。お願いしないと出てこなくなるのでそもそも手間ですし、「その人が自分の責任でやろうとしているのだから手を出すのは失礼だ」とか色々理由をつけて視界を閉ざしてしまうことも、私はよくあります。
なので、自己責任にラッピングする前に、一度晒してみて欲しい。私のために。 その問題が改善の機会などの宝物じゃないかを確認してからでも遅くないと思うんですよ。
おまけ: それはそうとして、現実問題の「遅れ」はどうすんの？
その責任をとるのが、見積もりを使った人の仕事です。
もしあなたが見積もりを使う側でないのであれば、あなたに責任はないです。もし責任を引き受けたければ、その権限を得るのがいいと思います。権限もなしに、勝手に取れない責任を取ろうとしないでください。とはいえ、一技術者として「見積もりと現実の差分」にアプローチはできると思います。例えば検出したら即アラートをあげるとか、早期に検出できるように不確実なところから先に手をつけるとかですかね。その辺は矜恃に従ってやればいいと思いますが、責任の所在は別の話です。
もしあなたが見積もりを使う側であるならば、甘んじて受け入れてください。そして自身のできる最大限のことをしてください。「できること」の中には見積もった人や実施者を叱責することや、「遅れを取り戻す」ために何かを強要することも含まれるかもしれません。その結果がどうなるかもご自身の責任ですが。個人的には「「現実と差分があった見積もり」を使ってしまう自分」にアプローチするのがいいと思います。まあそれができる人は「この遅れどうするんだ！」なんて言わない気はするけれど。
追記: 綺麗事
「悪者なんていない」と綺麗事を書いておきます。
基本的に「頑張って遅れを取り戻す」は自発的に出てくるので、他者の意図は介在しません。私は嫌いな発言のことを考えるより、その発言が出た事象をどう見るかを考えるほうが好きです。
もし言わせた側に悪意があるのであれば、言わせた側が悪者でいいと思います。対処はその人（往々にして権力者なのだけど）をすげ替えるとか、面倒なんでとっとと脱出するとか、それも面倒なんで時間が過ぎるのを待つとか、色々あるので好きなように。まあ言わせる意図があったとしても、悪意があるのではなく、策がないだけだったりするのだけど。だって責任取れない人に責任押し付けても何も解決しませんから・・・。
既存を正解とする減点ゲームへの違和感
オンラインミーティングとか、リモートワークとか、インターネットを介する話のメリットデメリットとかをみていると、「既存になるべく近づけよう」としているところに違和感を感じてる。
電子書籍もそうで、いかに紙をデジタルで表現するかに腐心しているように感じる。ページめくりのエフェクトなんて要らないのだけど、一時期ついてたりしたよね。紙っぽさにヒントはあるかもしれないけど、紙っぽくある必要はないはずなんだ。
差は減点対象となり、足切りとして機能している。減点ゲームをクリアしないと候補にもならない。そういう事実はある。けれど、足切りになりうる欠陥と、欠陥でないただの差異を混同している感じがする。
完全な代替なんてできないなんて認識は誰もがしているはずが、油断するとどこかに置いてきてしまいがち。ときに完全な代替ができることを宣言させられる圧力もあったりする。よくわからないけれど、そうでないと（それくらいでないと）進められないとかなんとか、言わせた側からはそんなよくわからない話も聞く。嘘をつかせる儀式に何の意味があるんだろう。
いくらデジタルにアナログっぽさを求めても、極限までアナログに近づけたデジタルはアナログの劣化コピーにしかならない。そんなことはわかると思うのだけど、それでも細かいところまでアナログっぽさを求めてる感じがする。
いくつかの理由づけはできなくはない。例えば「ただ変化を嫌っているだけ」とか。派生になるけれど「既存から変わるのを良しとしない人々を抵抗勢力と見立て、それを封殺するために既存を満たした上でメリットを強調したい」とか。後者は暴走品質を生み出す考え方の一つだと思う。
だからと言って妙案があるわけではない。 私は電子辞書と紙の辞書は両方使うけれど、使う場面は明らかに違う。仕事もリモートでいいものもあれば「これは対面だなぁ」と思って調整することも多々ある。漫画も紙、Kindle、iPhone、Macとまちまちで、今の所どれかに統一される気配はない。
きっと過渡期なんだろう。もしかしたら違うものが同じ名前で呼ばれているだけなのかもしれない。今「仕事」と言ってるものは、2種類（もしくはそれ以上）に分割され、仕事Aはリモートが当然で、仕事Bは対面が当然、みたいな感じになって、それらが「仕事」と一緒くたに呼ばれていたことなんて忘れられるのかもしれない。
とりあえずスクロールの漫画はとても良いと思う。あれは紙じゃ無理だ。できれば1話ごとに読み込みとかにせず、延々とスクロールさせてほしいもんだ。Kindleの合本も悪くないけれど、あれやるなら索引はちゃんとやってほしい。一昔前のゲームブックをデジタルで表現するなら読み進めながら文章が変化していく感じかなーと思ってたけど、よく考えたらそれってアドベンチャーゲームが済ませてるな。そこから少し捻ると、マニュアルとか技術書は利用者に応じて文章が変化していったりするといいよなーと思ったりする。読み飛ばすところもあるし、読む順番も人によって変わるのだから、その人の読みたい感じに構築されるようなのはどうかなーと。
ともかく、既存と比べて劣ってるところを何とかするのに注力するのはほどほどにしていいんじゃないかなー。コストに対して得られるものの上限は見えてるわけだし。対処するにしてもそのまま再現するんじゃなく、エッセンスを抽出して取り入れる方向で考えたいなと。
Tech Deep Dive #2 in Osakaに参加して思ったこと
Tech Deep Dive #2 in Osakaに「ブログ書いてくれる人」の枠で参加したので、書きます。枠空いてたので一般参加枠でもよかったんだけど、なんとなく。
Webアプリに低レイテンシ・高可用性を求めるのは間違っているのだろうか reloaded
www.slideshare.net
再演ということでスライドは公開されています。reloadedということでいくらか更新/調整は入っていますが、大筋はこの通りでした。
話は「性能」と「可用性」をポイントとしていて、その背景に「クラウドにより技術がコストに直結する」という話は新鮮でした。性能が悪いと高価なインフラが必要になる。即時復旧やデータ整合性がコストに直結する。オンプレだと初期に固定されていたものが可変なパラメータとなったことで浮き彫りとなっている形ですね。
よくあるWebアプリケーションの構成をあげて、性能や可用性の面でどこが問題となり得るか。ある程度簡略化された構成だからこそ、それぞれの場所と結合部分に何かしらの問題がありえることは当然かと思います。これはスライドの図がわかりやすいですね。
ああ、うんあるある。
タイトルの「高レイテンシ」を話は、ECサイトでどれだけの人数の同時購入を短時間に捌けるかと言ったシナリオ。パターンとして2種類、10,000商品に購入がそれなりに分散される場合と、1つの商品に購入が集中する場合。スケールアウト/スケールアップが効きやすい前者と、スケールアウト/アップが効きづらい後者というわかりやすい対比ですね。ここにキャッシュとインメモリデータグリッドのアプローチがどのような影響があるかの実測値で示され、確かにそうなるよねーと。
アーキテクチャや計測結果から読み取れることの説明を通して「この場合はこういうことが考えられる、こういう問題が起こり得る」と言った話が入り、実践する前に知識として持てているとだいぶ違います。
事象を聞いていると、2014年のJavaDayTokyoでせろさんが話された 実例Javaトラブルシューティング！ 〜稼働中のシステムを立て直した半年間の軌跡 の「DBがボトルネックなのに なんでAPサーバを スケールアウトするの？」とかを思い出しました。
キーワード
- 今の負荷は将来の負荷ではない
- 障害の復旧時間を（事前に）測っていますか？
- クラウドだと気軽にスケール頼りになっておかしくなる
もしもみなみんがアプリケーション開発者だったら
www.slideshare.net
前の話をうけて別の視点から、連続セッションだからこそできる話だと思いました。「構成を考えるのはできるけれど、実際作るのは難しい」とか、パフォーマンスの問題になったら「気軽に並列度をあげてたりすると、別のところに予期しない影響を与えるものだから徐々にしましょう」とか、「シャーディングは適切に分散されるように設計しないと効果がない」とか。
セッションはオペミスや性能などのよくある問題を挙げて、それに対する一般論の解決案が起こしうる問題の説明、理想的な解決や現実的な解決の提示という形で構成されていました。いくつかは踏んだこともあり、心当たりがありそうな参加者も多かったのが印象的でした。
インフラ側の言葉は初耳なものも多かった。
キーワード
- 時間↓ = 処理量↓ / （速度 * 並列度）↑
- まずは処理量をなんとかしましょう
感想
前提知識のハードルが高めに感じましたが、内容自体は一般的な知識の範囲で説明できるものだったと思います。それらを繋ぎ合わせてひとつなぎにしているところにこのイベントの価値があるのかなと思いました。ここで話された一通りを3時間程度で話せる気はしないので、素直にすごい。
一般的な知識の範囲とは言うものの、ギリギリいっぱいまで満たされていたと思います。ここから踏み込んだら現場の背景も全部入れないと的外れで「あー、うん、そうですよねー」な話にしかならない気がします。
と言うことで、経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。
以下、ポエム
仕事スイッチが入ってしまい、純粋に技術の話として楽しめなくなったポエム書きます。「Tech Deep Dive」に技術だけを求めた私の期待が外してただけなんでしょうけど、「おースゲー！なるほどー！」ってなりたかった。
事前にパフォーマンスを含めてアーキテクチャを検討する。もちろん重要なのですが、そんなの考えても仕方ないから今は考えないでおこうぜというバランスがあります。例えば「今はそれは考えない、何故なら・・・。このような条件が整ったら検討をはじめ・・・。それで間に合うように・・・・。」と言った判断を保留するアーキテクチャを採用する（かどうかすらも判断する必要があります）。このような「今は考えないでおこうぜ」という判断をするために、このイベントでの語られた知識は持っておく必要はありますが、その道具を常に振るうべきかというと否です。このバランスを取れない人にはミスリードになるのではないかと思ってしまいました。（そういうエンジニアは存在して、悪いとは言いづらいのだけど、そういう人が「エンジニアは話が通じない」と思われる原因になってるよなーというのもあって、もにょもにょ……）
例えば「10,000商品」と「1商品」と言ったシナリオがありましたが、これもECサイトならよくあるのかもしれませんが、そのプロダクトが扱う業務の性質としての取捨選択の上で成立するものです。少なくとも「1商品に注文が殺到し、それが同期処理でなければならず、待たせることがビジネスリスクだったり、本来得られるはずの利益を損ねる」ところまでが前提であり、そうでないものには無用の長物です。もちろんそんなことは当然の前提としているのだとは思うのですが、なんとなく「こういうのがあったらよくないですか？」みたいなところから銀の弾丸臭がすごく感じました。技術ってそういうものじゃない、と私は思ってます。
「xxxできたら嬉しく無いですか？」ってのは最近流行りなのかなー。銀行とかでもよく聞くのだけど。なんかよくわかんないけど、この言葉聞くと警戒しちゃう自分がいる。
— いろふ＠ふろい (@irof) 2018年3月17日
「インメモリデータグリッド最強」で話が終わるところにはなんとも言えません。この解決策が招く問題もあり、そちらを対処できなければ他のところに問題が移動するだけです。他と比べて重視しているものが違うという口頭でのやりとりもありましたが、それまで他のアーキテクチャでの懸念を挙げていたのにここだけ語られなかったところに疑問はありました。もちろん「でも、お高いんでしょう？」という話もありましたし、ハードウェアスペックがボトルネックにならないのも前提として提示されてはいますが、インメモリデータグリッドがパフォーマンスを発揮する前提条件がそもそも満たされないことも多くあります。認知度が低いのも確かに事実ではあるのですが、ミッションクリティカルシステム以外で使われない理由はそれだけではないわけで。
また気になったところとして、「アプリはインフラを意識したくない」というものの実現手段。疎結合は意識するところなのですが、「これで意識しなくていい」という方法がDAOの実装差し替えだとすると、これは多くの場合アプリケーションエンジニアの意識すべきレイヤーにあります。SQLを書かない世界（JPAでJPQLすら書かない場合などでしょうか）では妥当なのかもしれませんが、データベース設計などがアプリケーションエンジニアの守備範囲にある以上、意識せざるを得ない状況は変わりません。これを下手に「意識しなくていい」と言ってしまうと不適切に伝わる現場もあるのは悩ましいところですね。
金の弾丸は大抵の場合に有効です。適切なところに投資すれば、多くの場合にコストは抑えられるものです。一方、慎重になりすぎてか単にケチなのかはわかりませんが、このイベントで語られたようなものに一切手を出さず、独自技術症候群なのかなんなのかは知りませんが、力技で手当たり次第に場当たり対処して結果的に高くついているプロジェクトも多くあるのも悩ましいところです。
こういうのは金出すところを見極めなきゃなの。で、見極めるためには見極めるスキルに金を出さなきゃなの。その辺をケチるから、安物買いの銭失いになる。 #oratdd
— いろふ＠ふろい (@irof) 2018年3月17日
このイベントに限らず、アプリ/インフラと分けられた文脈で「意識しなくていい」「考えなくていい」という話はよくされます。でも「考えなくていい」というのはちょっと違うんじゃないかなと思いました。むしろ考えないためは知識を持つ必要があるはずです。知らずに領域を侵すことは頻繁にあり、それは知識が無いと止めるすべはありません。認知の外ってやつですね。知った上で、考えないでいいようにと言うよりも、邪魔しないように、適切に扱う必要があります。こういうものに「意識しなくていい」「考えなくていい」「勝手にやってくれる」となった瞬間に、なぜか「その領域の知識を持たなくていい」と解釈されるものなんだよね・・・違うよね。
とかなんとかだらだらと書きましたが、イベントも話もとても良かったとは思っています。長時間セッションで疲れたってのはありますが、続けて開催されるなら参加したいなぁ。
ベタープログラマ第二部の感想
第二部「練習することで完璧になる」を読みました。
読んだのは15,16,17,19,22章。15章は16,17章を読んでたら「我々のチームの三つの規則」として触れられてたので。
15章 規則に従って競技する
いろんな規則があるけれど「自分達で決めた規則が必要」とあります。規則は自分達のためにあるってやつですね。著者のチームでは以下の3つの規則が挙げられています。
- 単純に保つ
- 頭を使いなさい
- 変わらないものはない
これらの規則についてはそれぞれ別の章で語られていて、15章は規則のありかたが書かれています。この章で重要なことは、要点の囲みにも挙げられているこれだと思います。
曖昧で記述されていないチームの「規則」に頼らないでください。暗黙の規則を明示して、コーディングの文化を統制してください。
たまに見るのが、暗黙の規則が勝手にあると思い込んで「こうしないといけないと思っていました」「こうするものじゃないんですか？」というの。自分の書いたコードを説明するのを阻む、思考停止の臭いがします。こういうのを私は「呪い」って呼んでて、その解呪の方法の一つかなと。そもそも自分達で自分達のための規則を作れるなら、そんな呪いにかからないと思うけど。
16章 単純に保つ
KISS（Keep It Simple, Stupid）のことかと思ったし、確かにKISSについて書かれてました。けど単純とは何かってところに踏み込んでます。昔似たようなこと書いたなーと思ったので引っ張り出してみる。
コードに凝れば凝るほど、コードはシンプルになり、言われるような "凝ったコード" から離れていくと思う。
さて、本では単純さを「誤った種類の単純さ」と「正しい種類の単純さ」の2種類に分けています。
「誤った種類の単純さ」は、物事を単純に捉えてしまうことで「極度に単純化されたコード」を生み出し、逆に物事を複雑にしてしまうことになると書かれています。これは心当たりがある方も多いでしょう。そして「正しい種類の単純さ」を保つためにどのようなアプローチをとるかが挙げられています。
コードのエントロピーも増大していくものです。ですが、増えるのを放置して手に負えなくなったらスクラップ＆ビルドする以外にも、抑える方法はあるはずです。私の場合、例えば修正前後のコード量を見ます。コード量が想定以上に増えていないかってところですね。なんなら機能追加してもコード量が減っていなかったら、余計な複雑性を作り込んでいないかを確認します。数字はあくまで指標の一つでしかないので、使い所に注意は必要ですが。
17章 頭を使いなさい
この章は16章を前進させる規則ですね。曰く「Keep it simple, stupid. don't be stubid.」と。愚かになるのは典型的なギークの問題であr、コーディングの専門家でもやってしまうのだから、仕方ない。でもそれは愚かなままでいていいと言う意味ではありません。ちょっと時制に込められた意図が読み取りづらい章だなーとは思いましたが、勇気を出して失敗を認めて誤りを直そう、とかそんな感じです。愚かなコードや設計をしたからといって、「自分を失敗者と考えないでください」とあります。失敗はしていい。
「愚かなコードを書かないでください。」「不注意にコードを書かないでください。」などと書かれていますが、これはちょっと難しいかなー。書いたコードを落ち着いて見直して、直したい。私は。
さて、この章で抜粋したいのはこの文章。
あるコード部分に取り組むときには、その形と構造に関して意識的な決断を行なってください。コードを所有してください。そのコードに対する責任を持ってください。
「意識的な決断」や少し前に使われている「説明責任」などは普段使っている言葉に近くて共感を持てました。 コードをどまんなかに // Speaker Deck とかで言ってるつもりです。
19章 コードを再利用するケース
再利用のケース4種類が挙げられて、それぞれについて考察されています。一つ目の「コピー＆ペースト」はすごく嫌ってますね。ウェブ上で見つけたコードをそのまま貼り付けるな、とかも書いてます。なんか微妙な感じのコードがコミットされてる時とか、それをググったらコメントまで一致するのが引っかかってくるとか、たまにありますね。ああ言うのをやめてほしいなーってのは同意。でもコードのコピペ自体は私はよくやるんだよなぁ。昨日もやったし……。
22章 凍結されたコードの数奇な人生
コード凍結に対する、どのようなものがコード凍結と呼ばれるものにあるかが整理されています。もちろんブランチ戦略による凍結のない世界についても語られ、凍結しない世界を目指してほしいとも書かれています。
この辺はいまだに過渡期だなーと思います。凍結せずにできているもの、凍結させずにできないかと試行錯誤しているもの、凍結ありきから変化しない動こうとしないものも多くあり、その中には凍結しないことがメリットにならないものもあります。とはいえもはや凍結ありきの世界観ではないので、対応できる術は持っておかなきゃでしょうね。
第二部の感想
普段言ってることに近いこともあってか、正直薄味でした。どの章も短めだったし。他の人に説明するときの語彙は増やせたかなーくらいで、この部に書かれてることから新たなことを見出すのは難しい感じでした。見落としてるだけかもしれないけれど。
一方、ここまで書いているようなことを「はいはい、あのことねー」とならない方は読めば知の高速道路に乗れるかもしれません。エッセイだけあってちょっと他の本には書かれてないものなので、お勧め。
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
- 作者: Pete Goodliffe,柴田芳樹
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/12/15
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る