エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【書評】ダークサイド・スキル

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

ダークサイド・スキル 本当に戦えるリーダーになる7つの裏技

きっかけ

ダークサイドって言われると、魅力を感じる世代なのです。
ダークって単語を聞くと、ハートキャッチプリキュアのクモジャキーを思い出す。
もう、ダークって聞くと、その後の単語は、「な心に支配されるぜよ!」って脳内再生される。

まとめノート

7つのダークサイド・スキル

太字は、俺の考え。

U字型コミュニケーション

コミュニケーションって単語が気に入らんぜよ!

日本は、会議では互いの愚痴は言わないけど、会議の後に言う傾向が強い。
そして、それは部下に広まり、風の噂で流れて、ボトムアップで相手に伝わる。
こうした風土がある結果、相互不可侵な組織が形成される。

組織の中で重要なのは、中間管理職。
トップがすべて見切れるわけではないので、中間管理職の情報を信じるしかなく、組織を操作しようと思えばできてしまう。
トップよりも長く会社にいる可能性が高いので、先を見据えておく必要がある。

弱音を吐くこと≠実情を伝えること
勝ち抜くためには、冷静な判断とタイミングを知る。

上司への報告に必要なものは、調査・段取り・根回し。
実施するタイミングに気をつける。言い訳に聞こえるタイミングでの利用は、最悪の状態を招く。

評価は、成果をあげることだけではない。
失態を抑えることも評価するべき。
失敗から学んでいる人の方が、強く育ち、リスク勘定ができる。

結局、隠しても相手に情報は伝わる。愚痴をこぼす時は要注意

KYなやつを優先しろ

あうんの呼吸は、同質化を招く。
同質化した結果、すり合わせはしやすいが、異質なものを排除する傾向が強くなる。
そのため、新しい考えが出てこない。

同質化は、放っておくと、勝手に同質化する。
人は、フェストゥムのような性質を持っている。
多様性を維持するためには、同質化しないためのコストがかかる。

部下への直接指示は避ける。
なぜなら、バイアスがかかり、考えるのを放棄する危険がある。
相手に考えることを促すこと、考えた結果をいえる環境を作ることが大事。

ちなみに、KY発言がすべていいわけではない。
何も考えてないと、それはただの自己中。
ひんしゅくを買うことはさけ、適切なタイミングでする必要がある。

使える奴をてなづけろ

劇的なスキルアップは、難しい。
全知全能の神になるのは、無理がある。
結果を残そうと思うのなら、他人の能力を借りる必要がある。
他人を認めることから始めないと、人は集まらない。

知らないことは受け入れる。
知らない分野が何かをしり、そこに詳しい人を集めることが、強い組織を作るのに必要なこと。
弱いところを知って補強する

組織で重要なことは、手駒の数。
多くあったほうが、柔軟に対応できる。
将棋と同じで、持っている駒は多い方がいい。
ただ、駒だけ持っていてもしょうがない。打つタイミングを気にする必要がある

堂々と嫌われろ

意思決定することは、悪い決断もすることである。
悪い決断をしたくないから先送りにすることは、民主党政権みたいなものである。

意思決定とは、不十分な状況下でするもの。
十分に情報があり、迷う必要がないものは、決断と言わない。流されているという。

評価を気にすると、敵を作らないように動いてしまう。
結果として、悪い決断がやれなくなり、勝負時に勝負できなくなる。

煩悩に溺れず、欲に溺れろ

煩悩は、なくせない。
悪い方向に働かないように、自制心を持って制御する。

エロは命を救う
スティーブン・キングの短編集の解剖室みたいなことがあるかもしれない
エロは命を育むものでもある。なくてはならないものなのです。

踏み絵から逃げるな

リーダーの価値は、有事に決断できるかどうかで決まる。
リスクを取らずに失敗を避けることは、負けはしないが、勝ちもしない。

部下に使われて、使いこなせ

部下を使いこなすとは、意見を引き出させること。
そのためには、質問の仕方を工夫する必要がある。

リーダーシップとは、経験から強みと弱みを認識し、罠を避け、部下を思いやれば、自然と発揮される。

ダークサイド・スキルを磨くポイント

いつでも叩ける態勢を整える

自由な意見は、リスクがあるのでいいにくい。
そのため、保身に走ってしまう。

空気を読みすぎて、存在が空気にならないようにする。
意識的に思い切った発言をする必要がある。

黒子テツヤが存在感を示すために、強い意志と言葉と行動をしめしたように、空気にならないための努力もいるのだ!

決断の先送りは、何もやらないのと一緒であることを覚えておく。

人を操る3つの力

コミュニケーション力(意思疎通力)

人を動かすためには、ロジカルな説明が必須。
そのためには、財務表を読めることが大事。

上記3つを読めることで、事業のメカニズムが分かるようになる。
事件の気配を掴んだり、施策の有効さを紐付けることができる。
話すためのネタを見るける力にもなる。

先見の明を知るためだったり、振り返りをするためにも必要そう

硬軟織り交ぜて人を動かす「人間力

仲良くなってもいいが、緊張感は維持する。
関係を良好に保つには、配下メンバーを見る。
配下メンバーのキャリアを潰す選択は、極力回避する。

ナメられるのは、一番気に食わない!
特に、某となりの国にナメられるのは、腹が立つ!

リーダーとしての高い使命感

情報はすぐに拡散されることを理解する。
一定以上のポジションと影響力を持ったら、けじめをしっかり付ける。

自分の強さ・権威・背後にはる力が何かを理解する。
理解しないと、王様の耳はロバの耳や、虎の威を借る狐の虎と同じ愚行を犯してしまう。

【書評】ベタープログラマ

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック

読書開始日

2017.01.14

読もうと思ったきっかけ

なんとなく目に入って、目次を見た感じ、良さそうだったから買った。

本書の目次

  • 1章 コードを気にかける
  • 2章 見かけのよい状態を維持する
  • 3章 少ないコードを書く
  • 4章 取り除くことでコードを改善する
  • 5章 コードベースの過去の幽霊
  • 6章 航路を航行する
  • 7章 汚物の中で転げ回る
  • 8章 そのエラーを無視するな!
  • 9章 予期せぬことを予期する
  • 10章 バグ狩り
  • 11章 テストの時代
  • 12章 複雑さに対処する
  • 13章 二つのシステムの物語
  • 14章 ソフトウェア開発とは
  • 15章 規則に従って競技する
  • 16章 単純に保つ
  • 17章 頭を使いなさい
  • 18章 変わらないものはない
  • 19章 コードを再利用するケース
  • 20章 効果的なバージョンコントロール
  • 21章 ゴールポストを抜ける
  • 22章 凍結されたコードの数奇な人生
  • 23章 プリーズ・リリース・ミー
  • 24章 学びを愛して生きる
  • 25章 試験に基づく開発者
  • 26章 チャレンジを楽しむ
  • 27章 停滞を避ける
  • 28章 倫理的なプログラマ
  • 29章 言語への愛
  • 30章 プログラマの姿勢
  • 31章 一生懸命ではなく、賢く
  • 32章 完了したときが完了
  • 33章 今度こそ分かった……
  • 34章 人々の力
  • 35章 原因は思考
  • 36章 遠慮なく話す
  • 37章 多くのマニフェスト
  • 38章 コードへの叙情歌

まとめノート

you write (code)

見かけの良い状態を維持する

レイアウト論争は不毛。
プロジェクトで統一することが大事。
制定する場合、根拠を付ける。

少ないコードを書く

ソフトウェアの機能は、コード量に依存しない。
だから、なるべく書かないほうがいい。
ただし、読んで分からなくなるレベルに少なくコードを書くのは良くない。

少ないコードのデメリット

  • 保守範囲がデカい
  • 保守コストが高い
  • 可読性が悪い
  • 修正量が多い
  • バグの隠れる場所が多い
  • 複製するとバグも複製されやすい

取り除くことで改善する

システムの改善は、コードの削減でもできる。
死んでいるコードは邪魔なだけ。
プロジェクトが大きくなるほど、死んだコードも大きくなる。
放置するのは、失敗の兆候になり得る。

コードベースの過去の幽霊

古いコードは、宝の山でもある。
そこから学べることもある。それは、いい面・悪い面も含む。
過去を知ることで、スキルを知ることができる。

航路を旅行する

コードを知るには、プロジェクトを知っている人に導いてもらうのが、一番早い。
助けを求めることを恐れてはいけない。

システムの理想は、いくつか存在しているが、忠実に再現するのは難しい。
ちゃんと現実を見据えて行動を起こさなければならない。

汚物の中で転げ回る

コードは、知らないうちにひどくなる。
ひどいコードに対策できる準備を、常日頃からやっておく必要がある。

あえて酷いコードの中に入ることで、改善方法を学ぶこともあり。
できの悪いコードは、意図してできているわけではない。

そのエラーを無視するな

エラーは、何か原因があって出る。
無視・先延ばしは、問題の解決になってない。
あとでしっぺ返しが発生する可能性がある。

予期せぬことを予期する

コードを書く際は、可能性のある全てのルートを考慮する。
例外的なルートも、なるべく適切に対処する。

バグ狩り

その場しのぎのコードは、メンテナンスコストが高くつく。

テストの時代

改善するには、問題に気づく必要がある。
フィードバックは、早く頻繁に行われるほうがいい。

開発する場合は、テスト可能な状態にすることを心がける。

複雑さに対処する

複雑さを作り出すのは、人間であることを忘れてはならない。
複雑さには、必要なものと不必要なものもある。
必要な複雑さの見極めと管理方法を学ぶことが大切。

2つのシステムの物語

誤った設計は、誤った設計を更に呼ぶ、呼び水になる。
人によって起きる問題で、政治的な背景があることが多い。

アーキテクチャがシステムに与える影響は大きい。
呼び水にならないように、変更できるように単純に保っておく。
現状を嘆かず、どうすればいいのかを考えるのがエンジニア。

練習することで完璧になる

ソフトウェア開発とは

プログラミングには、美的感覚が必要なこともある。
しかし、思いつきのコーディングはダメ。常に自問自答して、答えを探る。

単純に保つ

単純な説明のメリット

  • 説明の簡略化
  • 理解・図解しやすい
  • 誤用対策になる

バグの改修

早まった最適化は、不必要な複雑さを呼ぶ。
暗黙の想定を作らない。
適度な改修ではなく、必要十分な対処で満足する。

頭を使いなさい

単純なこと≠考えなくていい

応急処置をせず、責任を持って対処する。

変わらないものはない

変更は必ずあるもの。
変化に対応して、最適化する。ありもしない変化は、考えない。
変化に対応するためには、自動テストを開発に入れる。

コードを再利用するケース

コピペは、悪魔の所業。
やる場合は、正しさを理解してからやる。

再利用のための設計は、推測でやってはいけない。
推測で作ると、複雑さを内包したものができあがる。
必要になってから、再利用を考える。
それは、ライブラリ化、リファクタリングも同じ。

購入や車輪の再発明は、コストを考慮する。
排他的になることは、コストが高いことを考慮する。

効果的なバージョンコントロール

VSCなしの状態は、支柱のない家と同じ。
間違いが起こっても戻せないことは、致命的。
VSCは、セーフティーネット的な役割を提供してくれる。

効果的に使うポイント

  • リリースバージョンを明確にする
  • 管理するファイル構成はシンプルにする
  • 必要なものだけ管理
  • 小さな意味のあるまとまりを頻繁にコミット
  • コミットメッセージは、単純・明瞭・完結を心がける

ゴールポストを抜ける

腐敗した開発環境は、下水道と一緒。
リリース前に待ち構えるQAチームに、汚水を流してはいけない。
品質は、全員で作ることを忘れてはいけない。

凍結されたコードの数奇な人生

コードの凍結は、変更しないリリース前の期間であって、永久に変更されないわけではない。

凍結中に、技術的負債を見つけて、凍結解除されたら改善に移れる準備をする。

プリーズ・リリース・ミー

規律と計画を作り、リリースサイクルを確立する。
早めに作って、頻繁に実行することが大切。

個人的なこと

学びを愛して生きる

何もしなければ、衰退するだけ。

学ぶことはいいことだが、集中しすぎると、視野が狭くなる。
多くの情報源を持ち、広い視野でいることは大切。

学んだことは、書き出す。
持っている知識を明確化する。積極的に使って、知識を定着させる。

試験に基づく開発者

有能になっても満足してはならない。
潜在的な危険は、いつも存在していることを自覚して、考えて開発を行う。

チャレンジを楽しむ

楽しみのために開発を行ってはならない。
どうしてもやりたいことがあるならば、計画を立ててやる。

停滞を避ける

安全地帯は、有害である。
さらに良くなることはない。
なぜなら、安全だから。

変化には、リスクが常につきまとう。
意図して投資しないと、成長はできない。

倫理的なプログラマ

やってはいけないこと

  • 可読性の悪いコードを書く
  • ライセンス違反
  • 中傷不正行為
  • 不正行為を見逃す
  • 働きすぎ

言語への愛

成長は、複数の言語を学ぶことで得られる。
複数の考え方・解法をしることで、多くの問題に対処できるようになる。

愛に必要なもの

  • 尊敬
  • 信念
  • 会話
  • 忍耐

プログラマの姿勢

同じことばかり考えない。
同じことばかり考えていると、解法がでないうえに、心も狭くなる。

一生懸命ではなく、賢く

生産的なプログラマは、賢く働いている。

賢く働くための戦術

  • 賢く利用(車輪の再発明をしない)
  • 他人の解答を見る
    優秀な人の解答をパクる
  • やらなければならないことだけやる
  • 一時的な解決策を試してみる
  • タスクに優先順位をつける
  • 本質を理解する
  • シングルタスク
  • 小さく実行
  • 先延ばししない
  • 自動化
  • 会話
  • 燃え尽きない

完了したときが完了

完了は、もしかしたら、完了したと思いこんでいるだけかもしれない。
タスクをこなすときは、完了を明確に定義する。
必要以上の完了を目指さないほうがいい。

今度こそ分かった・・・

ソフトウェア開発の問題は、人間の問題であることが多い。
多面的な見方で、解決方法を探る努力をする。

人々の営み

人々の力

優秀なプログラマになるには、環境が大事。
環境を変えるには、仕事を変えるか、イベントに出るしかない。
専門家の考え方を知るのが、優秀になる近道

原因は思考

明や理由付けしたり、批判を受け入れることを習慣化する。

遠慮なく話す

開発には、コンピュータとだけではなく、人と話す必要もある。
言葉選びにも注意する。

多くのマニフェスト

マニフェストは、原則の概要にすぎない。
常に正しいとは限らないので、過信せず、状況を見て判断する。

コードへの叙情歌

コーディングの問題には、人間の問題も含まれている。
健全な状態に戻すのは、急にできない。
考え方を少しずつ変えさせるしかない。

関東の雪での社員のあるべき姿

記録

とりあえず、積雪の記録

www.sankei.com

日本列島は22日、南岸を東進する低気圧の影響で太平洋側を中心に広い範囲で雪になった。関東甲信では平野部でも積雪を記録、東京都心でも雪が積もり、帰宅時間帯の交通に大きな影響が出た。関東甲信の雪は23日にはやむが、気温が低い状態が続くため、凍結した路面などに注意が必要だ。 気象庁によると、低気圧に伴う雨雲が22日未明には九州にかかり、徐々に東に進んだ。西日本は雨の地域が多く、中国や近畿の山沿いでは雪になった。昼ごろには、東京都内や神奈川、埼玉両県などの平野部でも雪が降り始め、夕方には積雪を記録した。 関東甲信を中心に、列車の運休や高速道路の通行止めが相次いだ。 低気圧は22日夜に関東の南の海上を通過。23日以降、三陸沖を急速に発達しながら北上し、冬型の気圧配置が強まる見通しだ。

思うこと

僕の行っている現場は、早期帰宅命令が出たので、すぐに帰りました。
翌日は、普通に出社してしまいました。。。

出社がおかしいと思いつつも、雇われているので、そんなこと言えないんですよね。。。
嬉々として出社しているような記事をみるけど、だれも嬉々として出社してないと思うのですよ。
しかも、残念なことに、翌日は、電車が動いていたんですよね。。。
あの京葉線が動いていたんだから、ほとんど運行していたと思う。
思うんだけど、関東は雪対策なんてないから、少しの積雪で、経済が止まるんですね。。。
実家が新潟なので、雪はなんとも思ってなかったけど、自然の脅威を知りました。

こういう時は、リモートワークだったりがある企業が羨ましいと思いますわ。

あるべき姿

  • 出社する
  • スケジュールを守る

本当は、「安全に待機」があるべき姿だとは思いますが。。。
他の人はどうだったんだろう?

『絶対にエンジニアが転職してはいけない会社の募集要項』の個人的まとめ

絶対にエンジニアが転職してはいけない会社の募集要項 | Findy Engineer Lab

きっかけ

転職を考え始めたから。
失敗しないためにも、まとめて、頭の中を整理する。

まとめ

やばい求人の特徴

  • エンジニア職種の分解がされていない
  • 開発言語のスペル間違い、または、大文字小文字が間違っている
  • ブラック企業ワードがいっぱい
  • 営業マンが大好きそうな単語(意識高い単語)がいっぱい
  • 事業戦略に言及なし
  • 募集要項の中身が薄い

エンジニア職種の分解がされていない

ありあらゆることがお願いされる可能性が高い。
理解が低く、過度な期待をしていることがある。

分業の概念を持っていないため、ブラックの傾向があるかもしれない。

開発言語のスペル間違い、または、大文字小文字が間違っている

人事部のみで書いた可能性が高く、組織的な風通しが悪い可能性がある。

ビジネス要件をまとめたりするのに、営業を通したりもするので、環境面について注意する。

ブラック企業ワードがいっぱい

個人的に思うブラック企業のワード

  • 根性
  • あきらめない
  • アットホーム
  • 未経験者歓迎
  • 熱意
  • やる気
  • やりがい
  • 充実
  • 残業なし
  • ノルマなし

やりがい搾取、精神論による労働、「なし」という甘いワードに隠されたサービスの強要。。。
僕が感じるのは、こんな感じですかね。

これは、アルバイトにも通じるし、就活生も注意しておいたほうがいい。

営業マンが大好きそうな単語(意識高い単語)がいっぱい

とりあえず、営業マンが好きそうな意識高い単語 ※自分で思いついたやつ

ここらへんの単語が出てきたら、よく話を聞いて、ツッコミを入れたほうがいい。
事実と矛盾している箇所がある可能性が高い。
意識高い系は、矛盾を日本人がよく知らなそうな単語で誤魔化している傾向が高い気がする。

事業戦略に言及なし

なにも考えないで仕事をしている可能性が高く、どこかの下請けの可能性が高い。

募集要項の中身が薄い

やる仕事の内容が薄いと、意図してないことまでやらされる可能性が高い。

感想

とりあえず、これを印刷して面談する時に、手元に置いておこう。。。

Java10 JEP296 翻訳(たぶんあってると思うよ?)

JEP 296: Consolidate the JDK Forest into a Single Repository

要約

原文

Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.

翻訳

多数の林立しているJDKリポジトリを一つにまとめて、開発を合理化します。

動機

原文

For many years, the full code base of the JDK has been broken into numerous Mercurial repositories. In JDK 9 there are eight repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.

While this model of multiple repos offers some advantages, it also has many downsides and does a poor job of supporting various desirable source-code management operations. In particular, it is not possible to perform an atomic commit across repositories of inter-dependent changesets. For example, if the code for a single bug fix or RFE spans both the jdk and hotspot repos today, the change to both repositories cannot be done atomically in the forest hosting those two distinct repos. Changes spanning multiple repos are a common occurrence; over 1,100 bug ids have been reused across repositories in the JDK forest. The 1,100+ repo-crossing bugs is only a lower bound on the number of logically repo-crossing bugs, since some engineers use separate bug ids to push to different repos.

This mismatch between the divisions of the Mercurial repos and unity of the engineering dilutes one of the main benefits of modern source-code management: tracking changes to sets of files rather than just individual files. As a corollary, this mismatch between SCM transactions and logical transactions complicates use of tools such as Mercurial bisect.

The individual repos don't have a development cycle separate from the JDK as a whole; all the repos advance in lockstep with the JDK promotion cycle. The multiplicity of repos presents a larger than necessary barrier to entry to new developers and has lead to workarounds such as the "get source" script.

翻訳(意訳:間違ってるかも)

長年の間、全てのJDKのコードベースは、多数のMercurialリポジトリに分断されていた。
JDK9の中には、root, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn の8つのリポジトリが存在している。

この構成は、多少のメリットがあると同時に、それぞれのソースコードを管理する上では貧弱であるデメリットがあります。
特に、相互に依存する変更箇所をコミットすることはできません。
例を挙げると、単一のバグ修正や機能拡張のエンハンス対応が、現在のJDKと改修中のリポジトリの両方に変更が必要な場合は、競合がおこってしまいます。複数のリポジトリにまたがる変更は、一般的に存在するものです。
1,100以上のバグが、JDKリポジトリで同一バグとして修正されています。
1,100以上のリポジトリをまたがったバグは、論理的には下限値ではありません。なぜなら、一部のエンジニアが、同一バグを別のバグIDを使用してリポジトリに反映させているからです。

Mercurialリポジトリの分割と統一されたエンジニアリングの両方を成立させるという相反する考えは、ソースコード管理の主なメリット(変更したファイル群の変更追跡)を弱くする。
その結果、ソースコード管理と論理的課題の間に起こる不一致は、Mercurial bisectなどのツールの利用を複雑化する。

リポジトリは、JDK全体の開発サイクルから独立しているわけではありません。
全てのリポジトリは、JDKの進捗状況と足並みを揃える必要があります。
多くのリポジトリが存在することは、新規開発者の参入に大きな弊害をもたらしたて、ソースコード入手方法が複数存在する状態になっています。

詳細

疲れたからパス

【WEB+DB PRESS】Vol.102 はじめてのペアプロ/モブプロ

目次

  1. ペアプロ/モブプロとは何か
  2. ペアプログラミングの基本
  3. ペアプログラミングの実践ノウハウ
  4. モブプログラミングの基本
  5. モブプログラミングの実践ノウハウ

まとめメモ

ペアプログラミングとは

2人でプログラミング(および分析、設計、テスト)とプログラムの改良を同時に行うやりとりのこと

モブプログラミングとは

ペア(2人)ではなく、モブ(チーム全体)でプログラミングを行う。

思うのだが、タイピングする人は、いろんな人からあれこれ支持されて、ストレスたまらないのかな?

役割

ドライバー

キーボードの前にいて、コードを書き進めていく人

ナビゲーター

ドライバーの隣に座り、ドライバーと会話しながら導く人

ペアプログラミングの歴史

XPを最も強く体現したプラクティスがペアプログラミングだった。
モブプログラミングは、XPのプラクティスをベースとして開発された発展的な手法。

ペアプロ/モブプロの効果

作業への集中と質の向上

  • リアルタイムでコードレビューしてコードに反映
  • 相互監視されることで、目標がブレを防止
  • 会話による思考整理
  • 集合知の結集
  • ケアレスミスの減少

知識と学びの共有

  • 技術力の底上げと高い教育
  • 過程(プログラミング)から学ぶ
  • 属人性の減少
  • 暗黙知の共有

ペアプログラミングの進め方

  • コードを書く前に方向付けを行う
  • コードを書きながら会話し、考えを共有する
  • ロールを交代する

組み合わせ

ベテランと新人の関係は、相互補完の関係にあり、理想形。
ベテラン同士は、揉めたりする可能性もある。
いわゆる音楽性の違いみたいなのが発生する。
新人同士は、学習の機会が少なく、あまり成果が得られない可能性が高い。

ペアプログラミングの実践ノウハウ

なるべく開発環境は、統一する。
しかし、現実的な解決策ではないので、エディタやIDEの依存度を下げるリアルタイム共同編集機能を備えた環境を作る。

ペアプロの強制はしてはいけない。
どうしても受け入れられない人もいるので、そのことは認めなくてはいけない。

知識はペア内にしか残らないので、ペアのローテーションをする。
その際、意図を残すプログラミングを心がける。
※それは普通のことな気もするが。。。

モブプログラミングの基本

モブプログラミングの始め方

  • 大画面のディスプレイを用意する
  • 解決する課題を絞る
  • ドライバーが積極的に助けを求める
  • ナビゲーターは手分けして調査

日本だとデカいディスプレイは高いので、プロジェクターにしたほうがいい気がする。

モブプログラミングを支える文化

スウォーミング

課題を複数のタスクに分散して作業すること。
変化に対する対応能力を高く保てる。

高度な意思決定

情報が常に集まってくるので、感覚の同期や意思決定の作業が迅速に行える。

高速な意思決定に必要なことは、迅速なフィードバック、ふりかえり、技術負債の認識。
実施する上で、上記のことを認識してやる。

外部との信頼関係

生産性に疑問を持つ人は多い。
近年のプログラミングは、定型文のコピペではないので、そのことを理解してもらう必要がある。

モブプログラミングの実践ノウハウ

モブプログラミングを支える技術

メインブランチでの開発

全員で開発するのでレビュー時に戻りが発生する可能性を下げる。
マージ作業がいらなくなるので、苦痛が減る。

変更したらすぐにデプロイ

モブプログラミングにかぎらずではあるが。。。

技術的負債の解消

集合知を活かして、どこで問題解決するかを選定する。
リスクを減らして対応できる可能性が高い。

感想

集合してやるのは、良さそうな感じはするが、誰かに頼り切っている奴らが多いと、破綻しそうな気がする。
構成するメンバーの価値観が、似通ってないとキツそう。
読んでて思ったのは、個を高めることに貪欲な人でないと、正の循環が生まれず、やってもメリット薄いような気がした。

Java10 JEP286 試し実装

Java10

JDK 10

JEP286

JEP 286: Local-Variable Type Inference

  • 要約の翻訳
    ローカル変数を型推論を使って初期化するための拡張実装案です。

試し実装

実装する前に試した結論から言うと、型を書かなくても良くなっただけで、失くなったわけではない。

環境

確認したバージョン。

$ java -version
java version "10-ea" 2018-03-20
Java(TM) SE Runtime Environment 18.3 (build 10-ea+37)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10-ea+37, mixed mode)

とりあえず使う

var型が追加されたので、使ってみる。

import java.util.*;

class TestJEP286 {
  public static void main(String[] args) {
    var list = new ArrayList<String>();
    list.add("test");
    System.out.println(list.get(0).getClass());
    System.out.print(list);
  }
}

実行結果は下記になるはず。

$ java TestJEP286
class java.lang.String
[test]

listは、特に型を指定してないけど、追加してもエラーは発生しない。
そして、getClassした値は、ちゃんと java.lang.String になっているはず。

意地悪してみる

新しいことをしているやつは、とりあえず痛めつけたい考えがある。
もちろん、対人関係でそんなことはしませんけど。
なんというか、新しいものをいじり倒したい願望が結構強い。

別な型を入れる

さっきの実装を下記に変える。

    var list = new ArrayList<String>();
    list.add(1);
    System.out.println(list.get(0).getClass());
    System.out.print(list);

型指定してないから、数値をぶっ込んでみる。
すると、下記の結果が返る。

$ javac TestJEP286.java
TestJEP286.java:6: エラー: 不適合な型: intをStringに変換できません:
    list.add(1);
             ^
注意:一部のメッセージは簡略化されています。-Xdiags:verboseで再コンパイルして
完全な出力を取得してください
エラー1個

想定通りの反応。
型が違うので、入れることはできない。
指定されてないからといって、なんでも入れられるわけではない。
コンパイルエラーになるので、型が指定されてないからわかんないってことは起きない。
そもそも、分からないってことは、ソースを理解してないってことだから、注意した方がいい。

入れられるものは、決まっている。
意図しないモノは、入れてはダメなのです。
違うと分かっていて、きゅうりやナス、人参を突っ込んではいけないのです。

nullは?

型でダメなら、異常な型だけど万人受けする奴はどう?ってことで、nullを入れてみる。

    var list = new ArrayList<String>();
    list.add(null);
    System.out.println(list.get(0).getClass());
    System.out.print(list);

型指定あっても大丈夫だから、たぶん、コンパイルエラーにはならないと予想。
たぶん、実行時にヌルポ

$ javac TestJEP286.java

$ java TestJEP286
Exception in thread "main" java.lang.NullPointerException
        at TestJEP286.main(TestJEP286.java:7)

予想通り、コンパイルは通って、実行時にヌルポ。
言っとくけど、試す前に予想してますからね。

やっぱりnullの特殊性が際立つんですよね、Javaって。
どの言語でもそうだけど、特殊な値は、挙動が似通っているから、どこかの言語で覚えれば、だいたい通用する。

途中で別のインスタンスにしてみる

もう、入れるモノを変えるのは飽きたので、入れ物の方を変えてみる。

    var list = new ArrayList<String>();
    list = new ArrayList<Integer>();
    list.add("test");
    System.out.println(list.get(0).getClass());
    System.out.print(list);

大丈夫そうな気がしないでもない。
直してコンパイル&実行してみる。

$ javac TestJEP286.java
TestJEP286.java:6: エラー: 不適合な型: ArrayList<Integer>をArrayList<String>
に変換できません:
    list = new ArrayList<Integer>();
           ^
エラー1個

初期化した時の型と違うから、怒られた。。。
考えたら、初期化したときの型は、変えられないから、当然といえば当然か。
これは、var 使わない場合も一緒ですね。

継承関係にあるとどうなるか

クラス設計で必須となる、継承関係が有効に働くのか一番気になったので確認。
確認は、以下のソースで。

import java.util.*;

class TestJEP286_2 {
  public static void main(String[] args) {
    var list = new ArrayList<SuperInteface>();
    list.add(new SubInterface1());
    list.add(new SubInterface2());
  }
}

interface SuperInteface {
}

class SubInterface1 implements SuperInteface {

}

class SubInterface2 implements SuperInteface {

}

予想は、問題なくコンパイル&実行できる。

$ javac TestJEP286_2.java

$ java TestJEP286_2

とくに出力してないので、味気ない感じ。。。
予想通り、ちゃんとコンパイル&実行できましたね。

互換性があれば、突っ込んでも問題ないということですね。
だからと言って、きゅうりやナス、人参を突っ込んではダメです。

感想

型を書かなくても良くなっただけで、なくなったわけではない。
型チェックは従来と一緒になる。
型が見えない分、分かりやすく、直感的なメソッド名や変数名を付けないとダメ。
そして、それはいい方向に向かうと、信じてる。

従来の知識は、ちゃんと活きてくるので、怖がらずに使ったほうがいいと思いました。

あと、ちゃんと実装が間に合ってるので、安心はしている。
リリースサイクル変わって、1発目の目玉機能がダメですは、洒落にならないからな。

他のヤツも、あとで確認したい。

雑記

とりあえず試したけど、IDEの予測変換が使えないようなので、久々にゼロからタイピングしたのが辛かった。
VisualStudioCode使ってみたけど、案外、Javaでもいい感じにコーディングできるんだなって印象だった。
動作も軽快だったし。
EclipseからIntelliJに行こうかと思ったけど、VisualStudioCodeでもいいかな~って最近思ってる。
業務で使っているTypescriptの実装にも使っているのがデカい。
久々に使うと、全然ショートカット使えずに焦るんだよね。。。