DEVGRU

プログラミングと競馬予想について書きます

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

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

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

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

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

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

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

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

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

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

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

曰く:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新装版 リファクタリング―既存のコードを安全に改善する― (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の良いところは、編集操作に特化したデフォルトのキーバインドがあり、 極めて効率的なコーディングができるところだ。

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

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

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

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

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

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

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

WebDriverIO で 複数のモディファイアキーを押して離すコード

プロジェクトで Ctrl + Alt + Shift + X を押す機能のE2Eテストを書くときに困ったのでメモ。

キーイベントを送るには keys() を使う。そこまでは変わらない。

webdriver.io

しかし、素直に browser.keys(['Control', 'Alt', 'Shift', 'KeyX']); とするとモディファイアキーが押しっぱなしになってしまい、意図した動作とならなかった。

これを解決するには、以下のように末尾にNULLを追加する。

browser.keys(['Control', 'Alt', 'Shift', 'KeyX', 'NULL']);

これで、最後には全キーを離した状態になるようになった。

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)

  • 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
  • 出版社/メーカー: 技術評論社
  • 発売日: 2016/02/02
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログ (4件) を見る

実践 Selenium WebDriver

実践 Selenium WebDriver

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

エキスパートが教えるSelenium最前線 (CodeZine Digital First)

  • 作者: 戸田広,島根義和,高橋陽太郎,沖田邦夫,松尾和昭,宮田淳平
  • 出版社/メーカー: 翔泳社
  • 発売日: 2018/05/15
  • メディア: オンデマンド (ペーパーバック)
  • この商品を含むブログを見る