コードレビュー開発者ガイド
コードレビュー開発者ガイド はじめに コードレビューとは、コードの作成者以外の人がコードを調べるプロセスです。 Google ではコードとプロダクトの品質を維持するためにコードレビューを実施しています。 このドキュメントは Google のコードレビューのプロセスとポリシーに関する正規の解説です。 このページでは私達のコードレビュープロセスを概観します。このガイドはさらに二つのドキュメントに分けられます。 コードレビューの仕方: コードレビュアーのための詳細なガイド CL 作成者のガイド: CL をレビューしてもらう開発者のための詳細なガイド コードレビュアーはどんな観点でレビューすべきか？ コードレビューは次の観点で見るべきです。 設計: コードはうまく設計され、そのシステムにとって適切か？ 機能性: コードは作成者の意図通りに動作するか？ユーザーにとってコードの挙動は適切か？ 複雑さ:
こどおじがAndroidアプリ作ってたらGoogleに子供部屋を追い出された話 - Qiita
自己紹介 皆様は個人開発をやっておられますでしょうか。私も億万長者を目指して日々スマホアプリ開発をしております。 代表作は安倍晋三エクスプローラー/聖帝エクスプローラー、最近力を入れているアプリはガチ有能AI助手です。他にもいくつかのアプリを個人で開発し、AppStore/GooglePlayで公開しています。 私はこれらのアプリを実家の自室で開発していました。10年以上実家暮らしをしていた筋金入りの子供部屋おじさんです。 なお、ガチ有能AI助手ではバックエンドで使用しているCloudRun、Firebase、Algolia、Suno、Huggingfaceでそれなりに運営費用が発生しています。そのためIn App Purchaseを使用してアプリ内から寄付ができるようにしています。 IAPを使用した寄付機能(iPhone) IAPを使用した寄付機能(Android) GooglePlay
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
コードレビューするときの観点 - Qiita
コドレビューの観点 コドレビューの観点をまとめてみました。チェックリスト的なものになりますた。 機能性 コードが設計通りの機能を有するか？ データの流れ、取得方法は、設計と一致するか？ データのチェックの漏れはないか？ データの生成、修正、加工は、設計と矛盾がないか？ ループの中で更にSQLなど重い処理を発行するなど、パフォーマンスの懸念はないか？ 必要な場合、国際化の対応しているか？ コネクションやリソースは適切な方法で閉じられているか？ NULLとなる場合や値が取れない場合を考慮しているか？ NULLをある程度許容したコードになっているか？ 読みやすさ 名前の付け方は、共通認識の範囲か？ スタイルガイドにそっているか？ ループ、分岐等の処理記述方法は同じか？ コード設計 パラメータ、プロパティなど正しく機能区別されて実装されているか？ インスタンス等の上書き、重複など考慮されているか？
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
メルカリShops の技術スタックと、その選定理由 | メルカリエンジニアリング
こんにちは。ソウゾウの Software Engineer (CTO) の @suguru です。連載：「メルカリShops」プレオープンまでの開発の裏側の1日目を担当させていただきます。 7月末にメルカリShopsという新しいサービスが公開されました。メルカリShops は、2021年1月にメルカリのグループ会社として設立したソウゾウが新たに立ち上げたサービスです。 この記事では、メルカリShops を作るにあたり、どういった技術、アーキテクチャを選定したのか、その背景と意思決定をまとめて共有したいと思います。 monorepo まず最初にプロジェクトをスタートしたときに、サービスのリポジトリを作るのですが、迷わず monorepo による構成を選択しました。monorepo は、システムを構成する複数のコンポーネントの独立性を保ちつつ、全ての構成を1つのリポジトリで管理する手法です。今
スクラムにおける朝会の目的は進捗共有ではないよという話 - Qiita
これは何 スクラムを採用していてもしていなくても、朝会（デイリースクラム）を行っているチームは多いと思います。 最近僕が在籍するQiita株式会社のチームで朝会が形骸化してない？みたいな話があったので、そもそも朝会を行う目的と、朝会で行うべきことについて記事化していきたいと思います。 今回はスクラムを採用している前提で話をするので、朝会=デイリースクラムとします。 デイリースクラムの目的は進捗共有ではない デイリースクラムで、進捗共有をして終わりになっているチーム、意外と多いのではないでしょうか。 しかし、そもそも進捗の共有をしないといけない理由を考えなければなりません。 もしチームのみんながやっていることを知りたいだけであれば、朝会などでみんなで集まらなくとも日報や日々のチャットの中で把握はできるのではないでしょうか。つまり、朝みんなで時間をとって集まっている以上、ある程度のリターンがな
チームで品質を考えるレビュー / team's review for quality
2021年1月22日（金）JaSST Hokuriku 21にて。
テストコードを書き始める前に考えるべきテストの話（2021年版） #scrumosaka / scrum_fest_osaka_2021
以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…
入門 GitHub Actions - メドピア開発者ブログ
CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ
Androidアプリ開発の学び方（2020年版）｜NTT Resonant Technology
NTTレゾナントテクノロジー アジャイルデザイン部の西添です。今年4月からAndroidアプリエンジニアをやっています。もともとAndroidアプリ開発は2012〜2013年頃に経験がありましたが、開発環境が当時とは随分と変わっており、再学習が必要でした。この記事では、6年間のブランクを埋めるために私がどのように勉強していったのかをご紹介します。 Step 1. Kotlin入門かつてはJavaでAndroidアプリを開発していましたが、今はKotlinの方が主流でしょうか。Androidアプリ開発に入る前に、まずはKotlinの基本文法を学習しました。日本語で体系的に学びたかったので、次の書籍を使用しました。 速習 Kotlin: Javaより簡単！新Android開発言語を今すぐマスター 速習シリーズ Step 2. Androidアプリ開発再入門6年前と比較して最もギャップが大きかっ
必要だと気付いてもいなかったフロントエンド用リポジトリ7選 - Qiita
より良いものをより早く作るのに役立つ、あまり知られていないリポジトリ。 Photo by Juan Rumimpunu on Unsplash はじめに 私たちは、汎用ツールやリソースが数回タップするだけで手に入る時代に生きています。しかも幸いなことに、そのほとんどが無料です。 新しいツールやより簡単な方法が見つかり、面倒で複雑なタスクを実行できれば、誰にとっても、特に開発者には嬉しいことです。 でも、より良く賢い方法があり、予想外の方法で時間を節約できることを知らない場合もあります。 この2年間で見つけたGitHubの素晴らしいリソースは、私をかなり助けてくれました。これらのうちいくつかは、その必要性さえ知りませんでした。 そこで、あなたもおそらく必要になるGitHubリポジトリのリストを作りました。 1. 33 JS concepts ソース 私はプログラミングをJavaで始め、その後
もしあなたが急にAndroidアプリを業務で作るはめになった場合の選択肢(2021年初頭版) - Qiita
本記事はAndroid Advent Calendar 2020の2020/12/01分です。 初っ端ということなので、2020年末と2021年頭でのAndroidエンジニアとして初めて業務でやる場合に抑えておいたほうが良い最低限の部分を書いていこうと思います。（ツッコミ待ちです） 対象 2021年3月ぐらいまでに !!業務!! でAndroidアプリを作らされる事になった可愛そうな人が居たとします この人は手続き型言語でオブジェクト指向プログラミングができる知識があり、Androidアプリもなんとなく趣味で作ったこともあるぐらいのレベル感です（なので上長からいきなりお前Android担当なと言われた） 最低限のAndroidアプリの作成の知識はあるものとします（画面の表示にはActivityがいるよとかは書かない) ゲームは対象外です 業務でAndroidアプリを作ることを想定しています
Command Line Interface Guidelines
Contents Command Line Interface Guidelines An open-source guide to help you write better command-line programs, taking traditional UNIX principles and updating them for the modern day. Authors Aanand Prasad Engineer at Squarespace, co-creator of Docker Compose. @aanandprasad Ben Firshman Co-creator Replicate, co-creator of Docker Compose. @bfirsh Carl Tashian Offroad Engineer at Smallstep, first e
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
良いコードを書くための8つの習慣
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
Favicon.io - The Ultimate Favicon Generator (Free)
Favicon Generator The only favicon generator you need for your next project. Quickly generate your favicon from text, image, or choose from hundreds of emojis. Image If you already have an image or logo that you want to use for your favicon then use this tool to convert your image to the proper favicon format. Text If you don't have a logo or image for your website and want to generate a favicon f
書籍『個人開発をはじめよう！』を出版しました - 下町柚子黄昏記 by @yuzutas0
こんにちは。ゆずたそ（@yuzutas0）です。 1年ほどお待たせしましたが『個人開発がやりたくなる本』の「FinalMix版」を インプレスR&D 様より 2020年4月3日(金) に発売開始しました。 個人開発をはじめよう！ タイトルは『個人開発をはじめよう！ - クリエイター25人の実践エピソード』 個人開発をはじめよう！クリエイター25人の実践エピソード (技術の泉シリーズ（NextPublishing）) 発売日: 2020/04/03メディア: オンデマンド (ペーパーバック) 今回のコンセプトは 24 + 1 。 個人開発者25人の事例をご紹介しています。 これまでの24時間の過ごし方を変えて、前に1歩踏み出せるような、そんな勇気が湧いてくる1冊に仕上げました。 表紙はイラストレーターの 湊川あい 様。 「24時間表示の時計塔」「街の外に1歩踏み出せるIdeaの案内看板」「1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT英語スタイルガイド | IT英語スタイルガイド
