コード品質向上のテクニック：第60回 出る杭を「ひっぱたく」な
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 60 回です。 LINEヤフー社内には、高い開発生産性を維持するための Review Committee という活動があります。ここで集まった知見を、Weekly Report と称して毎週社内に共有しており、その一部を本ブログ上でも公開しています。（Weekly Report の詳細については、過去の記事一覧を参照してください） 出る杭を「ひっぱたく」な 以下の compressFile 関数は、その名の通り、指定されたファイルを圧縮する関数です。 fun compressFile(...) { try { val workingDirectory = createDirectory(...) val fileToCom
バグの重さを定量化したら話が早い - Qiita
バグ管理にまつわる困りごと 検出したバグを報告したは良いけど、その先の判断が役割によって意見が割れることってよくありますよね！ 優先度が高いと思ってたのに、「このフェーズでは対応しない」ってなっちゃった…大丈夫かな？？ 「ユーザーさんが困るのでは」って訴えたけど、本当にそうかな？？ そもそも、QAチームで検出したこのバグ、プロジェクトにとってどの程度のインパクトになるんだろう？？ バグが溜まりすぎてどこから修正すればいいか分からない！ こうなる原因は、プロジェクトや製品にとって何が大事なのか「認識が合っていないこと」です。 もっと深掘りすると品質の曖昧さ（主観的で相対的で変化する）が要因なのですが、それはまたいずれ別の記事で（書けたら書く）。 そして、この認識を揃えるためには手間ヒマをかけたチームビルディングが必要だったりします。 ……とはいえ、いま困ってるんだよなぁ。という過去の自分にオ
ブラックボックスデバッグ
はじめに デバッグというとデバッガを使ったりprint文を挿入するのが一般的です。しかし、現実にはそういった手法を取れない環境でデバッグする必要があることもあります。 例えば私の仕事はLSIの設計ですが、製造されたLSIの動作中に内部を見ることは当然できません。もし何らかの不具合が発生した場合、内部を観測することなくデバッグする必要があります。 こういったデバッグ手法をここではブラックボックステストにならって「ブラックボックスデバッグ」と呼ぶことにします。ブラックボックスデバッグはLSI固有の技法ではありません。例えばソフトウェアでもデバッガのアタッチやprint文の挿入で状態が変わってバグが再現しなくなることはあります。また大規模なネットワークインフラのデバッグでは対象が大きすぎて、実質的に詳細を観測できないこともあるかもしれません。 このようなブラックボックスデバッグは（おそらくドメイ
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって間
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売
マーチン・ファウラー氏の新著「リファクタリング 2nd Edition」が完成、ほぼ全面的な刷新。日本でも11月22日発売 マーチン・ファウラー氏が約2年を費やして執筆してきた新著「リファクタリング 2nd Edition」が完成し、日本のAmazon.comなどで予約が始まりました。発売日は11月22日と表示されています（下記の表紙画像からもAmazon.comへリンクしています。記事執筆時点でのAmazon.comでの販売価格は7279円）。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変えずに、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングの意義や方法論をはじめて系統的に解説し、普及に大きな貢献を果たした
Repositoryパターンのアンチパターン - Qiita
よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
読みやすいコードってどんなものか考えてみた -抽象化と名前重要- - tumblr
あらすじ 人の綺麗なコードを読みまくると自分のコードも綺麗になっていくのに、イケメンを見続けても僕の顔が良くならないのは何故なの?? 2012-11-30 19:41:20 via web 今まであまり人のコードを読む習慣というか機会というかがあまりなかったのですが、最近になって、デスクの上がヨドバシのiMac売り場みたいと(僕の中で)話題沸騰中の@mitukiiiさんのコードを読む事があり、この人がまたすごく綺麗でスタイリッシュなコードを書くわけで、その時に、綺麗なコードというのはこういう感じに書くものなのかと結構な衝撃を受けたわけです。 またこれも最近なのですが、別の機会で、なんと言いますか、1つの関数が数千行あったり、しかもその内の大部分が共通処理として括り出せるような恐らくはコピペされたであろう部分が大量に入っていたりまぁ不可解な部分の多い、言うなればイケメンを見続けた僕みたいな、
米国人からコーディングについての怒りのメールを頂戴した - その手の平は尻もつかめるさ
"米国人からコーディングについての怒りのメールを頂戴した" の補足 - その手の平は尻もつかめるさ ↑の方で補足いたしました。(2012.09.04 追記) 最近、英語のメールでよく怒られます。moznion です。 海を隔てて共同作業しているアメリカ人から、僕のコーディングについてお叱りのメールを頂いたので、 自戒の念を込めて邦訳して記します。 書いてあることは「当然」とも言うべき内容ですが、僕はその「当然」も守れていなかったのかぁ〜と反省。 以下、邦訳(意訳)です。 1. 郷に入っては郷に従え 既にソースコードが存在しているって事は、そこには同時にコーディングスタイルも存在しているってことだ。 その既存のソースコードに手を加える場合、別のコーディングスタイルを導入してはならない。 もし君がバックエンドのソースコードを弄っているなら、バックエンドのコーディングスタイルで記述するんだ。 フ
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
エラー処理を書いてはいけない
エラー処理を書いてはいけない田中英行 tanaka.hideyuki@gmail.com 2011/12/08 @PFIセミナー 自己紹介田中英行 (@tanakh, http://tanakh.jp) PFI社でプログラマやってますJubatuspficommon検索エンジンのコアエンジンHaskell愛好家msgpack / rpc / idlpeggy (パーザジェネレータ & QQ w/ AQ)Shu-thing (シューティングゲーム) / (Monadius メンテナ)今気になるパッケージは monad-controlLearn you a Haskell 鋭意翻訳中 （春頃発売予定） エラー処理を書いてはいけない本日の概要エラー処理を抽象化しようというお話です 現在のエラー処理の抱える問題どのように解決するのか実際の例エラーは処理しなければならない エラー処理を書いてはいけな
Book: Debug Hacks
TOPICS Hacks , Programming , Linux , Ruby 発行年月日 2009年04月 PRINT LENGTH 424 ISBN 978-4-87311-404-0 FORMAT PDF ミラクル・リナックス株式会社の精鋭エンジニアたちが、長年のLinuxカーネル開発の経験で培ったデバッグテクニックを詳解。こころがまえから、準備、必要な知識、バグの原因をすばやく特定し修正するために便利なテクニックとツール、高度なデバッグ技まで惜しみなく披露します。多くの事例に基づいた実際的実用的な技が満載です。効率良くかつクオリティーの高い開発のために必須の一冊です。 Debug Hacks推薦の言葉 プログラムにはバグが付き物です。バグは人間の予想を超えたところからやってきます。世界最初のバグは、リレー式計算機の中にまぎれこんだ蛾だったそうです。あわれリレーの間に挟まれた蛾に
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
会話によるバグ解決:Geekなぺーじ
私にとっては、バグを解決する最短の手段は、そのバグについて語る事だと思われます。 バグの相談を他人にするときに以下のような会話になることがあります。 ちょっと見てください ここが変になるんですが、心当たりないですか？ この変数の数値が期待していた値になってくれなくて、ここで落ちる 変ですよね？ あ！ 初期化し忘れました！ (自己解決) 結局相談された相手は、ぽかーんと座って終わりになります。 相手に説明するには、順序だててバグ内容を頭の中で再構築する必要があります。 その考察を行っている最中に勝手に矛盾点が頭の中に湧いてきます。 プログラミングをしていて悩んできたら、一人で悩まずに誰かと話せると解決も早くなるだろうと思います。 ただし、問題点もあります。 他人の時間を消費してしまうことです。 そのため、この技を使いすぎると嫌がられるという諸刃の剣です。 また、フリーランスなどの場合は、一人
膨大なAjax,Javascriptをコピペで使えるサイトだけど英語。だったら英語サイトを７０％くらい使えるようになるYamada式翻訳でいきましょう。*ホームページを作る人のネタ帳
TOP› WEBの小技色々› 膨大なAjax,Javascriptをコピペで使えるサイトだけど英語。だったら英語サイトを７０％くらい使えるようになるYamada式翻訳でいきましょう。
論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記
僕は、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことができる。その結果、多い月で 10 万行 / 月くらいである。なお、言語は書くソフトウェアの性質上、大半が C 言語である。 また、プログラミングにはバグが付き物だが、ここ 2、3 年の間は、発生するバグの数を極めて少なく保つことに成功している。 とても大きく複雑で、かつレイヤ的に OS に近い処理をたくさんやるプログラムを書く場合は、プログラミングをするときでも、事前の設計が極めて重要となる。設計をうまく行わないと、後になって全面的に書き直しをしないといけなくなったり、パフォーマンスが低下したりする原因となり、開発者の苦痛の原因となる。 当然のことながら、これまで書いたいくつかの大きく複雑といえるソフトウェアの大半の設計も、自分で行った。いかなる場合でも、設計は、最初の 1 回目で確定
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一緒に使うことが多い値は別クラスにしよう（Data Clumps）/data_clumps_is_useful
Code Smellsの Primitive Obsession に気を付けて設計する/Designing-with-Code-Smells-Primitive-Obsession
http://blk.jp/archives/765
GitHub Flow (Japanese translation)
