here)技術部モバイル基盤グループのヴァンサン(@vincentisambart)です。今日は最近作ったツール「Dokumi」の話をしようと思います。他部署のエンジニアの仕事をもっと楽にすることが、技術部の重要な目的の1つです。その中で、Dokumiはモバイル開発者のコードレビューの負荷を減らすためのツールです。「毒味」という名前にしたかと言うと、人間がレビューする前に、コードに毒(バグ、不自然なコードなど)が入っているかどうか毒味するツールだからです。別の言葉で言うと、少し進化したCI用のlintツールですね。requestにDokumiをかけます。現在はDokumiはiOSアプリだけに対応してしていますが、今後はAndroidアプリへの対応も考えています。現時点でDokumiは以下のことをやっています。静的解析(Xcodeの「Analyze」機能)をかけます。自動テストを走らせます。コミットされたけどXcodeのバージョンデータしか変わっていないXIB/Storyboardファイルを指摘します。requestにmilestoneが指定されていないとそれを指摘します。静的解析や自動テストを走らせるためにアプリをビルドするので、ビルド中に出ている警告やエラーも同時に拾います。requestのコメントとして投稿します。requestで変わる行であれば、行にコメントを付けます。requestと関係ありそうなものは普通のコメントにまとめて投稿します。requestで変わっていないファイルに出る警告)は無視されます。メリットXcodeのTestやAnalyzeは、開発者が自分自身でかけることができますが、時間かかるし、かけるのを忘れる時もあります。gitに変更を入れるのを忘れることもあります。requestに強制的にかけます。因みにXcodeの静的解析のお陰で人間がレビューしたコードでも不具合や変なコードを見つけることができたのでやってみることをおすすめします。requestにコメントを付けるメリットも大きいと思います。requestの度に自動テストを走らせるのは、以前から行われていました。失敗したテストを知るには、Jenkinsのログのxcodebuildの出力を見るしかなく、簡単ではありませんでした。実は元々Dokumiの結果はウェブページとして整えようと思っていたけれど、良いデザインが思いつかなかったし、わざわざデザイナーに頼んでもな...と思っていたら、単に、普通の人間のレビューと同じようにすればいいだけだと気づきました。困ったことGitHubのAPIを使って実装しようとした時に、特定の行にコメントを付けるには現時点(2015年6月頭)のAPIでは不足しているところがあると気づきました。ファイルの行番号ではなくdiffの中の行番号ですね。requestのコメントに使われているdiffと相違があります:ファイル名変更の対応が違います。新ファイル名の追加になります。変わっている行だけの追加・削除になります。付けるかどうかの違いと同じです。指定できないならどうすればいいのでしょうか。いまDokumiはレポジトリを手元でcloneして、Ruggedというライブラリを使ってdiffを計算します。計算のやり方がGitHubのと違っていれば、ズレが出てくる可能性がありますが、それでも大きな問題にならないでしょう。僕自身も昔からRubyを使っていますし、社内にはRubyエンジニアが多いからです。正規表現を使ってxcodebuildの出力から拾っているだけです。analyzeがビルドディレクトリに生成したplistファイルを見ています。どの環境でも動くようにするにはコストが高いと思いますし、他人が使えないものをオープンソースする意味もあまり感じないですね。実装に関する質問あればお答えします。ソースコードがGitHubにて公開されました。技術基盤や研究開発領...2018-11-15デザインとエンジニアリングをつなげる取り組みこんにちは、Komerco事業部デザイナーの藤井(@kenshir0f)です。...2018-04-18ReactNativeプロジェクトのAndroid環境を整備する投稿開発部の吉田です。使ったセキュリティログ検索基盤の構築サービス特性にあった検索システムの設計戦略クックパッド採用説明会「クックパッドはサービスの作り手を採用したいんです。/*}*/スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。