タグ

開発に関するsuginoyのブックマーク (2,673)

  • Google Engineering Practices Documentation (日本語訳)

    Google Engineering Practices Documentation (日語訳) Google には、全言語および全プロジェクトをカバーする広範なエンジニアリングの慣行があります。 ここにあるドキュメントは私達が長年の経験からさまざまなベストプラクティスを蓄積してきたことを表しています。 この知識がオープンソースプロジェクトや他の組織の利益になることを願って、私達は可能ならそれを誰にでも利用できるように公開します。 現在、以下のドキュメントがあります。 Google コードレビューガイドライン。これは 2 つのドキュメントからなります。 コードレビュアーのガイド 変更作成者のガイド 用語 ここにあるドキュメントには、Google 内部で使われる用語があります。外部の読者のために意味を掲載しておきます。 CL: 「changelist」の略。一つの独立した変更を意味していて

  • Maxims

    心に留めておきたいこと 格言とか法則と言ってしまうとちょっと仰々しい。 でも、人と話をする、アドバイスを与える/受ける、 質をさぐる、まったりから抜け出す、などなど多くの場面で 役に立つ教訓。手始めに「コンサルタントの秘密」からの 抜粋が中心となるが、少しずつ書き溜めていきたい。 覚えやすさをねらって韻を踏んであるものが多いことにも注目。 ボールディングの逆行原理 (Boulding's Backword Basis) 「ものごとがそうなっているのは、そうなったからだ」つまり あらゆる事象は、そうなるべくしてなっているということ。 問題点を探ろうとするとき、その経緯を丁寧に調べることは とても有意義だということ。今となってみれば、とても不合理に 思えることであっても、当時は妥当であったかもしれない。 ボールディングとは、経済学者さんとのこと。 ルウディのルタバガ法則 (Rudy's Ru

  • システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』

    例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるw」という人は、書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場

    システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
  • うわっ…日本の住所表記、ヤバすぎ…?解決策をダラダラ語る会(主催:Code f...

  • ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経

    読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第52回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。 #51 V字モデルの深淵を覗き込んで反省する:「単体テストの考え方(UTPPP)」を読む(後編) - 勘と経験と読経 #50 V字モデルの深淵を覗き見た気分:UTPPPを読む(前編) - 勘と経験と読経 #49 「デジタルトランスフォーメーション・ジャーニー」でDXできる? #デッドライン読書会 - 勘と経験と読経 #48 頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会 - 勘と経験と読経 #47 いまさら「マスターアルゴリズム」読んだ #デッドライン読書会 - 勘と経験と読経 さ

    ウォーターフォールを殺しにきている書籍「継続的デリバリーのソフトウェア工学」を読んだ - 勘と経験と読経
  • リリースした新機能や改善の多くに価値がないという調査結果が意味すること - mtx2s’s blog

    プロダクトに備わる機能の64%がほとんど使われないと言う。あるいは、80%という数字が用いられることもある。これが当だとすれば、ソフトウェア開発に費やしたコストの多くが無駄だったことになる。ソフトウェア開発は常にスピードが求められるものだが、そもそもこのような無駄がなければ、ユーザーや顧客への価値の提供をもっと速くできたはずだ。 ソフトウェプロダクトをローンチし、それから次々とリリースを繰り返しながら追加されていった変更は、いったいどれだけのものが実際に価値があったのだろうか。稿では、Standish Groupやマイクロソフトの文献を中心に、ヒントとなる数字をいくつか紹介し、その理解を深める。 64%はめったに、あるいはまったく使われない 80%は価値が低い、あるいはまったくない 3分の2は価値がない、あるいは逆に価値を損なわせる 「勝利宣言」からの脱却 64%はめったに、あるいはま

    リリースした新機能や改善の多くに価値がないという調査結果が意味すること - mtx2s’s blog
  • 「100円×3個=301円」問題でセブンが公式に謝罪 見習うべきは「イオン方式」か

    「100円×3個=301円」問題でセブンが公式に謝罪 見習うべきは「イオン方式」か:お客の混乱を回避する狙い(1/3 ページ) 「事前の告知が不足しておりましたことをお詫び申し上げます」 セブン‐イレブン・ジャパンは9月18日、こんな謝罪文を公式Webサイトに掲載した。セブンは消費増税に対応するため、9月16日から支払金額の計算方法を変更した。しかし、お客に対して事前に十分な説明がなかったため、現場が混乱。不満の声があがっていた。Twitter上には、「店舗ではどうすることもできません。クレーム等は全てセブンイレブン部までお願いします」(表記ママ)というPOPを撮影した画像が投稿されていた。

    「100円×3個=301円」問題でセブンが公式に謝罪 見習うべきは「イオン方式」か
    suginoy
    suginoy 2023/01/21
    消費税の計算がめちゃくちゃなシステム見たことがある。
  • 十分ということ (from Extreme Programming Explained, Kent Beck) - Hot Heart, Cool Mind.

    「森の民(The Forest People) 」と「山の民(The Mountain People) 」の中で、人類学者 Colin Turnbull は、二つの社会を対照的に描きました。山岳地帯では、資源は乏しく、人々は常に飢餓の淵にいました。彼らが発達させた文化は、ぞっとするようなものでした。母親は、赤ん坊がなんとか生き延びられるかもしれぬ程度に成長するやいなや、捨て子たちの放浪集団にその子を遺棄しました。暴力、残虐行為、そして裏切りが、常態でした。 対照的に、森林地帯には豊かな資源がありました。ひとりの人が基礎的な必要を満たすには、一日に半時間も使えば十分でした。森林地帯の文化は、山岳地帯の文化を鏡に写したように逆になりました。大人たちは協力して子育てし、子供たちは、自分で自分の面倒をみる準備がすっかり整うまで、育てて貰い、愛されました。誰かが誤って誰かを殺してしまった場合(故意の

    十分ということ (from Extreme Programming Explained, Kent Beck) - Hot Heart, Cool Mind.
    suginoy
    suginoy 2022/12/15
    "XPは、「もし仮に十分に時間があるとすれば、あなたはどんな風にプログラムを書くでしょうか?」という質問に答える実験です。"
  • ワクチン接種歴「4回目までしか入力できない仕様」 - HER-SYSの接種歴回数、5回目は「不明」に(医療介護CBニュース) - Yahoo!ニュース

    厚生労働省新型コロナウイルス感染症対策推進部は、都道府県などに出した事務連絡(18日最終改正)で、新型コロナウイルス感染者等情報把握・管理支援システム(HER-SYS)での新型コロナウイルスワクチン接種歴の入力について、「現時点では4回目までしか入力できない仕様となっている」と伝えた。既に5回目接種が行われているが、接種回数を「不明」とするよう求めている。【新井哉】 事務連絡では、「今後、5回目以降の入力を可能とする改修を行う予定である」と説明。それまでの間、「新型コロナウイルスワクチン接種歴」の接種回数は「不明」とし、「感染経路分析」の「医師が必要と認める事項」に「ワクチン5回」と入力する。 HER-SYSを巡っては、入力作業に追われ、医療現場が逼迫した事態を踏まえ、入力する際、症状や診断方法などの項目をなくす改修を行っていたが、ワクチン接種歴に関しては、5回目以降に未対応だった。

    ワクチン接種歴「4回目までしか入力できない仕様」 - HER-SYSの接種歴回数、5回目は「不明」に(医療介護CBニュース) - Yahoo!ニュース
  • テストのカバレッジをコツコツ上げた話 - 食べチョク開発者ブログ

    こんにちは、endo と kawabata です。 今回はプロダクトチーム内の自動テスト改善チームでコツコツカバレッジを上げた取り組みと振り返りのお話をしたいと思います。 ここでテストのカバレッジを上げているのは、RSpec でのお話になります。 テストのカバレッジを上げていこうというお話は、こちらのべチョクの自動テスト改善活動 〜これまでとこれから〜のお話からきています。 ゴールを設定せずに活動するのは良くないので、10 月末までにカバレッジを 80%まで上げるということを目標に設定しました。 80%まで上がれば広範囲をカバーできているだろうというざっくりとした見立てです。 今回の取り組みでは、大きく分けて以下の 3 点を実施しました。 どのテストを追加するか決める コツコツテストを追加する 不要なコードを削除する どのテストを追加するか決める テストのカバレッジを上げていこう!という

    テストのカバレッジをコツコツ上げた話 - 食べチョク開発者ブログ
  • Cognitive Complexityを400以上減らすまでに何をしたか 〜 コード品質改善の具体的なプラクティス

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!広告 ディスプレイ広告エンジニアの安田です。私たちの開発チームでは広告配信の起点となるJavaScriptTypeScript)ライブラリを提供しています。今回はこのライブラリのデプロイ失敗率を改善できた、コード品質改善の取り組みについてご紹介します。 コード品質を定量的に測る指標の1つにCognitive Complexityがあります。Cognitive Complexityは人間視点での複雑性を評価する指標で、例えばネストが深くなるほど複雑と判断される特徴があります。複雑なコードは変更に多くの時間を要し、テストが難しくなるので要改善なシグナルといえるでしょう。私たちが今回実施した品質改善の取り組みで

    Cognitive Complexityを400以上減らすまでに何をしたか 〜 コード品質改善の具体的なプラクティス
    suginoy
    suginoy 2022/08/28
    “Change Failure Rateが課題だった”
  • チームで共通のフックスクリプト(Git hook)を使っています

    チームで共通のフックスクリプト(Git hook)を使っています Gitでバージョン管理されたスクリプトをフックスクリプトとして実行するために core.hooksPath の設定を利用 core.hooksPathを変えたことを忘れると .git/hooksにフックスクリプトを追加したのに動かない!ということになるので注意が必要 サービス開発グループの石川です。 今回のブログでは、チームで共通したGit hookのフックスクリプトによってコミット前のチェックをしている話をしようと思います。 Git hookとは? Gitで特定のアクションが発生したときにカスタムスクリプトを実行する方法です。 詳細: https://git-scm.com/book/ja/v2/Git-のカスタマイズ-Git-フック 利用しているフックスクリプト 「git commitコマンドを実行した際、変更されたファ

    チームで共通のフックスクリプト(Git hook)を使っています
  • 仕様書を浸透させるために仕様書のあれこれを決めた - パルカワ2

    仕様書を浸透させるために何が必要か? 品質の作り込みをしていきたい・仕様を把握するコストが高いので仕様書を書くことを会社全体で浸透させたいと思っていて、そのために書く・読むの負担軽減が重要だと考えて以下をやることにした。 仕様書の項目を減らす 仕様書フォーマットの統一 仕様書の命名規則を決める 統一されたフォーマットに沿ったテンプレートの作成 管理方法の明示化・単純化 仕様書作成・更新・廃止プロセスの明示化 仕様書の具体例の作成 仕様書を書くときに迷いそうなときに参照するガイドの作成または作成の依頼 実は一回シンプルなフォーマットを決めたのだが、自分の進め方が悪くそれが全く浸透しなかった。その反省を踏まえて上記を考えた。 仕様書の話は、このあたりの話に関係する。 仕様書は必要か? - パルカワ2 チームが品質を作り込むために必要なこととは - パルカワ2 ちなみに仕様書は、Notionで記

    仕様書を浸透させるために仕様書のあれこれを決めた - パルカワ2
    suginoy
    suginoy 2022/08/23
    これが大事だという人がいて、自分もその通りだと思うが、実施されてる現場はほとんどない。 “仕様書作成・更新・廃止プロセスの明示化”
  • Software Engineering Books

    I’ve been a software engineer for over 10 years now, and I’ve successfully passed through all stages of grief. I’m also an avid reader. This page contains my collection of books that have helped me the most throughout my career. The core of the list; this section contains books that are on-topic and give valuable technical insight. Some might seem outdated (a few are) and you may disagree with oth

  • 元コンサル、コーポレート部門の人間が10Xで2か月QAやって学んだこと - 10X Product Blog

    はじめに それは、昨年の瀬のこと。12月24日夕刻。やれ七面鳥だ、やれケーキだ、やれネットスーパーだと世が浮かれている頃、私もご多分に漏れずKFCや波乱万丈のカーネルサンダースの半生に思いを馳せながら、久しぶりにオフィスに出社して仕事のラップアップをしていた。 「・・はい、今目の前にいますよ」右前方の席でWeb会議をしているプロダクトマネージャーのA氏の声が聞こえる。そのときオフィスにいたのは私を含めて3名。私の左斜め後方にはBizDevのエースB氏がWeb会議をしているところだった。 コーポレート部門所属の私を挟んだA→Bの外角高めのスライダーであると判断し、きちんと意識をチキンに戻す。そのとき、スッコココと、Slackの通知が鳴る。代表からの「@udon、今トゥゲザーしましょう*1」というメッセージだった。 QAの人手が足りてないという話と、今目の前にある仕事はいったん棚上げでQAにダ

    元コンサル、コーポレート部門の人間が10Xで2か月QAやって学んだこと - 10X Product Blog
    suginoy
    suginoy 2022/05/10
    “最初の壁は、「テストレベル」「テストタイプ」という、テストの種別を分類するための2軸でした。 これらのうち、前者は比較的本やネット上の記事での定義が揃っている一方、後者はさまざまな呼称があり、混乱”
  • 質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition

    質とスピード(2022春版、質疑応答用資料付き)

    質とスピード(2022春版、質疑応答用資料付き) / Quality and Speed 2022 Spring Edition
  • Shinagawa Agile Talks #shinagile • A podcast on Spotify for Podcasters

  • Amazon.co.jp: Agile Practice Guide (Japanese): Digital Ebook Purchas

    Amazon.co.jp: Agile Practice Guide (Japanese): Digital Ebook Purchas
  • ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ

    Hatena Engineer Seminar #17 にて発表しました。 hatena.connpass.com Hatena::Letの式年遷宮 from Takafumi ONAKA www.slideshare.net 発表内容をかいつまんで記事にも書いておきます。 Hatena::Let とは はてラボ のサービスの一つ。 僕も入社するまで、はてラボ == ベータ版、だと思ってたんですが、 ラボならではの挑戦的なサービス 運用費が会社持ちで、会社の名前で出しても良い、はてなスタッフの有志が運営するサービス、という制度 も含んでいます。 で、Hatena::Let は、現在は主に id:onk が開発している、ブックマークレットをかんたんに作成・公開できるサービスです。 ソフトウェア式年遷宮とは 初出は 2013 年の id:kenjiskywalker によるもので、このときはイ

    ソフトウェア式年遷宮という概念の歴史と、Hatena::Let での実例 - id:onk のはてなブログ
  • 議論と関係性 / morrita - Message Passing

    強い言葉、有野さんがどのくらい力強くあるいは jerk-ish に発言したのか第三者の我々にはわからないけれど、若干 jerk ぽかったという設定でなんか書いてみたい。 この話はいくつか切り口があると思う。 気の弱いキャラのプログラマでも強い語調の相手に頑張って押し返すべきなのか 自分は時には強い語調で問題をはっきりと伝えるべきなのか めんどくささとトレードオフ 2 は和良さんが書いてくれているのでまず 1 から考えてみる 自分は(おっさん力や seniority によって薄まったとは言え)気の弱い方なのもあり、強く主張されると「めんどくせえなーハイハイ」といって微妙であれなんであれ相手の主張を受け入れる傾向はある。 「めんどくさい」というのは問題の根幹にある気がする。当たり障りのない言い方をすると、議論にはコストがかかる。 わかりやすいコストは時間。コードレビューとかだと、議論のラウンド

    議論と関係性 / morrita - Message Passing
    suginoy
    suginoy 2021/11/14
    “Google の有名なプログラマに Jeff Dean という人がいる。もう少しだけ有名でない話として、Jeff Dean は Sanjay Ghemawat 相棒といつもペアプロをしていた(と言い伝えられている)。”