3 ポイント 投稿者 GN⁺ 2023-12-09 | 1件のコメント | WhatsAppで共有

ソフトウェア品質の作り込み方法に関する教育の欠如

  • 大学でコンピュータサイエンスを学ぶ際、ソフトウェア品質保証(QA)に関する教育が欠けている。
  • ほとんどの時間はアルゴリズム、コンピュータの動作原理、言語や概念の歴史などに割かれる。
  • プロジェクト管理のアプローチやスクラムについて学ぶ学期はあっても、QAはまったく扱われない。

企業が納期内に製品を出す方法

  • 企業は予算の問題から、QAの標準や施策を真っ先にプロジェクトから外してしまう。
  • 開発が遅れたりスコープが拡大したりすると、QAに十分な時間が残らない。
  • 最低限の非構造化テストだけを経て、不安定なソフトウェアをリリースしてしまう。

ハムスターホイールから抜け出す方法

  • プロジェクトで欠けているQA施策について発言するための経験と自信を積むには、何年もかかる。
  • 抜け漏れた監視を見つけたり、本番システムが障害を起こしたりといった問題に直面する。
  • QA施策を実装しなければ、きちんと学べないという問題が生じる。

お金について話す

  • ソフトウェアが「より安定する」あるいは「保守がはるかに容易になる」と説明しても、非開発者にとっては具体性に欠ける。
  • QAをしないことのコストについて話す必要がある。
  • QA施策を例とともにコストの観点から説明するのが効果的である。

最小有効量

  • QA施策を過剰に設計せず、プロジェクトの進行を妨げてはならない。
  • アプリケーションの中核機能をテストし、それが常に期待どおりに動作することを確認するのが重要である。
  • 「最小有効量」(MED)の概念を使い、最も重要な部分から始める。

注意深く見るべきこと

  • 新しいプロジェクトを始めたり参加したりするときは、QAの考え方を探す。
  • チームがQAについて考えていたことを示す文書やテスト計画が重要である。
  • 新しいコードを書くときにテストも一緒に書くことで、コードが実際にテスト可能なように構造化される。

プロジェクト上の利点

  • 品質について話し、可能な解決策を提案することで、開発者としての影響力を広げられる。
  • QA施策によって、プロジェクトは健全なペースで成長できる。

プロジェクトを改善する方法

  • QA施策を使うことで、プロジェクトで品質の高いソフトウェアを書く人として知られるようになれる。
  • プロジェクトでMEDを考慮し、チーム内で変化を促す声になるべきである。

GN⁺の意見

この記事で最も重要なのは、ソフトウェア開発の過程における品質保証(QA)の重要性と、それを実装する方法に対する認識不足である。QAはしばしば見過ごされるが、長期的にはプロジェクトの成功と安定性のために不可欠だ。この記事は、初級ソフトウェアエンジニアにQAの重要性を認識させ、実際のプロジェクトでQAを統合する具体的な方法を示している点で、興味深く有益である。

1件のコメント

 
GN⁺ 2023-12-09
Hacker Newsの意見
  • ソフトウェアエンジニアリングはコンピュータサイエンス(CS)の中核的な主題ではなく、別の領域で教えられることが多く、選択科目やソフトウェアエンジニアリング課程で扱われることが多い。

    CMUではソフトウェアエンジニアリングの修士・博士課程を運営しており、ブログ記事で言及された内容を含むさまざまなトピックを教えている。

  • コンピュータサイエンスの学位を持つ人たちと協業するほうが楽だと感じることが多い。彼らは優れたアルゴリズムの重要性を理解しており、パーサーや暗号化を自前で実装しようとはしない。

    ソフトウェアエンジニアリング分野では、チームワークや品質に関する素朴な考えを正していく過程が不足していると指摘している。

  • 高品質なソフトウェア開発は、経験豊富な会社で学ぶことができる。

    以前はFAANG企業だったが、現在ではTailScaleのような会社から学べる。無意味なマイクロサービスやDocker、JSON処理を乱用せず、QuickCheck、仮説検証、ファジングなどを活用して品質を高められる。

  • バグのないソフトウェアを期限内にリリースしなければならないという主張は、品質ソフトウェアに関する記事を始める前提としては不適切である。

    バグのないコードを出荷できると信じるのは、現実とかけ離れた考えである。

  • コンピュータエンジニアリングのプログラムや、インターンシップと実習を重視する大学もある。

    多くの大学のCS学科は数学科から分化しており、理論を重視している。大学は単なる職業訓練校ではなく、複雑な資料を習得する能力を鍛える場所である。

  • 大学で産業用ソフトウェア構築を教えているという主張は誇張されている。

    継続的デプロイのパイプラインが一般化した現在、品質保証部門が手作業でバグを確認するのは時代遅れの方法と見なされている。

  • ソフトウェアが「より安定する」あるいは「保守しやすくなる」という理屈は、コードベースに直接手を入れない人たちには説得力がない。

    開発者は品質保証(QA)をしないことのコストについて語り、これがビジネスや管理職に伝わる言葉だとしている。

  • 品質、時間、コミュニケーションの複雑さ、コストのうち3つを選べる。

    ソフトウェアエンジニアリングは工場のプロセスを適用しにくいチームスポーツであり、チームワークと個人の成長を重視すべきである。

  • ソフトウェア開発者は高品質なソフトウェアを作る方法を学んでいるが、会社を運営するMBAや取締役会がそれを理解しておらず、実際に適用するのが難しい。

    ほとんどの職場では、ソフトウェア開発者の意見はおおむね無視される。

  • 品質は実際には練習を通じてのみ身につけられる性質である。

    高品質な成果物を生み出す能力は、反復的な実践を通じて得られる。