モブレビューやっていきたい | Melody
最近モブレビュー取り入れたいと感じていて、なんで取り入れたいかなどについて書いてみました。 モブレビュー自体まだ 2, 3 回しかやってないので説得力にかけますが、ご容赦ください。 想定チームは 6 人以下Pull Request (以下 PR) をマージするには必ず他の誰かが approve しないといけない目的チーム内の情報共有属人化の解消退職や異動などによる情報の喪失(誰も分からない状態)を防ぐチーム外の人とのコミュニケーションにも活用できるレビュー待ちの短縮レビューの品質の改善仕事を評価してもらうことで承認欲求を満たすオンボーディングの改善レビューを通じて必要な知識を吸収してもらうオンボーディングに限ったことではないが、オンボーディングにも有効ではないか最後までやりきる箇条書した内容を補足します。 情報共有属人化の解消は結構重要だと自分は思っていて、特定の人じゃないと出来ない
気が狂った設計 - hitode909の日記
大きめのこととか，自信のないところを触るときは，コード書く前に，こういう作戦考えてみたけどどうですかって聞いてみたり，こういうことやりたいんだけど一緒に考えませんかって，いっしょに話して設計考えたりするとよいと思う． 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので，未然に変な設計のままコード書いてしまうのを防げる． 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「（こんな実装は）有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う．我が社にはそんな強い言葉でレビュー書く人はいない． 我が社には，普段から強い言葉を発する人もいなくて，みんな物腰柔らかな変な言葉を話している． 言葉使いや文体は，ずっと過ごしてると同僚から移ったりするので，普段からそういう言葉を話していると，全体の雰囲気も悪くなりそ
コードレビューをし合える文化がチームを強くする - ppworks.jp
コードレビューしてますか？ 「コードレビューをしよう - pblog」でも触れたのですが、 今回はコードレビューの話です。 コードレビューって何からして良いか分からなかったり、レビューアーに負担なんじゃないか、、、って尻込みしがちですが、レビューしてもらう前に気を付けること、なにをレビューしてもらうのか、そして逆にレビューするのか、そして何が起きるのかあたりを考えていきましょう。 レビューして貰う前に気を付けること レビュアーの負担を減らすのは大事です。 コーディング規約に沿っているか？といった簡単なレビューは、犬にやらせるという方法もありますが、そもそもgit-pushする前に、ローカルのgit-commit時点で対処しておくというのもありです。 犬 is rubocopですし、 rubocopやjshintなどをgit-hookにまとめて設定できるpre-commit gemが便利そう
社内サービス開発のススメ - クラウドワークス エンジニアブログ
最近機動戦士ガンダム0083スターダストメモリーを一気見したエンジニアの那須（@nasum）です。好きなガンダムはExSガンダムです。リフレクターインコムかっこいいですよね（アイスブレーク）。 普段働いているとPCを使う以上様々なソフトウェアやサービスを使うと思います。DropboxやEvernote、Google Driveにスプレッドシート、エクセルからパワーポイントまで様々です。 そんなとき、「社内で使われているこのサービス、目的を果たすにはちょっと面倒だな」なんて思ったことはないでしょうか？ 自分が目的を果たすために、フラストレーションを感じてしまうのであればなんとかしたいものです。そういうとき無料のサービスを利用することや、オープンソースのソフトウェアを導入することをまず考えると思います。しかしなかなか自分の要件にフィットするサービスは意外にもなかったりします。 そういうときは勢
複数のエンジニアと開発を円滑に進めるためのissueの立て方 - クックパッド開発者ブログ
こんにちは。クックパッド特売情報ディレクターの田中です。 前回ヘルスケア事業部の濱田くんのエントリーでエンジニア以外のGitHubの利用について紹介されていましたが、今回は私がチーム開発で実践しているissueの立て方についてご紹介したいと思います。 チームが大きくなってきてヒズミが生じてきた 本来、ディレクターが開発を伴わない価値検証を十分に行った上で仕様を考え、デザイナー・エンジニアに引き継ぐのが理想的だと思います。 私自身も当初はその開発の進め方を採用していましたが、チームが大きくなり、ディレクター１人で関わるエンジニアが増えてくると、状況は変わってきました。 マルチタスク的に仕様を考えていたために詰めが甘い部分が多く、手戻りが発生してしまったり、仕様の準備が追いつかず、エンジニアの手が空いてしまうことが増えてしまったのです。 当初は自分自身の頑張りが足りないからだと、徒に気合いと根
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーション - ppworks.jp
pplogの過去のポエムを複数単語で絞込できるようになりました。 pplogは、自身と向き合い想いを言語化するためのサイトだったりします。（色んな使い方があります） 最新のポエムだけが他人に見えますが、 自分の 過去のポエムを見る機能があります。 この過去ポエムは検索機能が付いているのですが、先日まで複数単語で絞り込むことが出来ませんでした。 pull requestが来た id: shootaさんからpull requestを頂きました。 勝手にやった！まさにこれだ！と思いました。 よし、コードレビューをしよう！ 命名に突っ込んだ これを見て思うところがありました。 search_word_arrays = params[:keyword].gsub(/ /," ").split() 私は言った for文にナニカを感じた し、Cぽい！ search_word_arrays = param
「テストデータを修正しました」に学ぶ - (define -ayalog '())
2014-01-29 「テストデータを修正しました」に学ぶ 開発 日記 先日こんなことがあった。僕「このテストデータを使って、テストしてください」 海の向こう「日本から提供されたテストデータを使うとエラーがでます。なので、テストデータを修正しました。これで正常に動作することを確認しました」 ふざけるなああああああああああ(涙— ぷろぐらみんぐしょしんしゃ (@ayato_p) 2014, 1月 27どうやらIT系の人たちに刺さりまくったようで1000RT Overという自己*1最高記録を更新しました。オフショア開発やっていると「わりとよくある」日常だと思う。僕も過去4年間のエンジニア生活の中で何度となく出会ってきた。その度に「オフショア開発やりたくないよー」って思うわけなんだけど。 何故こんなことが起こるのか 可能性としては以下のような感じでしょうか。 自分たちは正しいという絶対の自信を持
QiitaやKobitoを作る開発チームの文化 - Qiita Blog
こんにちは，yaottiです． 今日はQiitaやQiita:Team, Kobitoを開発するチームでぼくたちがどういう文化，価値観を大切にしているかをお話したいと思います． HRT, SPOF, LeanIncrements(あまり知られていませんが，Qiitaを作っている会社の社名です)の開発チームが特に大切にしているのは以下の3つです． HRTを大切にしたコミュニケーション属人性を極限まで排除する重要な価値に集中する以降でそれぞれ具体的に見ていきます． HRTを大切にしたコミュニケーションHRTとは HRTとはTeam Geek ―Googleのギークたちはいかにしてチームを作るのかという本にある考え方で(あらゆるチーム開発者に読んでほしい!)，Humility(謙遜), Respect(尊敬), Trust(信頼)の3つを意味しています． 「驕り高ぶらないようにしよう」「相手を尊
つくること ＝ 生きること ： パターン・ランゲージによる創造の支援
成蹊大学「コース特殊講義Ａ （デザインとIT）」（坂井直樹先生）での井庭崇の講演スライド。2013年12月3日（火）。 Read less
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
新社会人の君へ-disるということについて - あんちべ！
「ご趣味は？」と聞かれて「Lispをdisることですね（ｷﾘｯ」と答えてしまい、 合コン開始4秒で蚊帳の外に放り出されるあんちべです、こんばんは。 今から長い文章を書く。 結論だけさっさと言っちゃうと 「まぁ、初めのうちは、あんまり『○○は使えない』とかdisらない方が良いよ」の一言だ。 さぁ、それで話しはおしまい。もし暇だったら続きも読んで欲しい。 （あと、この文章はたった一人のために書いた。 ちょっと妙に聞こえるところもあるだろうけど、そこは聞き流して欲しい） 私はよくいろんなものを嫌いだ嫌いだとdisる。 にわかベイジアンが嫌い（話すと長くなる）、Javaが嫌い（JVMは愛してる）、Perlが嫌い、 MavenとかCVSとかが嫌い、アジャイルアジャイル言ってる人が嫌い（アジャイルが嫌いなわけじゃないよ）… 言い出したらキリがない！毎日新しいdisりの種が沸いてくるんだ！ 何度か様々な
「エンジニアは魔法使い」という幻想 : LINE Corporation ディレクターブログ
こんにちは、ライブドアの櫛井です。今回はディレクターとエンジニアの意思疎通についてお届けしたいと思います。 ■魔法使いはいない？ 一般的な受託案件などの場合、サイトのプログラムやサーバーまわりの調整などはシステム開発会社の担当の人が一手に引き受けてくれます。しかし、 livedoor のように社内に開発部がある会社では、ディレクターが自力でエンジニアに「何をしたいか」「なぜそうしたいのか」「それをすることで何を目指すのか」ということを正確に伝えていく必要が出てきます。 サイトの規模によってはエンジニアがディレクターを兼ねる場合もあるかもしれませんが、ウェブ業界全体を見てみても「ディレクターで元エンジニア」という人は希少で、ほとんどの場合プログラムやサーバーサイドの仕組みを十分理解できているディレクターというのは稀な存在といえます。 システムの知識を十分持っていないディレクターたちが抱く幻想
はてなチーフエンジニアが聞く、サイボウズLiveのアジャイルな開発現場 - はてなニュース
「ビジネス上のコミュニケーションを、メールの不便さから解放したい」という思いから2009年にサイボウズがスタートした無料コラボレーションツール「サイボウズLive」。その開発現場は、Webアプリケーション開発の流行をうまく取り入れたアジャイルなものでした。その様子を、はてなチーフエンジニアの大西康裕がインタビューしました。テーマは、プログラミング言語の選び方から、自動ビルドと自動テスト、リファクタリング、チーム内コミュニケーションなど。大西自身も「面白かった」と語る取材の様子をぜひお楽しみください。記事の最後ではプレゼントもご案内しています。ところでこの取材には、サイボウズ・ラボの竹迫良範氏が、なぜか大量のレッドブルを抱えて登場したのですが……。 http://live.cybozu.co.jp/ （※この記事はサイボウズ株式会社提供によるPR記事です。） 大西 はてなチーフエンジニアの大
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
React/Storybookと、全員参加型のUI開発
「同調圧力」では何も深掘りされない──カーネルハッカー・小崎資広（6） | サイボウズ式
Hubotレビュアーおみくじ @ githubkaigi
就活生のみなさんへ ～文系？理系？～ « サーバーワークス社長ブログ