「技術的負債とはどういうものなのか？」をテトリスに例えるとこうなる
テトリスは落ちてくるテトリミノを積み上げ、横一列に並べて消すという有名なゲームですが、そのテトリスを例に「技術的負債」がどういうものかたとえた記事を、エンジニアでありコンサルタントでもあるというエリック・ヒギンズ氏が公開しています。 Technical Debt Is Like Tetris – Featured Stories – Medium https://medium.com/s/story/technical-debt-is-like-tetris-168f64d8b700 「技術的負債」とは、ソフトウェアの開発において、時間がかかるより良いアプローチではなく一番早く新機能の実装などの目的を達成できるアプローチを選んでしまったために生じたソフトウェアの複雑さのこと。例えば既存の機能を変更した際に説明書を書きかえなかった場合、後から別の人が動作を把握するにはソースコードを読む作業が
リアルタイム映像配信サーバ開発者からみた STADIA
まず、この記事では、STADIA で快適にゲームができるかどうかという話はしません。技術的にどうなの？というのを想像込みで書いていきます。 誰だよお前、って言われそうなので … 自分は WebRTC の通信部分と QUIC スタックの実装をフルスクラッチでしており、日本で多くの会社に採用されている WebRTC を利用したミドルウェア製品の開発者です。WebRTC を利用して 4K@30 をサーバ経由で配信というのを実現したりしています。 利用している技術STADIA が利用している通信技術は WebRTC (と QUIC)です。これは Project Stream という STADIA リリース前に公開された実験的プロジェクトがまさにそうでした。Project Stream の VP である Majd Bakar 氏がインタビューで回答しています。 Project Stream は 10
見積もりをめぐる話を見積もり初心者としてきた話 - Innovator Japan Engineers’ Blog
こんにちは、CTOの山岡（@hiro_y）です。 イノベーター・ジャパンでは「&donuts（アンドーナツ）」というプロジェクトをやっています。簡単に言うと、職住近接のコンセプトを基に子育て中のお母様方などに郊外のオフィスに集まっていただき、そこでお仕事をしてもらうという取り組みです。現在、千葉県・柏の葉と神奈川県・湘南（辻堂）に拠点を設けています。 今回、東京オフィスと&donuts柏の葉オフィスで「見積もり」をめぐるお話会（自由参加の勉強会みたいなもの）を開催しました。クライアントワークでは見積もりを出す機会はいくらでもありますし、社内のやり取りでもどれぐらいかかりそうか、話し合う機会は多いと思います。そのコミュニケーションを改善するきっかけになればよいなと思ってのことでした。 東京オフィスでは割とかために、見積もりとは〜のような感じで話を進めたのですが、&donuts柏の葉オフィスで
言葉をどう受け取るかは人それぞれ、かつ、多様ということを学んだ話 - 覚書
はじめに 最初に言っておきますが、とくにスカっと結論が出るような話ではないです。 昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。 わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。 コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな— sat (@satoru_takeuchi) 2019年3月20日 「50-60人くらい答えてくれたら面白いな～」と思っていたのですが、最終的には3705人もの人
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
「カバレッジが高ければ、品質が高い」と誤解している危険な思想家の皆様へ - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Unit testing Anti-patterns catalogue