コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
ダメなコードを改造しなくてはいけなくなったときは、ダメさを片っ端から潰していくしかない
仕事としてプログラミングをしていると、ときどき、どう見てもダメなコードを扱わないといけないことがある。そういうコードでも動いている以上はそれなりの価値を提供しているわけだけど、ときどき触るのすら嫌悪感を感じるようなものがある。 なぜ嫌悪感を感じるのかといえば、自分で最低限だと思っている想定すら守られていないからだ。常識の通じない人たちの書いたコードには身の毛もよだつような何かがある。 コーディングスタイルが統一されていない インデントが狂っている 到達不能なデッドコードがたくさんある 無意味なコメントやコメントアウトされたコードがある コメントの文章が文章としておかしい コピペの繰り返しがたくさんある ネストが恐ろしく深い 関数が絶望的に長い 無意味に複雑 こういったコードを触らなくてはいけなくなったとき、そのままで編集するのはかなり難しい。コードの内容以前に、不自然な部分でいちいち引っか
Effective Ruby を読んで - ボクココ
以前から気になっていた "Effective Ruby" を読んだ。 Effective シリーズは中級〜上級向けプログラマーの読むべき本として親しまれている。 個人的にもっとも得意な言語はRubyだったので、このシリーズが出るのを楽しみにしていた("得意な"と変換しようとしたら"特異な"と変換されるくらいには使用している)。 中身のネタバレはもったいないので、この本を通じて自分が今まで見落としていた点を挙げてみようと思う。 nil 時の対応 array = hoge() array.split('/')[1] NoMethodError: undefined method hoge for nil:NilClass。Rubyプログラマーなら何度も遭遇するであろうこのエラー。配列でnilっぽくしたい時は空の配列を用意してあげたいところだが、その変数にnilが返ってきてしまうとこの問題に出く
Re: 論理削除はなぜ「筋が悪い」か - Blog by Sadayuki Furuhashi
Kazuhoさんの論理削除はなぜ「筋が悪い」かを読んで。 UPDATEが発生しないテーブルならば、削除フラグを使った実装手法でも現在の状態と更新ログを別々に表現でき、結果として効率と過去の情報を参照できるメリットを簡潔に両立できるのではないか、という話。 大前提として全く同意なのだけども、今あるテーブルにdeleted_atを足すだけで、過去のレコードを復旧可能なようにしたい＞＜ みたいに思っちゃった僕のような人間が実際に取るべき実装手法は何か、あるいは、それを想定して今やっておくべきテーブル設計はどういうものか！？というのが最後の疑問。 まずUPDATEがなければ、immutableなマスタ、更新ログ、「現時点のビュー」の３テーブルは、例えば次のようになる（PostgreSQLの場合）： -- immutableなマスタ。 create table records ( id serial
論理削除はなぜ「筋が悪い」か
「論理削除が云々について - mike-neckのブログ」を読んで。 データベース設計において、「テーブルの書き換えをするな、immutableなマスタと更新ログによって全てを構成しろ」というこの記事の主張はモデリング論として全く正しい。 だが、残念なことに、ディスクやメモリが貴重な資源だった時代の技術であるRDBは、そのようなモデリングに基づいて設計されたデータベースには必ずしも適していない。 第一の問題は、RDBに対してなされる様々な「更新」（トランザクション）は不定形（どのテーブルをどのように修正するかはアプリケーション依存）だという点。不定形な「更新」を時系列にそってRDBに記録していくのは、設計と並走性の点において困難あるいは煩雑なコーディングが必要になる（というか、そのような「イベント」による「変化」はREDOログに書き、その更新された「状態」をテーブルに反映していくというのが
巨大 Pull Requestを避けるための9つのポイント - Qiita
巨大 Pull Requestの問題 レビューに時間がかかる、疎かになる テストとコードを照らし合わせが大変 本番で問題が起きたときに、問題の切り分けがしにくい masterとの差分を反映する際のレビューが難しくなる 一つのミスが大きなfeatureブランチになるきっかけになることも 大きくなるとmergeに時間がかかり、ますます大きくなる どのようにして大きなPRを避けるか PRが大きくなりそうな時は事前に相談する 作業しているときに、変更点がたくさん必要になったときは早めにレビューアーに相談する 複数人で開発しているときは、しっかり話す時間をとる PRが大きくなる問題は後で変更するのが難しいので、最優先で相談するとよい。近くにいるなら直接相談する。いないときはチャットで相談する。 モデルだけの変更とテストを書く なにか機能の変更がある時に、まずモデルからレビューする 実際にどういう変化
O'reilly の書籍を買ったら，ワンコインでePubゲットできる件 : 人生終わったブログ
3月1 O'reilly の書籍を買ったら，ワンコインでePubゲットできる件 カテゴリ:プログラミング書籍 オライリーの本っていいよね オライリーの本っていいよね！！ 内容が濃いのに読みやすい。読書嫌いの俺にも読めるよ。うれしい！！ いま読み途中なのが『jQuery クックブック』 と 『入門自然言語処理』なんだ。 ただ、「オライリーの本は良質だけど値段が高い」 そんなレビューを良く見るよ。確かに類書よりも値段は高い。 割高に感じちゃうかもしれないよね。 オライリーの本は決して高くない実はオライリーの本は高くないんだ。 良質だから費用対効果が高い、っていうのも理由の１つなんだけど。 でももう１つ長所がある。 それは、 +500円で電子書籍が追加購入できるってこと。 ワンコインでオライリーの電子書籍をゲットしようオライリーの電子書籍を500円でゲットする方法を紹介しちゃうよ。 （もしかした
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
Kazuho's Weblog: 「技術的負債」は避けるべき？ - 割引率を使って考えてみた
「技術的負債」をコントロールする定量評価手法への期待 からの続きです。 ソフトウェアサービス企業における技術責任者の最も重要な仕事のひとつが、エンジニアリングの効率化です。そのためには、サービスの初期開発コストだけでなく、運用コストを織り込んだ上で正しい技術的判断を行っていく必要があります。 「技術的負債」という言葉は、この運用コスト最適化の重要性を指摘する上で、とてもキャッチーなフレーズだと考えられます。しかし、「技術的負債」を産まないように、あるいは負債を早めに返していこうとすると、開発工数が大きくなってしまうという問題もあります。 初期開発コストと運用コストのバランス注1を、どのようにとっていけば良いのでしょう？ 同等の機能を提供する「ソフトA」と「ソフトB」を考えてみます。ソフトAは、初期開発工数が6だが、２年目以降の維持工数が毎年4かかるとします注2。ソフトBは、初期開発工数が1
「技術的負債」をコントロールする定量評価手法への期待
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます＆いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ
テンプレートをDRYにするのは慎重にやったほうがいいですよねというお話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
社内でレビューおじさん業してて書いた内容ですけど守秘する必要ない情報なんでちょっと内容書き換えてオープンアンドシェアーします。 本文 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品（些細な変更されることが多い部品）なので、「同じような部品だから共通化しちゃおう」ってやると失敗することが多いです。 特に気をつけるべきなのは、たとえばコンテンツをランキング形式でテーブルで表示する画面と、新着から順にテーブルで表示する画面があって、このふたつのテーブル部分は一緒だからパーシャルにしちゃおう、みたいなやつです。 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品、というのがここで効いてきて、「新着とランキングは基本的に同じ表示なんですけど、ランキングのほうではランクがアップしたかダウンしたかのアイコンを表示してほしいんですよね〜」とか言われたり、「今見てるページ
関数型プログラミング入門 | POSTD
多くの関数型プログラミングに関する記事が教えてくれるのは、抽象的な関数型のテクニックです。つまり関数合成やパイプライン、高階関数などです。この記事では違います。ここでは、プログラマが毎日書く、命令型で非関数型のコードの例を示し、それを関数型の形式へ書き換えます。 最初のセクションでは、短いデータ変換のループを取り上げ、map関数やreduce関数に書き換えていきます。2つ目のセクションではより長いループを取り上げ、ユニットに分解し、それぞれのユニットを関数型に書き換えます。3つ目のセクションでは、連続した長いデータ変換のループを関数型のパイプラインに分解します。 ここではPythonでの例を取り扱います。というのも多くのプログラマはPythonを読むのは簡単だと思っているからです。多くの例では、mapやreduce、パイプラインなどの多くの言語に共通する機能を例示するため、Python的な
Your Job Is Not to Write Code
Dear Engineers, Your job is not to write code. I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well. But it’s not your job. Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves
今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
グーグル、アイデアからプロトタイプの検証までたった5日で完了する課題解決メソッド「デザインスプリント」を公開 - BRIDGE（ブリッジ）
グーグル、アイデアからプロトタイプの検証までたった5日で完了する課題解決メソッド「デザインスプリント」を公開 Google Venturesが開設したDesign Sprint専用ウェブサイト グーグルのベンチャー投資ファンド部門「Google Ventures（グーグル・ベンチャーズ）」は、2015年1月30日、専用ウェブサイトを開設し、デザインにまつわる独自の課題解決メソッド「デザインスプリント（The Design Sprint）」を公開しました。 デザインスプリントは、ホームオートメーションの開発に取り組むNest Labsやロボット開発企業Savioke、サンフランシスコ発の人気コーヒーショップBlue Bottle Coffeeなど、様々な業種で実践された成果をもとに、スタートアップ企業に向けた“DIYツール”としてまとめられました。 プロトタイプを短期間でつくりあげてユーザー
多くの若きプログラマたちが学ぶべきこと | POSTD
私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン
今年も1月終わったし DCI の話しようか - Qiita
いままで色々 Rails 向けに DCI を実現する gem を作ってきたわけですが(Dicer / BluePrint)、今年もまた新しく考えなおして Rails 向けに DCI を実現する gem を書きました。毎年毎年ほんとよくやりますね。 今年は何気なく作り続けて、いままで活用されていなかった uninclude という gem をついに使って DCI をやってみました。 uninclude にてついては特に解説することもないというか、名は体を表すということで『#unextend や #uninclude を Ruby で使えるようになる』という gem です。Refinements などでも実現可能なのですが、Refinements はファイルごとだったりでスコープがわかりづらくなるので使っていません。 RockMotive 2015年の DCI on Ruby は RockMo
『DCI なんて面倒なだけで Service 使えばいい』への返答 - 鳩舎
NOTE: 最下部に追記があります。 よく言われる話として、 DCI なんて実装が面倒な上に夢の実装の話をしており、現実解としては Service クラスを用いて実装すればシンプルな実装になるのだから、そういったものは必要ないのだ、というご意見への返答です。 こういった批判の文脈の際、 Service クラスというのがどこの Service クラスを指しているのか、が問題なのですが、 DDD における Service ではないように思えるので、おそらく PofEAA などで語られる Service Layer などを指していると思われます(違うならそう言ってください)。 PofEAA における Service Layer(以後、 Service と呼ぶものはこの PofEAA における Service です)はドメインオブジェクトからアプリケーションロジックを切り離すことを主目的としていま
テストコードは、どの程度かけば良いものなの？ | Webシステム開発／教育ソリューションのタイムインターメディア
皆様、Spec(コードベースの単体、機能、結合テスト)書いてますか？ 私はあんまり書いていません。 「テスト書かないとかありえない！」と怒られそうなので一応弁解しておきますが、C0レベルのテストは、そこそこ書いているつもりです。 プロジェクトでカバレッジはXX%以上！(XXの部分は95だったり100!だったりします）という決まりがあるため、書いてます。消極的な理由ですね。 時としてカバレッジを満たすためのテストを書く、という意味の分からない事をしてしまったことは、反省しております。 しかし、C0は所詮C0であり、このレベルのテストをいくら一生懸命書こうが、バグがでるときはでるものなのです。 だからといってC1、C2、またはそれ以上を満たすようなテストを一生懸命かけばバグが無くなるか？という話でもありませんが、バグ発生率が少しは下がるかと思います。 さて、最近お固い業務システムで、そこそこ致
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://plus.appgiga.jp/masatolan/2015/01/23/55150/
