監視とオブザーバビリティ 〜 悩む前に確認しておくべきこと / 20230926-ssmjp-monitoring-and-observability
こんにちは、BASE株式会社 ランニング部部長の元木です。 日々、社員に運動不足解消を促す傍ら、Owners Marketingというチームでバックエンドエンジニアをしています。 さて、弊社ではソースコードを変更した際に必ずメンバー間でコードレビューを行ない、OKが出たコードだけをデプロイすることになっております。 今ではほとんどの開発現場でコードレビューを取り入れていると思いますが、読者の中には 「レビューのコメントって、どう書いたらいいのか分からない」 「こんな事を言って嫌な顔をされたり、喧嘩にならないか心配」 などと、苦手意識を持っている人もいるのではないでしょうか? そこで、今回は私がコードレビューの際に気をつけているコメントの書き方をご紹介したいと思います。 気を付けているポイントとレビューコメントの書き方の例 私は、レビューで指摘事項をコメントする際のポイントは 「いかに分かり
Martin FowlerがRefactoringの第二版 を記念してThoughtworks主催でWebinarを開催しました。 内容を箇条書きですがメモってみました。 雑に取ったものなので、誤字や合っていない部分もあるかもしれません。気付き次第、修正していきます。また、録画したものが、もし公開されたら、それをベースにもう少し整地にできれば、と思います。 なぜ新しい版? 基本的には変更はいらない とは言え 言っているコードとかが古い(java.util.vectorとか) Javaでない言語とかも念頭に入れたい リファクタリングでないものは? 見た目が変わらない変更 内部的な変更 理解しやすくするため 新機能開発とリファクタリングは行き来するもの まだまだ足りない?なぜか? まだ認知が低い 新しいエンジニアが入ってきている 教育が常に必要 新しい人への助言 実践あるのみ メンターがいると
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの1つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
この記事はCrowdWorks Advent Calendar 2018 の2日目の記事です。 はじめに こんにちは。 クラウドワークスでプロダクトオーナーをしている 柴田 @shiba_319 です。 私の担当するWEB開発チームでは、今年6月から10月の約5ヶ月間、クラウドワークスのコア機能の一つである「仕事依頼画面」の大規模なリファクタリングプロジェクトを行なっていました。 私は、普段コードを触るのはちょっとしたスタイル修正や簡単なコード修正程度の非エンジニアPOなのですが、 今日はそんな自分が 「約6万行の大規模リファクタリングを完遂するうえでPOとしてやってよかったこと」を書きたいと思います。 4名の開発チームで大規模リファクタリングをすることになった経緯 私たちの開発チームは、当時4名チームで、クラウドワークス発注者向けのUI/UX改善を担当していました。 (構成はエンジニア2
はじめに こんにちは、メドピアの駆け出しエンジニアの川﨑です。 最近我が広島カープが日本シリーズ進出を決めて機嫌が良いのでブログ書きたいと思います。 今回僕がお届けするのは、先月の9月14日 「Rails開発での技術的負債との付き合い方」 をテーマに開催された 「MedBeer」 にて、 Classi株式会社のCTOである佐々木 達也(@sasata299)さんの発表にて紹介された「整地部」がMedPeerでもできたよ!というお話です。 整地部とは? 整地部の定義に関しては、以下にある佐々木 達也さん の興奮する資料が分かりやすいです。 一言で言うと 技術的負債となっているコードを少しずつでも良くしたい人たちの集まり です。 どんな風に進めたか? 記念すべき第一回は、弊社Railsの技術顧問である前島(@willnet)さんがいらっしゃる水曜日に開催されました。 進め方としては、僕が前々か
2エントリ連続でこんにちは、@mugi_unoです。 名古屋には台湾ラーメンイタリアンという名物があるそうです。 富山県民の私には理解が追いつきませんでした。 フロントエンドでの金額計算処理 さて、Misocaは請求書作成サービスなので、金額計算処理が欠かせません。 フロントエンドも例外ではなく、消費税額や合計額を算出するロジックが存在します。 機能変更が必要になった!! 諸事情により、そのロジックに変更を加える必要が生じました。 長くプロダクトを支えてくれていた存在ですが、内容的にはいわゆるレガシーなコードで、たびたび開発者ミーティングでも課題として挙げられることがありました。 git log で確認してみると、該当コードに対しての機能的な変更は2015年の冬から行われていません。 何が問題だったのか? DOM操作と計算ロジックの混在 Misocaでは、新しくコードを書く際はVueやRe
リファクタリングの基本的方針のひとつめは、コードをできるだけ小さな単位に分割することです。 小さな部品のほうが理解しやすく、バグも少なくなるからです。 また、コードを小さく分割することで、そのまとまりごとにメソッド名やクラス名などの名前を付けることができます。 実は、この名前がコードがわかりやすくなるかどうかの分かれ目になります。 コメントを充実させるよりも、リファクタリングによってコードの断片をまとめ、適切な名前を付けるべしというのがリファクタリングの教えです。 (もちろん、実際にはコメントも重要ではありますが。) そして最後に重要なのが、コードの重複をできるだけ少なくすることです。重複コードを見つけたらまず間違いなくリファクタリングの対象になります。 重複するコードがあるということは、プログラムの変更時に変更しなくてはならない箇所が分散してしまい、変更時のバグが入り込みやすくなってしま
ちょっとそこのお客さん。ずいぶん浮かない顔をしていますね。え、仕事はプログラマ? そして評価が高く実績もあるプログラムのメンテナンスの仕事を任された? それはおめでとうございます。 え、めでたくない? それはいったいどうしてですか? ほほう。つまり、ユーザー・インターフェイスはすごく格好よいのに、ソース・コードがぐちゃぐちゃで何が何やら分からないと。それなのに、評価の高いソフトだからと機能追加の要求がいくつも発生していると。何が何やら分からないソース・コードを修正して、その要求に対応しなければならないわけですか。それは難儀ですな。すぐにやれといわれても、できるわけがない。 え、それは問題ではない? もう時間がかかることは了承させた? それは結構なことで。それなのに、どうして浮かない顔をなさっているので? ははぁ、時間をかけて書き直したとしても、その書き換えが正しいのか自信が持てないと。どこ
This plugin contains some basic refactoring commands for C/C++. For the complexity of C++, instead of really parse the source code, I used regular expression matches. But it works well as I tested. NOTE: It doesn't work for old style parameter declaratoins! And I admit that it may mess up your code sometime if you occasionally forget the rules. Thanks for the kind man who point out this. The refac
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く