リファクタリングを避けるコードデザイン(Railsを題材として)
2つの不確実性とリファクタリング プロダクションコードを書いていると、リファクタリングをしなければならないコードにぶち当たります。 正直なところリファクタリングは時間がかかるので避けたいものですが、必要になるようです。 必要な理由は大きく分けて2つあります。 1つ目は市場など外部の不確実性に対抗し、既存実装では不要だった抽象化を機能のために追加するためです。 これは因果的に回避できませんが、プロダクトの改善に直結するという意味でポジティブなものです。 2つ目は内部不確実性に対抗し、既存コードの意図の明瞭化や、必要以上の抽象化で身動きが取れない状況を改善するためです。 これは注意深くコードを構成することで回避可能なものです。 今回の記事では後者のリファクタリングを回避するためにどのようにコードを構成すべきかについて、筆者の判断基準を明確化することと、Railsでの適用例を示します。 (事例は
Railsでリファクタリングにオススメな gem 5選 - Money Forward Developers Blog
みなさん、こんにちは。 ウェブ・サーバーサイドを担当しています、Railsエンジニアの黒田です。 マネーフォワードも早いもので、サービスインしてから２年以上が経過しました。 サービスをご愛顧してくださっている皆様には、心から感謝しております。 さて、今回のエンジニアブログは「リファクタリング」についてです。 マネーフォワードのように、ユーザーファースト＆デリバリー優先で爆速開発を進めていると、サービスとしてはイケてても、コード的にイケてるとは言い難い部分が発生してしまいがちです。 「思いやりのないコード」「可読性が悪いコード」「必要以上に複雑なコード」は、バグ発生率を高め、開発スピードを低下させ、何よりエンジニアの気分を憂鬱にさせてしまいます。。。 マネーフォワードでは継続的かつ積極的にリファクタリングの時間を創る取組みをしていますが、そのなかで今回はRailsのリファクタリングでとても便
Rendering Collections in Rails
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 %>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
レールの伸ばし方
Blog
