গো প্রকল্পটি [বন্ধ] লেআউট করার একটি বুদ্ধিমান উপায় কী?

113

বন্ধ । এই প্রশ্নটি মতামত ভিত্তিক । এটি বর্তমানে উত্তর গ্রহণ করছে না।

এই প্রশ্নটি উন্নত করতে চান? প্রশ্নটি আপডেট করুন যাতে পোস্টটি সম্পাদনা করে সত্য এবং উদ্ধৃতি দিয়ে উত্তর দেওয়া যায় ।

গত বছর বন্ধ ছিল ।

এই প্রশ্নটি উন্নত করুন

আমার একটি গো প্রকল্প রয়েছে যা আরও জটিল হয়ে উঠতে শুরু করেছে এবং ব্যথা কমাতে এমন পদ্ধতিতে ফাইল সিস্টেমটি ছড়িয়ে দিতে চাই।

কিছু ভাল উদাহরণ আছে যার অর্থ কী?

go project

— aussiegeek
সূত্র

132

মে 2013 আপডেট করুন: অফিসিয়াল ডকুমেন্টেশন " কোড সংস্থা " বিভাগে রয়েছে

গো কোড অবশ্যই একটি কর্মক্ষেত্রের ভিতরে রাখতে হবে ।
একটি ওয়ার্কস্পেস তার ডিরেক্টরিতে তিনটি ডিরেক্টরি সহ একটি ডিরেক্টরি শ্রেণিবিন্যাস:

src প্যাকেজগুলিতে সংগঠিত গো উত্স ফাইল রয়েছে (প্রতি ডিরেক্টরিতে একটি প্যাকেজ),
pkg প্যাকেজ অবজেক্টস রয়েছে, এবং
bin এক্সিকিউটেবল কমান্ড রয়েছে।

go toolউৎস প্যাকেজ তৈরী করে এবং ফলে বাইনেরিতে ইনস্টল pkgএবং binডিরেক্টরি।

srcসাব সাধারণত (যেমন গীত বা Mercurial জন্য) একাধিক সংস্করণ নিয়ন্ত্রণ ভান্ডার যা এক বা একাধিক উৎস প্যাকেজ গঠন ট্র্যাক রয়েছে।

bin/
    streak                         # command executable
    todo                           # command executable
pkg/
    linux_amd64/
        code.google.com/p/goauth2/
            oauth.a                # package object
        github.com/nf/todo/
            task.a                 # package object
src/
    code.google.com/p/goauth2/
        .hg/                       # mercurial repository metadata
        oauth/
            oauth.go               # package source
            oauth_test.go          # test source

জুলাই ২০১৪ আপডেট করুন: বেন জনসনের " স্ট্রাকচারিং অ্যাপ্লিকেশনগুলিতে যান " দেখুন

এই নিবন্ধটিতে টিপস অন্তর্ভুক্ত রয়েছে:

আপনার বাইনারি আপনার অ্যাপ্লিকেশন থেকে পৃথক করুন

main.goএকই প্যাকেজে ফাইল এবং আমার অ্যাপ্লিকেশন যুক্তির সংমিশ্রণের দুটি পরিণতি রয়েছে:

এটি আমার অ্যাপ্লিকেশনটিকে গ্রন্থাগার হিসাবে অকেজো করে তোলে।

আমি কেবল একটি বাইনারি আবেদন করতে পারি।

cmdএটির সমাধানের সবচেয়ে ভাল উপায়টি হ'ল আমার প্রকল্পে কেবল একটি " " ডিরেক্টরি ব্যবহার করা যেখানে এর প্রতিটি উপ-ডিরেক্টরি একটি অ্যাপ্লিকেশন বাইনারি।

camlistore/
  cmd/
    camget/
      main.go
    cammount/
      main.go
    camput/
      main.go
    camtool/
      main.go

লাইব্রেরি চালিত উন্নয়ন

মুভিং main.goজন্য root ফাইল থেকে তোমাদের বের করে একটি লাইব্রেরি দৃষ্টিকোণ থেকে আপনার আবেদন নির্মাণ করতে পারবেন। আপনার অ্যাপ্লিকেশন বাইনারি কেবল আপনার অ্যাপ্লিকেশনের লাইব্রেরির ক্লায়েন্ট।

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

adder/
  adder.go
  cmd/
    adder/
      main.go
    adder-server/
      main.go

উপবৃত্তির সাহায্যে ব্যবহারকারীরা আপনার "অ্যাডারের" অ্যাপ্লিকেশন বাইনারিগুলি "Go get" দিয়ে ইনস্টল করতে পারেন:

$ go get github.com/benbjohnson/adder/...

এবং ভয়েলা, আপনার ব্যবহারকারীর " adder" এবং " adder-server" ইনস্টল করা আছে!

সাবপ্যাকেজ সহ পাগল হয়ে যাবেন না

সাধারণত আমার প্রকল্পের প্রকারগুলি সবগুলি খুব সম্পর্কিত তাই এটি ব্যবহারযোগ্যতা এবং এপিআই দৃষ্টিকোণ থেকে ভাল ফিট করে।
এই প্রকারগুলি তাদের মধ্যে অপরিবর্তিত কল করার সুবিধাও নিতে পারে যা এপিআইকে ছোট এবং পরিষ্কার রাখে।

প্রতিটি ফাইলটিতে গ্রুপ সম্পর্কিত প্রকার ও কোড একসাথে। যদি আপনার ধরণ এবং ফাংশনগুলি সুসংহত থাকে তবে আমি দেখতে পাচ্ছি যে ফাইলগুলি 200 থেকে 500 এসএলওসি এর মধ্যে থাকে। এটি অনেকটা মনে হতে পারে তবে নেভিগেট করা আমার কাছে সহজ মনে হয়েছে। 1000 এসএলওসি সাধারণত একটি একক ফাইলের জন্য আমার উপরের সীমা।

ফাইলের শীর্ষে সর্বাধিক গুরুত্বপূর্ণ টাইপটি সংগঠিত করুন এবং ফাইলের নীচের দিকে গুরুত্ব হ্রাসে প্রকারগুলি যুক্ত করুন।

আপনার অ্যাপ্লিকেশনটি 10,000 এসএলওসি-র উপরে উঠতে শুরু করলে আপনার এটি ছোট প্রকল্পে বিভক্ত হতে পারে কিনা তা গুরুত্ব সহকারে মূল্যায়ন করা উচিত।

দ্রষ্টব্য: সর্বশেষ অভ্যাসটি সবসময় ভাল হয় না:

দুঃখিত আমি এই অনুশীলনের সাথে একমত হতে পারি না।
টাইপগুলিকে ফাইলগুলিতে পৃথক করা কোড পরিচালন, পাঠযোগ্যতা, মেনটেন্যান্সিবিলিটি, টেস্টিবিলিটি সহায়তা করে।
এটি একক দায়বদ্ধতা এবং উন্মুক্ত / বদ্ধ নীতি অনুসরণ করাও নিশ্চিত করতে পারে ...
বিজ্ঞপ্তি নির্ভরতা না দেওয়ার নিয়মটি হল আমাদের প্যাকেজগুলির একটি সুস্পষ্ট কাঠামো বাধ্য করা force

( srcকেবলমাত্র সম্পর্কিত সম্পর্কিত ফেব্রুয়ারী ২০১৩ )
আপনি " গিটহাব কোড লেআউট " এ চিত্রিত ক্লাসিক লেআউটটি খুঁজে পেতে পারেন :

অ্যাপ্লিকেশন এবং উভয় গ্রন্থাগার পৃথক পৃথক গিথুবে রয়েছে।
$GOPATHপ্রকল্পের মূল - আপনার প্রতিটি গিতুব রেপো নীচে বেশ কয়েকটি ফোল্ডার পরীক্ষা করা হবে $GOPATH।

আপনার কোড লেআউটটি দেখতে এমন হবে:

$GOPATH/
    src/
        github.com/
            jmcvetta/
                useless/
                    .git/
                    useless.go
                    useless_test.go
                    README.md
                uselessd/
                    .git/
                    uselessd.go
                    uselessd_test.go
                    README.md

প্রতিটি ফোল্ডারের নীচে src/github.com/jmcvetta/পৃথক গিট চেকআউটের মূল।

এই reddit পৃষ্ঠায় যদিও এটি কিছু সমালোচনা আকর্ষণ করেছিল :

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

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

এটি ডাউনলোড, বিল্ড, ইনস্টল এবং সেটআপ করার জন্য কেবলমাত্র দুটি পদক্ষেপ প্রক্রিয়া: .:

" go get <your repo path>": সম্পদের সাবডির সহ গো কোডটি ডাউনলোড এবং ইনস্টল করে

$GOPATH/<your repo path>/setup.sh: সম্পত্তি সঠিক জায়গায় বিতরণ করে এবং পরিষেবাটি ইনস্টল করে

— VonC
সূত্র

15

এর একটি (বড়) সমস্যা setup.shহ'ল গো যুক্তিসঙ্গতভাবে ক্রস প্ল্যাটফর্ম যেখানে পসিক্স শেল স্ক্রিপ্টগুলি নেই।

— kostix

Jmcvetta কাঠামোটি গো গেটটি ভাঙবে না , যেহেতু অকেজো আমদানি অকেজো, গো গেট গো ... / অকেজোহাঁটি উভয়ই ইনস্টল করবে। তবে আমি সম্মত হই যে বেহুদা যদি বিশেষত অকেজো জন্য তৈরি করা গ্রন্থাগার হয় তবে এটি একটি একক গিট রেপোতে সাবফোল্ডার বা ভাইবোন হিসাবে রাখাই আরও বেশি অর্থবোধ করে।

— এমএনএ

@ পুয়েরকিটোবিও আমি সম্মত। সংস্করণ নিয়ন্ত্রণ এবং উপাদান-ভিত্তিক পরিচালনায় আমার প্রশিক্ষণ ( স্ট্যাকওভারফ্লো.com / a / 933735 / 6309 ) রেপো প্রতি একটি উপাদানটির দিকে আমাকে আরও বাড়িয়ে তোলে, সুতরাং এই উত্তরের দ্বিতীয় অংশ।

— ভনসি

7

আমি ধরে নিয়েছি যে 'প্রজেক্ট' দিয়ে আপনার অর্থ গো প্যাকেজ নয় তবে আপনার তৈরি হওয়া একটি সফ্টওয়্যার। অন্যথায় আপনি এখানে এবং এখানে সহায়তা পেতে পারেন । যাইহোক এটি প্যাকেজ লিখতে এতটা আলাদা নয়: প্যাকেজগুলি ব্যবহার করুন, প্রতিটি প্যাকেজের জন্য একটি ফোল্ডার তৈরি করুন এবং আপনার অ্যাপ্লিকেশনটিতে এই প্যাকেজগুলি একত্র করুন।

নিজেকে একটি মতামত তৈরি করতে, আপনি গিথুবটিতে ট্রেন্ডিং গো সংগ্রহস্থলগুলি দেখতে পারেন: https://github.com/trending/go । উল্লেখযোগ্য উদাহরণগুলি হল ক্যালে এবং জিউস ।

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

— নিমো
সূত্র

@aussiegeek, আমি একটি যান বিশেষজ্ঞ নই, কিন্তু আমি সফলভাবে প্রয়োগ না কি আমার নিজের কোডে প্রস্তাবিত নিমো - ধারণা আপনি মডিউল থাকতে পারে যে অধীনে আপনার প্রকল্পের তালিকা, আপনি শুধু তাদের পূর্ণ উপসর্গ ব্যবহার করে সেগুলি উল্লেখ করতে আছে - আপেক্ষিক থেকে $GOPATH/srcবা তাদের ব্যবহার go get-table নাম থাকবে না।

— kostix

doozerdএকটি ভাল উদাহরণ নয়, এমনকি এর পরীক্ষাগুলিও দুর্বল।

— Inanc Gumus

@ আইয়ান্কগুমাস আমি আপনাকে আরও ভাল উদাহরণ দেওয়ার পরামর্শ দিচ্ছি।

— নিমো

দেখতে এই এবং এই ।

— Inanc Gumus

1

গোলংয়ের লেখকদের একটি প্রস্তাবিত পন্থা রয়েছে যা কীভাবে গো সরঞ্জামগুলির সাথে সর্বোত্তমভাবে কাজ করতে এবং উত্স নিয়ন্ত্রণ ব্যবস্থা সমর্থন করার জন্য আপনার কোডটিকে কীভাবে বিন্যাস করতে হয় তা নির্ধারণ করে

— FigmentEngine
সূত্র

1

এটি কীভাবে বিন্যাস করা যায় $GOROOT, src/<project>ডিরেক্টরিটির মধ্যে কোড নয় ।

— ডক্যাচট

1

আপনারও সম্ভবত এই রেপোটি দেখে নেওয়া উচিত। এটি কীভাবে অ্যাপ্লিকেশনগুলিকে কাঠামোগত করতে পারে তার অনেকগুলি ধারণা দেখায়: https://github.com/golang-standards/project-layout

— Tarion
সূত্র