「モバイルアプリ開発における良いテストコードの考え方」の資料一覧です。
プロダクトづくりには2つの状況がある。何もない、ゼロから臨む場合と、すでにあるプロダクトをより良くしようとする場合とで。いずれの場合にも、「何が正しいのか?」に答えるための仮説検証と、作りながら確かめていくアジャイルの二刀流で臨む必要がある。 ただ、指す言葉は同じでも、「ゼロから」と「すでに」で適用する方法は変わる。置くべき焦点が異なる。そうした文脈の違いを捉えながら、どのようにしてアジャイルにプロダクトをつくるのか。ここを語るための本を書いた。文字通り「アジャイルなプロダクトづくり」だ。9月4日発刊予定。 プロダクトづくりの芯には「価値探索」という行為がある。誰にとってのどんな価値があり、どのようにしてそれを実現するのか、という探索活動のことである。どれほど忠実にスクラムを回転させたところで、価値あるもの、意味あるものの仮説がなければ、その回転は徒労に終わってしまうかもしれない。「間違っ
2024/06/29、開発生産性カンファレンス2024での登壇発表資料です。 https://dev-productivity-con.findy-code.io/2024?m=2024/m/Z8HnzjZb
読者の皆さんは、テストについてどのようなイメージをお持ちでしょうか。「開発の後に行う確認作業」といったイメージを持たれている方もいるかと思います。 しかし、開発しようとしているソフトウェアに不具合の混入を防ぐには、もっと早い段階でテストについて考えることが必要です。こういったテスト活動は、プログラムを1文字も書いていないときから始めることができるのです。 本記事では、2016年に提唱された継続的テストモデルを紹介しつつ、アジャイルとも親和性のあるシフトレフトなテスト活動について解説していきます。 DevOpsにおけるテストの考え方 DevOpsのループ図とは何か? 継続的テストモデルとは何か 継続的テストモデルにおいてテストは「活動」である シフトレフトなテスト活動とシフトライトなテスト活動 シフトレフトなテスト活動としてのテスト駆動開発 コード実装を始める前から行うテスト活動 シフトレフ
こんにちは!ファインディでFindy Team+開発チームのEMをしている浜田です。 昨今、開発生産性を高めるための取り組みを行っている組織が増えてきていると感じています。 開発生産性を向上させるためには、まずは定量的に可視化することが重要です。 可視化することで現状を把握して、開発組織の伸びしろを発見したり、課題を明らかにし、改善活動に取り組みやすくなります。 一方、定量的な指標に焦点を当てすぎてしまい本質的ではない対応をしてしまい、指標は向上したものの実際の生産性は向上していなかったり、むしろ悪化してしまうこともあります。 この記事では、開発生産性指標を向上させるためにやってはいけないアンチパターンについて紹介します。 デプロイ頻度を向上させるために、デプロイプロセスは変更せずに実施回数を増やした デプロイ頻度はDORAが提唱するDevOpsの4つの指標(Four Keys)の1つであ
ありがたいことに、いわゆる文系・ビジネス職からベイエリアでソフトウェアエンジニアになった前回の記事は多くの方に読んでいただきました。改めてお礼を申し上げます。とはいえ、当然ですが、ソフトウェアエンジニア(以下、SWE)になって終わりではなく、SWE になってからもそれ以上に大切であり、実際に SWE 転向後、どのような経験をしたのか、現実的な点も含めて、この記事では書いてみようと思います。 結論から言うと、初めは知識や経験の浅さから苦労しましたが、最終的には社内査定でも最高評価をいただき、なんとか昇進、異動する運びとなりました。 SWE になってみてまず、ポジティブな面から、状況整理も兼ねてお話しすると、自分は多くの方に使っていただいている製品・機能の Android アプリ(≠ Android OS)及び、そのバックエンドを担当することになりました(つまり、Android アプリがメイン
こんにちわ!hanetsukiです。 この記事はCursorが出た頃に一瞬使ってみて「う〜〜〜ん、なんかビミョい」となり、VSCodeに出戻ったフロントエンドエンジニアがもう一回Cursorを使い始めて長期的に使っていきそうな所感を感じたまとめ記事です。 Q.Cursorってなに? A.端的に申し上げますと、VSCodeにAI搭載したエディターです。 VSCodeをフォークして開発されているので、見た目もまんまVSCodeです。 Q.なんでVSCodeに戻ったの? A.UIの微妙な差が気に食わなかったのです。 過去のことなのでよくわかりませんが...当時の私は変化を受け入れることに抵抗があったのでしょう。 参考までに、VSCodeとCursorのスクリーンショットを掲載します。 VSCode Cursor お気づきになりましたでしょうか?...そうです。 アクティビティーバーが水平になって
Kotlin Fest 2024とは Kotlin Festは「Kotlinを愛でる」をビジョンに、Kotlin™に関する知見の共有と、Kotlinファンの交流の場を提供する技術カンファレンスです。(公式説明) 今回ログラスはひよこスポンサーとして、参加させていただきます。 なぜスポンサーするのか ログラスではサーバーサイドでKotlin+SpringBootを採用しております。 創業当初からドメイン駆動設計を実践し、最近では関数型の考え方を取り入れながら品質が高く、長期で価値を生み出せるプロダクト開発に取り組んでいます。 ログラスではKotlin以外にも様々なOSSを活用していますが、OSSが発展するためには技術コミュニティの発展が重要であると考えており、コミュニティへの還元を推進していきたい思いからスポンサーを実施しております。 Kotlin Festへは過去弊社社員の佐藤(@Yuii
はじめに 惜しくも(?) Kotlin Fest 2024で採択とならなかったセッションの供養を行います。とはいえ、全ての内容を網羅することはせず、かいつまんで話したかった内容を書いていきます。 Railway Oriented Programmingとは? Railway Oriented ProgrammingとはScott Wlaschin氏によって提唱された設計です。 詳細は全て無料でこちらから見れるのでぜひチェックしてみてください。 簡単にいうとRailway Oriented Programmingとは正常ケースと異常ケースの2つのレールを型で表現しながら設計をする手法です。 関数型プログラミングでは、RustのResultやScalaのEitherに代表される成功値かエラー値かのどちらか一方の値を持ったデータ構造を使ってエラーハンドリングを行います。以下はRustのResul
こんにちは、hacomonoのプロダクト開発本部のたつ(X)です。 前回は「hacomonoの機能開発チームのたつです」と自己紹介したのですが、組織も大きくなりまして「部」なんて言葉を使うようになりました。 さて本日のお話は、2024年に入って「プロダクトエンジニア」という役割を社内で定義・言語化しましたのでそのお話をしたいと思います。 以前にもこじこじが「プロダクトエンジニア」について記事を書いてくれています。 本日はその第2弾としてhacomonoの「プロダクトエンジニア」の定義とその誕生の経緯についてお話したいと思います。 と言っても何も新しい役割を定義しましたという話ではなく、今までも社内で活躍してくれていた人の特徴を言語化・再定義したというお話です。 なぜ「プロダクトエンジニア」という言葉を定義したのか? 理由は4つあります。 組織が大きくなるにつれて、プロダクト開発エンジニアの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く