結局 Git のブランチ戦略ってどうすればいいの？ - Qiita
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
テストカバレッジ100%を追求しても品質は高くならない理由と推奨されるカバレッジの目標値について - Qiita
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
テストを書く方針と原則の備忘録 - Qiita
こんにちは。サーバエンジニアのnsym-mです。普段はGoでバックエンドの開発などをしています。 最近テストに関する書籍や記事などを色々読み漁ったので、現時点での自分のテストについての考え方を備忘録として残しておきます。 今回の話はWebフロントエンドやiOS/Androidなどでも適用できる汎用的な考え方として記載していますが、ベースの文脈はバックエンド開発になりますのでそのつもりで読んでいただけますと幸いです なお、本記事では主にGoogle、『単体テストの考え方/使い方』、@t_wadaさんの発表されている考え方（いわゆる古典学派）に倣っています。 用語整理 よく使われるテストスコープ 単体テスト（ユニットテスト） 人によって定義に差がある 統合テスト（インテグレーションテスト） 結合テスト（E2Eテスト） 単体テストの定義がブレることから、スコープではなく実行時間で判断するテストサ
Figma でデザイン、そのままデモ、そのまま実装！ - Qiita
みなさん、デザインツールの Figma を使っていますか？ 私はまだ「使っている」と言えるほど使えていません というわけで勉強会を開催して勉強します Figma とは 公式の紹介文は以下のとおりです デザインの追求からプロトタイプ作成、制作物のコーディングまで、Figmaはチームがコラボレーションして製品開発するためのプラットフォームです 本記事のタイトルと同じように、「デザインからデモ・実装までチームで製品開発できる」旨が書かれています まさにその通りで、ブラウザ上で UI をデザインし、そのまま動かしてみることができ、最終的にはコードの生成までできてしまうツールです Figma の人気 2022年に世界中のデザイン関係者を対象としたアンケートでも Figma は圧倒的な人気です いずれのランキングでも2位の10倍以上の得票数になっています メインで使っている UI デザインツール第1位
自動テストはなぜうまくいかないか？乗り越えるためには何が必要か？ - Qiita
リファクタリングの鶏卵問題 ソースコードがクソなので綺麗にしたい。 リファクタリングしたい。 しかし、リファクタリングが出来ない。 リファクタリングが出来ないのは、テストが無いからだ。 よし。じゃあテストを書こう。あれ、テストが書けない？ そのようなテストが無く、書き換えられないことによる矛盾や憤りは皆さん何百回と感じてきたと思います。 しかし、この「テストが出来ない」ということを言語化するのは、非常に難しいと思います。それは、「テストが出来ない」には実は2つの視点があります。 本質的にテストが困難なモジュールで、誰がやってもテストが書けない。 本質的にモジュールはテスト可能だが、自分の実力が足りず、自分ではテストが書けない。 1.のようなテスト困難なモジュールは誰がやってもテストは書けないです。しかし、問題は、「テストを書きたい」と思ったとき、「自分がそれほどテストに詳しくない」という場
Github Copilotを活用する上でのおさえておくべき特徴とTips - Qiita
目的 個人の学習メモです。以下3点を目的にします。 Github Copilotを利用するにあたって現状で認識しておくべきであることを整理しておく。 Github Copilotを感覚ではなくコントロールして使用できるようになる。 知らないTipsをインプットする。 参考 こちらのサイトからのアウトプットです。Githubで公開されていて、Github Copilotを中心にまとめられています。 知識 Github Copilotに利用されているモデル codexというモデルが利用されている。 GPT-3ベースで自然言語の理解が可能。 codexモデルに渡せるトークン数は限られていることをしっておくべき。 Github Copilotの補完のしくみ 詳しいロジックは公開されていないようですが、エディタで開いているファイルを読んで現在開発しているファイルに関連の深いものを参考にしている。 T
ペアプロアンチだった私が心を入れ替えた話 - Qiita
この記事を書こうと思ったきっかけ ペアプロをディスったQiitaをわざわざ書くくらいには複数人開発を嫌っていた私ですが、最近ペアプロをしている時に「あれ、なんか楽しいかも」と思ったので記事にしてみることにしました。 息抜きのお供にどうぞ。 ペアプロが嫌いだった理由 「何もわからない新人と2,3年目の先輩」という組み合わせで開発をすると、どうしても先輩が新人に教える構図が出来上がります。当たり前なんですけどね。 分からないことがあればすぐに質問でき、適切な答えが返ってくる。最高ですね。 これは逆にいえば、「分からなければすぐに質問しなければならない」ということでもあります。せっかくペアプロをしているのに、新人が一人で考え込んでいては意味がないですから。 私はこれがどうも苦手でした。なぜなら、分からないことがあればまず自分で考えて、それでも分からなければ質問する、というのが私の理想だからです。
非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに？ ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ
スクラム開発を2年やって得た学びとか - Qiita
導入 会社のスクラム状況とサークルの話 弊社では6,7年ほど前まではウォーターフォール開発が主流とでした。 その後、スクラムマスターの資格を持つ方などの啓蒙活動を経て徐々にアジャイル/スクラム開発が浸透していき、今では社内の至るところでスクラム開発を見かけるようになりました。 また、多くのチームで似たようなことを経験していたり、プロジェクト特有のトラブルに見舞われたときにスクラムではどう改善していくべきか？という話をするスクラムサークルというものが存在します。 普段はSlack上で「こんなときはどうしていますか？」といった感じで相談をしていますが、月1の飲みながらのコミュニケーションではスクラムに限らず業務全般のお悩み相談をしたり和やかな雰囲気で進行しています。 弊社のサークル制度について簡単にではありますが公式noteに記載されていますので、そちらをご参照ください。 およそ2年間のスクラ
技術顧問との1on1で見積もりには3種類あることを教えてもらった - Qiita
はじめに 本記事はモチベーションクラウドシリーズ Advent Calendar 2022の17日目になります。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 ※公開するにあたって分かりやすさを重視して脚色しています。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがある 約束してはいけないと言いたいわけではない。約束が必要な場合がほとんどだと思う。ただ、その約束は開発を遅くするんだなぁ。だから、約束せずに気楽に開発
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
【GitFeatureFlow】GitFlowをやめて本番リリースが楽になった話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 背景 サーバーサイド開発のプロジェクトでGitFlow(的な)運用を行っていたが、本番リリースの際に困ることがあったのでgitの運用フローを変えて解消したという話。 まず問題の内容から順番に書いているので、結論(新しい運用ルール)だけ知りたい人はこちら git運用フローについては、GitFlow・GitHub Flow・GitLab Flowなどが有名だがどれとも少し違うように思ったのでまとめた。 <2018/06/10追記> 新フローにも名前が欲しいと思っていたが、同じやり方を「GitFeatureFlow」と呼んでいる記事を見つけた
ログ設計指針
概要 このドキュメントは、効率的かつ安定した、システム開発/運用をするためのログ設計指針です。 的確かつ無駄のない、ログ出力を目指します。 ログレベル ログの緊急度や用途により、以下のようにログレベルを設定する。 Log4j のログレベルを踏襲しているため、運用の状況によっては Critical などのレベルを適宜追加すると良い。 PHP における PSR-3 では、さらに細分化され emergency, alert, critical, error, warning, notice, info, debug となっている。 「出力先」「運用時の対応」は、各プロジェクトのポリシーに準じてください。 レベル 概要 説明 出力先 運用時の対応
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
