ソースコードの品質向上のための効果的で効率的なコードレビュー
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
ちゃんとした C# プログラムを書けるようになる実践的な方法～ Visual Studio を使った 高品質・低コスト・保守性の高い開発
3〜4時間でAWSの監視系のサービス一気に学べたらコスパ良いと思いませんか | DevelopersIO
突然ですが、以下の機能がそれぞれどういうものか すべて ご存知でしょうか？ CloudWatch ServiceLens X-Ray CloudWatch Contributor Insights CloudWatch Synthetics CloudWatch Container Insights CloudWatch Logs Insights CloudWatch メトリクス Metric Math 検索式 カスタムメトリクス CloudWatch ダッシュボード CloudWatch 異常検出（Anomaly Detection） CloudWatch 埋め込みメトリックフォーマット CloudWatch アラーム 異常検出に基づいたアラーム 複合アラーム 私はわからなかったですね。ここ 1〜2年のCloudWatch系のアップデート量は凄まじいなと個人的には思っていて、Cloud
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
グーグルでは、社内のプログラマによって作り出される大量のコードの品質を保つため、チェックイン前にユニットテストとコードレビューが行われているそうです。しかし、コードが大量になってくると、ユニットテストやレビューをすり抜けるバグも少なからず発生します。 そこでコードの品質をさらに高めるために、グーグルでは「バグ予測アルゴリズム」を採用。バグがありそうな部分をレビュアーにアドバイスする仕組みを採用したとのこと。 そのバグ予測アルゴリズムとはどんなものなのか。Google Engineering Toolsブログに投稿されたエントリ「Bug Prediction at Google」（グーグルにおけるバグ予測）で説明されています。 ソースコードの修正履歴を基に予測 コードの中にバグがありそうな箇所を分析する手法としては、「ソフトウェアメトリクス」がよく用いられます。これはコードを静的に分析して、
クソコードの測り方
PHPBLT#3 で話した内容です。
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
ソフトウェア開発の原点は可能性の追求であり、不可能を可能にすることです。ひとたび ソフトウェア が開発されると、エンジニアは次に 程度 という課題に向き合うことになります。企業向けのソフトウェアであれば、「速度はどれくらいか」と頻繁に問われ、「信頼性はどの程度か」という点が重視されます。 ソフトウェアのパフォーマンスに関する質問に答え、さらには正しい内容を語る上で欠かせないのが統計学です。 とはいえ、統計学について多くを語れる開発者はそうはいません。まさに数学と同じで、一般的なプロジェクトで統計学が話題に上ることなどないのです。では、新規にコーディングをしたり、古いコードのメンテナンスをしたりする合間に、手が空くのは誰でしょうか？ エンジニアの方は、ぜひ時間を作ってください。近頃は、15分でも貴重な時間と言えるでしょうから、 こちらの記事をブックマークに追加 しておいてもいいでしょう。とに
AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください！ 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ
HTML5 Conference 11/25
NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん（今はグループ内でアメリカでの新規サービスの立ち上げをしています）からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで
はじめに 入門監視をはじめ一般的な監視に関するプラクティスは出回っているものの、AWSで具体的に何を監視するか？そのとっかかりについてはあまり出回っていないような気がします。 AWSの監視ってみんな何監視してるんすか…っていうぐらい実例あまり見つからないな。門外不出？— mazyu36 (@mazyu36) 2023年2月14日 どこまで監視するかは基本的にシステムの特性によると思います。一方でAWSのサービスごとにシステムによらずよく監視で使う項目というのもあるかと思います。 今回は過去の経験をもとに、最低限この辺りは監視することが多いかなというものをまとめてみます。全体像としては以下になります。 最低限これは監視しないとダメでしょ、とかこれは不要でしょ、などなどあるかと思います。そういうのがあればぜひコメントいただきたいです。 はじめに 「監視」について 前提 1-1. Webサービス
ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第7回は、要求仕様フェーズで作り上げる正しい要求仕様書に向けた第一歩となる「ヒアリング」について解説します。
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
開発者の生産性を測るためのフレームワーク`SPACE`について
LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて 以下記事も Four Keysだけじゃない開発者生産性フレームワーク 開発生産性の可視化フレームワークであるSPACEを活用するために、どのようなメトリクスをどう取得するかについて考えてみる 要約 SPACEは開発者の生産性を計測するためのフレームワーク 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字 satisfaction and well being performance activity communication and collaborati
東京・銀座の和食店、がんこ銀座四丁目店。街の喧騒から隔離されたくつろぎ空間は、商談の場としても人気が高い。ここが、過去数回にわたり科学的・工学的アプローチによる「おもてなし研究のフィールド」になった。顧客が望む十分な接客ができているのか。それをつかむため"仲居さん"にセンサーを付け、行動を分析。おもてなしのレベルを高め、夜間の注文件数を4割伸ばすことに成功した。サービス業では、顧客の評価に直結
データ分析部で部長をしている@cou_zです。最近はLIBROのマイクロフォンコントローラーをよく聴いています。 Gunosyにおけるプロダクト改善は、データ可視化による現状把握から始まると考えています。 ログを収集して、ダッシュボードでKPI(重要業績指標)を可視化することは、今では当たり前のことになっていると思います。深夜バッチでKPIを集計して、翌朝に確認することは重要ですが、KPIをリアルタイムに知ることによって、現状把握がさらに進むことがあります。 しかし、リアルタイムにKPIを集計できたとしても、実際にそれらを確認するとは限りません。頻繁にダッシュボードを見るのはとても億劫で、次第に見なくなってしまいがちです。そこで、日常的に開いているチャットにKPIがリアルタイムに通知されると、確認の際の負担を軽減することができます。 Gunosyでは、チャットツールにSlackをダッシュボ
「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 - BASEプロダクトチームブログ
はじめに CTOの川口 (id:dmnlk) です。 5月にオンラインmeetupをさせて頂きその中で「具体的な負荷対策に関しては開発ブログで！」と言っていた件ですが気づいたらもう9月になりかけていました。 コロナ禍においてネットショップ作成サービス「BASE」の利用者様が急増しました。 www.nikkei.com 5 月には 100 万ショップを超えるショップオーナー様にご利用していただいております。 今まで EC 事業を行っていなかった飲食店様や様々な業種の方が利用をはじめていただき、ショップオーナー様も購入者様共に短期の見通しでは想定をしていないアクセスが発生しました。 その途中でシステムとして対応しきれない面もあり、アクセス負荷によるサービスの不安定を招き皆様にはご不便や販売時間を変更していただくお願いなどをしてしまい大変申し訳ありませんでした。 現在では安定しておりますが、その
定量評価疲弊しませんか？～Well-beingと生産性指標を組み合わせた エンジニアリングメトリクスプログラムについて～
Developers Summit 2023 登壇資料 https://event.shoeisha.jp/devsumi/20230209/session/4171/ overflowは、副業・転職サービス「Offers(オファーズ)」の開発、運用を行っています。 サービスの提供を開始してから3年。サービスの拡大に合わせ、組織も比例して成長してきました。 その中で、組織の成長に伴い、どのように生産性指標を開発に取り入れていったか。 取り入れていった結果、状態把握から逸脱し何が起きたか。そして、その後どのようにして改善していっているかご紹介します。 私達が行ってきたことを例に(反省として)、数値に踊らされずに正しく運用する方法を考えるきっかけになれば幸いです。 ▼関連リンク Offers：https://offers.jp/ Offers MGR（オファーズマネージャー）：https://
Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blog
こんにちは。id:shiba_yu36です。MackerelチームでWebアプリケーションエンジニアをしています。最近の開発合宿で、id:syou6162やid:polamjagと一緒に、社内の全チームの開発パフォーマンスを表す指標をGitHubのPull Requestから可視化し、開発チームの改善に活かせるようにしました。今回はその紹介をします。 説明するサンプルコードは、次のレポジトリで公開しているので参考にしてください。ここではGitHubのhatenaオーガニゼーションで集計していますが、forkして少し手直しすれば、別のオーガニゼーションの集計も可能になっています。 hatena/pull-request-analysis-sample 開発チームの改善におけるいくつかの課題感 開発チームのパフォーマンス指標に何を使うか 4つの指標のうち何からまず集計するか 変更のリードタイム
自社ソフトウェアプロダクトを内製する組織であっても、開発チームがそれをどうやって作り上げているか、開発者ら以外にとってはブラックボックスであり、不可視です。それだけに、開発チームのパフォーマンスや内部状況の良し悪しは、各々の主観や興味によって、不統一な認識を持ってしまうことも多いでしょう。そしてそのような認識のばらつきは、開発する当人たちにとっても実は同じです。 しかし、例えブラックボックスであっても、自動車のダッシュボードのように様々な指標によってその内部が数値化され、可視化されていれば、チームのパフォーマンスに統一的な認識を持たせやすくなります。 本記事では、どのような指標を可視化すべきか、その代表的なものについて取り上げます。 リードタイム（開発、製造）リードタイムは、開発項目ごとの作業期間を計測したもので、短いほど優れていることを示す指標です。計測対象となるプロセス全体を「開発」と
Amazon RDS Proxy が BASE にもたらした期待以上の導入メリット - BASEプロダクトチームブログ
はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす
freee では仮想マシンのインフラ監視に Mackerel を使っていますが、Kubernetes を使っているところは前例にとらわれずゼロベースで見直そうとしています。現状は Elastic Stack と Mackerel のハイブリット構成になっています。 Elastic Stack による Kubernetes モニタリングシステムの紹介 - freee Developers Blog どの SaaS を使うかを決める前に、そもそも Kubernetes の何を監視すればいいのか？ というところから考え直しています。宣言的なマニフェストにより Kubernetes が自律的にあるべき状態を保ってくれるのであれば、これまでの監視とは異なってくるはずです。 監視の観点として、ここでは通知レベルを用いて次の 3 つに分類します。 None: メトリクスは収集するが通知しない Notic
『LeanとDevOpsの科学』をきちんと解読する 〜Four Keys だけじゃ絶対もったいなくなる話〜
スクラムフェス福岡2024での講演資料です。 --- 皆さん、職場でFour Keysを導入していますか？ Yesと答えた皆さん、『LeanとDevOpsの科学』は読みましたか？ あくまで僕の周囲のみの観測で語るのですが、Four Keysを職場で導入しているという人はとても多いのですが、そのうち、出典である『LeanとDevOpsの科学』をきちんと読んだ人はかなり少ないようです。 そして、ここで敢えて強めの主張をするのですが 『LeanとDevOpsの科学』を読まずにFour Keysをきちんと利用することはほぼ不可能です。 Forsgrenらは徹底した研究の結果として4つのメトリクス（指標）を見出すのですが、その裏には彼女らの沢山の思いが詰まっています。その思いや彼女らの思考を理解し、彼女らの考えをきちんとトレースして始めて、Four Keysは意味を持ちます。 そして『LeanとDe
みなさん、監視作ってますか？ システムを作ったら、そのシステムを監視していく必要がありますよね。どうやったら「いい監視」が作れるのでしょうか。「いい監視」とそうでない監視との違いとは、いったいなんでしょうか。 今の時代、「監視」ではなくて「可観測性」、 Observability (o11y) の時代になっていて、良いプラクティスや考え方が色々とあります。 この記事は、監視や o11y についての考え方を社内に共有するため書いたものを、社外共有用に調整し直したものです。新しい Observability の時代を、一緒に生きていきましょう。 監視を作ろう あなたはシステムを作りました。そのシステムに「監視」をつけようと思ったとき、最初にすることはなんでしょうか？ まずは、システムを何らかのツールで監視するところから始めましょう。やらなきゃはじまらない。 Nagios, Cacti, Mun
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
ソフトウェアアーキテクチャメトリクスの基礎: Software architecture metrics in a nutshell
ソフトウェアアーキテクチャメトリクス - Forkwell Library #44 での発表資料です https://forkwell.connpass.com/event/309739/ 動画: https://www.youtube.com/watch?v=C52rYX_E9bA #Forkwell_Library
Looking for Datadog logos? You can find the logo assets on our press page.
オリジナルグッズ作成・販売サービス「SUZURI」に関わるエンジニアメンバーや事業部長が登壇し、SUZURIの開発の今や、現在の課題・今後の取り組みについて話す「43万人超のクリエイターの表現活動を支える！ECプラットフォームSUZURIの開発の裏側」。ここで技術部の近藤氏が登壇。生産性をすることになった背景と、具体的な測定方法を紹介します。 自己紹介 近藤宇智朗氏（以下、近藤）：では、お願いします。「生産性を可視化したい」と題して発表します。ということで、自己紹介します。私は技術部に所属している、近藤といいます。ふだん、インターネットなどでは“うづら”と呼ばれているので、お気軽にうづらと呼んでください。現在、技術基盤チーム兼データ基盤チームという感じで働いていて、SUZURIの事業部には直接所属していませんが、お手伝いという感じで今回はお話しします。 ちなみに、福岡市のエンジニアカフェと
こんにちは、事業開発部でプロジェクトマネージャー兼エンジニアをやっている新井(@SpicyCoffee)です。10 万円の申請書を書く前に 20 万円のパソコンを買いました。 クックパッドでは、毎日の料理を楽しみにするべく日々サービス開発がおこなわれています。本稿では、サービス開発の中でも重要かつ難解な「KPI の設定」について、私がプロジェクトマネージャーとして普段考えていることや注意している点を紹介します。 KPI を決めるのは難しい サービス開発において KPI を設定し、それを改善するような施策や検証を繰り返していくことは基本中の基本です。しかしながら、現実には「KPI を設定する」という行為自体の難易度が非常に高く、日夜頭を悩ませている開発者のみなさんも多いのではないでしょうか。 以下では、その要因の一つである「KPI は複数の要件を満たす必要がある」ことについて考えます。 満た
ぼくのかんがえたさいきょうのDevOps実現構成
はじめに 昨年、AWS のインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を紹介した記事、「【AWS】ぼくのかんがえたさいきょうの運用・監視構成」が投稿したその日の Qiita のトレンド 1 位になり、はてなブックマークのテクノロジー分野でトップを飾りました。（たくさんの方に見ていただき感謝してます！） 本記事では「ぼくのかんがえたさいきょうの運用・監視構成」の続編として「ぼくのかんがえたさいきょうの DevOps 実現構成」を紹介させていただきます。あくまでも「ぼくのかんがえた」なので私個人の意見として受け入れていただけると助かります。 前回の記事でもお伝えいたしましたが、各個人・企業によって環境は違うと思いますし、使いやすいサービスは人それぞれだと思うので、これが正解という訳ではありません。一個人の意見として参考にしてただければ幸いです。 また、こちらの記事
burndown chart via kakutani アジャイルなチームを目指す。私がチーム運営を始めたときのポリシーでした。どうやって作業をこなすだけから、アウトプットへの価値へとシフトしていくか？チームの方向を示すためにも、様々なメトリクスやKPIを見える化する必要がありました。 通常のプロジェクト管理方法だと、ガントチャートでロードマップを設定、進捗の状態を管理。WBSなどを作ってそれぞれのタスクを管理・・・といった形が一般的なのでしょうか。しかし、それではワクワクしない。そんな中、常に改善を心がけ、私が試して行き着いた方法を紹介させていただこうとおもいます。 唯一生き残ったプラグイン バーンダウンやタスクボードなど、Redmineのプラグインで様々な見える化をしましたが、ずっとそれを使うことはしませんでした。その中で、最終的に生き残ったのがパーキングロットチャートです。なぜ、これ
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 9 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。 DevOps Research and Assessment（DORA）チームが実施した 6 年間の研究から、ソフトウェア開発チームのパフォーマンスを示す 4 つの指標が確立されました。 デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度 変更のリードタイム - commit から本番環境稼働までの所要時間 変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%） サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間 概要レベルでは、デプロイの頻度と変更のリード時間は速度の指標であり、変更障害率とサービス復元時間は安定性の指標です。チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができま
Graphite
Graphite does three things: Kick ass. Chew bubblegum. Make it easy to store and graph metrics. (And it’s all out of bubblegum.) Learn more about Graphite About the Project Graphite is an enterprise-ready monitoring tool that runs equally well on cheap hardware or Cloud infrastructure. Teams use Graphite to track the performance of their websites, applications, business services, and networked serv
概要 Datadog というモニタリングサービスを利用して Docker コンテナの CPU やメモリなどのメトリクス収集・監視とコンテナの死活監視をするという話。 Datadog を使うメリット Docker をどうモニタリングすべきかのモデルとなる Datadog のエージェントは、 Docker が依存する Linux の "namespace" と "cgroup" が提供するメトリクスを 15 秒ごとに収集することでモニタリングを行っている。また Docker コンテナをどうモニタリングするか・どうメトリクスを収集するか・どんなメトリクスがあるかを学ばさせてもらっている。 参考: "How Docker monitoring works" Monitor Docker with Datadog - Datadog Blog コンテナへ自動でタグ付け Datadog は Docke
Redgate Test Data ManagerImprove your release quality and reduce your risk, with the flexibility to fit your workflow
コード探知機「Sonar」でプロジェクトの深海を探れ！：ユカイ、ツーカイ、カイハツ環境！（17）（1/4 ページ） プロジェクトの深海を照らす「Sonar」とは？ 「Sonar」は、スイスのSonarSource S.A.を中心に開発されているコードの品質管理を行うオープンソースのプラットフォームです。LGPLライセンスで提供され、無償で利用可能で、拡張も自由です。 2009年に「Jolt Product Excellence Awards」「Open World Forum Innovation Awards」などを受賞した、いま注目のツールです。 Sonarは、まるで音波探知機を装備した潜水艦のように、コードのさまざまなメトリクス（統計情報）を総合的に集計し、現在の開発の状況を視覚化します。非常に使いやすいWebのUI（ユーザーインターフェイス）で、プロジェクトごとのメトリクスから各パ
Eclipseで使えるメトリクス計測ツール
Eclipseプラグインで提供されるテストツールが充実してきた。本連載では、システム開発の現場に有効なテストツールを紹介し、統合開発ツールにEclipseを選択する開発におけるテストの効率化、ソフトウェア品質の向上のヒントを提供する。（編集部） 前回の記事ではソースコードのスタイルチェックやバグ検出を行う静的解析ツールを紹介しました。今回は、ソースコードの複雑さなどを計測するメトリクス計測ツールを紹介します。メトリクスを計測することにより、ソースコードの構造上の問題点を把握し、品質の評価および向上につなげることができます。今回は、Eclipse Metrics Plugin（2種類）、CAP、JDepend4Eclipseの4ツールを紹介します。 メトリクスとは ソフトウェアのメトリクスとは、ソフトウェアを計測する方法およびその尺度のことを意味します。今回紹介するメトリクス計測ツールは、ソ
DroidKaigi2018の講演の「アプリを成長させるためのログ取りとログ解析に必要なこと」の発表資料です。
はじめに 先日、「悪〜いコード」を読む機会がありました。 どんな風に悪いのか、軽くですが分析してみたので、ポエムとして投稿したいと思います。 古のコード 私は普段Ruby on Railsをメインに開発を行っているのですが、ユーザーからの質問に答えるために、普段の開発や保守しているのとは全く別のシステムのコードを読む機会がありました。 そのシステムはPHPで書かれた古いコードでした。ユーザーの質問はシンプルだったので、コードを見れば一瞬で答えは見つかるだろうと思ったのですが、とても読み難いコードだったので30分ほど頭を悩ませながら読むことになりました。 何が読み難いのか 結果、ユーザーからの質問には答えることができたのですが 「僕の30分を返してくれーーー！」と叫びたい気分です。 と愚痴ってしまいましたが、それだけでは何の進歩もないので、何が読み難かったのかを明らかにしてみたいと思います。
アジャイル開発において、プロダクトや組織の現状を把握するのに役立つメトリクスを知りたいと思い、「agile kpi」などでググって上位のサイトを読むという丁寧なサーベイを敢行。20個くらい読んでいくとだいぶネタも尽きてきたので、整理してみました*1。参考にしたサイトについては、記事の最後に載せておきます。 なお以下では、アジャイル開発とスクラム開発をほぼ同じ意味で使っていますが、怒らないでいただきたいですね。 メトリクスとKPI メトリクス（metric / metrics*2）とKPIはごちゃごちゃに使われがちです。こちらの資料では、以下のように説明しています。 Agile KPIs from Gaetano Mazzanti www.slideshare.net メトリック: プロセス・プロダクト・チームの定量的な評価・制御・改善のための物差し、またはその組み合わせ KPI: 戦略的な
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
ソフトウェアのための統計学 – 前編 | POSTD
【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
AWS監視アラート 事始め - mazyu36の日記
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
仲居さんにセンサー装着 がんこフードの「科学接客」 - 日本経済新聞
【Slack×Re:dash】リアルタイムKPI通知をコード0行で実現する - Gunosyデータ分析ブログ
ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する｜mtx2s
我々は Kubernetes の何を監視すればいいのか？
監視の考え方 〜あるいは可観測性とはなんなのか〜 - estie inside blog
データマイニングの話詰め合わせ
Cloud Monitoring as a Service | Datadog
“生産性向上に投資するため”のデータの可視化 生産性測定から組織の仕組み作りをサポート
KPI 設定の難しさについての思索とそれに付随した細かな考察 - クックパッド開発者ブログ
Redmineでアジャイルチームのスピードやパワーを見える化する
Datadog で Docker コンテナをモニタリングする - Qiita
Lutz Roeder's Programming.NET C# VB CLR WinFX
コード探知機「Sonar」でプロジェクトの深海を探れ！
アプリを成長させるためのログ取りとログ解析に必要なこと
「悪〜いコード」を読んだので、ついでにコードメトリクスを計測してみた - Qiita
アジャイル開発におけるメトリクスには、どういうものがあるのか - ソフトウェアの品質を学びまくる