ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
プログラミングスタイルガイドのスタイルガイド - Qiita
本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
Inspired: 顧客の心を捉える製品の創り方を読んだ - ninjinkun's diary
プロダクトマネージャーの職能+ユーザー体験設計の本です（と解釈しています）。 最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。 Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。 プロダクトマネージャーとは何か どうやって他の職種と連携して働くか どうやって製品を見つけ出すか どうやってユーザー体験を作っていくか 自分にとっては、
「最前線で戦う若手インフラエンジニアたちが語る『技術トレンド』と『数年後の未来』」参加レポート #jtf2015 - ブロッコリーのブログ
自己紹介 モデレータ @deeeet 登壇者 @catatsuy @okkun @y_uuk1 @rrreeeyyy wakateinfra 新卒入社3年以内のインフラエンジニアで集まったコミュニティ 今回のセッションの目標・ゴール 若者は今のインフラ界隈をどう思っているのか 質問について ＃wakateinfraのツイートを拾います agenda 自己紹介 技術トレンドについて 技術習得について 今後のキャリアについて まとめ 技術トレンドについて Infrastructure as Code JTFで長らく語られてきたテーマ 息を吐くようにコードを書いてきた世代 プロビジョニングツールの良い所、悪いところ コンテナ 事前アンケートより Chefかpuppetを使っている とりあえずAnsibleを触っている Itamaeも触り始めている @rrreeeyyy 構築を担当する人によって違
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
Code Review Best Practices
At my current company, we do a fair amount of code reviews. I had never done one before I started here so it was a new experience for me. I think it’s a good idea to crystalize some of the things I look for when I’m doing code reviews and talk about the best way I’ve found to approach them. Briefly, a code review is a discussion between two or more developers about changes to the code to address a
Shirobako characters
(Slight spoiler alert) One of the things I like about Shirobako is that it’s not just about creating anime, but it’s a story of building teams, and working with many kinds of people with different backgrounds. I knew I can relate to a few characters in the show, and after the second run of watching it, this filming director guy looks fitting very well. His name is apparently Yoshiki Sakura. For bo
開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Appleとの戦い
Apr 1, 2015 戦史 2月27日 戦いの始まり かねてより噂されていた2chのAPIの仕様変更が開発者に告知された． 私は2tchを修正し，新しい仕様に対応した2tchをiTunes connectに送信した． 戦いは，この日に始まったのである． 運営側の急な仕様変更に伴う作業であることをAppleに通知，特急審査を依頼し，受理される． 今思えば，このとき，この依頼をし，さらに受理されていたことが以後の戦いをスムーズにする，この戦いにおける不幸中の幸いであったことが痛感される． 2月28日 一回目のリジェクト． 理由は，App Store Review Guidlines - 16.1 Objectinable contentへの抵触． 確かに，低俗かつ卑猥な言葉がちりばめられたスレッドが指摘されている． たまにあることなので，指摘された板をフィルタリングし，再度新しいバイナリを提
ミスをエンジニアリングすることについて、例えばなぜ自動化するのかについて−−『「事務ミス」をナメるな！』を読んで - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 今更いうことではないのだけれど、自分は凡ミスの多い人間だという自覚がある。例えば、このブログを書いていたとしても、結構な割合で「てにをは」を間違えることが多いし、また予定等を勘違いして、実は期日を過ぎていたということもある。 そういうこともあってか、「こういう単純な凡ミスを無くす」ことが出来ないかなと思って、本を手に取ったのだけど、いい意味で裏切られた。いい意味、というのは、その本のタイトルに反して、要するに「ミスをエンジニアリングするということがどういうことか」ということが書かれていたからだ。この本はタイトルで純粋に損しているとは思う。 個人において「ミスをする」ということはどういうことか 大抵、人間が何かをミスする場合、そのミスというのは無能であるか、あるいはうっかりといったような「能力の欠如」として捉えることが多い。しかし、本書の場合、それよりかは、むしろ「人間の知恵が働き
巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
CIツール@福岡を主催した話 - nobkzのブログ
CIツール@福岡を主催した話 今回のエントリについて。 僕は福岡では結構いろいろな勉強会を、主催で開催してきて、実は、結構自分で、自分が主催した勉強会について、記録や評価を残したりしているが、なんか、自分の中に漬けておくのがもったいないと思うようになってきた。 なんで、公開できる範囲で、できるだけオープンにしようと思った。そして、その情報が、他の勉強会の主催、これから主催する方の参考になるようになればと思って、この記事を書こうと考えている。 とまぁ、ぐだぐだ前口上を述べたが、つまり、なにがしたいかって言えば、このブログはあるいみ、主催の失敗記録だ。失敗は反省するべきだけでは無く、今後何をしていくべきか?ということが大事であって、できるだけそういうことができればなと考えている。 ** 追記 追記1 失敗記録とは言ったが、細かいところの失敗をできるだけ書いて行こうって話でつ。まぁ、あんまり失敗
How to write the perfect pull request
EngineeringHow to write the perfect pull requestAs a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we've found it useful to remind ourselves what we aim for when… As a company grows, people and projects change. To continue to nurture the culture we want at GitHub, we’ve found it useful to remind ourselves what we aim for when we communicate. We re
Jenkins ユーザ・カンファレンス 2015 東京に行ってきた #jenkinsja #juc2015 - yukungのブログ
» Jenkins ユーザ・カンファレンス 2015 東京 日本Jenkinsユーザ会 2015年最初の課外活動は Jenkins 。connpass のリマインドメールに 13 時開始とあったので、13 時めがけて向かったら川口さんの基調講演は 12 時半からだったみたい。現地に着いてから気づいたんだけど、他にもそういう人多かったみたいで、少し開始時間を遅らせていたよう。おかげで基調講演も半分くらいは聞くことができた。 カンファレンスの最後にもお詫びをしていたし、こういう大規模なイベントだとなかなか運営も大変だと思いますね。運営の方々、お疲れ様でした。 全体の感想とか雰囲気とか 数年前に参加した Jenkins カンファレンスだと、まだ導入しているところの方が少なくて、どうしたら導入できますかみたいな話が中心だったと思う。けど今日参加してみて、既にそういうフェーズは過ぎて、みんな現場で
「Webエンジニアが知っておきたいインフラの基本」はぜひこの冬休みにWebエンジニア・ディレクタに読んでみて欲しい一冊 - blog.nomadscafe.jp
サーバの監視やモニタリングなどのサービス・ソリューションを提供するMSP(マネージメントサービスプロバイダ)のハートビーツの馬場さんが「Webエンジニアが知っておきたいインフラの基本」という本を出版されました。 献本頂きありがとうございます！！ 冬休みは実家に帰ったり、旅行に行ったりと何かとイベント事が多くなかなか本を読む時間が取れなかったり、年が明ければ弟妹・甥っ子姪っ子にお年玉を上げないとならず、自由に使えるお金も減ってしまうかもしれません。なので、読んでみて欲しい本が何冊もあっても困ってしまいますね。そこで自分がお勧めしたいのが、この一冊「Webエンジニアが知っておきたいインフラの基本」です。 本屋に行く時間がない方も安心。電子版があります Webエンジニアが知っておきたいインフラの基本 インフラの設計から構成、監視、チューニングまで【委託】 - 達人出版会 http://tatsu
クソレビューアだらけのレビュー会
体裁厨 「お♪ ここだけフォント違うくない? それからなんか間隔せまいし。」 用語統一厨 「"お問い合わせ"は"お問合せ"と表記することに決まってるので」 箇条書き過剰 「箇条書きにして。その方が分かりやすいよ。」 物忘れ激しい系 「こここんな仕様だっけ? え、設計書に書いてる? 作成者だれ? オレ? 決めた覚え無いけどなぁ…」 レアケース厨 「UUID? 100%衝突しないと言えない? じゃあダメじゃん。」 ショートカット厨 「Ctrl + Shift + T、Ctrl + Shift + T。あぁそれやるならCtrl + Shift + Rだ。」 遅れてくる系 「なんかここおかしくない? えっもう指摘された? ごめん、もう一回ちょっと説明して」 指摘曖昧系 「なんか分かりにくいなぁ。色付けたりするとかあんじゃん?」 寂しがり 「ちょっとなんか寂しいな。ここ説明書き足したら。いやこれだけ
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
YAPC::Asia Tokyo 2015, Aug 20, 21, 22
2015 8/20(木)、8/21(金)、8/22(土) 真夏に熱いカンファレンスを御届けします！ 8/20 18:00~ : 前夜祭 8/21 10:00~ : Day 1 8/22 10:00~ : Day 2 世界最大のYAPCが最後の大花火をぶちあげに今年ももどってきました！YAPCはYet Another Perl Conferenceの略で、Perlに関するカンファレンス・・・いや、お祭りです！Perlだけに限らず、様々な分野のギーク達が集まり技術の話と楽しさに満ちた三日間のお祭りが開かれます。Perlに関連する事に興味がなくとも心配する必要は全くありません、YAPC::Asia Tokyo 2015は技術者であれば誰でも楽しめるカンファレンスです。 今年も様々なゲストを集めて熱いトークが交わされます。世界中のギーク達がどんな事を今を考えているのか行っているのか、是非皆様も体験
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
