[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

タグ

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 チーム評価に入れたらいい)
  • タイム・コンサルタントの日誌から

    BOMの用語はややこしい。BOM(Bill of Material=部品表)の概念自体はもう、50年以上もの歴史がある。その間に、いろいろな用語・概念が確立し、徐々に変遷してきた。またBOMをめぐるソフトウェア業界にもいろんな技術進化と流行があり、大手ベンダーが差別化のために提唱した用語が、いつの間にかスタンダードみたいに普及していくこともある。 近年では、BOP(Bill of Processes)という用語がそうだ。このBOP概念はここ10年くらいに普及してきたものだが、実はまだ発展段階で、きちんと定まっていない。同一企業内でも異なる意味で使っていたりする。ちなみに2004年に発刊した拙著「BOM/部品表入門」では、BOPという言葉は取り上げなかった(ほとんど使われていなかったのだ)。しかし最近のBOMのセミナー等では、かならず説明する必要がある。 ちなみに、ERP(Enterpris

    タイム・コンサルタントの日誌から
    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