{あれ K#F85E/5B28-25A4}宇田川浩行 しかし,アプリケーションを「相振り」(あいぶり),データベースを「出場」(でば)と訳すと急に情技(IT)用語が渋い職人用語みたいになるな。データは「出与え」と訳してるから,出与えが出た場所(データバーショ),出場所,出場,で理には適っているのだが……。
{∗ K#F85E/5B28-476E}宇田川浩行 もう一つこの理腑(リファクタリング)で再確認したことは,ウェブ相振り(アプリ)でも言語の性能や最適化は重要だということ。出場(DB)ばかりに注目していると,意外と相振り側にゴミが溜まってたりする。
{あれ K#F85E/5B28-D03A}宇田川浩行 そんな作業をしながら感じたことだが,「理腑」(リファクタリング)という希哲館訳語,これ以上の翻訳語は日本語ではありえないので,是非使ってほしい。というか,技術者なら悪いことは言わないから無理にでも使え。リファクタリングとは「腑を理(おさ)める」こと。この表現を使わないだけで技術者として損している。
{あれ K#F85E/5B28-CC45}宇田川浩行 不幸中の幸いだったのは,デライト正式離立(リリース)についてほとんど宣伝しなかった,というか出来なかったことだ。最初はもっと大々的に宣伝していくつもりだったのだが,そんな暇が無かった。
{あれ K#F85E/5B28-BCDE}宇田川浩行 今のところ,デライト正式離立(リリース)と引き換えに得ているものの方が圧倒的に大きく,正式離立の覚悟を決めてはじめて見えてきた課題が多々あるので後悔も無いのだが,そろそろ技術的負債か機会的負債かの微妙な判断を迫られそうだ。
{あれ K#F85E/5B28-B934}宇田川浩行 そうして理腑(リファクタリング)を進めた結果,1週間前とは比べものにならないほど内部実装は整理され,洗練されたものになった。例えば10行かけて書いていた処理が1行になったり,あちこち分散していた類似交度(コード)が一箇所に集約されたり,といったことだ。保守性と性能向上に大きく寄与した。大袈裟でなく,この1週間の作業は長期的には3年以上の開発期間を節約したと思う。
{あれ K#F85E/5B28-AB67}宇田川浩行 そもそもデライトの CMS であるデルン自体が7年前に実用化したもので,交度(コード)も部分によってかなり年齢差があった。特に最初期に実装した中核部分は,当時の私の経験不足もあって「動くがごちゃごちゃ」という状態にあった。これに拡張を重ねていけば,まず間違いなく技術的負債に潰されるという直感的な判断で,理腑(リファクタリング)に時間を割くことになった。
{あれ K#F85E/5B28-BD0B}宇田川浩行 デライト正式離立(リリース)は12月1日の予定日から現在まで遅れているが,その主な理由は,「内部実装の混乱」にあった。表面的にそれなりのものは出来ているものの,離立後の保守・更新を考えた時,保守性にかなりの難を感じた。