Angular と RxJS のための情報サイトを作り始めた

「Angular のための RxJS」 というサイトを作っています（まだコンテンツしょぼい）。

ここ数年、業務でAngularを書いていて知見がだいぶ溜まってきたのと、業務委託のサービスもAngular移行して更に知見が増える速度が加速したので、 どこかにアウトプットしておこうと思った次第です。

まだAngular成分は皆無ですが、よくある使い方や落とし穴などを紹介できたらと思います。

learn-rxjs-for-angular.info

社内の認識合わせのために技術的負債を一文で定義してみた

社内では品質管理の名目で技術的負債の解消をミッションの1つとしているが、着手して一番最初に躓いたのは技術的負債とリファクタリングの認識が全く合わないことだった。

リファクタリングについては「リファクタリング」と「レガシーコード改善ガイド」にその定義が掲載されているのでソースをぶつけることで早々に解決した。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

レガシーコード改善ガイド

しかし技術的負債のわかりやすい定義は検索しても意外と見当たらず、何が技術的負債か明確でないためにいろんなものが技術的負債としてバックログに積まれた状態でミッションはスタートすることに...

（技術的負債が何なのかわからない状態でそれの解消をミッションにしてしまった時点で何か大きな間違いを犯している気がするが、それについてはこの記事中では言及しない）

また、営業への説明も必要になりそうだったので、簡潔で非エンジニアでも分かるような定義を作ることにした。

それをすると決めてから一番最初に見たのは「エンジニアリング組織論への招待」で、こちらからカニンガムが提唱したのが原点だとわかった。

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

曰く：

最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は代価を得て即座に書き直す機会を得るまでの開発を加速する。 危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。 技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。

（エンジニアリング組織論への招待 P249より）

この文章には、最初のコードは「品質が良くない」と前提があること、それを使い続けることの不利益について明言されていない、という問題を感じた。

同書では、「品質が良くない」前提については、新規追加しづらいコードを指しており、 使い続ける不利益については、「速度の低下」として表現されていた。

また、同書では技術的負債を「不可解な開発速度の低下」を説明しようとする言葉と記している。

まとめると、新規追加しづらいコードの蓄積＝負債の蓄積で発生する借金の利息＝開発速度の低下ということになる。

しかし、社内の開発を見渡すと、開発速度の低下の原因はコードだけに限らず、技術選定や運用プロセスもまたそれを低下させていると直感的に感じた（時間をかければ直感ではなくきちんと説明できると思う）。

そこで最終的にひねり出したのは、以下のような技術的負債の定義だ。

「ソフトウェア開発の加速を継続的に妨げる技術的な欠陥またはプロセスの不備」

「継続的に妨げる」は利息として払い続けることを指している。

「技術的な欠陥」は広範な意味を含んでいるが、理解しづらい・変更しづらいコード・アーキテクチャ、更新されていないライブラリ・フレームワーク、用途にマッチしないデータベースの選定、などが挙げられる（もっとあると思う）。 「プロセスの不備」も同様で、コードレビュー・リリースのフローが曖昧だったりとか、意思決定者が不明で誰に許可を取っていいかわからない、みたいな状況を指す。

非エンジニアには「欠陥を含まずに機能追加・変更を行うのは難しいため、それは負債のように蓄積され、利息として速度を奪っていく」という前提を添えて説明することにした。

この文章がカニンガムが提唱した概念から少し離れてしまっているというのはあるかもしれないが、言葉としては非常にわかりやすく、実用的だと思っている。

実際、この定義をごちゃごちゃしたバックログに溜まっている「技術的負債」に適用したところ、9割がたが「技術的負債」ではなく、ただのバグや小規模な改修要望であり開発速度の加速に関係ないものがほとんどで、 いかに定義なしでは技術的負債とそうでないものをごっちゃにしやすいかが身にしみてわかった。

まだ非エンジニアへの説明はしていないが、多分伝わるだろう。

もし社内の技術的負債が溜まっているようだったら、上記の定義をチーム内で共有してみてほしい。 また、非エンジニアに説明する機会があったら前提の一文を添えてうまく説明を試みてほしい。

うまく行けば幸い、だめでもこちらへの苦情は控えてほしい。

補： アジャイルサムライにも技術的負債について触れられていたが確認しそびれた。なんと書いてあったかちょっと気になる。

エンジニアリング組織論への招待　?不確実性に向き合う思考と組織のリファクタリング

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

レガシーコード改善ガイド

18年使ったEmacsを離れたあとVisual Studio Codeを2週間で辞めてNeovimを使う話

最近の仕事のパフォーマンス下げている要因の1つがエディタ使用時のフラストレーションで、 その解決のために10代から使っていたEmacsからついに離れた。

ただ、Visual Studio Codeを使い始め、強力なコーディング支援機能には感動すら覚えたものの、 細々としたところでどうしても許容できない箇所があったので結局2週間で挫折してしまった。

www.gnu.org code.visualstudio.com

Emacs を離れた理由をまとめると、以下のようになる。

• 初期状態でできることが少ない割にパッケージのメンテがどれも進んでいない
  • Python, TypeScript 周りの貧弱さ
• ウィンドウ操作がイライラ
  • 分割ウィンドウ時、ファイルを開くときとバッファ切り替えのときでどのウィンドウに出くるかイマイチ法則がわからなかった
• やりたいことに対して情報が少ない

ユーザが減少傾向らしいので、仕方ないといえば仕方ない。 バリバリ自分で調べてコミュニティに還元する道も考えたが、そもそも発端は仕事の忙しさだったりするので、続かないことは目に見えている。 学生時代や新人時代の暇なときにEmacs Lispを覚えておくべきだったのかもしれないが、時既に遅し。

Emacs 離れて Visual Studio Code に移行したものの、飛び抜けて良い部分があるのは認めつつやっぱり許容できない部分がある。

• Emacsキーバインドがとても弱い
  • 検索窓で使えないなど
• フォーカス飛びまくる
  • サイドバーに飛んでから戻るの面倒
• マウスオペレーション前提の作り
  • キーボードオペレーションで完結させる気を感じない

Visual Studio Code なのでEmacsキーバインドがどうの、というのはお門違いかもしれないが、ホームポジションから手を離さなずにオペレーションができることは生産性の観点からとても大切で、その部分の解決ができなかったためにVisual Studio Codeもやめることにした。

今はNeovimを使い始めている。

NeovimというかVimの良いところは、編集操作に特化したデフォルトのキーバインドがあり、 極めて効率的なコーディングができるところだ。

２０代のバイトでPHP書いてた頃はその補完能力の強さを買ってかなり使っていて、 Emacs乗り換え後もGitのコミットログはずっとVimを使っていたので違和感は少ない。

まだ乗り換えきっておらず、Gitプロジェクト内のファイル検索やgrepができていないが、 それでもVisual Studio Codeでさっぱりだった矩形選択が簡単だったりしてその編集能力の強さを享受し始めている。

エディタ周りはあまり変えたくないので、Vimとは長く付き合っていきたい。

実践Vim　思考のスピードで編集しよう！ (アスキー書籍)

Vimテクニックバイブル　?作業効率をカイゼンする150の技