タグ

qualityに関するmoronbeeのブックマーク (6)

  • コード品質はやはりビジネスに影響を与える - mtx2s’s blog

    私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト

    コード品質はやはりビジネスに影響を与える - mtx2s’s blog
    moronbee
    moronbee 2023/04/28
    よき。(ChatGPTに突っ込んで出してもらうクリーンコード指数をリリース判定 or チーム評価に入れたらいい)
  • タイム・コンサルタントの日誌から

    前回の記事「モダンPMへの誘い 〜 計画のSカーブは、実は2あり得る」 (2024-05-24)では、タイトルの通り、プロジェクト計画には最早ケースと最遅ケースの二つがありうることを説明した。より正確に言うと、最早と最遅の2ケースは理屈上可能な両極端を表しており、実際はその中間帯に、いくらでもバリエーションを取ることができる(ただし実務上は、たいがい最早ケースで計画を設定してしまう。そのよしあしについては後で論じよう)。 ところで、なぜ計画にこのような幅が生じるのか。それは、プロジェクトを構成するActivityの中に、余裕日数を持つものがあるからだ。前回の例で言えば、それは「ハード選定」と「ハード納品」の2つで、どちらも10日の余裕日数があった。というのも、並列して遂行している「詳細設計」「ソフト開発」の2つの方が、トータルで余計に日数がかかるからだった。まあ、IT開発系のプロジェクト

    タイム・コンサルタントの日誌から
    moronbee
    moronbee 2020/07/08
    "性能=機能要件に属する特性"、“品質=非機能要件で決まる特性”
  • Railsコードを改善する7つの素敵なGem(翻訳)

    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: 7 Gems Which Will Make Your Rails Code Look Awesome 公開日: 2017/10/14 著者: Val Zavadskiy サイト: https://blog.rubyroidlabs.com/ Rubyroid Labsの別記事「Ruby on Railsで使ってうれしい19のgem(翻訳)」も合わせてどうぞ。 私たちRubyroid Labはアプリのアーキテクチャに多くの情熱を注ぎ込んでいます。手がけているプロジェクトの多くが長期にわたっているので、設計のどこかで少し油断すると、機能を1つ追加するのにプロジェクトをスクラッチからやり直す方が早い、といった事態になりかねません。こんな目には遭いたくないものです。 新しく参加したメンバーがロジック把握のためにソースコードを読みとおすだ

    Railsコードを改善する7つの素敵なGem(翻訳)
  • 開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog

    Webサービスの開発は、ユーザ/顧客へ価値を早く届けるため、競合より早くリリースするため、人的リソースを無駄使いしないためなど、とにかく素早く進めたいものですね。一方で、開発を急ぐあまり品質を犠牲にすればかえって価値が失われたり、技術的負債が溜まって長期的なコストが大幅に増大する可能性もあります。開発速度とプロダクト品質は基的にはトレードオフの関係にあるのでしょう。 開発速度と品質のどちらを優先するかはプロダクトの性質や、チームもしくは会社の状況によって異なるとおもいます。この状況の認識がチームメンバー間でずれていると、チームのパフォーマンスを最大限に発揮できないばかりか、チーム内の関係悪化も招きかねません。エンジニアたちとプロダクトオーナーの間の対立のようなありがちな問題の原因の一つかもしれません。 そこで、開発速度と品質のトレードオフをどう判断すべきかの基準を明確にして、原則それに従

    開発速度と品質のトレードオフの判断基準の合意 - Hatena Developer Blog
  • クソコードの測り方

    PHPBLT#3 で話した内容です。

    クソコードの測り方
  • Travis CIとCoverallsとCode Climateを使ってGitHubリポジトリにバッジを付ける - アインシュタインの電話番号

    先月に公開した超ニッチなツールFont Awesome Workflow for Alfred 2が意外と好評で、そこにオクラホマ州からこれOS X Mavericksで動いとらんよとお便りが届いたりした。 そんなわけで少々テストを書いた上で、Mountain Lion以前に入っているRuby 1.8.7と、Mavericks以降に入るRuby 2.0.0の両方で常に動作確認しておくようにしたいと考えて、まずTravis CIを、その後CoverallsとCode Climateを導入した。この記事はその備忘録。 {: .ArtcleBody-inlineImage .u-textCenter } それらを導入すると、こんなかんじのバッジを表示できる。GitHubでよく見かけるやつ。今回使ったサービスはどれも、オープンソースなら無料で使わせてもらえる。 Travis CIは名前の通り継続的

    Travis CIとCoverallsとCode Climateを使ってGitHubリポジトリにバッジを付ける - アインシュタインの電話番号
  • 1