「保守性」の記事
12 件
-
記憶なんて当てにならない — どこまで配ったか、どこまで配るべきかで悩んだ話
PDF共通関数は、外部ライブラリ用のディレクトリの下に置いてあった。それだけの理由で配布から落ち、呼び出す側だけが現場に届いた。関数が無いまま「対応済み」になるところだった。どこまで配ったのか、どこまで配るべきなのか。チェックひとつ付け忘れれば同じことが起きる仕組みを、憶えていなくても済む形に作り替えた一日。
-
バックアップは、あるだけでは足りない — 静かに止まり、小さすぎて不安になった一日
前回建てたLinuxの土台に保守コンソールを載せた。ダッシュボードの数字が実機とずれていた。追うと、再構築のときにバックアップが静かに止まっていた。復旧させたら今度は6.5GBのデータが480MBに縮んで不安になる。バックアップは「ある」だけでは足りない。開いて、末尾まで揃っていると確かめて、初めてバックアップになる。
-
74件のうち、配るのは6件だった — 「更新日で選ぶ」が壊れた話
NGWの更新を配る仕組みは、とうに完成している。壊れたのは「何を配るか決める」ところだった。20年動いてきた「ファイルの更新日で選ぶ」が、AIと働き始めた途端に無関係なファイルを拾い出す。犯人はAIではなくgitだった。診断から、UPDATE MAKER を内容差分へ、さらに「案件を選ぶ」へ作り替えるまでの一日。
-
つぎはぎのメニューを、一本の ngwMenu にまとめた話
同じデータから3通りに描かれていたNGWのメニューを、単一のサーバ描画メニュー ngwMenu に一本化した。標準とドロップダウンを1つの土台で出し分けるハイブリッド構成へ。150超のアプリを一切触らず、差引 −2,403 行。動くだけのコードを、読んで美しいコードへ近づける記録。
-
メニューを、データで管理する — アプリメニューと NGWT_APP_MENU の JSON
NGWはアプリごとに専用のメニュー体系を出す。40超のアプリに40通りのメニュー。それをHTMLにベタ書きせず、NGWT_APP_MENU テーブルの1列にJSON配列として持つ。起動可能アプリは職員区分ごとに NGWT_BOOT_MANAGER で管理し、メニューで隠し起動で防ぐ。データで持つから、並べ替えも権限の出し分けも自治体ごとの差し替えも、デプロイなしでできる。
-
日付は和暦で見せる — 日付ピッカーと ngwFunc_SWHenkan
役所の日付は和暦で表示する。単純な整形に見えて、改元・元号の表記ゆれ・区切りと、制度の重みが詰まっている。NGWはそれを ngwFunc_SWHenkan というひとつの関数に集約し、CreateDBWebで「DATE」と定義するだけで和暦の日付ピッカーが生成される。
-
セレクトボックスは6行で作る — 共通ヘルパー（function）に揃える
NGWには数えきれないほどのセレクトボックスがある。それを、たった6行とひとつの共通関数ngwFunc_MakeSelectBoxに統一している。しかもその6行はCreateDBWebが生成する。手書きしないから、ばらつきが入らない。
-
AIは、私のコーディングのクセまで真似てくれる
NGWを開発して10年。命名規則も書き方も、私という一人の書き手の流儀でできている。新しく足すロジックを、AIはその流儀そっくりに書いてくれる。均質さは、そのまま読みやすさになる。
-
名前と実体が食い違う関数を掃除する — フォント設定のリファクタ
帳票PDFのフォント設定関数群が長年の変更で荒れていた。名前が嘘をつく関数をどう安全に掃除したか、その過程で見えた命名の価値を綴る。
-
「唯一の基準」を作る — 二重実装が生む静かなズレ
同じ計算や判断が複数箇所に重複すると、片方だけ直して片方が古いまま、という静かなズレが必ず生まれる。NGWの開発で何度も立ち返った「唯一の基準」という設計原則を、集約の実務と落とし穴とともにまとめる。
-
同じ役職名を6箇所で組み立てていた — 唯一の生成点に集約する
決裁欄の「◯◯課長」を作るロジックが帳票・画面・マトリクスに6重複し、画面ごとに表示がズレていた。唯一の生成関数へ集約するまでと、差分ゼロを確認してから切り替える移行のポイント。
-
定数をコードでなくデータベースに置く — 団体差を吸収する仕組み
団体ごとに変わる設定値を定数としてDBに持ち、起動時にdefineする設計。その利点と、型・存在をコード側で守る契約について。