やってはいけないコードレビュー

トピック「コードレビュー」について

こうならないようにと、気をつけていること

• 規約に従っているか

ツールでやる。最初に規約を提示する、教育する。

規約の後出しダメ絶対

• 好意的に進んで解釈する

初見でわからない構造、説明をきいてすっとはいらない構造

頭を捻ってみて理解できちゃうと、「入出力が合ってるならまぁ良いか」

という気になってしまう。

書いた人も自分も他の人も明日には理解できない可能性があるので、

わかりませ～ん。と馬鹿になるようにしている。

• コードを見ながら仕様を検討

レビュー受ける側にとっては時間の無駄。

コードみてから外部仕様を再検討したい思いに駆られることがある。

この時の検討はたいていおかしなところに着地する。

もしくは、付け焼き刃になって傷口を広げる。

だから別の場所と時間で検討してから、開発してもらう。

• 英語のスペルミスばかりをチェック

スペルミスは当然指摘しますが、そればかりに執着しない

• 不具合修正をレビューしない

変なコードが生まれるのは急場、鉄火場

「時間がなかった」を免罪符にできる場合とできない場合があるので、

時間をかけるべきかどうか、言ってあげるのが大事だと思う。

かといって、独りで書いて独り自分のコードをレビューできるほどに

人間できておらず「まぁよいか」の日々。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

Excelでもっとも使える技

人によって利用頻度が高いメニューや操作は違いますがね。

今すぐ使ってもらえて、今すぐ効果があるのは

• F4　キー　＝　直前の同じ操作を繰り返す。

あとはその人がどういう操作してるか次第でもう１つ出せればいいと思う。

そんなにいくつもいっぺんに操作覚えない、人間は。

ファンタジーと現実の区別がつかないけど病気じゃない

敵の正体が1個体ではなく、邪悪な怨念の複合体それも膨大な。

主人公が立ち向かおうとしてる敵が、見た目とは裏腹に想像を超える存在。

というような場面設定はよくあるかと思う。その、ファンタジーの世界の化物が身近にいることに気づいた。ここ数年、俗世を離れて気を読む修行をしていたことで、普段みえないものが見えるようになってきた。*1

例えば…

• エンタープライズシステムのコード
• なんだかわからない組織文化とか慣習

と、誰もが知ってること。

改めてファンタジーと現実に大差ないなと感じた次第。

ファンタジーを作るのが現実の人だから仕方ないことなんだろうけど。

銀の弾丸をぶちこんで退治してハッピーエンドできないのが現実との違い。

追記

• 右手を左手にするには180度だけ手を回せばよい、という異世界もあるそうだ。

*1:フィクション

TDDのデメリットを整理する－自分のためのメモ－

TDDとはいわゆるテスト駆動開発ではなく、トラブル駆動開発のことです。

テスト駆動開発を実践している方、模索している方、並びに35歳未満の健全な青壮年の方はブラウザの戻るボタンを押して速やかに退場してください。

 

 

 

 

：

 

：

 

概要

トラブル駆動開発 (トラブルくどうかいはつ、trouble-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にコードを書き、それがひと通り動作するとコーダーが納得する程度の実装をとりあえず行った後、共有するリポジトリにコミットし、後工程のテストもしくはそれよりも早いタイミングでの機能間担当者間のマージで発生するエラーを契機に、関係する開発者でコードを見なおして修正する、というサイクルの工程をなんとなくウォータフォール型の工程間に織り交ぜて、工程を推進するすスタイルである。

ウォータフォール型ソフトウェア開発手法の亜流として発生し、「編集して祈る」しかできない哀れな子羊たちを今日も疲弊させている。

 

 

特徴

• VCSを使っていないか、あってもブランチは１本だけである
• 品質を担保するのは常に後工程である
• 品質が評価されるのは納品直前(場合によっては納品後)である
• 暗黙の掟として、不具合は発見した人が対策する
• 開発者はマージが怖いため、ローカルで変更貯めこむ傾向にある
• 変更を貯めこむためさらにマージリスクが大きくなる
• 開発者はローカルでソース管理を新たにやり始めている
• 神に祈ることに既に抵抗がない

 

 

デメリット

• トラブル毎の調査工数が無駄に多くかかる

どのコードも品質が確保されていないため、マージ直前までの他者のコミットのせいなのか、自分のコードのせいなのか、組み合わせ問題なのか、設計の問題なのかわからない。そうすると最小限の正しい所がないために調査範囲が広くなり原因の究明に時間がかかってしまう。

 

• トラブル対応は予定されていない工数、追加の原価消費となる

ウォータフォールのテスト工程だと不具合は想定されるが、トラブルは想定外として計画されないことが多い。計画時はトラブルなどおこらないと楽観的なことが多い。結果的にプロジェクトは赤字になることが多い。

• トラブルは残業対応が原則であり、開発者は疲弊する

トラブルは開発側に起因する遅延となるため、納期の調整は許されない。常に開発者は残業対応が求められる。開発者は自分がババをひきやしないかと、怯えながらSVNの更新をし、えぇいままよとコミットする。

プロジェクト期間中は残業が常態化し、体力と睡眠時間を削がれ、やる気も失っていく。

• コードはさらに汚れていく

時が経てば経つほどに「つぎ」が大きく多くなり、より保守性は失われていく。そしてさらにトラブルの調査がストレスな作業になってゆく

•  原因と責任の所在が不透明

メリットと考える人もいるだろう。この開発手法は全ての人が「頑張っている」。みな遅くまで残業している。時間がかかった…なかなか手がまわらなかった。仕方なかったねで終わってゆく。不具合が起こるのは確率的に当然とする前提からすると、この赤字、納期遅延、品質（機能性保守性）低下の原因がどこにあるのかとても究明しづらい。また、繰り返す可能性が高い。

メリット

• 少なくともコードは統合されていて、ただひとつである
• 統合された物があることに安心感を得られる（まやかしだが）
• プロトタイプ的にお客様に見せることもできる（ここまでできてますよ）

いつでも組み合わせテストをできる、プログラムの出来具合を外部仕様の目線で確認できるということである。これはウォータフォールの下流の組み合わせテスト、システムテスト工程の担当者、開発の最終アウトプットの品質や進捗を把握したいPLにとっては非常に心強く感じるもののようである。対象が早い段階で見えるというのはなんとも頼もしい。

 ：

トラブル駆動から抜けださねばらない。今まで自分とともに開発してきたたみなに大変な苦労をかけてきていたことを謝りたい。こんなダメ手法は俺の代で終わればいい。

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

レガシーコード改善ガイド (Object Oriented SELECTION)

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))

生産性の上げ方を知らない人が多すぎるということか

chikirinさんや、脱社畜さんのブログで反響が大きくなっているようので、自分も日ごろ考えてるところを少し

 「生産性の概念の欠如」がたぶんもっとも深刻
http://d.hatena.ne.jp/Chikirin/20131015

「もしかして日本って、工場（製造部門）以外には、ほんとーに、そういう概念がないのかも」と思えてきた。

そう思う。

製造業の製造部門の生産性向上に貢献しようというコンセプトのベンダーの中ですら、必ずしも全員が生産性を意識していない。それでも、他のホワイトカラーに比べ生産性の意識は高いほうだと思う。普通のサラリーマン会社ですが、なぜ他と違うのかと言うと、お客様や、他部門、競合他社が生産性を上げるのに頑張っている姿を見たり、触れたりすることがあるから。

つまり、並みの組織であってもきっかけがあれば生産性をあげる意識はうまれる。

前向きに捉えて、諦めずに各組織・個人はチャレンジし続ければ良いと思う。

『生産性は上げたほうがよいか？』という質問は、誰にきいても「上げたほうがよいと思う」「重要だと思う」と回答する。『生産性？なにそれ美味しいの？』という人はむしろ少ないと思う。なぜ、意識があるのに生産性をあげないのか、きっかけがあればできるのになぜ実行できないのか、というところが本当に解決すべき問題だと思う。

生産性を上げたら評価がさがるから、残業代を稼げなくなるから、という一部の代弁者の回答は心に残る言葉だが、本当のところは、生産性の上げ方をしらない、だと思う。と、同時に何が障害になっているか知らないことだと思う。

「朝の通勤時間６０分を１０％カイゼンせよ！」

「もちろん毎日だ」

誰もができるか？どうやって？すでに最短時間で通勤してたら？

「ブログの更新頻度２０％あげよ！」

「ただし、文字量とクオリティは変えずにな」

誰もができるか？どうやって？既に質の高い人は？

普段自分が何気なくこなしている動作を改善しようと思うと、一体何が変えられるのか、全く検討がつかないのが普通の人だと思う。

一部のメールマガジンやニュース配信で、ちょっと効率向上といった、情報やアイデアをたびたび目にすることができるし、Lifehackerの記事を眺めると色々なアイデアが転がっている。多数の人が、こういった良いアイデアに触れているはずなのにどうして実行に移せないだろうか。その一つの理由が、自分の業務・作業に当てはまるのか、アイデアが有効かどうかわからないからだと思う。

例えばメールの整理術、一日５０通程度しかメールが来ない人にとっては有効だろうか。既に自分なりの整理術が確立されていて、特に困っていない、時間を取られていると感じていない人が、自分の動作よりも遅いかもしれない方法を、試す勇気と時間があるだろうか。

改善活動の最大の難敵は「今、困ってない」。次点は、「変えたら、何かいいことあるの？」だ。

どんないいことあるのか？変えないと何がやばいか？は、chikirinさんが書いてるような感じで。これはどんどん啓発していくべきだとつくづく思う。

余った時間はよりクリエィティブな仕事や、個人の時間に回せる。そうしてこそイノベーションが生まれ、そうしてこそワークライフバランスが可能になる。

「今、困ってない」という言葉が出る時には、自分の当たり前になっていて、改善対象として気づいていないもの、とっくに改善を無意識に諦めているものが思わぬ効果をあげるということがある。意識外になっている業務から見なおしてみると良いと思う。

また、製造業の現場改善では作業間の切り替わりで発生する「段取りの回数」や「段取り時間」が改善対象にとして着目される。これは各人の業務を見直すのに大きなヒントになると思う。

例えば、頭脳ワークの作業、システムアーキテクトの設計作業に、３０分おきに割り込みをかけると設計の仕上がりが遅くなるのは昔からよく知られていること。現実の工場では、一度止めると温度を上げるまで待たなくてはいけない設備を如何に連続稼働させるか生産計画を決めたり、治具をセットするため時間、物の移動時間までを考慮して道具や設備を配置する。ホワイトカラーの仕事もこのように、如何にアイドル時間と回数を減らせるかという観点で見直すと良いと思う。

誰もがすぐ見直せるのは、メール、もしもしゲーのログイン、SNSタイムラインのチェックあたりだろう。もちろんメール即返信が本当に必要な業務ならそこは改善ポイントではないが、これらに類似して改善できるところは多いと思う。

生産性をあげるといっても色んなアプローチがある

１つは、自分の生産性を上げる方法と、周りの生産性を上げる方法。

• 人に自分のよいやり方を教える/悪いところを指摘する
• 人からよいやり方を教わる/悪いところを指摘してもらう

自分の周囲の状況にあわせて、より望ましいワークライフバランスを達成可能な道がどちらにあるか、見極めたら良いと思う。自分の生産性をあげたらかえって仕事が増えてワークワークバランスになってしまったということがないように...。

生産性をあげてはいけないものもあるということがある

上げる労力に見合うほど上がらないものには向かわないほうがましということ。上げ方を知っている人、よい指導者や指導方法を見つけるようにしたほうがよい。あのグーグルですらなんでもかんでもテスト自動化しているわけではないことからも、これは覚えておいたほうがよい。

なんか内容がだれてきたので、生産性の上げ方として知らなければいけないことをまとめると

自分を知る

• １日や１周間といった中で、何の時間が多いか知る
• 何をされると（自分の中で）生産性が落ちるかを知る

冷静に自己を見つめるのは根気がいるが、これが大前提。

相手を知る

• 他人と自分の仕事をよく見て違いを把握する

なんとなくあの人バリバリやれてるなーという人をスネークしたり、それとなく会話しているとわかってくる。褒めると手の内を晒してくれる人もいるので、そこからたどってみたり。

コミュニケーションの難しさを知る

• 勇気をもって聞く/指摘することの難しさ
• 同行者、先行者がいると進めやすいということを知る

難しいですが、やらないよりましということで覚悟を持ってやる。覚悟がないならやらないほうがよい。ただし関係が悪くならないように言葉は選んで。人を巻き込む場合は率先垂範が原則ということも。

時間がかかることを知る

• 即効性のある改善策はないと知る
• 愚直に、地道に時間をかける

組織が縦割りになって個人に分解され、互いに関心が薄い組織であればあるほど、改善活動の障害が大きくなるし、個々人のタスクが多く時間に追われるようなやり方を容認している組織はどうあっても改善されないということを自覚したら良いと思う。

…

ま、ぶっちゃけて言うと。

自分や自分達が無駄なことをしているという事実に向き合える勇気が必要

冷静に事実受け入れて自己否定ができないといけない。

残業自慢で自己肯定、自慰行為してたら一生改善しませんよっと。

自戒も込めて

...

脱社畜さんところでは生産性向上にインセンティブがないという指摘もあってごもっともと感じたが、そういう組織はそもそもインセンティブを働かせること自体が困難になっているので生産性だけでは語れないかなと。これはこれで別の話題にしよう。

ゆとりの法則 ? 誰も書かなかったプロジェクト管理の誤解

テストから見えてくるグーグルのソフトウェア開発

韓非子 (第1冊) (岩波文庫)

プログラムコードに人生をみた

バージョン管理を導入する前からあるプログラムの話

このプログラムは10年以上の歳月を経て巨大化していた。基本的にソースの中に修正IDが埋め込まれているので「いつの時代の地殻変動」かはわかるようになっている。もちろんそれが何のために何をしているのかの手がかりは少ない、一つのIDが数百行にコメントされているし、IDからわかるのは紋切り型の20語に満たないキーワードだけだ。

使われないコードがたくさんある。

一目ではどこが生きているコードかわからない。長大な関数を#ifdefと#elseで大胆にかつ大量にわけている。もちろん、すべてがこのルールにのっとってるわけじゃない。使われなくなった関数はそのままそこに存在している。

なぜこんな複雑にわかりづらくして行くのだろうかと考えたところ、あるものに似ていることに気が付いた。

人生だ。捨てられない記憶達。ただただ経験(コード)を蓄積し、時々自分の記憶を忘れて似たようなコードをまた蓄積する。要求があれば膨大に蓄積された経験から何かの解決パターンを見つけて回答することができる。

あなたは何ができますか？と聞かれると様々なことができるという。学習して成長できるという。このプログラムも、様々なプロジェクトに関わり経験を自身の内部に溜め込んできたのだろう。

会社には様々なスクラッチブログラムが転がっている。それは大抵は特定の部署の資産ということになっていて、実質それぞれ1,2名の長いこと付き合ってる人に強く依存してることがある。

プログラムはその人達の会社人生の集大成でありナレッジデータベースでもある。コードそのものがリボジトリでありデータベースであるということだ。

私のこの開発作業は、プログラムに手をいれているのではなく、リポジトリを直接編集しているようなものなんだ。そう思ったら途端に寒気がしてきた。

心してかかる次第。

WF型開発はなくならないけど幸せになる方法はあると思う

プログラマの思索様の言葉から

アーキテクチャ設計の作業にもっとアジャイル開発のアイデアを注入できないか

WF型開発であっても、成功プロジェクトの現場では、無意識のうちに並行開発という形で、アジャイル開発のアイデアを相当な部分で実施している場合が多い。
アーキテクチャの構築・検証作業をプロトタイピングという名前で、アジャイル開発に近いことを行なっているのだ。

WF型開発でもアジャイル開発に近いことを部分的に自然にやっているし、アジャイルに向かうのは自然な流れなんだと思う。

開発と単体テスト、部分的な結合と組み合わせの疎通確認、開発の並列化といった感じで、プロジェクトの中の異なる工程と領域のなかでそれぞれアジャイル開発に近いことがあった。

今日は、１点目に少し前にふと気づいてたことがあったので、メモ兼ねて残しておこうと思う。気が向いたら２点目と３点目もメモしておこう。

１．WFの開発と単体テスト

WF型開発でテスト駆動も知らない時期の話だが、品質が高い人とそうでもない人という話題が雑談ででたことがある（ここでいう品質は、単に単体テストの不具合の件数。はっきりした評価軸の話ではない）。品質の高い人は開発工程のスケジュールがやや遅れがちで、それをよく残業でカバーしていた。一方品質の低い人は開発工程のスケジュールは守れているが、予定以上に不具合がでるのでテスト工程で遅れがちであった。

その時の現場では先に第一版として動くものが見えるので、品質がそれほど高くない方が重宝されていたように思う。

品質の高いと言われている方は、IDEでのステップ実行を常にしていたと思う。新調に、コードレベルの目視確認を常にしていて、何かあれば気づいて直していて、いつの間にかC0C1をチェックしている。という感じだった。

WF型の開発では開発工程の後に必ず単体テストの工程があるため、確認済みの事柄についてもチェックリストを作成して消化しなければならない。

この作業はテスト工程としてプロジェクト計画通りだし、品質を保証してくれるかもしれないが、工数としては無駄もあったと思う。開発者にはテスト済みのことをもう一度テストすることの煩わしさと、徒労感があったと思う。

開発時に検証しておくべきこと、チェックリストを作成してテストすべきことを切り分けておけば、彼は残業せずにタスクを終えられたのではないか、と思う。

TDDではテストを軽く再実行できることが必要とされている。現状のWF型開発ではテスト済みのケースに対する再テストのコストがとても高いので、どちらの方法でも再テストは苦痛な作業だ。

テストファースト的な開発として、テストケースやチェックリストを作成してからの開発が実施されるなど、徐々にアジャイルからの文化流入がSIerの開発プロジェクトに見られるようになってきた。それでも、手戻りに悩まされることは変わらない。

現状の最大の問題は手戻りのコストを残業で消化する、ブラックWF開発が染み付いていることだろうと思う。