古いコードに向き合い、未来に何を遺すか - たきざわの日記
ここ数年は仕事で「最後のコミットが10年前」みたいなコードを触ることが多く、古いコードに対してどのように向き合うかと同時に、 コードを長く維持していく上でどのいう振る舞いをするとよいかを考えることが多くなった。 年末なので、自分が特に最近意識していることをを紹介する。 要らないコードはさっさと消す 年末といえば大掃除、ということで年末らしい話題。普段仕事をしている中で「これは使われてなさそうだけど、消していいかわからないな」とか、「これは今は使わなくなったけど、残しておいたらあとで使うかもしれないし残しておく」という場面がある。 消すためにもちょっと調べないといけないし、消すより残しておいたほうが安全だし、面倒なので残しておくか・・・ということをやったことはないだろうか。僕はある。 しかし必要のないコードなのであればさっさと消したほうがよい。現代だと大抵gitなりなんなりで管理されているの
20 万行超のコードベースをテストせずにリファクタリングリリースした話 - MonotaRO Tech Blog
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
マネーフォワード MEのモバイル開発の生産性を爆上げした事ランキング - Money Forward Developers Blog
マネーフォワード ME（以降ME）のモバイルエンジニアの椎名です 今回、MEのモバイル開発のコストを大きく削減し、生産性を向上させた話をします どれくらいかというと、体感値ですが少なく見積もって 1/5くらい にはなったかな、とは思います(2018年頃と比較) この事は何か1つの取り組みによって達成されたのではなく、いくつもの取り組みによって数年かけて達成されました ここでは数々の取り組みの中から、"これは効果があった!"というものを独断と偏見でランキング形式にして紹介します 少しでも皆様のサービスに役立てていただければ幸いです 1位 リファクタリング 1位がありきたりな事で恐縮ですが、今のMEのモバイル開発を支えているのは間違いなく過去に行った大規模なリファクタリングです 2018年頃iOS版MEは、複雑化したアーキテクチャとコードに悩まされていて 当時、行き詰まりを打開するためにフルリ
内的品質を無視せざるを得ない状況に陥るな - Object.create(null)
ソフトウェアの品質 ソフトウェアの品質といえば, 大まかに外的品質と内的品質に分けられます. 外的品質: ユーザーから見た品質 例: 安全かつ確実に動作すること, 操作しやすいこと 内的品質: 開発者から見た品質 例: 変更しやすいこと, 型・linter・テストなどに守られていること, 読みやすいこと 当然ですが, ソフトウェア開発者としては外的・内的どちらの品質も高い, という状態を目指すべきでしょう. 場合によって優先度こそあれ, どちらかを一方的に切り捨てるべきではありません. どちらの品質から高めるか ある程度の複雑さを持ったソフトウェア (のコンポーネント) を作る場合, 大抵はどちらの品質も高い状態に向かって一直線に進めることはなくて, まずはどちらか一方の品質が高い状態を目指すのが普通かなと思います. こういった開発の進め方については様々な流派があると思いますが, ここでは
何年も前に書かれたソースコードを読むときの頭の中 - Mitsuyuki.Shiiba
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
Don't write clean code, write CRISP code — Bitfield Consulting
I’m sure we’re all in favour of “clean code”, but it’s one of those motherhood-and-apple-pie things that no one can reasonably disagree with. Who wants to write dirty code, unless maybe it’s for a porn site? The problem, of course, is that few of us can agree on what “clean code” means, and how to get there. A rule like “methods should only do one thing”, looks great on a T-shirt, but it’s not so
はてなブログで使われているフロントエンドのテストツールを統一した話 - Hatena Developer Blog
はてなでエンジニアアルバイトをしているid:wafuwafu13です。はてなブログのフロントエンドで使われているテストツールの統一を2021年11月頃から進めてきましたが、この8月に完了したので振り返りたいと思います。 はてなブログのフロントエンドに残された秩序の乱れ テストツールを統一する理由とツールの選定 移行をどう自動化したか（しなかったか） 余裕のあるスケジュールで小分けして作業を実施 はてなエンジニアのアルバイトは通年で募集中！ はてなブログのフロントエンドに残された秩序の乱れ 2020年のid:nanimono_demonaiさんの活動により、はてなブログのフロントエンドのテストはPhantomJSとKarmaを撤退し、Jestに移行されました。 はてなブログのフロントエンドに秩序はもたらされたのか - Speaker Deck これによって秩序がもたらされたものの、Node.
GitHub上で構築するコードメトリクス計測基盤 / TECH STAND #9 GitHub
https://standfm.connpass.com/event/256786/ GMOペパボではGitHub Enterprise Server を利用しています。 また、CI/CD基盤としてGitHub Actionsを活用してしています。 本発表ではGitHub上に構築したコードメトリクス計測基盤と、それを実現するために使用したGitHubやGitHub Actionsの機能について紹介します。 Links: https://github.com/k1LoW/octocov https://tech.pepabo.com/2022/01/06/four-keys-dashboard/ https://tech.pepabo.com/2022/04/25/code-metrics-dashboard/ https://recruit.pepabo.com/
期間の扱い方とその名前 - いけだや技術ノート
とあるAPIのスキーマの叩き台をクライアントサイドとして検討している際に、コンテンツの公開期間やイベントの開催期間のような期間について議論が少し盛り上がった。 要件としては、期間の開始と終了の日時をそれぞれ取得できたい。 期間を考える時、開始と終了がそれぞれinclusiveなのかexclusiveなのかをまず考慮すべきであるが、開始日時の重複や終了日時に隙間を発生させないためには、開始はinclusive、終了はexclusive、つまり半開区間（左閉右開）にするのが望ましいだろう。 終了をexclusiveにすると、例えば8月の1ヶ月間、つまり8月1日0時0分〜9月1日0時0分という期間の場合、ユーザー向けの表示としては終了日時は「8月31日23時59分まで」と表示したくはなるが、これはプレゼンテーションロジックとしてクライアントサイドの責務としてやる。基本的には-1秒してからフォーマ
Code Smells Catalog
Clever Code I am creating a conscious distinction between the Obscured Intent and Clever Code. While Obscured Intent addresses the ambiguity of implementation… Duplicated Code Duplicated Code does not need further explanation. According to Fowler, redundant code is one of the worst smells [1]. One thing is that this makes…
サービスを停止せずにデータベースリファクタリングする - Pepabo Tech Portal
2022年7月13日にカラーミーショップで提供開始した「副管理者機能」のアップデートにあたって、従前の挙動を変えずにデータベーススキーマの構造を変える必要がありました。また、サービスの提供を停止することなく、スキーマの構造の変更を進める必要がありました。 この記事では、サービスを停止せずにデータベースの構造を徐々に変更するデータベースリファクタリングをどのように進めたかについて紹介します。 「データベースリファクタリング」とは データベースリファクタリングについて体系的に述べた書籍として"Refactoring Databases"があります。この本では、データベースリファクタリングのさまざまなパターンにおいて、スキーマの変更、データマイグレーション（既存データの移行）、アプリケーションの変更それぞれをどのように進めるべきかについて解説しています。ここでは、"Refactoring Dat
先回りするコツとミカドメソッドという手法 - id:onk のはてなブログ
実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。 結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。 mikadomethod.info ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。 概要は本家なりこの辺のリンク先なりを見て貰って。 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット） 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo テストとリファクタリングに関する深い方法論 #wewlc_jp レガシーソフトウェア改善ガイド | Amazon 僕の理解は 1 ループ目 やりたいことを実現するコードを書く ギャップが無ければサクッと実装して終わり
Well-organized Transaction Script - リファクタリングの妥協的手法 -
設計ナイト2022 Related Links: p.7 https://speakerdeck.com/qsona/developing-masterdata-management-tool-by-using-vscode-extension p.18 https://higayasuo.hatenablog.com/entry/20080519/1211183826 p.30 https://speakerdeck.com/qsona/architecture-decision-for-the-next-n-years-at-studysapuri
ComplexとComplicated - kawasima
日本語だとどちらも「複雑」を意味するが、英語だと「Complex」と「Complicated」の2つの単語が該当する。 両者は明確な違いが無いともされるが、使い分けられるケースもある。Complicatedの方が頑張れば解消可能とされ、「複雑」じゃなく「込み入った」という訳語があてられることもある Cynefin Frameworkにおける使い分け Complicated: 分からないことは分かっている。理解するのは難しいが、時間と労力をかければ最終的にはわかる Complex: 分からないことが分からない。 英語ぷらすでの説明 Complicated: 関係性や状況が複雑。物理的でなく心情的・観念的にややこしい Complex: 構造や手順が複雑。物理的な複雑さ 対義語から Complexの対義語としてSimpleが使われるが、Complicatedの対義語としてはあまり使われない。 C
ボーイスカウト・ルール、先に直すか、後から直すか。 - ちなみに
ボーイスカウトルール。 機能追加より、 先に直すか、 後から直すか。— 人生踊れば丸儲け (@tomohi_ro) 2022年4月3日 まれによく目的の変更にリファクタリングを混ぜたプルリクのレビュー依頼を受けるので、そのたびに変更とリファクタリングは分けてねって話をしている。 レビューするときにもdiffが混ざっていて見にくいし、将来的に変更の経緯を追いかけるときにもノイズになってしまう。 コミットが分かれていたらまだマシなんだけれど、そういう場合はたいてい同じコミットに複数の目的が混ざってしまっている。 www.clear-code.com 僕は1コミットには1つのことというルールを出来るだけ守ろうと思って暮らしているのでどちらかというと過激派なのですが、プルリク単位くらいではやることを絞って欲しいとは思っています。 みんな単一責任原則は大好きな気がするけど、コミットやプルリクにも同じ
リポジトリ内のソースコードを機械的にリファクタリングし続けるスクリプトを作る - hitode909の日記
こんにちは、はてなのマンガチームでPerlを書いているid:hitode909です。 先日書いた、Perlのソースコードをリファクタリングし続けるスクリプトについて紹介します。 @EXPORTを撲滅したい 普段Perlを書くときに苦労していたのがテストを書くことで、さまざまなテスト用のヘルパ関数がどこからexportされているかわからない、という困りごとがありました。 私たちのプロダクトではマンガビューワを作っているので、テスト用の作品をcreate_seriesで作り、作品に紐づくエピソードをcreate_episodeで作り、エピソードに対してテストを書く、というような流れでテストを書くことが多いです。 以下の例ではGiga::Test::Core::Seriesからcreate_seriesがexportされていますが、込み入ったテストでは、このようなuseが数十行に渡って続き、どこ
良いコードとは何か - エンジニア新卒研修 スライド公開
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発生産性、上から見るか 下から見るか / development productivity and cognitive science
複雑さに立ち向かうためのコードリーディング入門