あなたがかつて好きだったプログラミングの習慣から、気が変わったものは何ですか？[閉まっている]

私たちがプログラミングするとき、私たちは皆、私たちが使用し、信頼しているプラ​​クティスとパターンを開発します。ただし、時間の経過とともに、理解、成熟度、さらにはテクノロジーの使用状況さえも変化するにつれ、以前は優れていたと考えていた一部のプラクティスが適切ではない（または適用されなくなった）ことに気付きました。

かつて私が頻繁に使用していたプラクティスの例は、近年変更されましたが、シングルトンオブジェクトパターンの使用です。

私自身の経験と同僚との長い議論の結果、シングルトンは必ずしも望ましいとは限らないことに気づきました。シングルトンは、モックのような手法を阻害することによってテストをより困難にし、システムのパーツ間に望ましくない結合を生み出す可能性があります。代わりに、私は現在、シングルトンの性質と存在を気にしない、または知る必要のあるシステムの部分から隠すオブジェクトファクトリー（通常はIoCコンテナーを使用）を使用しています。代わりに、そのようなオブジェクトへのアクセスを取得するためにファクトリ（またはサービスロケータ）に依存しています。

自己改善の精神でのコミュニティへの私の質問は次のとおりです。

• 最近どのようなプログラミングパターンや実践を再考して、今は避けようとしていますか？
• それらを何に置き換えることに決めましたか？

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

単一の戻り点。

以前は、各メソッドに単一の戻り点を優先していました。これにより、ルーチンに必要なクリーンアップが見落とされないようにすることができたからです。

それ以来、私はずっと小さなルーチンに移動しました-クリーンアップを見落とす可能性が減り、実際にクリーンアップの必要性が減りました-そして、初期のリターンがコードの見かけの複雑さ（ネストレベル）を減らすことがわかりました。単一の戻り点のアーティファクト-「結果」変数を保持する、フラグ変数を保持する、まだ完了していない状況の条件句-コードが実際よりもはるかに複雑になり、読み取りと保守が難しくなります。早い段階での脱出と、より小さな方法が、進むべき道です。

• 最初の試行で物事を完璧にコーディングしようとしています。
• コーディングの前に完璧なオブジェクト指向モデルを作成しようとしています。
• 柔軟性と将来の改善のためにすべてを設計する。

一言で言えば、オーバーエンジニアリング。

ハンガリー語表記（フォームとシステムの両方）。私はすべてにプレフィックスを付けていました。strSomeStringまたはtxtFoo。今、私はsomeStringとtextBoxFooを使用します。新しい人が一緒に来て拾う方がはるかに読みやすく、簡単です。追加のボーナスとして、一貫性を保つことは簡単です-camelCaseをコントロールに使用し、役立つ/説明的な名前を追加します。Forms Hungarianには、常に一貫性があるとは限らないという欠点があり、Systems Hungarianはあまり効果がありません。すべての変数をまとめることは、特に最近のIDEの場合はそれほど便利ではありません。

「完璧な」アーキテクチャ

私は数年前にTHEアーキテクチャを思いつきました。100％疎結合のレイヤー、デリゲートの広範な使用、および軽量オブジェクトが存在するように、可能な限り技術的に自分自身をプッシュしました。それは技術的な天国でした。

そしてそれはがらくたでした。アーキテクチャの技術的な純粋さが、開発チームの結果を完璧にしようとするのを遅らせ、完全な失敗をほぼ達成しました。

技術的に完全ではないシンプルなアーキテクチャになり、配信率が急上昇しました。

カフェインの使用。かつて私は目を覚まし、輝かしいプログラミングの気分になり、コードは私の指から猛烈な流動性で飛んだ。今、それは何もしません、そして、私がそれを持っていないなら、私は頭痛がします。

コードをコメント化します。私は以前、コードは貴重であり、あなたが作成した美しい宝石を単に削除することはできないと思っていました。TODOやNOTEを残さない限り、コメントアウトしたコードを削除します。これは、あまりにも危険なので、コメントアウトしたままにすることはできません。ありました：彼らは最近コメントアウトされましたか？これは開発環境の変更ですか？なぜこの無関係なブロックを行うのですか？

コードをコメントアウトせず、単に削除することを真剣に検討してください。必要な場合は、ソース管理のままです。YAGNIですが。

#regionディレクティブの乱用/乱用。これはほんの少しのことですが、C＃では、以前は#regionディレクティブをいたるところに使用して、クラスを編成していました。たとえば、リージョン内のすべてのクラスプロパティをグループ化します。

今私は古いコードを振り返って、ほとんどがそれらに悩まされています。私はそれがほとんどの場合本当に物事をより明確にするとは思いません、そして時々彼らは単にあなたを遅くするだけです。だから私は今私の心を変え、よくレイアウトされたクラスはリージョンディレクティブなしでほとんどきれいだと感じています。

ウォーターフォールの開発全般、具体的には、何らかの形で標準的であることが期待され、それらの実装が正確で許容可能であることが期待される、完全で包括的な機能および設計仕様を作成する方法。私はそれがスクラムに置き換わったのを見たことがあります。単純な事実は、顧客のニーズと欲求の性質の変化により、固定された仕様が事実上役に立たなくなることです。問題に本当に適切に取り組む唯一の方法は、反復的なアプローチです。もちろん、スクラムは特効薬ではありません。私はそれが何度も何度も誤用され、乱用されているのを見てきました。しかし、それは滝を打ち負かします。

クラッシュすることはありません。

いい考えですね。ユーザーはクラッシュするプログラムを好まないので、クラッシュしないプログラムを書いてみましょう。ユーザーはプログラムを好きになるはずですよね？それが私が始めた方法です。

最近では、うまくいかなくても、うまくいっているふりをするべきではないと思います。できるだけ早く失敗し、適切なエラーメッセージが表示されます。そうしないと、プログラムは後でいくつかの命令を実行するだけでさらに激しくクラッシュしますが、デバッグに1時間かかるいくつかの説明のないnullポインターエラーが発生します。

私のお気に入りの「クラッシュしない」パターンは次のとおりです。

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

ここで、ユーザーにエラーメッセージをコピーして貼り付けて送信するように依頼する代わりに、ログに飛び込んでログエントリを見つけなければなりません。（また、無効なユーザーIDを入力したため、ログエントリはありません。）

デザインパターンを認識したら、それを適用するのが理にかなっていると思いました。

私が実際に外国のプログラミング言語からスタイルをコピーしていることを少しも知りませんでしたが、私が使用していた言語は、はるかにエレガントで簡単なソリューションを可能にしました。

複数の（非常に）異なる言語を使用することで私の目が開かれ、自分以外の問題に対する他の人の解決策を誤って適用する必要がないことを実感しました。Rubyのような言語で適用されたファクトリーパターンを見ると、身震いします。

強迫的なテスト。私はかつてテストファースト開発の猛烈な支持者でした。一部のプロジェクトではそれは非常に理にかなっていますが、それが実行不可能であるだけでなく、機能のすべての単一部分のユニットテストを作成するという教義にずるずる従うことは多くのプロジェクトにとって有害で​​あることに気付きました。

本当に、何にでも従順であることは有害です。

これは小さなことですが、中括弧の位置（同じ行または次の行）を気にすること、コードの最大行長、変数の命名規則、およびスタイルの他の要素を提案しました。誰もが私よりもこのことを気にかけているようですので、私が現在取り組んでいる人の流れに沿って進みます。

編集：もちろん、これは例外ですが、私が最も気になる人（またはグループのスタイルを設定する立場にある人）です。その場合、私はやりたいことをします！

（これは一貫したスタイルがないことと同じではないことに注意してください。コードベースの一貫したスタイルは読みやすさにとって非常に重要だと思います。）

おそらく、私が考えを変えて以来、最も重要な「プログラミングの実践」は、私のコードが他の誰よりも優れているという考えです。これはプログラマー（特に初心者）に共通です。

ユーティリティライブラリ。私は、さまざまなヘルパーメソッドとクラスを使用してアセンブリを持ち歩き、いつの日か他の場所で使用できるという理論に従っていました。

実際には、私は機能が細かく整理されていない多数の名前空間を作成しました。

今、私はそれらを作成したプロジェクトにそのまま残します。おそらくそれを必要としないでしょうし、もし必要なら、いつでも後で再利用可能なものにそれらをリファクタリングすることができます。ときどき、// TODOでフラグを付けて、共通のアセンブリに抽出できるようにします。

私がコーディングした以上の設計。しばらくすると分析麻痺になります。

ビジネスロジックを実行するためのDataSetの使用。これは、コードをデータベースに緊密にバインドします。また、DataSetは通常SQLから作成されるため、物事がさらに壊れやすくなります。SQLまたはデータベースが変更されると、データセットが触れるすべてのものに細流化する傾向があります。

オブジェクトコンストラクター内でビジネスロジックを実行する。継承とオーバーロードされたコンストラクタを作成する機能により、メンテナンスが困難になる傾向があります。

変数/メソッド/テーブル/ ...の名前の省略

名前の長さに制限を設けていない言語で作業しているときでも、私はこれをいつも使用していました（おそらく255かそれくらいだったでしょう）。副作用の1つは、（非標準の）省略形を説明するコード全体に散らばった多数のコメントでした。そしてもちろん、名前が何らかの理由で変更された場合...

今、私は物事を本当の意味で、わかりやすい名前で呼ぶことにしています。標準の略語のみを含みます。無駄なコメントを含める必要はありません。コードははるかに読みやすく、理解しやすくなっています。

エンタープライズライブラリなどの既存のデータアクセスコンポーネントを、ヘルパーメソッドのカスタムレイヤーでラップします。

• それは誰の生活も楽にしない
• バグを含む可能性のあるそのより多くのコード
• 多くの人々は、EntLibデータアクセスコンポーネントの使用方法を知っています。社内のデータアクセスソリューションの使用方法を知っているのはローカルチームだけです

1984年にSmalltalkを読んでいるときに最初にオブジェクト指向プログラミングについて耳にしましたが、1992年にcfront C ++コンパイラを使用するまでoo言語にアクセスできませんでした。1995年についにSmalltalkを使用するようになりました。技術、そしてそれがソフトウェア開発を節約するだろうという考えに賛成しました。

今、私はooをいくつかの利点を持つ1つの手法と見なしていますが、それはツールボックスの1つのツールにすぎません。私はほとんどの作業をPythonで行っており、クラスメンバーではないスタンドアロン関数を作成することが多く、以前はクラスを作成していたタプルまたはリストにデータのグループを収集することがよくあります。データ構造が複雑な場合や、データに関連付けられた動作が必要な場合でも、クラスを作成しますが、それに抵抗する傾向があります。

時間があるときに、Coojureでいくつかの作業を行うことに実際に関心があります。oo機能は提供されませんが、正しく理解すればJavaオブジェクトを使用できます。私はooが死んだようなことを言う準備はできていませんが、個人的には、以前はそうであったファンではありません。

C＃では_notation、プライベートメンバーに使用します。今は醜いと思います。

それから私はthis.notationプライベートメンバー用に変更しましたが、それを使用することに一貫性がないことに気付いたので、それもドロップしました。

実装する前に、大学が推奨する設計方法を使用するのをやめました。カオス的で複雑なシステムでの作業は、私に態度を変えることを余儀なくさせました。

もちろん、私はまだコードの調査を行っていますが、特にこれまで触れたことのないコードに触れようとしているときは、通常、できるだけ小さな実装に焦点を当てて最初に何かを始めようとします。これが第一の目標です。次に、徐々にロジックを調整し、デザインを単独で表示します。プログラミングは反復プロセスであり、アジャイルなアプローチと多くのリファクタリングで非常にうまく機能します。

コードは、最初はどのように見えるかと最初に思ったすべてのものを調べるわけではありません。毎回起こります:)

私は以前、契約ごとの設計に大きく関わっていました。これは、すべての関数の最初に多くのエラーチェックを置くことを意味しました。契約は、懸念の分離という観点からは依然として重要ですが、コードで実行してはならないことを強制しようとするのではなく、ユニットテストを使用してそれが何を実行するかを確認しようとします。

より簡潔だったので、多くのメソッド/クラスでstaticを使用しました。私がテストを書き始めたとき、その実践は非常に速く変わりました。

チェックされた例外

紙の上で驚くべきアイデア-契約を明確に定義し、間違いや、例外条件のチェックを忘れる余地はありません。初めて聞いたときに売り切れました。

もちろん、それは実際にはそのような混乱になった。今日では、主な機能の1つとしてレガシーチェック例外を非表示にするSpring JDBCのようなライブラリを使用できるようになりました。

価値のあるものは、1つの特定の言語でのみコーディングされました。私の場合、私はCがこれまでで最高の言語であり、他の言語で何かをコーディングする理由がなかったと思っていました...

それ以来、私は多くの異なる言語とそれらが提供する利点/機能に感謝するようになりました。小さなものをすばやくコーディングしたい場合は、Pythonを使用します。大規模なプロジェクトに取り組みたい場合は、C ++またはC＃でコーディングします。脳腫瘍を開発したい場合は、Perlでコーディングします。

何らかのリファクタリングを行う必要があるとき、すぐに始めて新しいデザインを実装し、接続が機能するまで接続を修正する方が速くてきれいだと思いました。その後、一連の小さなリファクタリングを行って、ゆっくりと、しかし確実に新しいデザインに向けて進む方がよいことに気付きました。

おそらく、私のコーディングプラクティスや他のコーディングプラクティスで変わった最大の点は、アプリケーションの動作と機能の基礎として、インターネットからダウンロードされた外部のクラスとライブラリを受け入れることです。私が大学に通っていた当時の学校では、独自のコードを使用して物事を改善する方法を見つけ、問題を解決するために言語に依存するように勧められました。ユーザーインターフェイスとサービス/データの消費のすべての面での進歩により、これはもはや現実的な概念ではなくなりました。

言語によって決して変更されない特定のことがあり、このコードをより単純なトランザクションでラップし、記述する必要のあるコードの行数を減らすライブラリがあることは幸運です。データベースへの接続は常に同じです。DOM内の要素を選択しても変わりません。サーバー側のスクリプトを介してメールを送信することは決して変更されません。この時間を何度も書く必要があるため、アプリケーションのコアロジックを改善するために使用できる時間を無駄に費やしています。

すべてのクラスメンバーを初期化しています。

私はすべてのクラスメンバーを明示的に、通常はNULLで初期化していました。私はこれに気づきました：

• 通常、すべての変数が読み込まれる前に2回初期化されることを意味します
• ほとんどの言語では自動的に変数をNULLに初期化するため、これはばかげています。
• ほとんどの言語で実際にわずかなパフォーマンスヒットを強制します
• より大きなプロジェクトでコードを膨らませることができます

あなたと同じように、私もアプリのさまざまなコンポーネント間の結合を減らすためにIoCパターンを採用しました。各コンポーネントをできるだけ独立させておけば、メンテナンスと部品交換がはるかに簡単になります。また、NHibernateなどのより多くのオブジェクトリレーショナルフレームワークを利用して、データベース管理の作業を簡素化しています。

一言で言えば、私は「ミニ」フレームワークを使用して、ソフトウェアをより迅速かつ効率的に構築するのを支援しています。これらのミニフレームワークは多くの時間を節約し、正しく実行すれば、アプリケーションを将来的に維持するのが非常に簡単になります。勝利のためのプラグアンドプレイ！