タグ

2017年1月27日のブックマーク (3件)

  • コードレビューをより効果的にする方法

    ツールに任せることができないどんなことを人間は指摘できるのだろうか? 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか? コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか? 新しいコードでデザインパターンは使用されているだろうか?これらは適切だろうか? コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか?コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか? コードは正しい場所に配置されているだろうか?例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか

    コードレビューをより効果的にする方法
  • PMのためのプロジェクトの壊し方~そのアンチパターン~:30過ぎで5社目でした。:エンジニアライフ

    季節外れのレイアウト変更があり、古いノートを捲っていたら1枚のメモを見つけた。「PMのためのプロジェクトの壊し方」。自分でゆーのもなんですけれど、うまく出来ていたのでコラム用に加筆修正してみた。 ■会議篇 失敗プロジェクトと言ったら会議。切っても切れない。その特徴を挙げてみよう。 長い 多い 開始午前、終了夕方 開始夜、終了深夜 とりあえず招集する 自分のために開く 関係者以外も招集 長いとか、多いとかは当たり前。午前中始まり夕方までとなるマラソン会議もよく行われる。出席者(俗に言うえらい人)都合によっては終業後の開始となり終電までというコースもあり。にもかかわらず(会議で半日以上潰れるのにもかかわらず)1日の予定工数が8時間と計画されていたりして当事者のエンジニアにとっては笑えない事態となる。 問題が起こるととりあえず召集してしまう、されてしまうというのもありがち。何のために呼ばれたかわ

    PMのためのプロジェクトの壊し方~そのアンチパターン~:30過ぎで5社目でした。:エンジニアライフ
  • Codeigniter 2 x Scrutinizer CIでユニットテストを自動化するまで - Qiita

    この記事はCodeIgniter Advent Calendar 2016の16日目です。 概要 業務でレガシーなPHPアプリケーションを運用しており、改善のためにScrutinizer CIを導入しています。 Scrutinizer CIはソースコードの静的解析がメインの機能ですが、ユニットテストの実行もサポートしており、一番安いベーシックプランから利用できます。 導入までに何箇所か躓いたので、備忘録のために残します。 前提 GitHubでコードを管理している Scrutinizer CIにリポジトリを登録している Codeigniter 2.0.3を利用している CIUnitをインストール CIUnitはCodeigniterでPHPUnitを使うためのツールです。 以下のURLにCodeigniter 2.0.3へのCIUnitのインストール方法が詳しく説明されています。 http:

    Codeigniter 2 x Scrutinizer CIでユニットテストを自動化するまで - Qiita