手元にある LINE ボット環境のソースファイルが 1 ファイルにも関わらず 350 行超えたので、最近勉強したドメイン駆動設計を実践も兼ねてリファクタリングしてみました。 こんにちは、高崎＠アノテーションです。 はじめに 過去の拙記事にも何度か登場している自身の LINE ボットの環境ですが、cdk のスタック定義が約 100 行、Lambda のソースが約 370 行と注ぎ足し注ぎ足しでだんだんと大きくなってきました。 一方、業務で使用している環境はドメイン駆動モデルを元に設計・構築を行っているものが多いため、これらの環境やドメイン駆動設計を学んだことを実践すべく、この LINE ボット環境をリファクタリングしてみました。 この記事の対象 筆者と同じく「ドメイン駆動設計を始めたばかりの方」向けと考えております。 今回の内容は筆者個人が参考文献を元に記載した記事で、ドメイン駆動設計の正確
皆さんこんにちは。 CTO-Office の香川とEC開発-Bグループの竹原です。 11/28に 和田卓人氏(id:t-wada)を講師としてお招きしてテストとリファクタリングのためのワークショップを開催いたしました。 技術者正社員のうちプログラミングをすることの多いメンバー全体の約1/3にあたる総勢53名が参加しての開催となりました。 本記事ではまず第一弾としてワークショップの概要や目的、全体の流れについて簡単にご紹介いたします。 また第二弾(2024年1月公開予定)では、運営とワークショップの問題の作問に関わったメンバーにそこでの学びや実践について紹介いただきます。 開催に至った経緯とMonotaRO DOJO MonotaRO DOJO とは 社内の課題とワークショップの目的 開催経緯 ワークショップの全体像と開催までの段取り ワークショップの全体像 概要 タイムテーブル 開催までの
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
#CNDT2021 で Kustomize の話をしたときの資料です。
19/07/24開催の「持続可能なプロダクト開発への取り組み ～メドピアとクラウドワークスの事例公開～」における、クラウドワークス側の登壇資料です。 https://connpass.com/event/136791/Read less
コードから不吉なにおいがしてきたなーと思うことはよくあるだろう。リファクタリングの機運かもしれないし、YAGNI原則を思い出して踏ん張るときかもしれない。では、いつリファクタリングをやるべきか、どのようにコードを整理していくべきだろうか？ リファクタリングには方針が必要リファクタリングの目的は、コードの拡張性を高めることだ。ここではそういうことにしよう。Open-Closed原則に従うように、凝集度を高め、結合度を低くするようにやっていけばいい。つまり、何か既存機能を変更するときはたった1箇所だけの変更で済むとか、もしくは新しい機能を足すときには既存機能を触らないで済むとか、そういう状態であれば比較的マシなコードになりえるよねっていうことです。 では、あらゆる変更に対してOpen-Closedであることはできるのか？おそらくそれは難しい思う。なので僕らは、経験的に「どの辺に変更が入りそうで
こんにちは。Airシリーズ開発チームでiOSの開発リードを担当している永井です。 この度、Airレジから予約台帳機能を切り出して、Airレジとレストランボードの2つのアプリとして新たに5/10にリリースしました。 iPad版・iPhone版合わせて181,175行あったAirレジですが、今回内部的にもObjective-CからSwiftに全面的に書き換えています。 まだまだリファクタリングしていきたい課題はありますが、コード行数は70%も減り（つまり元々の行数から30%になりました）、SonarQubeで示される技術的負債も500dから21dに減り、かなり成功したと言って良いのではないかと思っています。 今回の取り組みの中で、良かったこと・再検討したいことがいろいろ発見できました。それらについてまとめてみるので、これからSwift採用を検討している方々の参考になれば幸いです。 取り組みのポ
大変長らくお待たせしました。Forkwell Jobs にて、2015年11月24日〜12月31日の期間で開催していた【リファクタリングコンテスト in Ruby 】の審査結果がようやく出揃いました。 今回、なんと最もよいコードに贈られる Ruby賞 を1人のユーザーが独占する結果となりました。 気になる審査結果の前に、あらためて審査員をご紹介します。 松田 明 ( @a_matsuda ) Ruby / Rails / Haml / CarrierWave等のコミッター。kaminari / action_args / active_decorator / motorhead 等の作者。 好きな寿司：アナゴ 和田 卓人 ( @t_wada ) タワーズ・クエスト株式会社取締役社長、プログラマ。日本におけるテスト駆動開発（TDD）のスペシャリスト。 好きな寿司：赤貝 藤村 大介 ( @ff
class: center, middle # Refactoring in Scala Scala Matsuri 2016 1/30 --- class: middle ## Who am I * Manabu Nakamura * [@gakuzzzz](https://twitter.com/gakuzzzz) * Tech to Value Co.,Ltd.  --- class: middle ## Who am I I'm a "Professional Null Cleaner"  Lately my work has been removi
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか（1/2 ページ） 大企業では実施が難しいと思われるソフトウエアのリファクタリング。富士ゼロックスでは、どのように取り組んでいるのか。リファクタリングの実施を決断した理由、課題とその対応方針、成果、今後の展望などについて聞いた。 バグの有無ではなく保守性を品質管理の指標にすべき 1962年設立の富士ゼロックスは、主に複合機やオフィスプリンターなどに内蔵されるコントローラーソフトウエアの開発を行っている。コントローラーソフトウエアは、スキャナーで撮り込んだ画像の加工や印刷、ネットワーク経由の通信、セキュリティなどの各種機能を、操作パネルのユーザーインターフェースを介して制御しており、昨今の多機能なオフィス機器の要といえる。 一方で、多機能になったことでコードは大規模かつ複雑化の一途をたどっ
他の人が書いたRubyコードをリファクタリングしてみました。 画質を上げてから視聴してください。(720p以上 x PC全画面表示を推奨) 題材に使った問題はこちらです。 http://judge.u-aizu.ac.jp/onlinejudge/description.jsp?id=2006 リファクタリングしたコードはこちらにあります。 https://github.com/JunichiIto/Keitai-Message 見どころはこのあたりかも。 getterメソッドではなく、attr_readerを使う - 開始位置: 0:04:00 API利用者の予想を裏切るような「サプライズメソッド」をなくす - 開始位置: 0:15:45 仕様書に書かれていない「憶測に基づいた独自仕様」をなくす - 開始位置: 0:33:20 正規表現を導入してコードをシンプルにする -
みなさん、こんにちは。 ウェブ・サーバーサイドを担当しています、Railsエンジニアの黒田です。 マネーフォワードも早いもので、サービスインしてから２年以上が経過しました。 サービスをご愛顧してくださっている皆様には、心から感謝しております。 さて、今回のエンジニアブログは「リファクタリング」についてです。 マネーフォワードのように、ユーザーファースト＆デリバリー優先で爆速開発を進めていると、サービスとしてはイケてても、コード的にイケてるとは言い難い部分が発生してしまいがちです。 「思いやりのないコード」「可読性が悪いコード」「必要以上に複雑なコード」は、バグ発生率を高め、開発スピードを低下させ、何よりエンジニアの気分を憂鬱にさせてしまいます。。。 マネーフォワードでは継続的かつ積極的にリファクタリングの時間を創る取組みをしていますが、そのなかで今回はRailsのリファクタリングでとても便
今まで golang で変数名や関数名のリネームには gofmt の -r オプションを使ってきましたが、これからは gorename を使いましょう。 文法を解析して正しくリネームしてくれるので、gofmt で起き得た誤爆も心配ありません。インストールは以下の様に実行します。 $ go get golang.org/x/tools/cmd/gorename 使用方法は以下の通り。 gorename: precise type-safe renaming of identifiers in Go source code. Usage: gorename (-from <spec> | -offset <file>:#<byte-offset>) -to <name> [-force] You must specify the object (named entity) to rename
Partials are a great way to break down complex view into more manageable chunks as well as keeping view code DRY. However, rendering a partial for each item in a collection looks ugly: <% @user.comments.each do |comment| %> <%= render partial: 'comments/comment', locals: { comment: comment } %> <% end %>
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
