-
hotchpotch
- 4168
- 0
- 26
- 1
-
- いいね！1
YAMAMOTO Yohei
@yohei
http://t.co/0oPxV3aX を読み返して、そしてそのブクマコメントを読んでいろいろ思うところがあったのでちょっとつぶやいてみます
2011-12-21 06:11:08
YAMAMOTO Yohei
@yohei
まず、テストって言葉は広いからうまくどの「テスト」について話しているのかを切り分けないと混乱しますね。特に開発者テストといわゆる品質保証的なテストとが混乱すると悲劇。そういう意味でTDDって言葉は功罪あったと思う
2011-12-21 06:12:44
YAMAMOTO Yohei
@yohei
僕がブックマークでコメントしたプロセスを強化する方向が楽だからというのは、何か問題が起きたときの対策として、その原因を突き止めてそれが再発しないことをプロセスに落としこむの方が楽だからという意味です
2011-12-21 06:15:31
YAMAMOTO Yohei
@yohei
もちろんプロセスの強化が必要な場合もある。でもそれってものすごく基本的なプロセスが間違っていたとか、ひどいミスが多発した場合に必要なことであって、プロセスの強化だけで何か解決しようとするのは本質的ではないのではないかと感じます。
2011-12-21 06:18:15
YAMAMOTO Yohei
@yohei
ただ、このプロセス強化症候群は潜在的にあるちょうに思う。たとえばドキュメントやソースコードのレビューでも、文書の書き方、コーディングルールばかりの指摘で本質的な指摘がなかなか出なかったりする。文書のフォーマットを定義すると、人はそれに従えばいいと勘違いしてしまうのではないかな。
2011-12-21 06:20:19
YAMAMOTO Yohei
@yohei
文書やソースコードの本当の目的はフォーマットに従うことではない。たとえば設計書であればそのコンポーネントの役割とか外部とのインターフェース、設計思想ややること、やらないことを明確にすることが目的なのです。でもフォーマットがあるとその本質をさぼって文書を書いちゃったりするんだよな
2011-12-21 06:22:55
YAMAMOTO Yohei
@yohei
本当は真っ白な紙を渡して、さあここに自由に設計を書いてくださいといいたいところなのだけれど、それだとあまりに非効率的なのでフォーマットを定める。そしてそのうちそのフォーマットが肥大化し、一人歩きを始めてフォーマットを守ればいいと勘違いされちゃう
2011-12-21 06:24:36
YAMAMOTO Yohei
@yohei
プロセスも一緒で、本質的には各ステップで何を目的にしているのかをはっきりさせなきゃいけないんだけど、時間の経過とともに本来の目的は忘れられ、ただただ重くなったプロセスに従うことを強制されているように担当者が感じるようになってしまう
2011-12-21 06:26:13
YAMAMOTO Yohei
@yohei
この最初はよかったはずの指針が形骸化して負の遺産となり、未来の担当者の足かせになってしまう問題をどうしたら解決できるのかなあとずっと考えていますが、答えがないです。
2011-12-21 06:28:19
YAMAMOTO Yohei
@yohei
人は実力以上のパフォーマンスは出せないので、アウトプットの品質を向上さるのであれば、人にフォーカスしてスキルを伸ばすしかないと思うんだよなあ。プロセスやフォーマットを押し付けても、本当の最低限までしか底上げできないんだし
2011-12-21 06:32:43
YAMAMOTO Yohei
@yohei
あ、そういえば今回のWEB+DB PRESSのクックパッドの特集を読んだんだけど、記事を読む限りクックパッドはこのあたりうまく回っている感がしました。なんていうのかな、経営理念という一貫した行動指針があって、それを貫くためにどう仕事を回すかという意識が徹底されている感じがしました
2011-12-21 06:35:20
YAMAMOTO Yohei
@yohei
同意 / “「品質に厳しい組織で、なぜ品質が劣化するのか？」 - カレーなる辛口Javaな転職日記” http://t.co/wnzz0jiU
2011-12-21 06:41:52
YAMAMOTO Yohei
@yohei
そうなんだよね。レビューするスキルがないのにレビューを義務付けると、ただただ時間が無駄に消費されていくので関係者全員の負荷が増すだけ
2011-12-21 06:42:14
YAMAMOTO Yohei
@yohei
実力以上のアウトプットを求めても出るわけない。素振りを怠ったチームを戦術だけでどうにかしようとして逆ギレしている監督みたいな感じ
2011-12-21 06:43:44
セコン
@hotchpotch
クックパッドは品質について考えるとき、最終的にどこにラインを引くかが「本当にユーザのためになるか」という指針があるので、解りやすいと云えば解りやすいです。
2011-12-21 12:51:36
セコン
@hotchpotch
品質が劣るコードでもプロトタイプや限定リリースなら出して良い、というのもユーザフィードバックを高速に回したいところに繋がってます。そのためのアプリケーションコードで例外が出たらその機能が落ちる仕組みや、できるだけ素早く築ける仕組みは技術で解決できる問題なので作る。
2011-12-21 12:52:25
セコン
@hotchpotch
全体的なコード品質においては、クックパッドの定義としはユーザに価値が届けられるエンジニア＝すぐれたエンジニア、なためコード汚くてもちゃんと価値が届けられれば認められます。コードがすごく綺麗で、ユーザに役に立つ実装を綺麗にこなすことももちろん重要。
2011-12-21 12:54:06
セコン
@hotchpotch
ただ、コードの品質においては僕レベルぐらいには誰でもすぐなれると思ってるので、そこの部分を最低ラインにしたいです、けどなかなか難しいのでその辺考えたり取り組みが好きな人は常時募集してます！！
2011-12-21 12:55:27
セコン
@hotchpotch
クックパッドの開発の考え方については、明後日発売の Web+DB Vol.66 に執筆したので、良かったらどうぞ！ http://t.co/GxjvmWvp
2011-12-21 12:56:36