タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

ProgrammingとDevelopmentとmanagementに関するrydotのブックマーク (7)

  • クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々

    デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒

    クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
  • Martin Fowler's Bliki in Japanese - 生産性は計測不能

    http://www.martinfowler.com/bliki/CannotMeasureProductivity.html 設計手法などのソフトウェアプロセスについて、感情的に議論されているのをよく目にします。しかし、その議論に答えを出すのは不可能です。ソフトウェア産業では、ソフトウェア開発の効果要因を計測する術がないからです。特に、生産性を合理的に計測する方法はありません。 生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。 これに対して何もしなかったわけではありません。コード行で生産性を計測しようと研究をしている人たちがいます。めちゃくちゃムカつきますね。だって言語は違うし、数え方の違いもあるし

  • 効果の高いテストについて考える - gong023の日記

    テストエンジニアという奇異な立場にいる。 普通にプロダクトメンバーの一員だが、プロダクト自体のコードはあまり書かず、品質という観点から良かれと思ったことをする。大体グーグルのテストに載っているSETをロールモデルとしている。 テストから見えてくる グーグルのソフトウェア開発 作者: ジェームズ・ウィテカー,ジェーソン・アーボン,ジェフ・キャローロ,長尾高弘出版社/メーカー: 日経BP社発売日: 2013/05/23メディア: 単行この商品を含むブログ (8件) を見る SWTは、例えばエンジニアがテストを書きやすいようにライブラリを作ったり、テストがリリースのネックにならないように高速化したり、手動テストを支援するようなサポートツールを作ったりするのが役割となる。普通に単体テストも書く。(が、それはあまり理想ではなくて、当はそのコードを書いた人が単体テストも書くべきだ。) しかし、現

    効果の高いテストについて考える - gong023の日記
  • テストを書く - シンデレラは削らない

    http://t-wada.hatenablog.jp/entry/debugging-tests 和田さーん! テスト駆動開発(TDD : Test Driven Development)は、プログラマが自分の不安を克服し、自分が書くコードに自信を持ちながら一歩一歩進んでいくための手法です。不具合の発生は、端的に言えばこれまでの「自信」を揺らがせる事態です。テスト駆動開発者は不具合にどう立ち向かうのでしょうか? やはりテストを書いて立ち向かってゆくのです。 チーム内にテストを書く習慣を持ち込んで三年、最初のうちは工数が増えるだけだ(あるある)、テストを書いても不具合がでるじゃないか(あるある)、システムテストでカバーすればいい(あるある)などという抵抗があり、それでも僕は淡々と雨の日も、晴れの日も、雪の日も、朝も夜も深夜も、終電後のオフィスでも、GW中の人気のないオフィスでも、自動テスト

    テストを書く - シンデレラは削らない
  • いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ

    色んな所で「テスト(ここではユニットテスト)を書かないのは小学生までだよねー」とか、もっと汚い言葉で言われたりするけど、いまだにうちのチームでは自分だけしか書かない現状が悩ましい。 Jenkinsさんが激おこになっても誰も何も反応しない。 もちろん、全部が書けるとも思ってないので、自分が不安なところとか、変更が多く入りそうなところとかを中心に書くようにしてる。一種の精神安定剤みたいなもん。 あるとき、一緒に働いてるエンジニアさん(ここではAさんとしておこう)に「ここ難しそうだから、テスト書いたほうがいいですよ」って話をしたら、「じゃぁ、工数かかっちゃいますね」って言われて結局書いてなかったな。 そうだよ。ユニットテスト書いたら工数かかるよ。それは純然たる事実。でも、再利用できないチェックシートを作ってやるよりもいいと思うんだけどね。しかもこの前に見せてもらったこのチェックシートも運用レベル

    いまだにユニットテストって受け入れられないんだろうな - 個人的なまとめ
  • 作業中断のコスト

    Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。このでは、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

    作業中断のコスト
  • アジャイル開発手法「SCRUM」の真実

    スクラム(SCRUM)という開発手法がある。一時期雑誌をにぎわせたさまざまなアジャイル開発手法群のうちの1つである。日国内で実際の導入事例はないが、米国では提唱者のケン・シュエイバー(Ken Schwaber)氏によって着実に導入実績を積み重ねているという。今回公開する「スクラムワークショップ体験記」は、筆者2名が日人として初めて認定スクラムマスターを授与されたワークショップの様子を報告したものである。 米国のソフトウェア開発業界における独立系コンサルタントの躍進とアジャイル開発手法群の台頭という現象は切っても切り離せないものだ。このことは、XP(eXtreme Programming)の提唱者であるケント・ベック(Kent Beck)氏をはじめ、ソフトウェア開発手法に関する分野の“カリスマ”が日のソフトウェア開発業界に紹介されたことからも記憶に新しい。米国のこのような動きは日にも

    アジャイル開発手法「SCRUM」の真実
  • 1