「図解即戦力 アジャイル開発の基礎」の補足

技術評論社から「図解即戦力 アジャイル開発の基礎」を発売したので、ぼちぼちと補足記事を書いていきます。 この本は、いわゆる「はじめてのアジャイル開発」ということで開発者とプロジェクトリーダー向けに書いた本です。具体的なプログラミング技術要素は皆無なのですが、特定のプログラム言語やフレームワークに関係なく使えるノウハウ集です。基本は、20年前に発祥した「アジャイル開発憲章」が日本に伝わったところからスタートします。温故知新的に基本を大切にするという精神。で、20年後の最近のシステム開発(特にチケット駆動とDevOps的なシステムリースサイクル)を含めて書き進めてあります。 さて、その中で少し小難しいのが第4章の「EVMを使ったプロジェクト完了時期の予測」の部分で、よく言われる「アジャイル開発では完了時期が予測できない」という誤解を覆します。まあ、漠然とチケット駆動していると完了時期が読めない … 続きを読む

カテゴリー: 開発 | コメントする

リファクタリングの価値を概算する

元ネタは、以下にあるリスクの計量です。 https://twitter.com/moonmile/status/1683420756598988800 リファクタリングの価値の考察 – プログラマーの脳みそ https://nagise.hatenablog.jp/entry/2022/08/12/121524 ここにある需要と供給の交点「均衡点」をどのように算出するのか?という話…だと思うのですが、要は、「開発者がリファクタリングしたいと言ったとき、プロジェクトマネージャや顧客をどのように背って説得するのか?」と言う問題です。 開発者にとっては、リファクタリングは価値があるものとして当然な結果なのですが、マネージャーや顧客にとっては「価値がない」ものとして認識されがちです。 という返答を貰いがちです。 結果、リファクタリングをするための正式な時間(プロジェクトとし … 続きを読む

カテゴリー: 開発 | リファクタリングの価値を概算する はコメントを受け付けていません

Vue2 から Vue3 へ移行する ボタンイベント編

前回の続き こんな風に CRUD 機能が付いた画面を Vue2 から Vue3 へ移植してみる(実質的には Vue3 から Vue2 形式を書き起こしている)。通常ならば、上部のリスト部分とか、下部の編集項目のところを Vue コンポーネント化するところなのだが、その前段階として、1枚のベタの *.vue ファイルに書き起こす。 template 部分 リストの部分は共通にしておいて、CURD 機能を v-if で切り分ける。初心者っぽいけど、新人教育では初心者なのでこれで問題なし。最初は v-if で区切っておいて、徐々に Vue コンポーネントに慣れていくというスタイルにする。いきなり Atomic Design に進むのもアリなんだろうけど、歴史的な経緯を追っておくほうが体系的で覚えやすい。なによりも、業務システムが Vue2 と Vue3 が混在している状態なので両方覚えるのは必須 … 続きを読む

カテゴリー: 開発 | Vue2 から Vue3 へ移行する ボタンイベント編 はコメントを受け付けていません

Vue2 から Vue3 へ移行するための其の壱

「其の壱」とは書いたものの、其の弐があるかわからないが、ひとまず Vue2 から Vue3 へ移行するときの肝を示しておく。 Vue2 から Vue3 の大きな変更点は、Options API から Composition API によって関数の使い方が変更になったということなのだが、あいにく Vue2 の経験の浅い私としては、どちらでも構わない。2年程前から Vue.js を教えていたときは Vue2 であって、去年の途中から Vue3 が盛り上がってきて、今年に至っては Vue3 を使わざるを得ない≒教えざるを得ない状況になっている。 新人にとっては、Vue2 だろうと、Vue3 だろうと関係ないのだが、いざ配属された後では既存の Vue2 を修正する機会が出てくるだろう。あるいは Vue2 から Vue3 に変更するしないといけないかもしれない。さらに言えば、現状では Vue3 の情 … 続きを読む

カテゴリー: 開発 | Vue2 から Vue3 へ移行するための其の壱 はコメントを受け付けていません

Good Code 書籍の例外処理とフェールセーフ思想の違い

新人教育に「Good Code ~」を使うのだけど、第4章の「エラー」の部分だけは、ちょっと私の思想とは異なる。一般的に言えばそういう書き方が推奨されるのだが、実務的にはフェールセーフな動きが求められることが多い。ゆえに、ある程度のコードを書かずに「Good Code ~」を先に読んでしまうと変なところに陥る(たびたび原著が抜けてている点も含めて)の難点・・・なのだけど、まあ、新人教育には便利な教材である。 例外を呼び出し元に通知するべきか? 15年前位に、アプリケーション例外とシステム例外の区別をすべきかどうか?というのが流行った時期がある。システム例外はオペレーションシステムが発生する例外、アプリケーション例外はシステム以外全般のユーザーが使うという意味でのアプリケーション層ということになる。 一般的にユーザーが使うアプリケーションは、何か問題が起こったときにはユーザーに対して「予期せ … 続きを読む

カテゴリー: 開発 | Good Code 書籍の例外処理とフェールセーフ思想の違い はコメントを受け付けていません

chu言語の配列とクラス

配列 💋言語の配列は let x = [1,2,3,4,5] のようにカンマで区切ることができないので、 👼🍎👈👫1😀2😀3😀4😀5👫 のようにブロック👫と区切り文字😀を使う。 クラスか構造体 いまのところ Rust の構造体に近い形で、データのみ扱う 🐱🍱🍊🌸🍱 この意味は struct cat { var orange var cherry_blossom} のように cat クラスで、orange と cherry_blossom というプロパティを持っているこという意味である。オレンジとサクラは変数名(プロパティ名)なので、多分、型が「くだもの」と「花」なんだと思う。「猫」と「オレンジ」と「サクラ」は、ユーザーが自由に決めていい変数(ただし絵文字1文字に限る)。クラスや構造体は🍱で区切る。 型をどう指定しようか?string, number, boolean 程度が指定されてあれば … 続きを読む

カテゴリー: 開発, chu | chu言語の配列とクラス はコメントを受け付けていません

chu 言語のパースと改行

💋言語は、1文字でひとつの単語をあらわす。構文はF#に寄せる。ということで、 👼🍎👈10 は let x = 10 ; となる。 中間言語としては 👼🍎👈10 これを :let: “apple” “=” “10” に直したうえで let apple = 10 にすれば簡単でよい。 F#の構文と1対1になるとは限らないので 🤔🍎🤝10🙆OK🙅NG の場合は if apple = 10 then OK else NG になるが、 “if” “apple” “=” “10” “then” “OK” “else” “NG” から直すことに … 続きを読む

カテゴリー: 開発, chu | chu 言語のパースと改行 はコメントを受け付けていません

不具合票の書き方

おそらく、急遽新人に不具合票の書き方を伝えないといけない気がするのでメモ書き。 もともと新人教育では一連のソフトウェア開発を教えるので、PMBOKに従い、 ・要件定義・設計(外部設計、内部設計、詳細設計、画面設計など)・コーディング(単体テスト込み)・結合テスト(不具合票の取り回し込み)・システムテスト、運用テスト・運用保守に関する手順書 あたりを網羅するようにしている。なにか、品質が悪くてどうしようもなくなっている場合は、初手として上記の PMBOK のプロセスが欠けていないか確認する。各プロセス自体は必須という訳ではないが、視点として落としてしまうとそこにハマるという特性がある。なので、俯瞰して網羅的に知っておいて損はない。知っているが、時間や予算の関係で「やらない」という選択肢を敢えてとるし、あるいは簡略化・省力化する。あるいは、うまくいかないときは原点に返って、組み込むことを考える … 続きを読む

カテゴリー: 開発 | 不具合票の書き方 はコメントを受け付けていません

絵文字プログラム言語 chu 構想はじめ

実は構想だけは10年前ぐらいからあるのだけど(言語名自体は一発ネタだし)、今朝方、円城塔「文字渦」を読んで絵文字≒表意文字1文字という縛りでこだわってみてもいいのでは?と思って思考実験してみる。 もともとの発想として関数言語を絵文字であらわすというのある。 let x = 10 ; これを 😇🍎👈10 のようにする。 print x ; を 💋🍎 のように変換する。 if x = 10 then “ok” else “ng” は 🤔🍎🤝10🙆ok🙅ng になる。 単語や数字は面倒なので、英数字をそのまま使って、文法はすべて絵文字の1文字であらわす。1文字しかないので、単語の区切りとかで半角スペースはいらない。print あるいは console.log が💋なのは、chu 言語だから。 プログラム言語の意味論を考え直す 絵文字1文字縛りにするのは、構文解析が楽というのもあるけど、制御文なの … 続きを読む

カテゴリー: 開発, chu | 絵文字プログラム言語 chu 構想はじめ はコメントを受け付けていません

新人教育のための Good Code, Bad code のメモ書き

一読してみて、これならば新人研修に使えるかもしれないと思いつつ、同時に研修に使うときには「元ネタ」を明確にしないとミスリードっぽくなるだろう。と思われたので、そのメモ書き。 参考文献のほうに リファクタリング デザインパターン Unit Test が書いてあるので、XP のプラクティスに合わせてもいいと思われる。 コードの品質とは何か? 日本語でいうとこの「品質とは」に関係してくるので、「高品質なコード」と「低品質なコード」の比較や、「1.2 コードの品質にゴール」に書かれている4つの箇条書きのように漠然としてくると、新人(特にコードを書く前の新人)にはちょっと困った自体に陥るんじゃないかな、と思う。 ここでいう「正しく動くコード」というのは、動くべき仕様書に対応するコード、という隠れた意味がある。細かく言えば、動くべきことを記述した「仕様書」と、実際に顧客が想定している「動作」とは乖離が … 続きを読む

カテゴリー: 開発 | 新人教育のための Good Code, Bad code のメモ書き はコメントを受け付けていません