よいコミットメッセージ・よくないコミットメッセージ - 弥生開発者ブログ
こんにちは、mzpです。 今日はMisocaのesaに書いていた「よいコミットメッセージ・よくないコミットメッセージ」という記事を紹介したいと思います。 あらすじ 開発チームでは「コミットメッセージには変更理由を書いて欲しい」「コミットメッセージはWhatよりもWhyが大事」という話を何度かしているのですが、なかなか徹底できていません。 ので、もう少し具体的に「こういうコミットメッセージはよくないですね」というまとめを作ってみることにしました。 ちなみにこの過程でみつけたコミットメッセージに、こんなものがあります。 一切情報がなくておもしろいですね。 ファイル移動を移動した事実しか書かない これは以下のようなコミットメッセージです。 ファイル名を変更 ディレクトリを移動 ファイルを移動したことはコミットメッセージを見なくてもdiffから分かりますが、なぜその移動をしたかが分かりません。 の
技術フェローが名古屋を流していたのでペアプロの手ほどきを受けたら捗った - 弥生開発者ブログ
Misoca開発チームの黒曜(@kokuyouwind)です。 先日大須演芸場で開催された名古屋Ruby会議03ではTwitterでひたすら実況していました。大喜利が思った以上に大喜利で面白かったです。 お題「みなさんRubocopになってもらって『直しました』といってください。『何を直したんですか？』と聞くので、直したところを答えてください」 須藤さん「直しました」「何を直したんですか？」「RSpecをTestUnitにしました」 #nagoyark03— 黒曜@技術書典2 か-13 (@kokuyouwind) 2017年2月11日 流しの技術フェローに教わったペアプロのコツ 先日、弊社技術フェローのkakutaniさん(@kakutani)からペアプログラミング(以下ペアプロ)のコツを教わり、社内でのペアプロ機運が高まっています。 今回はkakutaniさんから教わった内容のまとめと
積極的にコードの闇を消していこうな - 弥生開発者ブログ
こんにちは。 開発チームのめろたん(@renyamizuno_)です。 マイブームは開発メンバーの写真をトリミングしてSlackの絵文字に追加することです。 これは哀愁ただよう僕の写真です。こくぼさん(@yusuke_kokubo)が「アイキャッチにどうぞ」と作ってくれたのでアイキャッチにしました。 このブログを書いている今ですらこの写真を貼ったことを後悔しています。 ですがせっかく作ってくれたものなので貼ったままにしておきます。 はい。 今回は無駄なコードや深淵をのぞいてしまった時、「あっあっあっ。」と言いながらフタをするのではなく積極的に闇を消していこう。 という話を書きます。 大量のログイン画面 最近実装した画面でログインモーダルを追加することがあり、単純にログインフォームを実装したのですが上手く動きませんでした。 参考にログイン画面を見ようと思ったら、 sessions/new.h
レビュー依頼前のコミット整理方法 - 弥生開発者ブログ
Misoca開発チームのmzpです。 新しいMisocaステッカーが完成したので、いろいろな場所で配りはじめました。 今日は、Misoca内でレビュー依頼をする前にやっているコミットの整理について紹介しようと思います。 Misocaの開発の話ですので、GitHubのpull requestベースでのレビューが前提です。 要約 pull requestをレビューしやすくするために、コミットを整理しよう。 方針 最終的な結果だけを残し、途中の試行錯誤の跡を消す 無関係の内容は別のコミットにする 具体的な作戦 自動生成と非自動生成のものは分ける scaffoldで生成されたものや Gemfile.lock 等の自動で更新されるものは、特にレビューする必要はありません。 そのため、それ以外の手で書いた変更とは別のコミットとは別にしておくとよいです。 試行錯誤の跡を消す PR内で発生したバグの修正コ
ソースコードを読むときの3つのステップ - 弥生開発者ブログ
はじめに はじめまして。お盆明けからMisocaでインターンをしているhmryuです。Misocaにジョインする前は、個人でサービスを作ったり、研究でプログラムを書いたりしていました。 一方で、チームで開発する経験はあまりなく、Misocaにジョインした始めの頃は慣れないことばかりでした。中でも、他人の書いたソースコードを読んで理解することが、一番大変だったかもしれません。 そこで今回は、機能追加・変更を加えるためにソースコード*1を読む上で、僕が大切だと感じた3つのステップについて書きたいと思います。 1. 機能とソースコードの対応を調べる まず、自分が変更を加える機能がどんなもので、どこに実装されているのか理解する必要があります。実際にサービスを動かして、どんな機能なのかを確認します。その後、その機能がソースコードのどの部分に対応するのかを調べます。 例えば、メール送信について調べる場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
