私は比較的新しいデベロッパーで、大学の新人です。大学在学中およびその後の求職中に、ユニットテスト、ロギング、データベースの正規化、アジャイル開発（一般的なアジャイルコンセプト）、コーディングスタイルに欠けている多くの「最新の」ソフトウェア開発方法があることに気付きました。ガイド、リファクタリング、コードレビュー、標準化されたドキュメント化方法（または要件）などもありません。

全体として、これが問題だとは思いませんでした。私は私の最初の仕事がこれらすべてのアイデアを受け入れ、仕事で私にそれらを教えることを期待していました。それから私は大企業で私の最初の仕事（フルスタックWeb開発）を得ました、そして、私は我々がこれらのことのどれもしないことに気付きました。実際、チームで最も経験の浅い私は、「最新の」プログラミング技術でチームをスピードアップさせようと試みている先駆者です。

最初にロギングソフトウェア（log4J）から始めましたが、すぐに独自のスタイルガイドの作成に移り、それをGoogleスタイルガイドのために放棄しました。 Springの採用-しかし、ユニットテストもなかったことに気付きましたが、私はすでにSpringを学習していました...そしてご覧のように、特に通常の開発作業と組み合わせると、圧倒的に速くなります。さらに、これらの方法論の中で「専門家」になって、他の誰かに教えるのに十分な「専門家」になるのは難しいです。

今日のソフトウェア開発の世界では「期待される」と思われるこれらのテクニックのうち、自分とチームの両方を圧倒することなく、それらを新しいプレーヤーとしてチームに統合するにはどうすればよいですか。

どうすればチームに影響力を与えてアジャイルになれますか？関連していますが、私はここの質問者のようなアジャイル開発者ではなく、アジャイルよりもはるかに広範な方法論のセットを探しています。

馬の前にカートを置いているように聞こえます。

あなたのチームが直面している主要な問題は何ですか？また、どのテクノロジーがそれを修正するのに役立ちますか？

たとえば、多くのバグ、特に回帰タイプのバグがある場合、単体テストが出発点になる場合があります。チームに時間が足りない場合は、フレームワークが役立つ場合があります（中長期）。人々が互いのコードを読むのが困難な場合、スタイリングが役に立つかもしれません。

あなたが働くビジネスの目的は、コードを作ることではなく、お金を稼ぐことです。

Java？モダン？！最初のハードルで失敗しました。本当にモダンになり、「プロの自殺」を避けたいなら、Rustコードを書かなければなりません。もちろん、来週、それはすべて変化します、そして、あなたは遅れずについていくためにさらに何かを学ぶ必要があります！

それとも、あなたは流行語の技術や方法論やフレームワークのない量または任意の他のことを受け入れることができる今はやりのはあなたが仕事品質の製品を構築したいという事実を変更しません。適切な出力を正常に生成できれば、アジャイルを使用しなくても問題ありません。もちろん、あなたがそうでないなら、あなたは物事を変えたいかもしれませんが、チャンスは問題を解決する特定の習慣ではないでしょう。それらは、さまざまな方法で修正できる人間の問題のままです。

専門的な自殺に関しては、自分が何をしていて、柔軟であるかを知っていれば、言及したことは一切必要ありません。人々は古い仕事をする新しい方法を考え出し続け、あなたは常に追いつくでしょう。または、現在の会社が使用している手法に関係なく、単に使用することができます。会社を変えるとき、あなたは彼らが使用する技術を単に学び、使用します。

あまりにも多くの子供たちは、使用できるすべての新しいツールに夢中になり、初心者の手にはこれらのツールが役に立たないことを忘れています。最初に実践を学び、経験豊富な開発者になると、「クールな新しいもの」で開発実践を「修正」し始めることができますが、それまでに、それらが現在考えているほど重要ではないことに気付くでしょう。本当に必要なときにのみ使用します。

多くの企業はこのように立ち往生しています。一部の開発者の同僚は独学であり、正式なバックグラウンドをまったく持たない開発者になったことに驚くかもしれません。これらの開発者は、単に仕事をするのではなく、新しいスキルを学び、成功するように駆り立てられるので、多くの場合、仕事で優れています。残念ながら、これは、プログラミングには優れているものの、これらのプラクティスの利点を認識していない可能性があることも意味します。実際のところ、これらはベストプラクティスであり、一般的なプラクティスではありません。最高はそれらを使用するが、彼らが成功するためにすべての要件ではありませんが、彼らは単に成功を容易にするためのツールです。

あなたは絶対に正しいです、それはすべてを一度に実装しようとすると圧倒されます。おそらくあなたは（そしておそらくあなたのチームも）それを試みて燃え尽きるでしょう。これは、新しい方法論/技術を採用する将来の推進力をやる気にさせるでしょう。このような状況で行うのに最適なことは、いずれかを選択することです（ログを記録せずにバグを見つける前におそらく困難な道を歩んでいるので、ログはおそらく良いスタートです。バグがあるはずです）、チームにそれについて話します。これを単独で実装する必要はありません。賛否両論についてチーム（および上司、このようなものに必ず参加している必要があります）と話し合い、それを実装する計画を練ります。できる限り苦痛を感じないようにする必要があります（覚えているのは、既に行っていることに加えて、余分なコードを記述する必要があることを人々に伝えていることを思い出してください）。

そして、もう一度言いましょう。あなたの上司がに買収されたことを確認してください。これは非常に重要です。新しいものを実装すると、修正/リリースの速度が低下することがわかるでしょう。ポイントは、ラインを節約するために前払いしていることです。彼らはこれを理解し、あなたの側にいなければなりません。あなたが彼らを乗せなければ、あなたはせいぜい負けた戦いと戦っています、そして、最悪の場合、彼らはあなたを積極的にチームを妨害しているとみなすかもしれません（私が知っている方法を聞いてください）。

これらのアイテムをテーブルに持ち込み、チームと話し合い、それらの実装方法を計画し、2番目、3番目、8番目などを簡単に実行します。それだけでなく、あなたの提案が実装され、付加価値として認識されるため、チームと上司があなたを尊敬する可能性があります。すばらしいです！柔軟性を維持するようにしてください。ここで慣性に逆らって、変更は簡単ではありません。ゆっくり小さくする準備をしてください変更し、進捗状況と獲得した価値を追跡できることを確認します。新しいプロセスでロギングを実装し、3週間でバグを発見する時間を節約するのに役立つなら、大いにそれを作ってください！事前に正しいことをすることで、会社が$ XXXを節約したことを全員が知っていることを確認してください。一方、プッシュバックが発生したり、締め切りが厳しい場合は、問題を強要しないでください。しばらくの間、新しい変更をスライドさせ、円を描くようにします。チームにやりたくないことを強制することで勝つことは決してありません。彼らがドロップすることを最初に提案するのは、新しい「余分な」作業（ログの書き込み、フォローなど）単に「動作させる」のではなく、スタイルガイド）。

あなたがあなたの投稿で私たちにしたように、あなたが同僚に問題を提示していないことを願っています。それはプロの自殺でしょう。

最初の問題は、あなたが経験のない技術や方法を、少し時代遅れかもしれないが「仕事をする」プログラマのグループに教えようとしていることです。その逆火の可能性は無限であり、おそらく同僚に多くの喜びをもたらすでしょう。自分自身と自分の部署を改善したいが、「先頭に立って」などの用語を使用しないことは興味深いことです。心から、その言葉を使用しないでください。

上記の副次的な問題として、作業を行っていることを確認してください。私は孤独で自己学習型のプログラマーとして長い間働いてきましたが、有望なフレームワークやテクノロジーなどを探求するために実際の作業を脇に置くのがいかに簡単かを知っています。あなたのパフォーマンスが期待されるパラメータの範囲内であることを確認してください（いいえ、彼らがあなたに尋ねたという報告があれば、Springの調査に20時間を費やすことに誰も気にしません）。

上記のすべてから、教師になることは避けてください（実際に十分な経験がある分野/技術に関連している場合を除く）。より中立的なプレゼンテーションでは、たとえば自動化されたテストの利点を指摘し、管理者がそれらのプラクティスの長所と短所を調査する対象を選択できるようにします。

さて、これらの「ベストプラクティス」を提示するために、チームにそれらを説明する2つの方法があります。

• なぜなら、それらはベストプラクティスであり、それで十分だからです。
• それらは有用であり、問​​題の解決に役立つからです。

最初の引数を使用すると、あなたが上司またはチームの非常に上級のメンバーでない限り、彼らがあなたに注意を払う可能性は低いでしょう。そして、「私はそう言っているKnuthの本を読んだ」または「SEの男はそれを言っている」とも何の印象も引き起こさない、 "）。彼らには方法、ルーチン、手順、および「多かれ少なかれ」機能するものがあるので、なぜ変化の努力とリスクを取るのですか？

2番目のアプローチが機能するためには、問題が存在するという認識がなければなりません。そう：

• 自動テストのために昼も夜も押さないでください。更新によって一部の機能が破損し、チームがそれを修正するために残業してから、自動テストシステムの構築を提案するまで待ちます。
• コードレビューを求めないでください。Joeが長期休暇を取り、Joeだけが知っているモジュールを変更する必要があるまで待ち、Joeのコードを理解しようとしてどれだけ時間が失われたかを上司に示します。

もちろん、変化はゆっくりで進歩的です（大企業ではもっとそうです）。5年以内にコードレビューと自動テストを導入できるようになった場合は、よくできたことを祝福する必要があります。しかし、完全な書き換えは外的要因に存在しない限り、彼らはコアにされたスイッチになることを任意のファンタジーを忘れて、たとえば、春（ジョエルは、あなたが生まれた前であっても、私が今までできたよりも良い、そのように説明した¹）。その時点で、サポートされているプラ​​ットフォームのリストでせいぜいSpringを取得して、重要でないシステムを作成できました。

エンタープライズITの世界へようこそ、男の子！:-p

¹：わかりました、多分私は少し過大評価していますが、多すぎません。

Michael Feathers の著書「レガシーコードを効果的に使用する」から始めてください。本の紹介から、「絡み合った、不透明な、複雑なシステムを、ゆっくりと、徐々に、少しずつ、一歩ずつ、シンプルで、適切に構成された、よく設計されたシステムに変えることです」。彼は主に自動化されたテストから始めて、あなたが安全にリファクタリングできるようにします（何かを壊すかどうかはわかります）。また、困難なコードを自動化されたテストの下に置くための多くの戦略を含んでいます。これは、まだ開発中のすべてのプロジェクトに役立ちます。基本的な順序が整ったら、プロジェクトが実際にどのような最新のテクノロジーから利益を得ることができるかを確認できますが、それらすべてが必要であると想定しないでください。

現在のプロジェクトが実際に必要とするのではなく、専門的な理由で新しいフレームワーク（または何か）を学習したい場合は、個人的なプロジェクト（自分の時間）で使用する必要があります。

ソース管理。

あなたはそれを既に言及していませんでしたが、できれば既に設置されていますが、そうでない場合はそこから始めてください。

ソース管理には、他の何かを病理学的に必要とするまれな状況を除いて、最大の価値があります。

そして、最初に誰も買わないなら、あなたは一人で始めることができます。

直接の答え

他の回答は、より良いプラクティスの採用に関する良い「メタポイント」になりますが、直接関連するガイダンスを提供するために、チーム（またはチーム）が採用することをお勧めするベストプラクティスの大まかな順序を示します（最初）：

1. ソース管理
2. 問題追跡（プロジェクトおよびタスク管理）
3. 自動ビルド¹
4. 自動展開

^{1 _{非常に関連するプラクティスは、開発または保守している各アプリまたはソフトウェアプロジェクトのビルドおよび開発環境のセットアップを自動化、または少なくとも文書化することです。あなたがこれを頻繁にまたはめったに行わないので、それははるかに有用ではありません。}}

ほかのすべて

「ユニットテスト、ロギング、データベースの正規化、...リファクタリング、...ドキュメント」など、他のいくつかの優れたプラクティスについて言及していますが、これらはすべて徐々に実装する必要があるプラクティスです。それらを一度にすべて採用する必要はありません。慎重にかつ慎重に採用することで、おそらくそれらを採用する方がよいでしょう。

上記の4つのプラクティスにより、新しいプラクティスを可能な限り簡単に採用し、実験することができます。たとえば、ユニットテストを自動ビルドに組み込み、自動展開の一部としてドキュメントを公開できます。

「アジャイル開発、...コーディングスタイルガイド、...コードレビュー、...標準化されたドキュメント作成方法」およびフレームワーク（Springなど）といった他のプラクティスは、本当にオプションであるか、疑わしい価値があります。そして、それは、あなたが発見または遭遇する可能性のある多くの（ほとんどの？）可能な慣行に当てはまります。

アジャイル開発は、使用される他の方法論より明らかに優れているわけではありません。そして、多くの人々（私を含む）がそれについて恐ろしい経験をしました。しかし、多くの人々もそれを本当に気に入っています（または愛しています）。それを試してみてください！

コーディングスタイルガイドは、特に大規模なプロジェクトや大規模なチームで役立ちますが、これらのガイドラインを実施するのは大変な作業であり、それを行っている人にとっては最善の方法とは言えません。

コードレビューも非常に役立ちます。コードのレビューを同僚に依頼したことがありますか。グッドプラクティスを採用するための正式なプロセスは必要ないことに注意してください！

ドキュメントは素晴らしいです–何かありますか？もしそうなら、あなたに良い！（より）「標準化された」ドキュメントを作成することで防止できる多くの余分な作業に直面していますか？もしそうなら、それはおそらくやりがいのあることです。ただし、ご使用のソフトウェアが少数の人々によって使用されている場合は、ドキュメントは不要かもしれません。（または、ドキュメントをソフトウェアに直接組み込むこともできます。それが常に私の好みです。）

フレームワークは...（非常に鋭い）両刃の剣です。ソフトウェアのコア以外の機能に対する、きちんとカプセル化され、よく管理されたソリューションは、そうでないまでは素晴らしいものです。「手書きのフロントコントローラー」が正確に何なのかはわかりませんが、Springを活用するコードよりも劣る理由については明確な説明はありません。これらすべてのコントローラーの共通ロジックを独自の社内フレームワークにカプセル化することを検討しましたか？Springを採用し、既存のすべてのコードを書き直すことは、膨大なリファクタリング（または、おそらく書き直し）プロジェクトになる可能性があり、コードに加えることができる最良の変更ではない可能性があります。もちろん、使用するすべてのソフトウェアを書くべきではありません。フレームワーク（およびライブラリ）は素晴らしいです！しかし、素晴らしい（または良い）Webアプリを作成するために、Spring（または代替）を使用する必要はないかもしれません。

あなたが所属しているチームを見てください。テスト駆動開発またはデータベースの正規化により、作成中のソフトウェアの品質が向上するか、人々の生産性が向上するという証拠を確認できますか？

開発スーパーバイザーの1人、または開発責任者に話しかけましたか？本当に非公式のチャットは良い出発点です。あなたの上の人々は同じアイデアを持っていなかったが、ビジネスがそれを許可しないので、それらを実装できない/できないと思うのはなぜですか？

模範を示すことは良い方法だと思います。他の誰かがすでに作業を行っており、それを複製する方法を示すことができれば、人々ははるかに抵抗力が弱まります。作業中のプロジェクトにTDDを導入します。チームの他のメンバー、または他の数人にプレゼンテーションを行い、自分が何をしたかを見せるように依頼します。@DrewJordanが上司から買収することについて言ったことは、おそらくあなたが思っているよりも重要です。

欠陥を見つけます。欠陥を修正します。修正を表示します。

最初に正規化*を見てみましょう。実際、正規化の欠如はそうでなければ存在することのできない実際のバグのあるデータになる可能性が高いため、最初にそれを取ることをお勧めします。 Aは、ポリシーX "に従っていないことが原因でした。正規化されていないデータベースがある場合、データに矛盾が生じる可能性があります。

一貫性のないデータの実際のケースを見つけることができるのはいいことです。これで2つのことがわかりました。

1. データのバグ。

2. データベーススキーマのバグ。

最初に2番目のバグについて知っていましたが、最初のバグはより簡単にわかりやすく、理論的に可能なものではなく、実際の問題を引き起こしているものでもあります。

残念ながら、正規化されていないデータベースの正規化に抵抗する本当の理由の1つは、そのようなバグのあるデータをどう処理するかという質問は必ずしも簡単ではないが、実際のバグが見つかることです。

（ただし、意図的に一部のデータを非正規化する場合がある理由があることに注意してください。ルールの知識のない破壊をルールの無知と間違えないでください。ルックアップの速度のために故意に非正規化されたテーブルを正規化すると、勝ちます賞賛に値するものではありません。ここでも、非正規化は困難であるため、手続き的に行う必要があります。したがって、非正規化テーブルが正規化テーブルの内容に基づいて自動的に作成されない場合、まだ進展があります）。

残りの部分については、短期的に支援するときに導入し、後で長期的に構築するようにします。たとえば、ビルドする小さなコードが与えられた場合、そのための単体テストを作成します。さらに良いことに、修正するバグが与えられた場合、バグのために失敗する単体テストを作成し、バグを修正したら、バグを閉じたときに合格するという事実に言及します（または修正されたというメールを送信します） 、または何でも）。

*ちなみに、あまり現代的ではありません。それが呼ばれる理由正規化ではなく正規化または何か他のものは、一度にそれを固執する局所冗談だったということです-izationリチャード・ニクソンの名前の楽しさを作るために、物事の終わりにベトナミゼーションのポリシー。

私は穀物に逆らって言います：少し履歴書を作成するためにこの仕事に時間を費やした後、新しい仕事を見つけます。1年かそこらを目指します。多くのことは「流行語」ですが、単体テストの完全な欠如などの問題は、1人の開発者にとっては扱いにくいものです。会社であなたを一生懸命に考えさせることによって。文化を基本的な能力に押しやろうとするのではなく、指導を受けることができる場所にいる必要があります。

プログラミングパラダイムを改善するための多くの提案がありました。最も人気のある流行語は、アジャイルプログラミングとオブジェクト指向のようです。それとも彼らですか？どちらもわずか5年前と比較して大幅に衰退しています。

どのような方法論が導入されても同じ最終結果を達成しようとしていると確信できます。つまり、エンジニアが経済的に十分な最終製品を生産できるようにします。

：論争1960年代に導入された1つのパラダイムがあり 、プログラミングの構造は：唯一の「ハイレベル」のような構成を使用してwhile、for、repeat、if/ then/ else、switch/ caseの代わりに頻繁に使用されるの文gotoデフォルトで受理された声明を。正当な用途があるかどうかについてはまだ議論がありgotoます。

の使用を最小限に抑えることgotoは良いことですが、他のすべての良いことと同様に、行き過ぎる可能性があります。

あなたはagile方法論を前向きなものとして言及しています。私は約6か月間、1つの開発チームに所属し、意図的にアジャイルレジメンを従いました。すべてが改名されていることを除けば、数十年前の賢明なプロジェクト管理方法論に似ていることがわかりました。おそらく、誰かがコミュニケーションをとるためのアイデアを再束ねて再販することで、生計を立てることができ、企業は皇帝の新しい服を「見る」ことを気分よくすることができます。

アジャイルの最も価値のある教訓は、昔から知られていましたが、完成品へのより良いパスを見つける柔軟性は良いことであり、そのパスを見つける能力は、上級管理職だけでなく誰からでも得られるということです。

反ゴトの首謀者エドガー・ダイクストラによる文章から：

プログラミングの技術は、複雑さを整理し、多数を習得し、そのろくでなしの混乱を可能な限り効果的に回避する技術です。

—Dijkstra、in：Dahl、Dijkstra＆Hoare 1972、pg。6.（ここの 6ページを参照してください。）