私はいつも、よく構成された読みやすいコードを書くようにしています。
私は何か新しいものをいじり回しているとき、私は特定の問題に直面します。私はコードや構造などを変更し続けています。結局、私はコードを見て、とても単純なことをしようとしたときにコードがどれほど複雑になったのか悩みました。
何かを完成させたら、それをよりリファクタリングしてよりクリーンにします。これはほとんどの場合完了後に発生し、コードが大きくなるほどコードを書き換えるのが面倒になるため、面倒です。
特に多くの人が共有する大きなプロジェクトで、人々がそのような苦痛にどう対処するのか知りたいです。
回答:
あなたがリファクタリングしている限り、あなたはそれを正しくやっています。
これを考慮してください。いつでも、問題の解決策をグラフ化できます。しかし、時間の経過とともに、問題についてより多くのことがわかり、より良い解決策を考え出すことができます。最初のイテレーションは逆の可能性があり、最後のイテレーションはうまくいけば有効です。知識が増えてもリファクタリングを続けると、常により良い結果が得られます。すでに同様の問題に遭遇したり、過去の問題から一般化したり、幸運になったりできる場合を除き、「学習」ステップを実行せずに、最もエレガントなソリューションにすぐにジャンプするショートカットはありません。
特に多くの人が共有する大きなプロジェクトで、人々がそのような苦痛にどう対処するのか知りたいです。
"hooby projects"ビル・コスビーによって書かれたコードのように聞こえます。「IDEとアジャイルな方法論では、KIYDSは知らない...どのような低レベルのコードなのか...すべてについて」;）
まあ私は単体テストでTDDを行います。TDDマントラ全体は、次のサイクルを中心に展開します。
TDDを使用しているため、単体テストを作成する必要があります。テストを書くのが難しい場合、それは私のデザインが複雑すぎて単純化する必要があることを示しています。
冗長性を取り除くためにリファクタリングしない限り、サイクルは終了しません。そのため、ほとんどの場合、リファクタリングは小さなチャンクで行われ、時間がかかりません。さらに、リファクタリングのたびに、すべてのテストケースを実行して、何も壊れていないことを確認します。
画像ソース：http : //www.javacodegeeks.com/2012/05/test-driven-development-win-win.html
誰もがそれを書くことによってプログラムを書く方法を学びます。リファクタリングはプロセスの一部です。これは、2回目のリファクタリングの方が優れているためです。コツは、リファクタリングを回避しようとすることではなく、より迅速かつ頻繁に行うことです。「終了」まで待つのではなく、問題に気づいたらすぐにリファクタリングします。
問題の領域を完全に理解すると、より明確で単純なコードを書くことが練習からわかりました。残念ながら、顧客は自分が何を望んでいるかを正確に明確にできないことがよくあり、これは通常の作業状況です。ドメインを誤解した場合は、コードに反映されます。そして、あなたがプロジェクトリーダーである場合、主要なタスクの1つは、顧客が実装してほしいビジネスソリューションを新たに理解できるようにすることです。したがって、ドメイン分析により多くの時間を費やすようにしてください。そうすれば、より単純で明確なコードを書くことができます。