はじめに こんにちは。WEARフロントエンド部Webチームの藤井です。私たちのチームでは、WEARのWebサイトのリプレイスと新規機能の開発を並行して進めています。これらの開発を推進する中で、Pull Requestのレビュー負荷を軽減し、開発生産性を向上させるための取り組みを行なってきました。本記事では、その中で効果的だった取り組みについてご紹介します。 目次 はじめに 目次 背景と課題 レビューの体制の薄さ スコープの広さ 仕様把握の負担 対応内容についての説明不足 処理の複雑性 仕様の抜け漏れ 動作確認の手間 課題解決に向けた取り組み レビュー体制の見直し Pull Requestを小さくする Issueを小さくする Pull Requestの粒度について明文化する 機械的なチェックの拡充 ESLintルールの拡充 Visual Regression Testの拡充 Pull Req
こんにちは。食べログシステム本部技術部データサイエンスチームの先端領域推進ユニットに所属する佐藤です。 私たちのユニットでは、先端領域技術を活用して多方面で価値を創造することをミッションとしており、生成AI技術を活用した業務効率化や開発生産性向上に取り組んでいます。その取り組みの1つとして、生成AI技術によって開発生産性を上げることを目的とした、コーディング支援ツール「GitHub Copilot」の導入を推進しています。 先日、GitHub Copilotの利用を促進させるために、社内ナレッジ共有イベントを企画・実施しました。このイベントは、参加者に実際の開発現場で使われているGitHub Copilotの利用例を投稿してもらい評価・表彰するというユーザ投稿型の取り組みです。このイベントを通じて全体の利用率を約1.2倍に向上させることができました。本記事では、その事例についてご紹介します
※この記事では、codecovの公式ドキュメントを参考に、codocov.ymlの設定に関わる部分をかいつまんで記載しております。 より詳細に知りたい場合は、要所要所に対応する公式ドキュメントのリンクを入れているので、そちらを参照ください。 codecov.yml codecov.ymlとは、codecovの各種設定ファイル。 必須ではなく、存在しなくてもデフォルトの設定でcodecov自体は動作するが、codecov.ymlを設定することでより様々なことができる。 主な設定項目は以下5つ。「About Code Coverage」 PRコメント ステータスチェック(PRブロック) レポートのマージ フラグ パスの操作 codecov.ymlの種類 「About the Codecov YAML」 codecov.ymlにはGlobal YAMLとRepository YAMLの2種類ある
こんにちは。開発部門 開発部 Data AI Strategyセクション データ基盤 Unitの小野です。 2020年8月に入社してから早3年。SREエンジニアとして、日々業務改善に励んでいます。 ここ一年ほど、DAOという組織改善プロジェクトを推進していく中で、Google Kubernetes Engine (GKE)を使ったGKE共通デプロイ基盤の整備も進めてきました。 ※ DAOについての詳細はSREエンジニアが組織改善プロジェクトを立ち上げてみたを参照ください SREエンジニアの責務の一つは、プロダクトのリリースサイクルを極限まで短くし、次々と新しいサービスを世の中にリリースすることです。ChatGPTのような誰でも簡単に扱えるAIモデルが誕生したことで、プロダクト開発競争は今後ますます激しくなっていくと予想しており、SREエンジニアの責務の重要性をヒシヒシと感じています。 そう
SREホールディングス株式会社の松本です。 プロダクトはリリースしてからが始まりで開発し続けることが当たり前の時代、ソフトウェアは変更や拡張に強く設計しなければなりません。クリーンアーキテクチャはそんな設計を実現する方法の1つですが、名前は聞いたことはあるけど実践したことはない、なんだか複雑で難しそう、という印象を持っている人が多いのではないでしょうか。 クリーンアーキテクチャを詳細に説明している記事は数多くありますので、本記事ではクリーンアーキテクチャを触ったことがない方に良さが伝わるように、やさしく噛み砕いて説明してみようと思います。 対象読者 クリーンアーキテクチャをこれから学びたい方 クリーンアーキテクチャとは 機能を実現しているコアな部分をフレームワークやDBなどに依存しない状態(関心事の分離)にすることで、他が変わってもコアな部分への影響をなくし、変更や拡張に強くすることができ
序章 静的型付け言語がスタートアップにおける成長戦略にどのように貢献するかを解説する記事です。 静的型付け言語とは 静的型付け言語とは、プログラムの実行前に変数の型が決定され、コンパイル時に型チェックが行われる言語のことです。Java、C#、Rust、TypeScript、Goなどが代表的です。実行前にエラーを発見しやすく、大規模なプロジェクトや長期的なメンテナンスに適しています。 静的型付け言語のメリット エラーの早期発見 静的型付け言語は、コンパイル時に型の不一致や変数の誤用を検出します。これにより、ランタイムエラーが減少し、開発初期段階で問題を発見できるため、時間とコストの節約につながります。 コードの可読性と保守性 型情報がコードに明示されているため、他の開発者がコードを理解しやすくなります。チームが拡大する際に、コードの保守性を高める重要な要素です。 パフォーマンスの最適化 静的
どうもキャッシュバスターズ、 id:Soudai です。 Cache(以下、キャッシュ)は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
本をよく読むエンジニアであれば、ライブラリの導入には慎重になるべきだということは共通の認識になっていると思う。しかし、どういったライブラリを導入すべきかという選定基準は自分の中ではまだ言語化できてないことに最近気がついた。絶対的な基準を設けるのではなく、ある程度柔軟に考えるべきだと思うが、自分がどう考えて選定するかを考えてみる。 品質 テストが書かれているか 自分のプロダクトでテストを書いているのであれば、ライブラリにもテストを求めるべき 長い間継続してメンテナンスされている(いた)か 急に出てきてセンセーショナルな売り文句で注目を浴びるライブラリは怪しむべき コードの品質は悪くないか 導入する前にライブラリのコードは読むべき 効果 その後の実装効率をどれだけ上げるか 導入しない場合と大して変わらないのであれば不要 自分でそれを書いた場合と比べてどうか 短時間で同じようなものを書けるのであ
生産性とかもそうなんだけど、「次来た人のことを考えて行動する」ということなのかなと思った。 自分の話に戻ると、古いIssueを掃除したり、ランタイムをアップグレードしたり、RDBの不要なカラムを削除したり、シードデータ生成処理を改善したり、不要な処理を削除したりといった感じで、「美しく」の捉え方にもよるけど、次来た人のことを考えてこういったことに手を伸ばした。 自分以外の例だと、多くのリポジトリのデフォルトブランチが未だにmasterになっているのを全てmainにしようと呼びかけた人がいた。その時限プロジェクトにはたくさんの協力者が集まり、あっという間にmainブランチへのリネームをやりきった。 今自分がいる会社にはボーイスカウト・ルールを当たり前のように実践できる人がたくさんいいて日々刺激を貰っているのだけど、彼らを見たり、自分の経験を元に考えてみると、ボーイスカウト・ルールを実践すると
プロダクト技術本部の川口です。 3年間、ビッグローブ光といった固定回線のインフラ部門に所属していましたが、今年の4月に BIGLOBE の基幹システムのリニューアルを推進していく部署に異動することになりました。 所属するチームでは、ドメイン駆動設計(DDD)で開発しています。 チームにジョインすると開発チュートリアルをやることになっており、そこで IntelliJ や Spring Boot での開発の仕方を学んだり、チュートリアルを通して DDD を学んだりします。 今回は、DDD のチュートリアルで実際に作成したドメインモデルがどういう風に成長していったかについて紹介します。 勤怠管理アプリ チュートリアル 初期ドメインモデル 中期ドメインモデル 後期ドメインモデル 学んだこと、感想 勤怠管理アプリ チュートリアル お題は GitHub のパブリックリポジトリに公開されています。 ht
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発(TDD:Test Driven Development)です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①~④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図:レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか?」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
先日同僚と雑談的に話してたことを書いておく。ソフトウェア開発のバックログにおける話です。 「〜対応」とは 主に差し込みで入ったタスクやなにか早めに単一の解決したい事象のためのタスクに名付けられやすい名前。 あくまでも例としてだが 「マーケから割引データ表示依頼対応」 「監視アラート対応」 みたいなやつ。「〜対応」というのは日本語としてはかなり便利なので、とりあえずバックログに入れておきたいときに使いがち。 なぜ避けたいか 完了基準があいまいになる タスクを流していく際の問題。 バックログ上のタスクは完了基準を定めておかないと、作業スコープがどんどん広がったり、完了したかどうかを確認する人から見ると完了していないということが作業後にわかったりして不便。「〜対応」という名前をつけるタスクは、そもそもの作業スコープがはっきりしていないことが多く、結果として、作業を始める前に関係者との認識合わせが
↑by Image Creator from Microsoft Bing CodeRabbitのレビュー もう初回コードレビューはAIに任せる時代になった - CodeRabbit -を読んだ。レビューはとても負担が多く、時間もかかる。これをAIがやってくれたら、こんな有難いことはない。というわけですぐに使ってみた。 CodeRabbitを使った結論 結論から書くと、レスポンスも速く、技術レベルも高く、気を使う必要もない上に、コミュニケーションも出来る。若干問題に対して答えを言いすぎるキライはあるが、これも使い方に依る。さらにレビューを意識することでコードの健康まで得られてしまう。良いことしかない。 CodeRabbitの価格体系 気になっていたのはやっぱり価格だが、調べてみたらオープンソースであれば無料!だった。また有料も以前はOpenAPIのトークン使用量が別途かかっていたようだが、
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
みなさん、デザインツールの Figma を使っていますか? 私はまだ「使っている」と言えるほど使えていません というわけで勉強会を開催して勉強します Figma とは 公式の紹介文は以下のとおりです デザインの追求からプロトタイプ作成、制作物のコーディングまで、Figmaはチームがコラボレーションして製品開発するためのプラットフォームです 本記事のタイトルと同じように、「デザインからデモ・実装までチームで製品開発できる」旨が書かれています まさにその通りで、ブラウザ上で UI をデザインし、そのまま動かしてみることができ、最終的にはコードの生成までできてしまうツールです Figma の人気 2022年に世界中のデザイン関係者を対象としたアンケートでも Figma は圧倒的な人気です いずれのランキングでも2位の10倍以上の得票数になっています メインで使っている UI デザインツール第1位
この記事の目的 今まで Web アプリケーション製作を行った経験が無い方が「ちょっと個人開発で何か作ってみようかな!」と思ったときにうっかり脆弱性を作りこんでしまうことを少しでも防げたらいいなと考えました。 そのためにはまず脆弱性を他人事だと考えないことが大事だと思ったので、私が過去の開発現場において実際に遭遇したことがある Web アプリケーションの脆弱性の事例を幾つか紹介します。 紹介の前に注意喚起をします。 自分が管理しているわけではない Web アプリケーションに対し、依頼されてもいないのに脆弱性を探す行為は絶対にしないでください。その行為の内容によっては犯罪になる可能性もあります。 外部から渡されたデータを何の対策もなしに SQL に埋め込んでいる SQL インジェクション攻撃の説明でよくみられる例ですが、ログイン処理でユーザーが入力した ID とパスワードに一致するユーザー情報
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く