技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
良いコードってどんなコードですか？という質問を受けたら何と答えるか - snoozer05's blog
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期（それぞれRubyの会社で働いている）と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の
Don't DRY Your Code Prematurely
TotT 98 GTAC 61 James Whittaker 42 Misko Hevery 32 Anthony Vallone 27 Code Health 27 Patrick Copeland 23 Jobs 18 Andrew Trenk 12 C++ 11 Patrik Höglund 8 JavaScript 7 Allen Hutchison 6 George Pirocanac 6 Zhanyong Wan 6 Harry Robinson 5 Java 5 Julian Harty 5 Alberto Savoia 4 Ben Yu 4 Erik Kuefler 4 Philip Zembrod 4 Shyam Seshadri 4 Adam Bender 3 Chrome 3 Dillon Bly 3 John Thomas 3 Lesley Katzen 3 Ma
Why, after 6 years, I’m over GraphQL
GraphQL is an incredible piece of technology that has captured a lot of mindshare since I first started slinging it in production in 2018. You won’t have to look far back on this (rather inactive) blog to see I have previously championed this technology. After building many a React SPA on top of a hodge podge of untyped JSON REST APIs, I found GraphQL a breath of fresh air. I was truly a GraphQL h
数値や日付をさまざまな形式の文字列に！ toLocaleString()を使ってスマートに変換しよう - ICS MEDIA
数値や日付をさまざまな形式の文字列に！ toLocaleString()を使ってスマートに変換しよう ウェブアプリケーションなどでは外部のAPIからデータを取得して表示することがあるでしょう。しかしながら、APIの値を必ずしもそのまま表示せず、ユーザーにとって分かりやすい文字列に加工することもあります。たとえば、数値をカンマ区切りにしたり、日付データを特定のフォーマットに変換したりといったことはみなさんも経験があるのではないでしょうか？ そのような数字や日付を変換するのに便利なのが、JavaScriptのtoLocaleString()メソッドです。このメソッドを使うことで、数値や日付をさまざまな形式に変換できます。この記事では、toLocaleString()メソッドの使い方と、その応用例を紹介します。 サンプルを別ウインドウで開く コードを確認する toLocaleString()メソ
実装に“思想”を乗せ続けて 「携帯動画変換君の人」がCTOになるまでの開発人生放浪記【フォーカス】 レバテックラボ（レバテックLAB）
株式会社バーチャルキャスト CTO MIRO／岩城 進之介 1972年生まれ。東京都出身。複数の企業において、映像制作やオーサリングツール、PDA端末の内蔵ブラウザなど、多岐な開発に携わる。個人としては2000年代に「携帯動画変換君」の開発などで注目を集める。2011年に株式会社ドワンゴに入社。360度LED画面を擁した没入型映像ライブ施設「ニコファーレ」でのネット連動演出システムや、ARライブシステムの開発など、AR、VR、放送技術、イベント演出のシステム開発を手掛ける。2018年、3Dアバターの共通フォーマット「VRM」を設計・提唱。同年、バーチャルキャストの立ち上げに携わり、CTOに就任。2023年、POPOPO株式会社を設立。 X ブログ「MobileHackerz」 バーチャルキャスト公式サイト VRMコンソーシアム POPOPO株式会社 かつて、「携帯動画変換君」というフリーウ
令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
単体テストの考え方/使い方 の感想文 | フューチャー技術ブログ
はじめにTIG EXU真野です。 積読を消化しようというテーマの、読書感想文連載 の1冊目は、単体テストの考え方/使い方 です。 書籍の基礎情報です 2022年12月28日発売 Unit Testing Principles, Practices, and Patterns の翻訳書。原著は2020年1月14日に発売 テーマ 質の高いテストを行い、ソフトウェアに価値をもたらそう！単体（unit）テストの原則・実践とそのパターン プロジェクトの持続可能な成長を実現するための戦略 単体テストの原則・実践とそのパターン コード例は C# であるものの、どの言語でも適用できる汎用的な内容とのこと 中を見ると、微妙にC#特有ぽいところに1箇所悩みましたが、それ以外はその通り 翻訳者の須田さんは、他にもセキュア・バイ・デザイン: 安全なソフトウェア設計 やOAuth徹底入門 セキュアな認可システムを適
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
「作りたいものをいかに早く完成させるかが正義」 まつもとゆきひろ氏が語る、ソフトウェア開発におけるベロシティの重要性
「作りたいものをいかに早く完成させるかが正義」 まつもとゆきひろ氏が語る、ソフトウェア開発におけるベロシティの重要性 #18 動的型付け言語と大規模開発 今回のテーマは「動的型付け言語と大規模開発 まつもとゆきひろ氏：こんにちは。まつもとゆきひろです。Matzチャンネル、18回目になりますね。今日は前回の続きで、「動的型付け言語と大規模開発」について話そうと思います。 本当は前回放送リリースした次の日ぐらいに放送できるようにと思っていたんですけど、意外と忙しくてですね（笑）。 今度、フィンランドのヘルシンキで、「Euruko」というカンファレンスが開かれるんですけれども、まだ物理で海外旅行する気にならないので、キーノートを録画しましょうという話になって、そのキーノートの準備をして、スライドを書いて、英語の講演を録画するみたいな作業をしていたら、あっという間に時間が経ってしまって、「Voic
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」大企業病の罠を乗り越え若々しいチームを実現する/Traps of Optimization in Product Management 2024
「プロダクトマネージャーがプロダクトマネジメントを失敗させる!?」カオスなプロダクト開発を効率化したら硬くて息苦しい官僚組織になっちゃった! 大企業病の罠を乗り越え若々しいチームを実現するぞ 効率化を進めていったら息苦しい組織になってきたと悩む方に向けたセッションです。 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19268 発表者 https://twitter.com/_N_A_ https://note.com/mryy 関連スライド 「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法 https://speakerdeck.com/moriyuya/product-management-rsgt20
影響力のあるプロダクトリーダーシップとは 〜リーダーシップのBサイド：信頼獲得編〜 / B-side of Product Leadership
ProductZine Day 2024 Winterでの登壇スライドです
変数への再代入を避けたいのは何故か - Qiita
##記事の想定読者 コードレビューで困ったことのある方 感覚的な経験を他人に納得させるための言葉が必要な方 ##一言で答えると 再代入は参照透過性を壊すため ##参照透過性って何さ 以下のような性質のこと 関数は同じ引数に対して常に同じ値を返す 値は最初に定義した値から常に変わらない ##参照透過性を確保したい理由 関数やクラスの仕様を一意に定められるため、バグの混入を避けやすい。 テストが容易になる。 状態の変化を考慮する必要がないため、パターンの組み合わせ爆発が起きにくい。 ##まとめ : 再代入を許容すると何が起きるのか 言い換えてみるとわかりやすい hoge = fuga だった値が、いつのまにか hoge = piyo に変更されている状況では 値が変わった場合でも正しく動作するということを再度テストする手間と 値が変わったことを検出する手間と それを見落としてしまうリスクが生じ
変数代入を複数回行うと何が良くないのか、どうするといいのか - コード日進月歩
変数の代入を複数回行う、すなわち変数の再代入をすることは何が辛いか、また変数の代入を1回にすると何が嬉しいかを書く。 今回の題材 例えばRubyで以下のようなメソッドがあるとする def make_aisatsu_text(people_name: "Suzuki", is_san: false) text = is_san ? "さん" : "" text = people_name + text text = text + "、こんにちわ！" return text end この記述を例に辛い部分は大きく以下の2つ 変数の状態がメソッドの最初から最後まで変わり続けるので変更に弱い （型付き言語だと発生しないが）途中の状態が削除されると読み取り難易度が増す １つずつ簡単に説明していく 変数の状態がメソッドの最初から最後まで変わり続けるので変更に弱い 上記の例だと text という内容が行
可変性の回避 ― Rubyへの関数型プログラミングスタイルの適用 | POSTD
本稿では、関数型プログラミングのコンセプトを実用的な方法でRubyのコードに盛り込む方法について紹介します。これは、私が「関数型プログラミングのスタイル」と呼んでいるものです。 私が言う「実用的」とは、関数型プログラミングのスタイルを取り入れた後もなお、コードの見た目や印象にRubyの特徴が残っていることを意味します。Rubyは、Haskellではありませんし、Haskellであるべきでもありません。考え方としては、この言語の性質を 利用しよう とするものであって、それに反することをするわけではないのです。出来上がったコードは、Rubyユーザにとって簡単に理解できるものであるべきです。うまくいけば、使い慣れているものよりも簡単と感じていただけるはずです。 では、可変性を回避する利点、方法、欠点、そして可変性の回避が適切ではないケースについて見ていきましょう。 なぜ可変性を回避するべきなのか
防御的プログラミングと契約プログラミング - よしたろうブログ
1. 猜疑心か相互信頼か、防御的か契約に基づくか 防御的プログラミングと契約プログラミングについて、後述する勉強会で疑問を持ち、勉強会内で説明されていること深堀りしてみました。 asken.connpass.com すべてが勉強になる話だったのですが、こちらの記事でフォーカスするのは「クラス設計スタイル」におけるふたつの選択肢 トランザクションスクリプト方式 ドメインモデル方式 に登場する「防御的プログラミングと契約プログラミング」になります。 トランザクションスクリプト方式が「防御的プログラミング」 ドメインモデル方式が「契約プログラミング」 増田さんのお話ではクラス設計において変更容易性を実現するには「ドメインモデル方式」選択すべきというお話でした。 本記事では、実装フェーズにおいて、各クラスがどのレイヤー以降なのか？によって、防御的・契約どちらのプログラミングを行うべきか異なる。とい
Feature Tests vs. Integration Tests vs. Unit Tests | Mix & Go
YOU SHOULD BE TESTING! — Every Rubyist Testing is important; you hear that a lot in the Ruby community. And not without good reason. But this doesn’t apply to Ruby alone. Ruby on Rails applications should have a well built testing suite. And if you’re just learning Ruby on Rails (or Ruby), this topic might not be as sexy as all the others, but trust me when I say it is very important to the qualit
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
強いエンジニアという灯
Top Page | Ryuzee.com