学習者
最初からアプリケーション全体の構成を決めずに、プログラミング言語を練習したり、小さなコーディング課題に取り組んだりしたい方。
空のワークスペースから始め、目的を絞ったファイルを1つ追加し、変更するたびにテストしましょう。
初心者向けReplitクイックスタートガイド
ReplitでReplを作成する方法は、用意されたひな形から始めるか、空のワークスペースから始めるかによって異なります。目的に合った方法を選び、作業を進める前にプロジェクトを確認しましょう。
これらのガイドでは、ワークスペースを開いた後に検討することになる次の選択肢を扱います。
最初に適切な方法を選べば、その後の設定が簡単になります。実際に取り組みたいことに合うカードを選びましょう。
最初からアプリケーション全体の構成を決めずに、プログラミング言語を練習したり、小さなコーディング課題に取り組んだりしたい方。
空のワークスペースから始め、目的を絞ったファイルを1つ追加し、変更するたびにテストしましょう。
初心者向けReplit作りたいスクリプトの種類がすでに決まっていて、作成、実行、修正を行える実用的な場所が必要な方。
Pythonをすぐに使える開始方法を選び、プロジェクトにわかりやすい名前を付け、最初は小さな処理だけを実行しましょう。
ReplitでPythonを使うインタラクティブなアプリの大まかなアイデアがあり、単一のコードスニペットを超えて拡張できる構成を求めている方。
適切なテンプレートまたは生成された初期プロジェクトから始め、サンプルの内容を独自のロジックに置き換えます。
Replitアプリの例以前にこのプラットフォームを使用したことがあり、既存の実験やチュートリアルを続けるためにワークスペースを開いています。
既存のプロジェクトを開き、選択したファイルを確認して、何かを変更する前に現在のバージョンを実行します。
Replitの使い方テンプレート、言語のスターター、または生成されたプロジェクトが、空の状態から始めるよりも役立つ土台になる場合は、このパスを使用します。
作成フローを開き、最も近い言語、テンプレート、またはプロジェクトの説明を選びます。幅広いものより、目的に合う小規模なものを選びましょう。目標は、始める前に機能を詰め込むことではなく、自分で把握できるワークスペースを作ることです。
プロジェクトに具体的な名前を付け、編集する前にファイルツリーを確認します。メインファイル、設定ファイル、画面上の実行ボタンを見つけ、初期プロジェクトで何が想定されているかを把握しましょう。
変更を加える前にプロジェクトを実行します。最初の実行が成功すれば比較の基準になります。失敗した場合は、独自のコードを追加する前にセットアップの問題を解決できます。
一般的な2つの開始方法は、どちらも有効です。どちらが適しているかは、最初の変更を加える前にどの程度の構成を理解したいかによって決まります。
適している用途
テンプレートまたはスターター
構成、言語、または処理の流れが分かりやすいプロジェクト
空のワークスペース
最初に作るファイルが明確な、小規模な実験、レッスン、スクリプト、またはプロジェクト
初期構成
テンプレートまたはスターター
ファイルや規約がすでに用意されている
空のワークスペース
ファイル名や構成を自分で決める
最初のアクション
テンプレートまたはスターター
置き換えたり拡張したりする前に、既存のファイルを読む
空のワークスペース
メインファイルを作成し、役立つ最小限のバージョンを書く
主な利点
テンプレートまたはスターター
スターターが目標に近い場合、セットアップ作業を減らせる
空のワークスペース
より自由度が高く、関係のないコードを理解する負担が少ない
主なリスク
テンプレートまたはスターター
使われていないサンプルコードによって、プロジェクトに実際に必要なものが分かりにくくなることがある
空のワークスペース
必要なファイル、コマンド、または実行設定を忘れる可能性がある
推奨される最初のテスト
テンプレートまたはスターター
動作を変更する前に、元のスターターを実行する
空のワークスペース
すぐに最小限の出力または入力テストを実行する
切り替えるタイミング
テンプレートまたはスターター
テンプレートが価値よりも混乱を招く場合は、空白の状態に移行する
空白のワークスペース
繰り返しのセットアップ自体が本当の問題になったら、スターターを使う
最初のルートが重すぎると感じる場合は、空白のワークスペースから始めて、検証済みの要素を1つずつ構築します。変更前と変更後の違いは見た目よりも、不確実性を減らせることにあります。
変更前:未検証の開始
変更後:確認済みのワークスペース
最初の試行は、何が変わったのか、そしてなぜ変わったのかを把握できる程度に絞り込みます。
ワークスペースの作成は始まりにすぎません。こうした制限は通常のもので、それぞれに実用的な回避策があります。
作成フローで開始時の構造は用意できますが、アイデアが完成していること、テスト済みであること、他の人が使える状態であることまでは証明されません。
回避策
小さなユーザー成果を1つ定義し、画面や機能を追加する前に、その成果をテストします。
サンプルファイル、依存関係、命名規則によって、スターターが本来作ろうとしていたプロジェクトよりも複雑に感じられることがあります。
回避策
まずエントリーファイルを読み、明らかに無関係なサンプルを削除し、残した各ファイルの役割を短くメモしておきます。
プロジェクトが起動しても、境界条件での誤動作、入力処理の不備、アプリ内の未完成の処理経路が残っている場合があります。
対処法
通常の入力、想定外の入力、プロジェクトで得たい主な結果をそれぞれ1つずつテストします。
最初に達成する結果を決めていないと、有意義な作業を進める代わりに、設定の細部を変更し続けてしまいがちです。
対処法
最初の機能を「1つの値を受け取り、明確な結果を1つ表示する」のように具体的な一文で書き、それだけを作ります。
スターターと空のプロジェクトのどちらが必要か決まれば、次にすることは明確です。最初に役立つバージョンを説明し、作成されたものを確認して、初回の実行を検証します。重要なファイルをすべて理解できるよう、作業範囲を小さく保ちましょう。
新しいReplitを作成する現在の手順で新しいReplitを作成する際によくある質問への回答です。
プロジェクトの作成画面を開き、適切なスターターまたは空のワークスペースを選び、プロジェクトに分かりやすい名前を付けます。開いたらファイルを確認し、大きな変更を加える前に初期バージョンを実行します。
テンプレートには、用途に合わせて変更できる既存の構成、ファイル、規約が用意されています。空のワークスペースは自由度が高い一方、最初のファイルと基本構成を自分で決める必要があります。
手順に沿った例を進める場合や、動作する構成を見たい場合は、小さなテンプレートから始めましょう。課題が単純で、ファイル構成の組み立て方を学びたい場合は、空のプロジェクトを選びましょう。
プロジェクトを開いたときに想定どおりのファイルがあり、主なエントリーポイントが明確で、初回の実行が想定どおりに完了することを確認します。その後、小さな変更を1つ加えて再実行し、その変更が反映されていることを確かめます。
一度にすべてを変更しないでください。エントリーファイルを特定し、元のバージョンを実行して、理解できるコードだけを削除しましょう。次の変更で問題が起きたときに復元できるよう、動作する最小限の状態を残してください。