迅速なプロトタイピングとリファクタリング


9

小さなプロジェクト(Androidアプリなど)を開始するとき、最後にどのアプローチがうまくいくかわからないことがあるので、1つのアプローチを試してみます。しかし、このアプローチをこれまでに使用したことがない場合(ある種のアプリケーションの場合、これまでプログラムしたことがない)、それは未知の地形に足を踏み入れるようなものです。使用するライブラリがわからない(たぶん、いくつかのライブラリを試す必要があるかもしれません)非常に多くの認識されていない(例:Androidで生のオーディオデータを取得する方法)

したがって、私の開発プロセスは次のようになります。

  • コードを記述して、アプローチにチャンスがあるかどうかを確認します。(アプローチが不確実であるほど、コードはより醜くなります)
  • 機能する場合は、綺麗になるまでたくさんリファクタリングしてください

この時点でソフトウェア設計を詳細に計画した場合、それは時間の無駄になると思います。それは、地図のない旅行を計画するようなものです。

これはアグリー開発の一部ですか?ソフトウェア開発で未知の地形にどのように対処しますか?


これは、反復的な開発の手段としてClean Code 2で言及されています...その本を信じるかどうかはあなた次第です。
リグ

回答:


11

これはアジャイルとは何の関係もありませんが、アジャイルがそうであると彼らが考えているからです。ヒッピーコミューンで頭のない鶏の開発。

あなたがしているのは、テクノロジーを評価することです。あなたは現在、判断を下すのに十分なテクノロジーの経験がないからです。新しいライブラリ、フレームワーク、言語、プラットフォームがほぼ毎日表示されるため、これは良いことであり、決して終わらない。

未知のものにどのように対処するかは、実際には非常に良い質問であり、代替案を調査し、それらを評価し、1つを選択することになります。

ここで役立つアジャイルに関連する傾向があるスキルには、リファクタリングが簡単で安全なコードを作成することが含まれます。TDDは良い例です。それはあなたがあなたの結果を結果の観点から考えることを奨励します。「このコードはこの結果を生み出すはずです」これは心に焦点を当て、目標の解決に寄与しないコードの量を減らします。

SOLID(頭字語)の原則に従ってコードを記述した場合、間違った選択をした場合、または頻繁に発生するように、選択の範囲を超えた場合に、後でライブラリを置き換えることができます。

このような質問をするのは良いことです。さまざまな理由で、正しいテクノロジーを選択するために時間をかけて「無知」に見えるリスクを負わない開発者が多すぎます。プロジェクトの早い段階でミスをしないでください。実験は無駄ではなく重要なので、あなたはそれを正しい方法で行っていると思います。


2

これはアグリー開発の一部ですか?ソフトウェア開発で未知の地形にどのように対処しますか?

あなたが説明したのはアジャイルではありません。アジャイル開発は、ある時、箱入りの反復アプローチと適応計画、進化の開発と提供を推進についての詳細。アジャイルは、変化への迅速かつ柔軟な対応を促進します。したがって、開発の進行に合わせてコードをリファクタリングすると、アジャイル手法が組み込まれます。

プロジェクトの未知の部分を扱うことは、高レベルの設計で、既知の要件を収集することから始まります。ほとんどのコンポーネントを手に入れたら、適切なソリューションを探すことができます。そうは言っても、本格的な開発の前に小さな概念実証を構築することは、私たちのチームが従うアプローチです。

SOLIDと呼ばれるソフトウェア開発の原則があります。私の経験では、問題/問題にそれらを適用することは、常にプロジェクトのコードベースを改善するための一歩前進です。


2

プロジェクトによって異なりますが、小規模なプロジェクトで単独で作業している場合は、開発の一環として技術調査と調査を行うのが最適です。そして、アジャイルの一部ではありませんが、もちろんアジャイル方法論を使用して、これに何らかの制御を追加することができます。ただし、これによりプロセスの予測や時間ボックスの予測が非常に困難になります。完全にあなたのものである小さなプロジェクトで一人で作業している場合は、うまくいくかもしれませんが、もっと速く、要件を学習しながら展開していきます。途中で適切な原則を使用し、一貫性があれば、それほどリファクタリングする必要はありません。

職場では、カンバン、スクラム、およびより伝統的なウォーターフォールアプローチを使用しています。プロジェクトによっては、明確に定義された事前要件のある複雑な開発はアジャイルに最適ではないことがわかりますが、多くの人は反対します。

アジャイルプロジェクト(最も単純なものを除く)で作業を開始する前に、ドキュメントを作成します。モックアップ(UIに焦点を当てている場合)、一連の要件、および機能仕様があります。

開発では、機能仕様から技術仕様を作成するよう求められます。このプロセス中に、技術を特定し、必要な先行研究を行います。このプロセスは、要件/機能仕様のギャップを確認する機会を与え、そのような決定を行うための経験とシステム知識を持つ人々に前もって大きなテクノロジー決定を与えるので、私にとって非常に重要に思えます。

ただし、重要なことは、機能仕様は箇条書きのリストである可能性があり、技術仕様は通常モデルであり、いくつかの箇条書きとテクノロジーステアリングがあり、場合によっては3ページまたは4ページしかない場合があります。

アジャイルプロジェクトを実行しているときでも、ドキュメントを作成します。

  • すべてのドキュメントにはコストがかかります。
  • 高レベルの要件の移動と不適切な定義に対する開発にはコストがかかります。
  • 上記の適切なバランスは、プロジェクト、文化、人々によって異なります。
  • 文書化ジャストインタイムで、文書が古くなります。
  • かろうじて十分/十分に文書化します。
  • これらのドキュメントの保守や更新は行っておらず、それらに多大な労力を費やしていません。彼らは小さい。私たちはそれらを捨てることを期待しています。
  • テクノロジーの決定、漠然とした要件、アーキテクチャなどの大きな未知の要素を事前に解決します。
  • 始める前に私たちは何を開発しているか知っています。
  • 私たちは、開発者がドキュメントに関する情報に基づいた決定を下し、問題について話し合うことを信頼しています。
  • ドキュメントを介したコミュニケーションを大切にしています。関係者全員が頻繁にコミュニケーションを取ることを期待しています。
  • システム(概要)は、開発中ではなく、開発前にではなく、開発後に文書化します。

アジャイルプロセスに小さな滝があるのがわかります。

一人で作業する場合は、事前のモデル(図!)を作成し、技術を操作して選択します。次に、高レベルの要件に関するこの概念がある場合は、先に進み、俊敏な反復的な方法で開発しますが、適切な原則とあなたが行くにつれて一貫性を保ち、あなたはあなたが行くにつれてより少ない、より多くのリファクタリングを行う必要があります。

しかし、一般的に、実際のコストがかかる(趣味ではない)場合は、コードを書く前に何を開発しているのかを知ってください。十分な情報に基づいて、開発中に考え方を変えてください。そして、あなたのプロジェクトは大きく方向を変えるかもしれませんが、良い、明確に定義された基盤から始めます。


1

これが大まかに私が新しいプロジェクトを始める方法であり、私たちが小さなプロジェクトについて話していると仮定すると、それはかなりうまくいきました。たとえば、ORMまたはその規模の何かを書いている場合、私はこのルートに行きません。時々、私は本当に頭の中にいるとき、より正式な研究に頼ります。しかし、ほとんどの場合、コードを書き始めて、何が起こるかを確認します。ただし、これを行う場合は、多くのコードを破棄する準備をする必要があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.