お金を稼ぐために、どの時点でソフトウェア開発の原則をいくつか捨てますか？

興味深いことに、メディアがどこにあるかを見るために、この質問をそこに投げ出したいと思います。

過去12か月で、TDDとソフトウェア開発におけるアジャイルの価値の多くを取り上げました。私はソフトウェアの開発がどれほど良くなったかに圧倒され、それらを原則から外すことはありませんでした。まで...私は年間の持ち帰り給与を倍増する契約の役割を提供されました。

私が参加した会社は特定の方法論を踏んでおらず、チームはコードの匂いやソリッドなどのことを聞いていませんでしたし、チームでさえもしていないなら、TDDに時間を費やすことはありませんでした実際にユニットテストを見ました。売り切れですか？いいえ、完全ではありません...コードは常に「ボブおじさんの教えに従って」「きれいに」書かれ、SOLIDの原則は必要に応じて私が書くコードに常に適用されます。しかし、テストフレームワークを作成したとしても、テストフレームワークを正しく使用/保守することはありませんでした。

それを例にとると、開発者は個人的にお金/その他の利益のために職人技の原則を落とすべきではないという点を教えてください。これは、自分のニーズ、ビジネスニーズ、職人技などのためにどれだけ関心があるかについて、非常に個人的な意見になり得ることを理解しています。しかし、たとえば、テストチームは、プログラミングの単体テストを理解するのではなく、私がやったように自分自身を許すことができるでしょうか？あなたが落とすものがあることを考えると、通常はあなたが落とすものを補うビジネスに等しい費用があるはずです-できれば、もちろんあなたがあなた自身のポケットを並べてコミュニティ/社会的コラボレーションではなく）。

お金を2倍にして、RADに戻りますか？または、歩いて、アジャイルをしている人を探して、決して振り返らないでください...

私は10年以上前にユニットテストに夢中になって以来、職場の大半でこれらについて聞いたのは私が初めてでした。それでも、できる限りいつでも小さな単体テストを書き続け、単体テストのコストをタスクに見積もりました。誰かが私のコーディング習慣について尋ねたときはいつでも、私が何をしていたのか、なぜそれが私にとってうまくいったのかを話しました。通常、少なくとも一部の人々は興味を持っていたので、最終的にはトピックに関するプレゼンテーションを行い、人々に最初のユニットテストを書くよう指導しました。

新しい職場での初日から、アジャイルな方法について人々に納得させる必要はありません。できるだけ自分の仕事の原則に従ってください。うまくやれば、より良いコードを提供できます。あなたの同僚や経営者がそれに気づいた場合、あなたはどうするか尋ねます。その後、それらを伝えることができます。

更新

経験豊かな開発者（およびマネージャー）のほとんどは、トレンドや流行が行き交うのを見てきたため、最新の流行語に興奮することはありません。ただし、特定のアプローチ（ツール、考え方）が実際に実際に機能することを実証できれば、実際のプロジェクトでは、クラフトを気にする人はほぼ確実に座って耳を傾けます。ただし、チームにそのような人がいない場合は、おそらくより良い場所を探すときです...

ここで、すべての開発者がプロ​​ジェクト管理について少し知っておくべきだと思います。すべては時間、お金、リソースの間のトレードオフです。あなた自身をリソースと考えてください。

私のプログラミングの12年間で、私はプロジェクトを完了して、それが完了した、または私の頭の中で完了したと考えたことはないと思います。もっと良くしたい、もっときれいにしたかったのにと思っていました。これがトレードオフのせいであることに気付くのに非常に長い時間がかかりました。

方法論が存在しないという理由だけで転職を考えているのであれば、私があなただったらもう一度考えます。これらのトレードオフは一定であり、すべてのソフトウェア開発者に適用されます。最も熱心なゲーム開発者でさえ、もう一度やり直したり、機会があればもう一度別の方法論を練習したりしたいと思っています。

アジャイル開発の実践を見て、ミクロレベルでもそれができることを理解すべきだと思います。あなたのチームメイトがラ・ラ・ランドで好きなことをしていることは確かですが、あなたの個人的な満足度は大きくなり、長期的には彼らよりも優れたコードを確実に生成します。次に、マネージャーが来て、なぜあなたのコードがこれほど優れているのかを尋ねると、チームを変換するチャンスがあります:)

しかし、あなたが人々や仕事が好きでないなら、あなたはすでに答えを知っていると思います。しかし、誰かが部屋に入って、コーディング中にアジャイル開発の原則を使用しないようにと言うことを非常に疑います。

長期的に不幸になるようなものを落とさないでください。もちろん、誰もいない土地から始めて、チームをあなたの方向に動かそうとすることができます。あなたがそれに努力を注ぎ、仕事に価値があるなら、これは興味深い挑戦でさえあります。

しかし、コーディング（またはそのことについての仕事）の楽しみを保つものそのものを残さなければならない場合、私の経験では、遅かれ早かれあなたは立ち去ることになります。欲求不満を過小評価しないでください...

あなたの最後の仕事の人々は、TDD、SOLIDなどをすでに知っていました。それは素晴らしいことです。そこでの仕事を楽しんで、たくさんのことを学んだと思います。今、あなたはそれらの概念を教える機会を持っています（同時に大金を稼ぎながら）。私の経験では、他の誰かに概念を教えることは、自分自身でさらに詳細に概念を学ぶのに常に役立ちました。ただ忍耐強く、コンセプトを1つずつ押し続けてください。イライラしたら、家に帰ってお金を数えましょう。または、SEのサポートを探してください。

その点で私はab * tchであることを認めなければなりません。フリーランサーとして、クライアントがプロジェクトに適切な方法論とみなすものは何でも、私は大丈夫です。それはお金だけが私が気にしていることを意味するものではありませんが、何をするか、何を残すかについての決定はクライアント次第です。しかし、悪い労働条件（騒々しい、長時間労働など）は受け入れません。

私の元同僚を引用したいと思います。彼は、仕事やアルバイトを探しているときはいつでも、プロジェクトが満たさなければならない3つの基準があると言いました。

• 一緒に仕事をするのは楽しいに違いない
• コンピテンシー開発に有益である必要があります（これが正しい表現方法であるかどうかはわかりません）
• うまくいくはず

あなたの質問を読みましたが、このプロジェクトは最後の基準のみを満たします。

あなたがTDDを好むようになったので（私がそうであるように）、あなたは毎日動き回り、あなたの同僚全員があなたと同じ洞察に到達したことを願っています。したがって、最初の基準はおそらく満たされないでしょう。

第二に、TDDプロジェクトを追求し、おそらくアジャイルチームを構築するためのより多くの経験を得たい場合、このプロジェクトに取り組むことは、それらのスキルを強化する助けにはなりません。したがって、2番目の条件もおそらく満たされません。

個人的に、もし私があなたの立場にあり、TDDを会社に紹介するのを手伝う立場にないなら、私は他の場所を見るでしょう。

決して。

人生は短すぎて（特に年をとるにつれて）嫌いなことをすることができません。

もちろん、それは仕事を変えるのをより難しくします、そして、仕事をするより少ない場所があります。

しかし、少なくともレガシーコードだけが悪臭を放ちます。（そして私には自治権があるので、レガシーコードベースからコンパイラの警告を排除するのに一週間を費やすなどの賢明なことをすることができます...）

つまり、開発方法論はあなたの一部ではありません。それは宗教ではなく、あなたが誰かではありません。これはツールです。あなたが言われたこと、あなたが言われた方法をして、余分なお金を稼ぐ。数千のシステムが開発され、現在TDDやCode Smellなどなしで実行されています。数年後には、方法論が都市バスよりも頻繁に行き来するため、これらの用語の意味が誰にもわかりません。あなたが言われたように一生懸命働き、それがいつでも感謝されているお金を取る:)

新しいチームと協力することが、あなたの時間の良い投資であることを確認してください。

おそらく、これまでに遭遇したよりも効率的な方法で動作するのでしょうか？もしそうなら、彼らと一緒に仕事をすることはあなたにとって素晴らしい学習経験になるでしょう（したがって良い投資です）。

一方、新しいチームの方法論はあまり価値がないかもしれません（「カウボーイコーディング」など）。その場合、追加のお金はおそらく価値がありません（IPO前のスタートアップまたは特別なものでない限り）。あなたはおそらくあまり学ばないでしょう...そしてあなたは燃え尽きる危険があります。

私は自分が望んでいた方法で仕事をすることができなかったどこかで働いていません。それは、私がマイクロ管理されたくないことを意味します。

私は自分がやることに長けているという仮定の下で仕事をしており、もしあなたが私にいくつかのタスクを与えれば、私はそれらを効率的かつ効果的に終わらせるでしょう。コードのガイドラインとパターンに違反しない限り、どのように実装するかは私次第です。それが私の仕事の楽しい部分です。

私が書いたすべてのクラスを単体テストしたい場合、それは問題になるかもしれませんが、締め切りに間に合うのであれば、単体テストを書くことは一般的には問題ありません。TDDの支持者は、単体テストを書くことで実際に生産性が向上すると主張するだろうと考えています（後でなど）。私はあなたの靴にあった場合は、私が書きたいいくつかの私に保存されますユニットテスト、いくつかのトラック（おそらくバグも少ない、簡単に修正）ダウンタイムを。その時間をより多くのテストに再投資すると、さらに多くの時間を節約でき、素晴らしいテストスイートがある場合は大きな笑顔で座って、新しい11時間目にコードの変更を簡単に確認できます要件が入ります。

それができなかったら、そこで働きたいかどうかわかりません。

私が言っているのは、これらの事柄に譲歩するべきだと思うということです。彼らが私にお金を払うほど、私が期待する非金銭的な利益は少なくなります。しかし、特に拒否する必要がない場合は、常にある程度の自主性と自尊心が必要です。少しの自主性がある限り、他の原則はすべて放棄します。結局のところ、いくつかの逆方向のクレイジーな方法論のように見えるかもしれないことは、あなたがこれまでにした最高のことかもしれません！