新卒エンジニア向けにコードレビューを「する」話をしました。 http://hisaichi5518.hatenablog.jp/entry/2014/10/29/165721
![コードレビューの話](https://cdn-ak-scissors.b.st-hatena.com/image/square/9dc252bba39d8d1105ea9f9e612a97317b86d784/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fe7d97d7041590132d584068a5b24ded7%2Fslide_0.jpg%3F3803385)
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフー株式会社の有地です。 9/27(土)の昼から6時間にもわたり、さまざまな視点から「レガシーコード」について知識を深めるための勉強会を開催いたしました。 「そもそも正しい仕様を知っている人がいない」 「システムのブラックボックス化が留まるところを知らない」 こんな不条理なレガシーコード(テストコードが無いコード)と日々戦うエンジニアも多いことと思います。 今あるレガシーコードをどうやって保守・改善していけばよいのかという課題に本気で取り組んでいる、または取り組みたいと考えている大勢の方々に参加していただきました。 <開催趣旨・目的> テストコードが無いプロダクションコードをレガシーコードと定義し、テストコードによって保護され、
業務でソースコードレビューを行う機会が増えたので、複数回指摘した項目や気になった実装などをまとめてみました。 こういう観点をできる人と共有できるといいなあ…。 2014/09/29 23:00 一部修正しました。 業務上ソースコードレビューの名目で仕様・デザインまで見ることになっていたためこれらを先頭に書いていましたが、わかりづらかったため最後にまとめました。 Fragment関連 FragmentとActivityの密結合 Fragmentが特定のActivityから呼ばれることを想定して書かれている場合、そのFragmentとActivityは密結合である場合が多いです。 具体的には、以下の様な実装です。 ActivityのViewを参照する Activityのメソッドを直接呼び出す なぜダメか Fragmentの利点のひとつは優れた再利用性にあります。 Fragmentが特定のAct
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
はじめに 2014年8月11日の晩に放送されたソニックガーデンのweb勉強会、SonicGardn Studyでは「いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜」というタイトルで、弊社ソニックガーデンの西見さん(@mah_lab)が講演してくれました。 デキるプログラマだけが知っているコードレビュー7つの秘訣 from Masahiro Nishimi いつまでクソコードを書き続けるの? 〜出来るプログラマだけが知っているコードレビュー7つの秘訣〜 - YouTube この放送の中でも触れられていたように、ソニックガーデンではコードレビューを大事にしています。 ただ、勉強会のスライドの中では具体的なコード例や指摘の例がほとんど出てこなかったので、「実際どんな感じなの?」という疑問を持った方もいたんじゃないかと思います。 そこで今回は「入社
実践テスト駆動開発を読んだ(和智さんいい仕事、ありがとう!)。 タイトル(GOOS = "Growing Object-Oriented Software, Guided By Tests")に、「テスト(TDD)」と「オブジェクト指向(Object-Oriented)」と「育てる(Growing)」が入っていて、ずっと読まなきゃと思っていた。出たときに角谷さんに「これは!」、と薦められたのに、機会を失っていたけど、最近、astahの開発でテストに悩みがあって読んでみた。 外から攻めるか、内からか テストを書いてプロダクトコードを育てていくという話なのだが、内側のテスト(ユニットテスト)と外側のシステムテスト(受け入れテスト、システムテスト、エンド・トゥ・エンド(E2E)テスト)をどっちを先に書くべきかいつも悩む。外側のテストを書いて、内側に進んでいくのか、内側から組み上げるか。設計の方向
出張中。時差ボケ修正のためキータイピングで眠気を払おうと試みているところ。 いつになくどうでもいい内容につき見逃してください。 最近はやりの Podcast 番組 Rebuild を聴きはじめた勢いで他の番組も聴くようになった。にわかポッドキャスト好き。 にわか欲があるうちに聞いている番組を紹介したい。といってもだいたい ”オススメ Tech Podcast 5選” の記事にあるやつなんだけど。ちなみに私の Podcast 歴がどれだけにわかかというと、rebuild.fm の序盤はブラウザから mp3 をダウンロードして聴いていたくらい。 Podcast はとっくに滅びたメディアだとおもっていた。でも Blog が生き残っている程度には元気だと知りました。 私の聞いている番組は基本的にアホらしい内容のものが多く、情報収集というより娯楽。 ニュースほど早口でも無味乾燥でもなく、講演ほど背筋
先週の土曜日、技術力の低い人限定ロボコン(通称:ヘボコン)というイベントを開催しました。 白熱の決勝戦のようす すべてがわかる紹介動画 https://www.youtube.com/watch?v=YCx_scvzxNY イベント概要 http://portal.nifty.com/kiji/140603164276_1.htm 出場ロボット紹介 http://portal.nifty.com/kiji/140715164618_1.htm イベント当日の映像はこちら https://www.youtube.com/watch?v=mt48hhhTv4A Togetterによる暫定レポート http://togetter.com/li/696415 正式なイベントレポートはまたデイリーポータルZのほうで書きますが、開催意図みたいな堅い話はそこには書かないと思うので、ここにちょっと書き残し
Inspiredという本があって、数年前からWeb上で翻訳が進んでいたのは知っていた。 しばらく忘れていて、先ほどたまたま確認したら既に2年前に翻訳が終わっていた。 http://inspiredjp.com/toc/ この本にはソフトウェア企業に務めている人であれば誰でも悩むようなことが書かれている。 プロダクトマネジメントとプロジェクトマネジメントの違い、プロダクトマネージャーの重要性と不在、特にプロダクトマーケティングの不在。アジャイル開発との関係。カスタム開発*1とパッケージソフトあるいはインターネットサービス開発の違い。アジャイル開発はもともとカスタム開発の問題解決のために考案されているためか、プロダクトマネジメントについての考慮が抜け落ちている件、などだ。 僕もまだ読んでいる最中なんだけど、この話題はとても興味があり、悩みも多い。 プロダクトマネジメントとプロジェクトマネジメン
フリマアプリFrilのリニューアルを題材に、iOS開発でのコードレビュー事例を紹介します
2014年6月1日(日)、東京・渋谷マークシティにおいて、GitHubユーザグループ主催によるイベント「GitHub Kaigi」が開催されました。500人の定員に対し800人を超える参加申し込みのあったこのイベントには、日本におけるGitHub活用の第一人者たちはもちろん、米GitHub社から招いた開発者たちも登壇し、いずれ劣らぬ濃いセッションが繰り広げられました。ここではその様子を紹介します。 GitHub実践入門 ── Pull Requestによる開発の変革 トップバッターとして登壇したのは、WEB+DB PRESS plusシリーズ『GitHub実践入門 ── Pull Requestによる開発の変革』の著者である大塚弘記氏です。 『GitHub実践入門』の著者、大塚弘記氏 同氏はまず、「GitHubを利用した開発の世界を知る」「GitHubを(利用|活用)する違いを
最近、社内の新人研修を企画・運営する仕事をしている。 まだ研修は進行中なので、得られた知見は研修終了予定の6月末以降に書くと思う。 しかし、「とりあえずプログラミングやっとくだろ」と思って考えたTDDBCが結構いい感じっぽいので、そこだけまとめてみようと思う。 TDDBC概要 既に弊社の技術研修で5日間みっちりTDDBCをやってぼちぼち好評だったので、同様のものを土曜日に行う旨を告知した。 その結果、個人的に親交がある某web系の会社から4人と、弊社から僕含めて2人の計6人が集まった。 僕は2年目、他の人達は1年目で、歳も近い。 しかも、同じようなメンバーで4月にAnsibleの会をひっそりと行っていたこともあり、いわゆる顔見知りの集まりだった。 当日の流れ 0900 会場(弊社)集合 0900 - 1000 TDDについて、t-wadaさんの資料を見たりして全員の認識を合わせ
この前id:hitode909くんからピープルウェアを貰ったので読んだ。非常に面白くて、興味深い話が多かった。 ピープルウエア 第3版 作者: トム・デマルコ,ティモシー・リスター,松原友夫,山浦恒央出版社/メーカー: 日経BP社発売日: 2013/12/18メディア: 単行本(ソフトカバー)この商品を含むブログ (6件) を見る この本は、作者のトム・デマルコさんとティモシー・リスターさんが10年に及んだ調査と、自身のソフトウェア開発の経験をもとに、ソフトウェア開発における人に関する問題をたくさんのコラムを通じて教えてくれる。冒頭には以下のようにある。 実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである。 いろんなレイヤにおける人の問題についてそれぞれ章がわかれていて、個人からオフィスやチーム、さらには会社組織のはなしへと続く。結構マネージャー視点ぽいコ
「Ruby on Rails 4 アプリケーションプログラミング」の書評になります。 Ruby on Rails 4 アプリケーションプログラミング 作者: 山田祥寛出版社/メーカー: 技術評論社発売日: 2014/04/11メディア: 大型本この商品を含むブログを見る今回はWINGSプロジェクト様( @yyamada )で書籍レビュアーに応募させていただき書評を書かせていただくことになりました。 まずは、前回に引き続き応募を受けて下さったWINGSプロジェクトの皆様、著者の山田様ありがとうございます。 今後もどうぞよろしくお願いいたします。 さて、ここから本題の書評に入らせていただきます。 はじめに本書の内容を簡単に説明させていただきます。 まず、本書の内容は一言で言えば、今後Ruby on Rails4(以下、Rails4とする)で開発をしていく方は絶対に買うべきだと言えるものになって
日常的なコードレビューで気をつけていることリストです。GitHub会議(仮)で発表しようと思っていたのですが、日程の都合で参加できないので、書きためておいたメモを公開します。またどこかで発表するかもしれません。 AutoLayoutにできないか AutoLayout化した方がすっきりしそうならAutoLayout化する AutoLayout化できそうなものでやっていないものは、なぜコードで実装したか質問する 例えばUITableViewCell ちゃんと理由があれば別に良い。コードの方が良いことも多い UIAppearanceで解決できないか 各クラスの中にスタイルの指定が入るより、UIAppearanceでスタイル指定を分離して別クラスに書く方がデザイナーも弄りやすくて良い 3.5インチ端末が考慮されているか レイアウトが決め打ちだとここで問題が出ることが多い 着信ステータスバーが考慮さ
ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。 なぜレビューがうまくいかないのか? ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー(以下、レビュー)の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く