新しい現場にjoinする。私はこの「ほぼコピペ」というものに大変な闇を負わされてしまいました。簡単に経緯を書くと以下のような感じです。規模のプロジェクトがあった。そのプロジェクトはメンバーに恵まれず、中核を担うプロパー社員は数人だった。私の担当はデータベースと全文検索エンジンの設計・実装のみだった。あるチームで品質の悪いコードが書かれていた。(レビューする時間も無く・・・)あちこちで悪いコードがあったが、ギリギリ納期に間に合い、利益も結構出た。保守フェーズになった。「ほぼコピペ」がまかり通っても問題にならなかった。私は他のプロジェクトに移動し、暫くそのプロジェクトから離れた。そのプロジェクトは派遣社員が2〜3名で回すようになった。その体制が始まってから2年程度経過し、派遣社員のメンバーが入れ替わったりして人員不足により私が戻ってきた。そのサイトで中核となる機能でバグが見つかった。その中核機能は低スキルな人によって低品質なコードが書かれ、保守フェーズの「ほぼコピペ戦隊」の人たちによってその低品質コードが大量量産された事が判明した。バグをいざ直そうと思ったら修正箇所が40ケースくらいあった。リファクタするのはもう手遅れなレベルの作り込みで、無理ゲーだった。リファクタを諦め、全40ケース全てのユニットテストを他プロジェクトを沢山掛け持ちしながら1ヶ月かけてバリっと書き、「結果だけ」問題ない状態を作り上げた。ク◯みたいなコードが目茶苦茶な量を量産されていて、泡吹いて倒れるかと思いました。コピペ戦隊恐るべし・・・どの辺が問題だったか保守フェーズで派遣社員のみでチームが構成されていて、プロパーに開発に関する相談をするきっかけが無かったかもしれない。リスクを負いたくない・負えない(派遣社員だから?)という気持ちが強すぎるあまり、リファクタを極度に恐れ、ほぼコピペしかできない状況だった。リファクタするスキルが無かった。要件を満たす実装をする事だけで手一杯だった。(当然低品質)保守フェーズの当事者達は「このコードは問題がある」事に気づいていた人もいました。(問題に気づかないレベルの人もいます)しかし彼らは現状を改善する事はできませんでした。リファクタしなかったのかの理由を聞くと、以下の答えが返ってきました。「時間が無かったので既存のコードを参考にコピペするしかありませんでした。「どうリファクタしていいか解りませんでした。「相談する相手もいなかったししょうがなかった。「他プロジェクトとの掛け持ちでリファクタどころではなかったです。要は「時間とスキルが足りないからコピペするしか無かった」という事です。それだけでは無いようでした。保守フェーズに入社2〜3年目のプロパー社員が実はいたからです。彼もまた「既存のコードを参考に〜」と語っていたので、結局はリファクタをするきっかけを作り出す事はできませんでした。プロパー社員であるにも関わらず、です。時間が足りなくなるのかこれは私の周辺の場合のケースですが、他プロジェクトの掛け持ちが多いためです。プロパー社員なら2〜5件、派遣社員なら1〜3件くらいが平均です。私が最も酷い時は7プロジェクトのかけもちで、1日1時間毎に違うプロジェクトをやっていた時期もありました。掛け持ち以外では、単にスキルの問題で、速く上手く設計・実装できないから時間が足りないケースもありました。スキルが足りなくなるのかスキル不足系の人を私が見てきた感じでは、「コピペばかりで自分発の新規コードが極端に少ない」場合がほとんどであるように見えました。そこでそういう傾向が見られる人に何故新規コード書かないの?と聞いてみたところ、以下の答えが返ってきました。「既存コードを参考にした方が確実だから。「他プロジェクトとの掛け持ちで時間が無いから。「自分にはそういう権限は無い。「権限が無い」と言った方に「では権限を与えます。」と言ったところ、「実は◯◯の経験が無いので、新規のコードが書けません・・・」と返ってきました。「権限が無い」というのは実は自分を守るための口実だったようでした。「既存コード参考にした方が確実」と言った方に、「では既存コードを無視していいので、あなたが考える最高のコードを書いて下さい。」と言ったところ、彼は黙りこんでしまいました。聞いてみると、実は「新規にコードを書く自信・スキルが無い」事が解りました。結局これも自分を守るための口実でした。皆リスクを恐れるあまり、守りに入ってしまっていたわけです。フルアーマーでシールドガチガチの防御態勢になって硬直していたのですね。元にしたコードが5年前に書かれたコードの場合、5年前の技術水準と全く同じレベルのコードを書いている事になりますね。IT業界で5年といったら相当な技術革新が進みます。様々なナレッジも蓄積され、効率化が進む筈です。昔の水準のコードを量産します。するとどうでしょう?あなたは現代の人なのに、数年前の古い水準のままのコードを書き、効率化も図っていません。1年経っても2年経っても変わりません。普通に考えると、「年齢を重ねた分だけ何かが向上していないといけない」ので、何も進歩が無い状態では評価が下がる、ボーナスが減る、給料が下がる、単価が下がるという結果が待っていると思われます。それだけではなく、新規に何かを生み出すきっかけも極端に少なくなるので、「参考にするものが無いと何も始められなくなる」状態になってしまい、永遠にサポート約に甘んじるしかなくなってしまいます。その状態が許される期間はそう長くないので、それなりの年齢になった時、相応の結果がふりかかるでしょう。「ほぼコピペ」は最初は数が少ないので問題が表面化し難いのですが、コピペ数が増えるにつれ、「あ、これメンテ無理だわ」「誰だよこのク◯コード書いたクズ野郎は!」という負の感情が大きくなります。徐々に文句が増えていく現場コピペ戦隊によって荒らし尽くされた現場に、新規参入した人は皆口をそろえて不満を吐き出します。その人達も「ほぼコピペ」を右に倣え?で始めてしまいます。不満を言っておきながら、自分でその不満なコードを量産するというダブルスタンダードを始めてしまう、おかしな現場が出来上がってしまいました。CIすら導入せず、ひたすらお手製シェルスクリプトを手動実行してデプロイする毎日。それについて不満たらたらなのに一向に自動化しようともしない。ソースコードの問題の改善もしようともせず、ひたすら防御に徹して自分を守り、最後は壊れるという悪循環に陥っていました。最後に待つものはそして最後に待つものは、静かな終わり、です。コピペによって量産されたコードのメンテが限界に達し、メンテコストの採算が合わなくなり、状況を改善しようという者も現れにくくなり、硬直せざるを得ない状況が続き、顧客から見放され、そのプロジェクトはゆっくりと終わりを迎えます。無茶なりファクタは避けるリファクタするにせよ、テストが必要になりますね。リファクタすると影響範囲が広いなら、テストが可能か、ユニットテストが存在しているか、等を考慮する必要があります。現実的にそれらが難しいなら、根本的なリファクタは諦め、ユニットテストを書くだけでも改善に繋がります。どの程度の粒度でユニットテストを書くかは宗教論争になりそうなので明言しませんが、私は少なくとも中核機能は守られ、ユーティリティー系は引数の網羅パターンは欲しいなと思っています。雑感ちなみにこのお話は、「たった1行のコードの変更をするのに申請用紙に沢山のハンコが必要」だとか「sshも許されない現場」みたいな、極限の環境の話ではありません。逆で、「現状が改善するならバシバシやっていこう」「リーダーがOKといえば大抵の事は許される」「むしろもっと改善しろ」という、非常に柔軟で緩い環境で起きた話です。色々な闇を見てきた私ですが、硬直したメンバーを導いていける人が一人でもいる場合、解決に向かっていく場合が多いように思えました。率先してリファクタの設計・実装していくリーダーがいるのが最善ですが、設計・実装はしないけど「メンテコストが上がらないように極力重複コードを書かないようにしましょう」と指示するだけでも、状況がよくなっていきます。結局のところ、膠着したメンバーも何かきっかけがあれば変わる事ができるので、きっかけを与える事が重要だと思います。少なくとも私の周辺環境では、「悪くない環境であるにも関わらず、自発的に膠着しようとする」現象が起きているので、きっかけ作りは重要だと思います。最悪なのは「導く人が一人もいない」状況です。要件と納期だけが延々と降ってくるだけで、リファクタの指針を決める人・実行に移す人がおらず、コピペ戦隊を生み出してしまうのは絶対に避けたいですね。状況を改善するきっかけが生み出せない、生み出したくても生み出せなくなり、皆諦めムードでお通夜状態になってしまったら、相当危険な状態であると言えるでしょう。コピペだけでなく、「標準◯◯」とかいう設計というか、手法?も私はあまり好きではありません。最初は「おお!これ見れば大体問題無いな!」と感じるのですが、徐々に誰もその標準が正しいのかを考えなくなります。「標準◯◯」を延々とメンテするようなチームを存続する事も難しいので、コスト的にそれはメンテされない場合が多く、徐々に使い物にならなくなります。すると「標準◯◯」はフォークされ、徐々に各所で別の何かが生まれます。Requestされる事もなく、結局は狭い範囲で共有されるだけのものに成り下がる場合がほとんどです。Requestされてmasterにマージされて改善されていくフローが成功している環境を見た事が無いので、「標準◯◯」は信用していません。ほとんどの場合、単に思考停止に陥っているだけのように思えました。した思考停止に陥る罠は沢山あるので、常に「今やってる事は本当に正しいのか?」を考えなくてはならないといけません。それに加え、納期と相談しつつ、目先のリスク回避のためにコピペを量産して後々の負の遺産に変貌させない努力もすべきだと思っています。Capitanに対...もうこれだけでいいんじゃないかな2015-08-29JDK1.5以上で最近のeclipseのWTPにtomcat6の動的webプロジェクトを追加する実はserversにtomcat6を追加する方法、あるんですよこれが。週間)昔は業務系SIer、今はベンチャー企業でプログラムを書いています。INFILEを実行できるようにするmacのAutomatorでhomebrewのコマンドをFinderのサービスから実行できるようにするReactオススメ書籍React自体の基礎、AtomicDesignの適用、CSSの運用手法の歴史的な経緯とメリットデメリット、Reduxの基礎、redux-sagaによる非同期処理、サーバサイドレンダリング、テスト、lint、を学ぶ事ができます。単行本(ソフトカバー)この商品を含むブログを見るAngularオススメ書籍Angularを学ぶなら絶対以下がおすすめです!バインディング、ディレクティブ、パイプ、フォーム、コンポーネント、サービス、ルーティング、httpClientによる非同期httpリクエスト、テスト、angular-cli、を非常に丁寧な説明で網羅的に解説しています。大型本この商品を含むブログを見るSEOオススメ書籍SEOを学ぶなら絶対以下がおすすめです!クローラに対して何をどうすればサイトの巡回効率・速度を上げる事ができるのか、どういったマークアップをする事が標準仕様なのか。巷に溢れる業者による経験則に基づくオレオレSEO情報は一切無く、全てGoogle等のオフィシャルな情報に基づいて何をすべきか、どんな手段があるのかを解説されています。プログラマな私が業務で行った施策が多く書かれており、プログラマ寄りで高度な内容となっており、巷のビギナー向けの曖昧な情報集とは一線を画しています。Amazonアソシエイト・プログラムの参加者です。reserved.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。