私のチームは「モダン」になるためにどこから始めるべきですか？
私は比較的新しい開発者で、大学を出たばかりです。大学在学中、そしてその後の求職中に、私の教育には欠けている「近代的な」ソフトウェア開発方法論がたくさんあることに気付きました：ユニットテスト、ロギング、データベースの正規化、アジャイル開発（vs.一般的なアジャイル概念）、コーディングスタイルガイド、リファクタリング、コードレビュー、標準化されたドキュメンテーション手法（または要件）なしなど.
全体として、これが問題であるとは思いませんでした。私は最初の仕事でこれらのアイデアのすべてを受け入れ、仕事でそれらを私に教えることを期待していました。次に、大企業で最初の仕事（フルスタックWeb開発）を取得しましたが、これらのことをしないことに気づきました。実際、私がチームで最も経験が少ないのは、「モダンな」プログラミング手法でチームをスピードアップしようとする試みを先導している人です-そうしないと、プロの自殺が心配です。
最初にロギングソフトウェア（log4J）から始めましたが、すぐに独自のスタイルガイドの作成に移り、それをGoogleスタイルガイドのために放棄しました。その後、Java Web開発では手作業を使用していました-フロントコントローラーを作成したので、Springの採用を推し進めましたが、単体テストもないことに気付きましたが、既にSpringを学習していました...ご覧のように、特に、さらに、私がこれらの方法論を「専門家」として、他の誰にも教えるのに十分な時間を費やすことなく、それらすべてを教えることは困難です。
今日のソフトウェア開発の世界では「期待」されていると思われるこれらすべての手法のうち、自分とチームの両方を圧倒することなく、それらを新しいプレーヤーとしてチームに統合するにはどうすればよいですか？
チームにアジャイルになるように影響を与えるにはどうすればよいですか？ は関連していますが、私はではありませんaskerのようなアジャイル開発者ですここでは、アジャイルよりもはるかに幅広い方法論を検討しています。
馬の前に荷車を置いているように聞こえます。
チームが直面している主な問題は何ですか？それを修正するのに役立つテクノロジーはどれですか？
たとえば、多くのバグ、特に回帰タイプのバグがある場合、ユニットテストが出発点になることがあります。チームに時間がない場合は、おそらくフレームワークが役立ちます（中長期）。人々がお互いのコードを読むことが困難な場合は、スタイリングが役立つことがあります。
あなたが働いているビジネスの目的は、コードを作ることではなく、お金を稼ぐことであることを忘れないでください。
Java？モダン？！あなたは最初のハードルで失敗しました。本当にモダンになり、「プロの自殺」を避けたい場合は、Rustコードを記述している必要があります。もちろん、来週はすべてが変更され、何かを学ぶ必要があります。追いつくために新しい！
または、流行語のテクノロジーや方法論、フレームワーク、またはその他のdu jourを使用しても、機能する高品質の製品を構築したいという事実が変わることはないことを受け入れることができます。適切な出力を正常に生成している場合、アジャイルを使用しなくても問題ありません。もちろん、そうでない場合は、状況を変えたいと思うかもしれませんが、問題が解決する可能性は特にありません。それらは残ります人間の問題これはさまざまな方法で修正できます。
プロの自殺については、自分が何をしているかを理解していて柔軟性がある場合は、言及したことは必要ありません。人々は古い仕事をするための新しい方法を考え出し続け、あなたは常に追いつくでしょう。または、現在の会社が使用しているテクニックに関係なく、単純に使用できます。あなたが会社を変えるとき、あなたは単に彼らが使う技術を学びそして使う。
初心者にはこれらのツールが役に立たないことを忘れて、使用できるすべての新しいツールに夢中になる子供が多すぎます。最初にプラクティスを学びます。経験豊富な開発者になると、「クールな新しいもの」で開発プラクティスを「修正」し始めることができますが、それまでに、それらが現在考えているほど重要ではないことに気付くでしょう。それらが本当に必要な場合にのみ使用されます。
多くの企業はこのように立ち往生しています。一部の開発者の同僚は独学で、正式な背景のない開発者になったことに驚かれるかもしれません。これらの開発者は、単に仕事をするのではなく、新しいスキルを習得して成功するための原動力となるため、多くの場合、仕事が得意です。残念ながら、これは彼らがプログラミングには優れているものの、これらのプラクティスの利点を認識していないことを意味する場合もあります。実際は、これらはベストプラクティスであり、commonプラクティスではありません。 bestはそれらを使用しますが、成功するためのすべての要件ではなく、単に成功を容易にするためのツールにすぎません。
あなたが絶対に正しい、すべてを一度に実装しようとすることは圧倒されるでしょう。あなたはおそらくそれをしようとすることであなた自身（そしておそらくあなたのチーム）を焼き尽くすでしょう、それは新しい方法論/技術を採用するための将来のプッシュをやる気にさせるでしょう。このような状況で行うのに最適なことは、pick oneのことです（ログは、ログなしでバグを見つけるための困難な道のりであり、バグ）、それについてチームに話します。これを単独で実装する必要はありません。チーム（および上司は絶対にこのようなものに参加しなければならない）と賛否両論について話し合い、それを実装する計画を立てることができます。できる限り痛みを伴わないようにする必要があります（覚えていることに加えて、extraコードを今すぐ作成する必要があることを人々に伝えます）行う）。
そしてもう一度言いましょう、上司が確実にバイインするようにしてください。これは重要です。新しいものを実装すると、修正/リリースの速度が遅くなることに気付くでしょう。ポイントは、あなたが前払いして線を節約することです。彼らはこれを理解し、あなたの側にいなければなりません。あなたが彼らを参加させなければ、あなたはせいぜい敗北の戦いを戦っています、そして最悪の場合、彼らはあなたがチームを積極的に妨害していると考えているかもしれません（私にどのように知っているか聞いてください）.
これらのアイテムをテーブルに持ってきたら、チームと話し合い、それらの実装方法を計画し、フォロースルーすることで、2番目、3番目、8番目などがより簡単になります。それだけでなく、提案が実装され、付加価値として認識されると、チームと上司があなたを尊敬する可能性があります。すごい！ただ柔軟性を保つことを忘れないでください。ここでは慣性に逆らっていますが、変更は簡単ではありません。 ゆっくりと準備する小さな変更を行い、できることを確認する進捗状況と獲得した価値を追跡します。新しいプロセスでロギングを実装し、それが3週間でバグを見つける時間を節約するのに役立つ場合は、それについて大事にしてください！事前に正しいことを行うことで、会社がXXXドルを節約したことを誰もが知っていることを確認してください。一方、プッシュバックを受け取ったり、期限が厳しい場合は、問題を強制しないでください。とりあえず、新しい変更スライドをスライドさせて、元に戻ります。チームに望まないことを強制することでチームに勝つことは決してありません。彼らがドロップすることを最初に提案するのは、新しい「追加」の作業（ロギングの作成やフォローなど）であることは確かです。単に「機能させる」のではなく、スタイルガイドを使用します）。
あなたが投稿で私たちに行ったようにあなたが同僚に問題を提示しなかったことを望みます。それはプロの自殺でしょう。
最初の問題は、経験の浅い技術やメソッドを、少し古くなっているかもしれないが「仕事」を終えたプログラマグループに教えようとしていることです。そのバックファイアの可能性は無限であり、おそらくあなたの同僚に多くの喜びをもたらすでしょう。あなた自身とあなたの部門を改善したいが、「先陣」のような用語の使用を避けたいのは興味深く、立派です。心から、そのWordを使用しないでください。
上記の副次的な問題として、いくつかの作業を行っていることを確認してください。私は長い間、独学で自己学習型のプログラマーとして働いており、有望なフレームワークやテクノロジーなどを探索するために、実際の作業を簡単に片付けることができることを知っています。自分のパフォーマンスが期待されるパラメーターの範囲内であることを確認します（いいえ、20時間がSpringの調査に費やしても、その報告が行われなかったとしても誰も気にしません）。
上記のすべてから、教師になることを避けます（実際に十分な経験がある分野/技術に関連している場合を除く）。より中立的なプレゼンテーションは、たとえば自動化されたテストの利点を指摘し、経営者にそれらのプラクティスの長所と短所を研究したい人を選択させます。
これらの「ベストプラクティス」を提示するために、チームにそれらを説明する方法は2つあります。
- 私はそれらがベストプラクティスであると言います、そしてそれで十分です。
- それらは有用であり、問題の解決に役立ちます。
最初の議論を使用して、あなたがチームのボスまたは非常に上級のメンバーでない限り、彼らがあなたに注意を払うことはほとんどありません。そして、「私はそう言っているKnuthからの本を読んだ」または「SEの人はそれを言っている」ことは、印象も引き起こさないでしょう（「彼らはここで働いていないので、彼らはこのITショップにとって何が良いのか本当に知りません。 "）。彼らは彼らの方法、ルーチン、手順、および「多かれ少なかれ」機能するものを持っているので、なぜ変化の努力とリスクを取るのですか？
2番目のアプローチが機能するには、問題が存在するという認識が必要です。そう：
- 自動テストを昼も夜も行わないでください。更新によって一部の機能に問題が発生するまで待ち、チームはそれを修正するために残業してから、自動テストシステムの構築を提案する必要があります。
- コードレビューを求めないでください。 Joeが長期休暇を取り、Joeだけが知っているそのモジュールを変更する必要があるまで待って、Joeのコードを理解しようとしただけでどれだけの時間が失われたかを上司に指摘します。
もちろん、変化はゆっくりで進歩的です（大企業ではさらにそうです）。 5年以内にコードレビューと自動テストを導入するようになった場合は、作業がうまくいったことを祝福する必要があります。しかし、外部の原因による完全な書き直しがない限り、コアを切り替えるファンタジーは忘れてくださいISたとえば、Spring（ Joelは、あなたが生まれる前でさえ、1 ）;その間、せいぜい、重要でないシステムを作成するために、サポートされているプラットフォームのリストにSpringを入れることができました。
エンタープライズITの世界へようこそ。 :-p
1：わかりました、たぶん私は少し老化していますが、多すぎません。
Michael Feathers著の本Working Effectively With Legacy Codeから始めるべきです。本の序文から、「それは絡み合った、不透明な、複雑なシステムを取り、ゆっくり、徐々に、少しずつ、段階的に、それをシンプルでうまく構造化された、うまく設計されたシステムに変えることについてです。」安全なリファクタリングができるように（何かを壊した場合でもわかるように）自動テストから始め、難しいテストを自動テストに組み込むための多くの戦略を取り入れています。これは、まだ開発中のすべてのプロジェクトに役立ちます。基本的な順序を整えたら、プロジェクトが実際にメリットをもたらす他の最新テクノロジーを確認できますが、それらすべてが必要であるとは限りません。
現在のプロジェクトで実際にフレームワークを必要とするのではなく、専門的な理由で新しいフレームワーク（または何か）を学びたい場合は、（自分の時間に）個人的なプロジェクトで使用する必要があります。
ソース管理。
あなたはそれについて言及しませんでした。うまくいけば、それはすでに設置されているからですが、そうでない場合は、そこから始めてください。
ソースコントロールは、病理学的に他の何かを必要とするまれな状況を除いて、最大の対価を持っています。
そして、誰も最初に賛同しなければ、一人で始めることができます。
直接的な回答
他の回答は、より良い実践の採用に関する「メタポイント」を作成しますが、直接関連するいくつかのガイダンスを提供するために、ここにベスト実践の大まかな順序を示します。 （または任意のチーム）採用（最初）：
- ソース管理
- 課題追跡（プロジェクトおよびタスク管理）
- 自動ビルド1
- 自動展開
1非常に関連するプラクティスは、開発または保守している各アプリまたはソフトウェアプロジェクトのビルドおよび開発環境を自動化するか、少なくともdocument設定することです。あなたが（うまくいけば）これをたまに行うか、めったに行わないので、それはあまり役に立ちません。
ほかのすべて
「ユニットテスト、ロギング、データベースの正規化、...リファクタリング、...ドキュメント」など、他のいくつかの優れたプラクティスについて言及していますが、これらはすべてであり、採用する必要があるプラクティスです徐々にそして徐々に。それらのすべてを一度に採用する必要はありません。慎重に注意深く採用することで、おそらくすべてを採用することになります。
上記の4つのプラクティスにより、新しいプラクティスの採用と実験も可能な限り簡単になります。たとえば、ユニットテストを自動ビルドに組み込んだり、ドキュメントを自動デプロイの一部として公開したりできます。
「アジャイル開発、...コーディングスタイルガイド、...コードレビュー、...標準化されたドキュメントメソッド」、およびフレームワーク（Springなど）など、他のプラクティスのいくつかは、本当にオプションであるか、または疑わしい値です。そして、それはあなたが発見したり遭遇したりする可能性のある多くの（ほとんど？）可能な実践に当てはまります。
アジャイル開発は、使用されている他の方法論よりも明らかに優れていません。そして、私を含む多くの人々がそれを使って恐ろしい経験をしました。しかし、多くの人々も本当にそれを気に入っています（またはそれを愛しています）。それを試してみてください！
コーディングスタイルガイドは、特に大規模なプロジェクトや大規模なチームで役立つ場合がありますが、これらのガイドラインを実施することも多くの作業であり、これは、誰がそうしているのか。
コードレビューも非常に役立ちます。同僚にコードのレビューを依頼しましたか？グッドプラクティスを採用するための正式なプロセスは必要ありません。
ドキュメンテーションは素晴らしいです–何かありますか？もしそうなら、あなたのために良いです！ 「標準化された」ドキュメントを作成することで防ぐことができる多くの追加作業に直面していますか？もしそうなら、それはおそらくやりがいのあることです。ただし、ソフトウェアが少数のグループで使用されている場合は、anyのドキュメントは不要です。 （または、ドキュメントをソフトウェアに直接組み込むことができます。それが常に私の好みです。）
フレームワークは...（非常に鋭い）両刃の剣です。ソフトウェアの非コア機能のための、適切にカプセル化され、十分に維持されたソリューションは、そうでない場合は素晴らしいです。 「手書きのフロントコントローラー」が正確に何であるかはわかりませんが、なぜSpringを利用するコードよりも劣っているのかについて明白な説明はありません。これらすべてのコントローラーの共通ロジックを独自の社内フレームワークにカプセル化することを検討しましたか？ Springを採用し、既存のすべてのコードを書き直すことは、莫大なリファクタリング（または、より可能性が高い、書き直し）プロジェクトであり、コードに加えることができる最良の変更ではない可能性があります。 もちろん 使用するソフトウェアのallは記述しないでください–フレームワーク（およびライブラリ）は素晴らしいです！ しかし多分素晴らしい（または良い）Webアプリを作成するためにSpring（または代替）を使用する必要はありません。
欠陥を見つける。欠陥を修正します。修正を表示します。
最初に正規化*を見てみましょう。そして、実際には、最初にそれを採用することをお勧めします。正規化の欠如は、他の方法では存在し得ない実際のバグのあるデータをもたらす可能性が高いためです。残りは、ベストプラクティスが役立つ可能性があるケースですが、「バグAは、ポリシーX "に従っていないことが原因です。正規化されていないデータベースがある場合、データが不整合になる可能性があります。
矛盾するデータの実際のケースを見つけることができるのは良いことです。これで2つのことがわかりました。
データのバグ。
データベーススキーマのバグ。
あなたは実際に最初に2番目のバグを知っていましたが、最初のバグはより簡単に実証可能であり、理論的にはできなかったものではなく、実際の問題を引き起こしているものでもあります。
残念ながら、正規化されていないデータベースの正規化に抵抗する本当の理由の1つは、このようなバグのあるデータをどう処理するかという問題は必ずしも簡単ではないが、実際のバグを発見したことです。
（意図的に一部のデータを非正規化することがある理由があることに注意してください。ルールの知識不足をルールの無知と誤解しないでください。ルックアップの速度を意図的に非正規化したテーブルを正規化すると、賞賛を勝ち取らないでください。ただし、ここでも、正規化されていないテーブルの内容に基づいて非正規化されたテーブルが自動的に作成されない場合でも、問題のある正規化は手続き的に行う必要があります）。
残りについては、彼らが短期的に役立つときに紹介し、後で長期的にそれらを構築する。例えば。ビルドする小さなコードが与えられたら、そのための単体テストを作成します。さらに、修正するバグが与えられた場合は、そのバグのために失敗する単体テストを作成し、バグを修正したときに、バグを解消したときに合格するという事実に言及してください（または修正済みのメールを送信してください）。 、または何でも）。
*ちなみに、あまりモダンではありません。 normalizationと呼ばれnormalizingなどと呼ばれないのは、当時、その話題について-izationを貼るのが話題の冗談だったからです。 Richard NixonのVietnamizationポリシーの名前をからかうことの終わり。
あなたが所属しているチームを見回してください。テスト駆動開発またはデータベースの正規化によって、作成しているソフトウェアの品質が向上したり、人々の生産性が向上したりする証拠はありますか？
それについて開発監督者の一人、または開発の責任者に話してみましたか？本当に非公式のチャットは良いスタートです。あなたの上にいる人たちが同じアイデアを持っていなかったが、ビジネスがそれを許可しないためにそれらを実装できない/実装しないと思うのはなぜですか？
模範を示すことが良い方法だと思います。他の誰かが既に作業を行っており、それを複製する方法を示すことができる場合、人々ははるかに抵抗力が弱くなります。作業中のプロジェクトにTDDを導入します。チームの残りのメンバーまたは他の2、3人にプレゼンテーションを行って、あなたが何をしたかを彼らに見せてもらいます。上司からバイインすることについて@DrewJordanが言ったことは、おそらくあなたが理解しているよりも重要です。
私は穀物に逆らって言うつもりです：あなたの履歴書を少し構築するためにこの仕事に少し時間を費やした後、新しい仕事を見つけてください。 １年くらいを目指そう。多くのことは「流行語」ですが、単体テストの完全な欠如などの問題は1人の開発者にとって扱いにくいものであり、そこで働くプログラマーがテストを望んでいない場合、購入することができず、ポジションを危険にさらすことさえあります。会社であなたを一生懸命だと思わせることで。メンタリングを行うことができる場所にいる必要がありますnot文化を基本的な能力に向けてプッシュしようとしています。
プログラミングパラダイム を改善するための多くの提案がありました。今最もホットな流行語は、アジャイルなプログラミングとオブジェクト指向のようです。またはそうですか？どちらも、わずか5年前の状態と比較して大幅に衰退しています。
導入されている方法論が同じ最終結果を達成しようとしていることはかなり自信があります。エンジニアが十分に優れた最終製品を経済的に生産できるように支援してください。
1960年代に物議を醸したように導入されたパラダイムが1つあります： 構造化プログラミング ：while、for、repeat 、if/then/else、switch/caseステートメントは、頻繁に使用されていたgotoステートメントではなく、デフォルトで受け入れられました。 stilldebates には、gotoが正当に使用されているかどうかについての説明があります。
gotoの使用を最小限に抑えることは良いことだと私は認めますが、すべての良いことと同様に、行き過ぎることも可能です。
あなたはagile方法論を何か肯定的なものとして言及しています。私は約6か月間1つの開発チームに所属しており、意図的に所定のアジャイルレジメンを採用していました。私はそれが何十年も前から啓蒙されたプロジェクト管理方法論のようであることがわかりましたが、すべての名前が変更されています。おそらく、誰かをコミュニケーションするためのアイデアを再バンドルして再販することにより、生計が立てられ、企業は 皇帝の新しい服 を「見る」ことについて気分を良くすることができます。
アジャイルの最も貴重な教訓は、以前から知られていましたが、完成品へのより良い道を見つける柔軟性は良いことであり、その道を見つける能力は上層部だけでなく誰からでも得られるということです。
反ゴトの首謀者であるEdsger Dijkstraの著述から：
プログラミングの技術は、複雑さを整理し、多数を習得し、その粗野な混乱をできるだけ効果的に回避する技術です。
—Dijkstra、in：Dahl、Dijkstra＆Hoare 1972、pg。 6.（6ページを参照 ここ 。）