আপনি কীভাবে আপনার প্রকল্পগুলির ফোল্ডারগুলি সংগঠিত করবেন? [বন্ধ]

Question

শুভ অপরাহ্ন

আমি জানতে চাই আপনি ছেলেরা কীভাবে আপনার প্রকল্পের ফোল্ডারগুলি সংগঠিত করবেন?

আমার একবার বস ছিল যা আমাকে গ্রাহকদের দ্বারা সংগঠিত করার পরামর্শ দেয়।

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

আমার এক বন্ধু আমাকে প্রযুক্তি দ্বারা টেম সংগঠিত করতে বলেছিল

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

এবং তুমি? আপনার প্রকল্পের ফোল্ডারগুলি গুছিয়ে রাখার জন্য কি আপনার কোনও চতুর উপায় আছে?

Comments

# 2 ভাল ...

— ইউশা আলেয়াউব

হাই, 2018 এখানে। আপনি কি চয়ন করেছেন?

— দানিয়াল আয়টেকিন

Answer 1

এটি আমরা ব্যবহার করে যাচ্ছি:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

আমরা এই কাঠামোটি বহু বছরের জন্য বিভিন্ন গ্রাহকের সাথে একাধিক প্রকল্পের জন্য ব্যবহার করে আসছি এবং এটি খুব ভালভাবে কাজ করে।

এটি আপনার প্রাথমিক পরামর্শের সাথে খুব মিল, তবে আমরা সংস্করণ পরিচালনা করতে সংস্করণ নিয়ন্ত্রণ ব্যবহার করি। সার্ভারের সংগ্রহস্থলের নাম অন্য কোনও কিছুর পরিবর্তে "গ্রাহক এক্স - প্রকল্প ওয়াই" হিসাবে রাখা হয়েছে। এটি আমাদের কয়েকটি প্রকল্পে বহিরাগত ঠিকাদারদের কাজ করার অনুমতি দেয় তবে অন্যদের অ্যাক্সেস করতে সক্ষম হয় না কারণ আমরা সংস্করণ নিয়ন্ত্রণের রুটে অনুমতি নির্ধারণ করতে পারি।

প্রত্যেকে তাদের (উইন্ডোজ) ডেভ মেশিনে যেখানে খুশি সেখানে তাদের কাজের কপিগুলি পরীক্ষা করে এবং সেই জায়গায় ড্রাইভ লেটার ম্যাপ করতে SUBST কমান্ডটি ব্যবহার করে। এইভাবে আমাদের বিল্ড ফাইল ইত্যাদিতে হার্ড-কোডেড আপেক্ষিক পাথ থাকতে পারে যা প্রত্যেকের সেটআপ জুড়ে কাজ করে। সুতরাং, উদাহরণস্বরূপ, আমরা চাইলে ভাগ করা লাইব্রেরিগুলিতে লিঙ্ক রাখতে পারি। এই সাধারণতটি অর্জনের জন্য আমরা সাধারণত সংস্করণ নিয়ন্ত্রণ লিঙ্ক / উপকরণগুলি ব্যবহার করি।

এই কাঠামোর একটি বড় সুবিধা হ'ল আপনি গ্রাহকদের কোড একে অপরের থেকে বিচ্ছিন্ন করতে পারেন। এটি কার্যকর যদি আপনার (ক) সংহতকরণের উদ্দেশ্যে উত্সটির নিয়মিত আপডেটগুলি তাদের প্রেরণ করা প্রয়োজন, (খ) কোডের নির্বাচিত অংশগুলিতে বহিরাগত ঠিকাদারদের কাজ করা উচিত।

আপনার দ্বিতীয় পরামর্শটি কোনও জটিল প্রকল্পে এত ভাল কাজ করবে না যা একাধিক প্রযুক্তি ব্যবহার করে।

Comments

হার্ডকোডযুক্ত পরম পাথের প্রয়োজনের জন্য বেশ যুক্তিসঙ্গত, তবে -1। হার্ডকোডযুক্ত আপেক্ষিক পাথগুলি 99.9% জিনিসের জন্য কাজ করা উচিত।

— ওয়াইয়াট বার্নেট

এর, আমি কি সেখানে পরম পথ রেখেছি?

— জেবিআরউইলকিনসন

Answer 2

আমি বেশ ফ্ল্যাট:

/ প্রকল্প

কিছু নির্ভরযোগ্যতা বক্সের উপর নির্ভর করে সেখানে পৌঁছেছে, তবে এর পিছনে প্রকল্পগুলির জন্য কেবলমাত্র প্রচুর পৃথক ফোল্ডার রয়েছে। বাস্তব চুক্তি যে কোনওভাবে উত্স নিয়ন্ত্রণে থাকে, সুতরাং এটি কেবল অস্থায়ী স্থানীয় বাড়ি।

Answer 3

আমার এমন একটি কাঠামো রয়েছে যা নিছক নীচের মত দেখাচ্ছে:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archivesপুরানো প্রকল্পগুলিতে রয়েছে আমি আর কাজ করছি না। Workকাজ সম্পর্কিত প্রকল্প রয়েছে। Currentসমস্ত বর্তমান উন্নয়ন। তারপরে, আমার হোম ডিরেক্টরিতে, আমি এতে সিলেট Projectsকরি ~/Developer/Projects/Current। ~/Projectsকিছু কাজের প্রকল্পের সিমলিংকগুলিও অন্তর্ভুক্ত।

Comments

কারেন্ট থেকে ওয়ার্কে সংরক্ষণাগারগুলিতে প্রকল্পগুলি সরানো উত্স সংস্করণ নিয়ন্ত্রণ সরঞ্জামগুলি ব্যবহার করে ভাল হয় না। এক্ষেত্রে ফোল্ডারের রেফারেন্স / লিঙ্ক (ওয়ার্কিং কপির বাইরে) থাকা ভাল। সম্ভবত আপনি 'সংরক্ষণাগার', 'কারেন্ট' এবং 'কাজ' এর ভিতরে কাজকর্মগুলি অনুলিপি করছেন?

— ফীল

@ ফিল: আমি গিট ব্যবহার করি। প্রতিটি প্রকল্পের নিজস্ব স্ব-অন্তর্ভুক্ত রেপো হয়, তাই এটি কোথায় স্থানান্তরিত হয় তা বিবেচনা করে না।

— মিপাদি

Answer 4

আমারও সমতল কাঠামো আছে।

/ প্রকল্প

ওয়াইয়াট বার্নেটের সাথে একমত হয়ে, বাস্তব চুক্তি যাইহোক উত্স নিয়ন্ত্রণে থাকে।

কেবল যুক্ত করতে চাই যে ফোল্ডারের কাঠামো সম্পর্কে যে কোনও বিশেষরকম হওয়া উচিত নয়, যেহেতু অনেক IDEs সাম্প্রতিক প্রকল্পগুলি / ফাইলগুলিকে শর্টকাট সরবরাহ করে। এবং যে কোনও উপায়ে কতগুলি প্রকল্প কাজ করে? সত্যই, কেবল সংজ্ঞা অনুসারে, সাম্প্রতিকটি।

এছাড়াও, আমি যাইহোক যাইহোক কেবল শীর্ষ স্তরের ফোল্ডারে সাম্প্রতিক প্রকল্পগুলি যুক্ত করি। আমি পুরানো এবং সমাপ্ত সমস্ত স্টাফ এতে আর্কাইভ করি:

/ প্রকল্প / Old_stuff

বা এই জাতীয় কিছু। আমি সাধারণত যা কাজ করব না তা সংরক্ষণ করি।

Comments

আপনি অবাক হবেন - আমার সাধারণত এক ডজন বা তার বেশি প্রজেক্টগুলির প্রয়োজন হয়, বর্তমান এবং আমার "গো" ল্যাপটপে চালানোর জন্য প্রস্তুত এবং কোনও সাধারণ দিনের মধ্যে আধা ডজন সহজেই খোলা যায়।

— ওয়াট বার্নেট

Answer 5

আমি অতীতে, আমার উত্স নথি সংরক্ষণের জন্য সাবভার্সন সংগ্রহশালা ব্যবহার করেছি এবং সংগ্রহস্থল সংস্থার জন্য "প্রকল্প-গৌণ" কনভেনশন অনুসরণ করেছি, যা আমি বড় এবং ছোট উভয় প্রতিষ্ঠানের পক্ষে খুব ভালভাবে কাজ করতে দেখেছি।

আমরা আমাদের ভাণ্ডার শাখা গঠন করব; ট্যাগ এবং ট্রাঙ্ক নীচে:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

প্রকৃত উত্স গাছের মধ্যেই আমরা নিম্নলিখিত কাঠামোটি ব্যবহার করব (এর মতো কিছু):

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

ইঞ্জিনিয়ারিং দলের মধ্যে কাঠামো যোগাযোগের ক্ষেত্রে সাহায্যের জন্য সংগ্রহস্থলের কাঠামোটি ব্যবহার করার (এবং এখনও রয়েছে) ধারণাটি ছিল; ব্যবসায়ের গ্রাহক-মুখোমুখি অংশ এবং অন্যান্য বিভিন্ন স্টেকহোল্ডার এবং ডোমেন বিশেষজ্ঞ

বুদ্ধিমান হতে: উত্স নথি যা "প্রকল্প" ডিরেক্টরিগুলির মধ্যে একটিতে বসে থাকে কেবল একবার একবার ব্যবহার হয়ে যায় (এবং অর্থ উপার্জন করে)। "প্রোডাক্টলাইনস" ডিরেক্টরিগুলির মধ্যে যে কোনও একটি দস্তাবেজগুলি সেই নির্দিষ্ট লাইন থেকে পণ্য বিক্রি হওয়ার পরে বহুগুণ অর্থ উপার্জন করে। "লাইব্রেরি" ডিরেক্টরিগুলির মধ্যে যে কোনও একটি দস্তাবেজগুলি যে সমস্ত পণ্য ব্যবহার করে সেগুলি বিক্রি হয়ে যায় তার থেকে বহুগুণ বেশি অর্থ উপার্জন করে।

এটি ব্যয়গুলির সূক্ষ্মকরণের ধারণাটি সুস্পষ্ট করে তোলে এবং ব্যবসায়ের পুরো উত্স নথির পুনরায় ব্যবহারের জন্য সমর্থন তৈরি করতে সহায়তা করে।

একটি আদর্শ বিশ্বে, ব্যবসায়ের অংশগ্রাহক গ্রাহকরা উপস্থাপনা এবং অন্যান্য বিক্রয় জামানত সংরক্ষণ করতে এই কাঠামোটি ব্যবহার করবেন, যাতে বিকাশকারীরা প্রাসঙ্গিক পণ্য ডিরেক্টরিটির পাশাপাশি গ্রাহক প্রত্যাশা কী তৈরি হয়েছে তা দেখতে পাবেন এবং গ্রাহকের মুখোমুখি সহকর্মীরা উন্নয়ন ট্র্যাক করতে পারবেন তারা বিক্রি করছে এমন বৈশিষ্ট্য এবং পণ্যগুলিতে অগ্রগতি।

এর অর্থ হ'ল এখানে একটি সাধারণ কাঠামো রয়েছে যার উপরে আমাদের বিল্ড অটোমেশন সরঞ্জামগুলি পরিচালনা করতে পারে। (আমাদের বিল্ড স্ক্রিপ্টগুলি "বিল্ড" ফোল্ডারগুলির সন্ধানকারী উত্স গাছের পথে হাঁটে যার মধ্যে তারা কনফিগারেশন ফাইলগুলি সন্ধান করে যা প্রতিটি উপাদান কীভাবে তৈরি করা যায় তা উল্লেখ করে; ডকুমেন্টেশন জেনারেশন এবং পরীক্ষার জন্য অনুরূপ প্রক্রিয়া ঘটে)। আবার, একটি আদর্শ বিশ্বে প্রতিষ্ঠানের ওয়েবসাইট এবং অন্যান্য বিপণন জামানত একই পদ্ধতিতে নির্মিত হতে পারে।

একটি চূড়ান্ত নোট হিসাবে; অবিচ্ছিন্ন ইন্টিগ্রেশন সিস্টেম জানে যে এটি একটি বিল্ড ট্রিগার করা প্রয়োজন; স্থির বিশ্লেষণ; প্রতিবার ট্রাঙ্কটি সংশোধন করা হলে প্রতিটি ধোঁয়া পরীক্ষা ও ইউনিট পরীক্ষা চালানো হয়, প্রতিবার কোনও "ট্যাগ" শাখা সংশোধন করা হয় এবং প্রতিবার কোনও "স্বয়ংক্রিয়" শাখা শাখা সংশোধন করা হয়। এইভাবে, পৃথক বিকাশকারীরা তাদের ব্যক্তিগত শাখা, একটি গুরুত্বপূর্ণ সামর্থ্য, আইএমএইচও সহ সিআই সিস্টেমটি ব্যবহার করতে পারে।

Answer 6

আমি মনে করি আপনার অর্থ "ডকুমেন্টেশন ফোল্ডার"। আমি "নথিভুক্ত এবং রক্ষণাবেক্ষণ" এর জন্য গ্রাহক / আবেদনের পরে, প্রথমে সেক্টরের জন্য আমার নথিগুলি সাজিয়েছি।

উদাহরণ: প্রকল্পসমূহ

• আর্থিক

  • ওয়েব অ্যাপ্লিকেশন

    • অ্যাপ্লিকেশন আলফা

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • অ্যাপ বিটা

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • ডেস্কটপ সফটওয়্যার
• শক্তি এবং ইউটিলিটিস
• বিএলএ বিএলএ

Comments

সংস্করণ নিয়ন্ত্রণ সম্পর্কে কি? একটি আলফা ডকুমেন্ট বিকাশের সাথে সাথে বিটা ডকুমেন্টে পরিণত হয় না?

— জেবিআরওয়িলকিনসন 21

স্থানীয় ডেস্কটপে আমার কাছে সমস্ত সংস্করণের সমস্ত অনুলিপি নেই: কোড, ডকুমেন্টস ইত্যাদির শেষ স্থিতিশীল সংস্করণটি পেয়েছি আমার যদি পূর্ববর্তী অন্য সংস্করণের প্রয়োজন হয় তবে আমি এই সংস্করণটি সাবভার্শন এবং সিমিলিয়া দ্বারা ডাউনলোড করেছি (এতে অন্য প্রকল্প হিসাবে সংরক্ষণ করছি) ক্ষেত্রটি: অ্যাপ্লিকেশন বিটা_সভারশন_এক্সওয়াইজেড যদি আর্থিক হয়)

— আলেপুজিও