Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/torniker/go-right

Sample project structure for Go projects
https://github.com/torniker/go-right

Last synced: 24 days ago
JSON representation

Sample project structure for Go projects

Awesome Lists containing this project

README 

        
# How to Go Right

ვინც წინა devfest-ზე იყავით, იმედია გახსოვთ ჩემი თოქი, Why Go? რატომ უნდა წავიდეთ?

დღეს ვეცდები გაჩვენოთ როგორ უნდა წავიდეთ მარჯვნივ. 

How to Go Right. 

როგორ წავიდეთ სწორად? 

მოკლედ ვისაუბროთ იმაზე თუ როგორ დავწეროთ კოდი Go-ზე “სწორად”.



## Disclaimer

მოცემული სოლუშენი, მაგალითები და საერთოდ ყველაფერი არის სისულელე და არ ნიშნავს რომ ესაა სწორი გზა, სათაურია უბრალოდ ეგეთი.



ყოველთვის ეცადეთ იპოვოთ უკეთესი და გააუმჯობესოთ არსებული.



## How Deep Does the Gopher Hole Go?

თანამედროვე სამყაროში რაც უფრო ვითარდება ტექნოლოგიები და ხდება საყოველთაო, მით უფრო იზრდება მოთხოვნა სოფტვეარზე და პროდუიქტებიც უფრო და უფრო კომპლექსური და მასშტაბური ხდება.

როგორ ბანალურადაც არ უნდა ჟღერდეს ეს წინადადება არის მასში სიმართლის მარცვალი.

ხოდა რაც უფრო გაიზარდა და გართულდა მოთხოვნები, პროგრამისტებმა ვცადეთ რომ კოდის წერის უკეთესი გზები და მეთოდები გვეპოვნა.



პირველი ნაბიჯები ამ მიმართულებით GoF-მა (Gang of Four) გადადგა, 1994 წელს გამოცემული წიგნით `Design Patterns`. მას მერე ვცდილობთ pattern-ების პოვნას რომელიც უკეთ მოერგება პროდუქტის მოთხოვნებს, გუნდის ზომას და კიდევ ბევრ სხვა რამეს. ალბათ გსმენიათ SOLID პრინციპებზე, DRY-ზე, KISS-ზე, YAGNI-ზე და ა.შ. ეს ყველაფერი სწორად ზემოთ ხსენებულს ემსახურება.

ყველაფერ სიკეთესთან ერთად Go შეიქმნა სწორად ამ პრობლემების მოსაგვარებლად. 

ჩემს და Go-ს ურთიერთობაზე ბევრს აღარ ვილაპარაკებ, ისედაც იმაზე მეტი გაგანდეთ წინაზე ვიდრე საჭირო იყო...

ახლა მინდა მოგიყვეთ რას მივაგენი, როცა ორმოებს ვთხრიდი და მიწისქვეშა გვირაბები გამყავდა, როგორც ჭეშმარიტ gopher-ს.



ფრაზები რომლებიც შეგიძლია გამოიყენო როგორც კოდი წერისას ასევე სექსის დროს?

- Go Deeper

- Go Faster

- Go Harder



ჩემს და Go-ს ურთიერთობაზე ბევრს აღარ ვილაპარაკებ, ისედაც იმაზე მეტი გაგანდეთ ვიდრე საჭირო იყო...



ხოდა რას ვამბობდი, ჯიგრებმა Google-დან სცადეს დეველოპერების მძიმე ტვირთის შემსუბუქება.



Go შეიქნმა მრავალბირთვიანობის, ქსელური მანქანების და დიდი კოუდბეიზის ერაში. შექმნის მიზანი არასდროს ყოფილა რაიმე სამეცნიერო თეორიის იმპლემენტაცია, მიზანი იყო დეველოპმენტის ეფექტურობის და  პროდუქტიულობის გაზრდა.

 

სწორად ამიტო ალბათ ის ერთ-ერთი ყველაზე მოსახერხებელი ენაა რომლის დახმარებითაც მრავალფეროვანი პროდუქტების შექმნაა შესაძლებელი.



## Drill Down

ახლა მინდა მოგიყვეთ რას მივაგენი, როცა ორმოებს ვთხრიდი და მიწისქვეშა გვირაბები გამყავდა, როგორც ჭეშმარიტ gopher-ს.



რასაც ახლა წარმოგიდგენთ საინტერესო უნდა იყოს სტარტაპებისთვის რომლებსაც უნდათ რომ სწრაფად დადონ MVP და არ დაკარგონ ზრდის უნარი პირველი ეტაპების გავლის შემდეგ.



თანამედროვე სოფტვეარის შექმნისას ავტომატურად გვეფიქრება მიკრო სერვისებზე და კოდის თუ ბიზნეს ლოგიკის ისე განაწილებაზე რომ მინიმალური იყოს მათ შორის დამოკიდებულება (dependecy)...  ამას გვეუბნება და გვასწავლის ბევრი უკვე არსებული მიდგომა.



ვინმეს თუ აგიწყვიათ სისტემა მიკრო სერვისებით გეცოდინებათ რომ პლიუსებთან ერთად ბევრი მინუსიც აქვს. როგორც წესი პროექტის კეთებისას გუნდების და მიკროსერვისების რაოდენობა ერთმანეთს არ ემთხვევა და ერთ გუნდს უწევს რამდენიმე მიკრო სერვისის თუ ბიბლიოთეკის დეველოპმენტ / მეინთენენსი. ვქმნით ხოლმე ცალ-ცალკე რეპოებს მათთვის და ცალკე რეპოებს მათი საერთო დეპენდესებისთვის, მშრალებიც (DRY) რომ ვიყოთ. ამ ყველაფრის მართვას მივყავართ დიდ თავის ტკივილთან და მერე ვამბობთ რომ მიკროსერვისები არ ვარგა, ცუდია და არა პრაქტიკულია.



თუმცა მგონია რომ შესაძლებელია ისე დავალაგოთ პროექტი რომ მიკროსერვისების უპირატესობები შევინარჩუნოთ და მის მინუსებს მინიმუმამდე დავიყვანოთ.



პირველ რიგში დავივიწყოთ ბევრი რეპო და მათი მეინთენენსი, მათი ცალ-ცალკე კონფიგურირება დაშვებების მართვა თუ სხვა დეტალები და მაიმუნობები რომლებიც თან ახლავს. თუმცა გავითვალისწინოთ ის რომ კოდი ისე უნდა დავწეროთ რომ საჭიროების შემთხვევაში ეს შესაძლებელი იყოს… თუ თიმი გაიზარდა და შესაბამისად შეგვეძლოს კოდის ისე დაყოფა რომ ერთმანეთს ხელი არ შევუშალოთ.



## გატვა

პირველ რიგში კოდის ორგანიზებისას გამოვყოფდი 3 ძირითად ნაწილს რის მიხედვითაც კოდს ვყოფ:

Callers

Domain

Helpers

Callers - არის კოდი რომელიც იძახებს Domain-ს, ეს შეიძლება იყოს http layer ან/და command line და რავი ნებისმიერი სხვა… ამ layer-მა იცის თუ რა პროტოკოლით მიიღებს request-ს და იცის როგორ უნდა თარგმნოს მოცემული რეკვესტი domain-სთვის გასაგებ ბრძანებაში.



Domain - ეს არის ბიზნეს ლოგიკის ლაიერი, ერთი პატარა განსხვავებით სტანდარტული მიდგომებისგან, როგორც წესი ამავე ლეიერში ვაქცევ ხოლმე persistance ლეიერს. იდეაში პერისტანს ლეიერს აცალკევებენ ხოლმე იმ მიზნით რომ თუ საჭირო გახდება ბაზის შეცვლა რომ ადვილად იყოს შესაძლებელი ამის გაკეთება მომავალში. თუმცა პრაქტიკაში იშვიათად თუ მქონია მსგავსი შემთხვევა სწორად ამიტომ პირველ ეტაპზე ამაზე დროის ხარჯვას ვამჯობინებ სწრაფ დეველოპმენტს და MVP-ს მალე დადებას ვიდრე კოდის უფრო დეტალურ დაყოფას.



Helpers - აქ შედის კოდი რომელსაც იზიარებს სხვადასხვა მოდული და არაა პირდაპირ დაკავშირებული ბიზნეს ლოგიკასთან