سؤال

أنا بدأت تعلم روبي.أنا أيضا يوما بعد يوم C++ dev.C++ المشاريع وعادة ما تذهب مع التالية dir هيكل

/
 -/bin <- built binaries
 -/build <- build time temporary object (eg. .obj, cmake intermediates)
 -/doc <- manuals and/or Doxygen docs
 -/src
 --/module-1
 --/module-2
 -- non module specific sources, like main.cpp
 - IDE project files (.sln), etc.

ما dir تخطيط روبي (غير القضبان ، غير Merb) تقترح أن تبقى نظيفة وبسيطة الصيانة?

هل كانت مفيدة؟

المحلول

محزم تشمل البنية التحتية اللازمة لتوليد جوهرة:

$ bundle gem --coc --mit --test=minitest --exe spider
Creating gem 'spider'...
MIT License enabled in config
Code of conduct enabled in config
      create  spider/Gemfile
      create  spider/lib/spider.rb
      create  spider/lib/spider/version.rb
      create  spider/spider.gemspec
      create  spider/Rakefile
      create  spider/README.md
      create  spider/bin/console
      create  spider/bin/setup
      create  spider/.gitignore
      create  spider/.travis.yml
      create  spider/test/test_helper.rb
      create  spider/test/spider_test.rb
      create  spider/LICENSE.txt
      create  spider/CODE_OF_CONDUCT.md
      create  spider/exe/spider
Initializing git repo in /Users/francois/Projects/spider
Gem 'spider' was successfully created. For more information on making a RubyGem visit https://bundler.io/guides/creating_gem.html

ثم في lib/ إنشاء وحدات حسب الحاجة:

lib/
  spider/
    base.rb
  crawler/
    base.rb
  spider.rb
    require "spider/base"
    require "crawler/base"

قراءة دليل الصفحة حزمة جوهرة لمزيد من التفاصيل على --coc, --exe و --mit خيارات.

نصائح أخرى

اعتبارا من عام 2011 ، فمن الشائع استخدام الصائغ بدلا من newgem وهذا الأخير هو فعليا التخلي عنها.

البنية الأساسية القياسية روبي المشروع هو في الأساس:

  lib/
    foo.rb
    foo/
  share/
    foo/
  test/
    helper.rb
    test_foo.rb
  HISTORY.md (or CHANGELOG.md)
  LICENSE.txt
  README.md
  foo.gemspec

على share/ نادر ويسمى في بعض الأحيان data/ بدلا من ذلك.هو للأغراض العامة غير روبي الملفات.معظم المشاريع لا تحتاج ذلك, لكن حتى عندما تفعل ذلك عدة مرات كل شيء هو مجرد الاحتفاظ بها في lib/, ، على الرغم من أن ربما ليس أفضل الممارسات.

على test/ الدليل يمكن أن يطلق عليه spec/ إذا BDD يتم استخدامه بدلا من TDD, على الرغم من أنك قد ترى أيضا features/ إذا كان الخيار هو استخدامها ، أو demo/ إذا كان هذا هو المطلوب المستخدمة.

في هذه الأيام foo.gemspec يمكن أن يكون مجرد .gemspec - خاصة إذا لم يتم الحفاظ يدويا.

إذا كان المشروع الخاص بك قد سطر الأوامر التنفيذية ، ثم تضيف:

  bin/
    foo
  man/
    foo.1
    foo.1.md or foo.1.ronn

بالإضافة إلى ذلك فإن معظم روبي المشروع هو:

  Gemfile
  Rakefile

على Gemfile هو استخدام محزم ، Rakefile هو الخليع بناء أداة.ولكن هناك خيارات أخرى إذا كنت ترغب في استخدام أدوات مختلفة.

قليلة أخرى ليس من غير المألوف الملفات:

  VERSION
  MANIFEST

على VERSION ملف يحتوي على رقم الإصدار الحالي.و MANIFEST (أو Manifest.txt) يحتوي على قائمة الملفات التي سيتم تضمينها في المشروع ملف حزمة(ق) (مثلا ، جوهرة حزمة).

ما قد ترى ، ولكن الاستخدام متقطع:

  config/
  doc/ (or docs/)
  script/
  log/
  pkg/
  task/ (or tasks/)
  vendor/
  web/ (or site/)

حيث config/ يحتوي على العديد من ملفات التكوين; doc/ يحتوي على إما إنشاء الوثائق ، مثلRDoc ، أو في بعض الأحيان يدويا الحفاظ على الوثائق ؛ script/ يحتوي على البرامج النصية قذيفة للاستخدام من قبل المشروع ؛ log/ يحتوي على إنشاء المشروع سجلات مثلااختبار التغطية التقارير ؛ pkg/ يحمل ولدت حزمة الملفات ، على سبيل المثال foo-1.0.0.gem; task/ قد عقد العديد من الملفات المهمة مثل foo.rake أو foo.watchr; vendor/ يحتوي على نسخ من المشاريع الأخرى مثلبوابة الوحدات الفرعية;وأخيرا web/ يحتوي المشروع ملفات الموقع.

ثم بعض أداة ملفات معينة التي هي أيضا شائعة نسبيا:

  .document
  .gitignore
  .yardopts
  .travis.yml

فهي إلى حد ما تفسر نفسها بنفسها.

أخيرا, سوف أضيف أنني شخصيا إضافة .index ملف var/ الدليل لبناء هذا الملف (البحث عن "Rubyworks المفهرس" لمعرفة المزيد عن هذا) و غالبا ما يكون work دليل شيئا مثل:

  work/
    NOTES.md
    consider/
    reference/
    sandbox/

مجرد نوع من الخردة لأغراض التنمية.

@Dentharg:الخاص بك "تشمل واحدة تشمل جميع الأجزاء الفرعية" هو النمط الشائع.مثل أي شيء له مزاياه (من السهل الحصول على الأشياء التي تريدها) و سلبياته (العديد من يشمل يمكن أن تلوث مساحات لا السيطرة عليها).النمط الخاص بك تبدو مثل هذا:

- src/
    some_ruby_file.rb:
      require 'spider'
      Spider.do_something

+ doc/

- lib/
  - spider/
      spider.rb:
        $: << File.expand_path(File.dirname(__FILE__))
        module Spider
          # anything that needs to be done before including submodules
        end

        require 'spider/some_helper'
        require 'spider/some/other_helper'
        ...

قد يوصي هذا للسماح أكثر من ذلك بقليل التحكم:

- src/
    some_ruby_file.rb:
      require 'spider'
      Spider.include_all
      Spider.do_something

+ doc/

- lib
  - spider/
      spider.rb:
        $: << File.expand_path(File.dirname(__FILE__))
        module Spider
          def self.include_all
            require 'spider/some_helper'
            require 'spider/some/other_helper'
            ...
          end
        end

لماذا لا تستخدم نفس تخطيط ؟ عادة لن تحتاج بناء لأن لا يوجد تجميع الخطوة ، ولكن بقية يبدو على ما يرام بالنسبة لي.

أنا لا أفهم ما تقصد من قبل وحدة ولكن لو كان مجرد فئة واحدة مجلد منفصل لن يكون ضروريا إذا كان هناك أكثر من ملف واحد تكتب عادة وحدة-1.rb الملف (على اسم مستوى الوحدة النمطية 1 مجلد) التي لا تتطلب أي شيء أكثر من كل شيء في الوحدة النمطية 1/.

أوه, و أود أن أقترح استخدام أشعل النار إدارة المهام (بدلا من جعل).

أود أن التمسك شيئا مشابها لما كنت معتادا على:ما فائدة أن تكون غريبا في المشروع الخاص بك الدليل.:-)

نموذجية الأشياء التي كنت دائما هي lib|src, بن, اختبار.

(أنا أكره هذه الوحش المولدات:أول شيء أريد أن أفعله مع مشروع جديد هو الحصول على بعض التعليمات البرمجية إلى أسفل ، وليس كتابة التمهيدي, مستندات, الخ!)

لذا ذهبت مع newgem.أنا إزالة جميع لا لزوم لها RubyForge/جوهرة الاشياء (مجرفة الإعداد ، الخ) ، إنشاء بوابة الريبو المستوردة المشروع في NetBeans.جميع استغرق 20 دقيقة و كل شيء على الأخضر.حتى أعطاني الأساسية الخليع مهمة المواصفات الملفات.

شكرا لكم جميعا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top