მიმოხილვები 

JavaScript პროგრამირების ენა: ინფორმაცია დამწყებთათვის. რატომ გამოვიყენოთ სტატიკური ტიპები JavaScript-ში? (Დადებითი და უარყოფითი მხარეები)

PHP ენა ძალიან აქტიურად გამოიყენება ვებ აპლიკაციების დასამუშავებლად და დღეს მასზე მუშაობს ხუთი ვებ-გვერდიდან სამი. თუმცა, აუცილებლად უნდა მიაქციოთ ყურადღება შესაძლო ალტერნატივებს. ერთ-ერთი მათგანია Node.js.

Node.js-ის უპირატესობები

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

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

ნაგულისხმევად, Node.js-ს გააჩნია მოსახერხებელი და ფუნქციონალური პაკეტის მენეჯერი - npm. ეს ხდის მოდულების და დამოკიდებულებების მართვას მარტივ და კომფორტულს. და Noda-სთან მოთხოვნისა და პასუხების დასამუშავებლად ჩაშენებული ბიბლიოთეკების წყალობით, თქვენ არ იქნებით დამოკიდებული მესამე მხარის სერვერებზე. ეს პლატფორმა ასევე უზრუნველყოფს უკეთეს შესრულებას ზოგიერთ სიტუაციაში.

და ბოლოს, Node.js-ს აქვს ბევრი დადებითი გამოხმაურება დეველოპერებისგან. რამდენიმე ადამიანი, ვინც წერს PHP-ს, არის გატაცებული ენის მიმართ, მაგრამ Javascript-ით სიტუაცია სრულიად განსხვავებულია.

ხარვეზები

ამასთან, უნდა გავითვალისწინოთ, რომ Node არ არის ნაკლოვანებების გარეშე:

  • უფრო რთულია სწავლა და ამ ტექნოლოგიის გამოყენებით მუშაობის დაწყება არც ისე ადვილი იქნება, მით უმეტეს, თუ თქვენ ახალი ხართ ვებ პროგრამირებაში, ხოლო PHP-ში ვებსაიტის შექმნა გაცილებით მარტივია;
  • Node ტექნოლოგია შედარებით ახალგაზრდაა, ამიტომ მასზე გაცილებით ნაკლები ინფორმაციაა, ვიდრე PHP-ზე;
  • ნებისმიერი ჰოსტინგი გამოდგება PHP-სთვის, მაგრამ თქვენ მოგიწევთ მოძებნოთ შესაბამისი პლატფორმა Node-სთვის;

ამრიგად, არ არსებობს მკაფიო პასუხი კითხვაზე, რომელია უკეთესი - PHP თუ Node.js. თუმცა, უნდა გაითვალისწინოთ, რომ ეს უკანასკნელი სწრაფად იძენს პოპულარობას. დღეს მას იყენებენ Microsoft, PayPal, LinkedIn, Yahoo და მრავალი სხვა დიდი კომპანია.

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

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

სარგებელი # 1: თქვენ შეგიძლიათ იპოვოთ შეცდომები და შეცდომები ადრეულ პერიოდში

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

სწრაფი მაგალითი: ვთქვათ გვაქვს პატარა ფუნქცია, რომელიც იღებს რადიუსს და ითვლის ფართობს:

Const გამოთვლა ფართობი = (რადიუსი) => 3.14 * რადიუსი * რადიუსი; var ფართობი = გამოთვლა ფართობი(3); // 28.26
ახლა თუ გვინდა რადიუსი გადავიტანოთ ფუნქციას, რომელიც არ არის რიცხვი (როგორც "ინტრუდერი")...

Var area = გამოთვლა ფართობი ("im evil"); // NaN
ჩვენ დავიბრუნებთ NaN-ს. თუ ზოგიერთი ფუნქციონალობა ეფუძნება გამოთვლა Area ფუნქციას, რომელიც ყოველთვის აბრუნებს რიცხვს, მაშინ ეს გამოიწვევს დაუცველობას ან ავარიას. არ არის ძალიან ლამაზი, არა?

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

Const გამოთვლა ფართობი = (რადიუსი: რიცხვი): რიცხვი => 3.14 * რადიუსი * რადიუსი;
ახლა შეეცადეთ გადასცეთ რაღაც, გარდა რიცხვისა, გამოთვლის ფართობის ფუნქციაში - და Flow დაგიბრუნებთ მოსახერხებელ და სასიამოვნო შეტყობინებას:

CalculateArea ("ბოროტი ვარ"); ^^^^^^^^^^^^^^^^^^^^^^^^ ფუნქციის გამოძახება გამოთვლა Area("Im Evil"); ^^^^^^^^^ სტრიქონი. ეს ტიპი შეუთავსებელია const გამოთვლასთან ფართობი = (რადიუსი: რიცხვი): ნომერი => 3.14 * რადიუსი * რადიუსი; ^^^^^^ ნომერი
ახლა ჩვენ გვაქვს გარანტია, რომ ფუნქცია მიიღებს მხოლოდ მოქმედ ციფრებს შეყვანად და შედეგს დააბრუნებს მხოლოდ მოქმედ რიცხვებად.

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

სარგებელი #2: თქვენ გაქვთ საცხოვრებელი დოკუმენტაცია

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

იმის გასაგებად, თუ როგორ, მოდით შევხედოთ მეთოდს, რომელიც ოდესღაც ვიპოვე დიდ კოდების ბაზაში, რომლითაც ვმუშაობდი:

ფუნქცია გამოთვალეთPayoutDate(ციტატა, თანხა, გადახდის მეთოდი) (დაუშვით payoutDate; /* ბიზნეს ლოგიკა */ დააბრუნეთ payoutDate; )
ერთი შეხედვით (მეორეც და მესამეც) სრულიად გაუგებარია როგორ გამოვიყენოთ ეს ფუნქცია.

ციტატა ნომერია? ან ლოგიკური მნიშვნელობა? არის თუ არა გადახდის მეთოდი ობიექტი? ან შეიძლება იყოს სტრიქონი, რომელიც წარმოადგენს გადახდის მეთოდის ტიპს? ფუნქცია აბრუნებს თარიღს სტრიქონის სახით? თუ ეს არის Date ობიექტი?

Აზრზე არ ვარ.

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

მეორეს მხრივ, თუ თქვენ დაწერეთ მსგავსი რამ:

ფუნქცია გამოთვალეთPayoutDate(ციტატა: ლოგიკური, თანხა: ნომერი, გადახდის მეთოდი: სტრიქონი): თარიღი (დაუშვით payoutDate; /* ბიზნეს ლოგიკა */ დააბრუნეთ payoutDate; )
მაშინვე გახდება ნათელი, თუ რა ტიპის მონაცემებს იღებს ფუნქცია და რა ტიპს აბრუნებს. ეს არის მაგალითი იმისა, თუ როგორ შეიძლება სტატიკური ტიპების გამოყენება ფუნქციის კომუნიკაციისთვის აპირებსკეთება. ჩვენ შეგვიძლია ვუთხრათ სხვა დეველოპერებს, რას ველით მათგან და დავინახოთ, რას მოელიან ისინი ჩვენგან. შემდეგ ჯერზე, თუ ვინმე აპირებს ამ ფუნქციის გამოყენებას, კითხვები არ იქნება.

შეგიძლიათ დადოთ ფსონი, რომ ეს პრობლემა მოგვარებულია კოდზე ან დოკუმენტაციაზე კომენტარების დამატებით:

/* @function განსაზღვრავს შეძენის გადახდის თარიღს @param (ლოგიკური) ციტატა - არის ეს ფასის შეთავაზებისთვის? @param (ლოგიკური) თანხა - შესყიდვის თანხა @param (სტრიქონი) paymentMethod - ამ შესყიდვისთვის გამოყენებული გადახდის მეთოდის ტიპი */ ფუნქცია გამოთვალოთPayoutDate(კოტირება, თანხა, გადახდის მეთოდი) (დაუშვით payoutDate; /* .... ბიზნეს ლოგიკა ... */ დაბრუნების გადახდის თარიღი; );
Მუშაობს. მაგრამ აქ ბევრად მეტი სიტყვაა. გარდა იმისა, რომ სიტყვიერია, კოდში ასეთი კომენტარები ძნელია შენარჩუნება, რადგან ისინი სუსტია და არ აქვთ სტრუქტურა - ზოგი დეველოპერი წერს კარგ კომენტარებს, ზოგი კი შეიძლება დაწეროს რაღაც გაუგებარი და ზოგმა შეიძლება დაავიწყდეს კომენტარის დატოვება.

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

სარგებელი #3: აღმოფხვრის დამაბნეველი შეცდომების დამუშავებას

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

ამჯერად მას გადავცემ რადიუსების მასივს თითოეული რადიუსისთვის ფართობის გამოსათვლელად:

მუდმივი გამოთვლა ფართობები = (რადიუსი) => ( var არეები = ; for (დავცეთ i = 0; i< radii.length; i++) { areas[i] = PI * (radii[i] * radii[i]); } return areas; };
ეს ფუნქცია მუშაობს, მაგრამ არასწორად ამუშავებს არასწორი შეყვანის არგუმენტებს. თუ ჩვენ გვინდა დავრწმუნდეთ, რომ ფუნქცია სწორად უმკლავდება სიტუაციებს, როდესაც შეყვანის არგუმენტები არ არის მოქმედი რიცხვების მასივები, ჩვენ მივიღებთ დაახლოებით ასეთ ფუნქციას:

მუდმივი გამოთვლა ფართობები = (რადიუსი) =>< radii.length; i++) { if (typeof radii[i] !== "number") { throw new Error("Array must contain valid numbers only"); } else { areas[i] = 3.14 * (radii[i] * radii[i]); } } return areas; };
Ვაუ. არსებობს უამრავი კოდი ფუნქციონირების ასეთი პატარა ნაწილისთვის.

და სტატიკური ტიპებით ჩვენ უბრალოდ ვწერთ:

): მასივი => < radii.length; i++) { areas[i] = 3.14 * (radii[i] * radii[i]); } return areas; };
ახლა ფუნქცია რეალურად გამოიყურება ისე, როგორც ეს იყო ყველა ვიზუალური ნაგვის დამატებამდე, შეცდომების დამუშავების გამო.

ადვილია სტატიკური ტიპების უპირატესობების გაგება, არა?

სარგებელი #4: შეგიძლიათ უფრო თავდაჯერებულად გადააკეთოთ

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

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

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

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

სარგებელი #5: ცალკეული მონაცემები და ქცევა

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

მოდით კიდევ ერთხელ გადავხედოთ ჩვენს გამოთვლის ფართობის ფუნქციას სტატიკური ტიპებით:

Const გამოთვლა ფართობები = (რადიუსი: მასივი ): მასივი => ( var სფეროები = ; for (var i = 0; i< radii.length; i++) { areas[i] = 3.14 * (radii[i] * radii[i]); } return areas; };
განვიხილოთ, როგორ მივუდგებით ამ ფუნქციის შედგენას. იმის გამო, რომ ჩვენ ვაზუსტებთ მონაცემთა ტიპებს, იძულებულნი ვართ ვიფიქროთ მონაცემთა ტიპებზე, რომელთა გამოყენებასაც ვაპირებთ, რათა დავაყენოთ გადაცემული პარამეტრების ტიპები და შესაბამისად დავაბრუნოთ მნიშვნელობები.

მხოლოდ ამის შემდეგ ვახორციელებთ ლოგიკას:

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

სარგებელი #6: აღმოფხვრის შეცდომების მთელ კატეგორიას

Run-time ტიპის შეცდომები არის ერთ-ერთი ყველაზე გავრცელებული შეცდომა ან შეცდომა, რომელსაც აწყდებიან JavaScript-ის დეველოპერები.

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

Var appState = ( isFetching: false, messages: , );
და დავუშვათ, რომ ჩვენ გავაკეთებთ API ზარს, რათა მივიღოთ შეტყობინებები და შევავსოთ ჩვენი appState. შემდეგ, ჩვენს აპლიკაციას აქვს ზედმეტად გამარტივებული მაყურებლის კომპონენტი, რომელიც იღებს შეტყობინებებს (ზემოთ ჩამოთვლილ მდგომარეობაში) და აჩვენებს წაუკითხავი შეტყობინებების რაოდენობას და თითოეულ შეტყობინებას, როგორც სიის ელემენტს:

იმპორტი შეტყობინება "./Message"-დან; const MyComponent = (( შეტყობინებები )) => ( დაბრუნება (

( messages.map (გზავნილი => )}
); };
თუ API ზარი შეტყობინებების მისაღებად ვერ მოხერხდა ან დაბრუნდება განუსაზღვრელი, მაშინ შეგხვდებათ ტიპის შეცდომა წარმოებაში:

TypeError: არ შეიძლება წაიკითხოს თვისება "სიგრძე" განუსაზღვრელი
...და თქვენი პროგრამა ჩაიშლება. თქვენ დაკარგავთ კლიენტს. ფარდა.

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

ჩაწერეთ AppState = ( isFetching: ლოგიკური, შეტყობინებები: ?Array ); var appState: AppState = ( isFetching: false, messages: null, );
ვინაიდან ცნობილია, რომ შეტყობინებების მისაღებად API არ მუშაობს საიმედოდ, ჩვენ მივუთითებთ შესაძლოა ტიპის შეტყობინებების მნიშვნელობას სტრიქონების მასივისთვის.

ისევე, როგორც წინა დროს, ჩვენ ვიღებთ შეტყობინებებს არასანდო API-ს მეშვეობით და ვიყენებთ მათ ხედვის კომპონენტში:

იმპორტი შეტყობინება "./Message"-დან; const MyComponent = (( შეტყობინებები )) => ( დაბრუნება (

თქვენ გაქვთ ( messages.length ) წაუკითხავი შეტყობინებები

( messages.map (გზავნილი => )}
); };
მაგრამ ამ მომენტში Flow აღმოაჩენს შეცდომას და უჩივის:

^^^^^^ თვისება `სიგრძე`. საკუთრებაზე წვდომა შეუძლებელია შესაძლო ნულოვანი მნიშვნელობით

თქვენ გაქვთ (messages.length) წაუკითხავი შეტყობინებები

^^^^^^^^ null

თქვენ გაქვთ (messages.length) წაუკითხავი შეტყობინებები

^^^^^^ თვისება `სიგრძე`. ქონებაზე წვდომა შეუძლებელია შესაძლო განუსაზღვრელი ღირებულებით

თქვენ გაქვთ (messages.length) წაუკითხავი შეტყობინებები

^^^^^^^^ განუსაზღვრელია ( messages.map(message => დარეკე მეთოდის `რუკა. მეთოდის გამოძახება შეუძლებელია შესაძლო ნულოვანი მნიშვნელობით ( messages.map(message => )) ^^^^^^^^ null ( messages.map(message => დარეკე მეთოდის `რუკა. მეთოდის გამოძახება შეუძლებელია შესაძლო განუსაზღვრელ მნიშვნელობაზე ( messages.map(message => )) ^^^^^^^^ განუსაზღვრელია
მოიცადე, მეგობარო!

მას შემდეგ, რაც ჩვენ განვსაზღვრეთ შეტყობინებები იქნებიან ტიპის, ჩვენ დავუშვებთ, რომ ის იყოს null ან განუსაზღვრელი. მაგრამ ეს არ გვაძლევს უფლებას შევასრულოთ მასზე ოპერაციები (როგორიცაა .length ან .map) null-ის შემოწმების გარეშე, რადგან თუ შეტყობინებების მნიშვნელობა რეალურად არის null ან განუსაზღვრელი, მაშინ წარმოიქმნება ტიპის შეცდომა, როდესაც ვცდილობთ მუშაობას. ის.

მოდით დავბრუნდეთ და განვაახლოთ ჩვენი ხედვის ფუნქცია მსგავსი რამით:

Const MyComponent = (( შეტყობინებები, isFetching ): AppState) => ( if (isFetching) ( დაბრუნება ) სხვა თუ (შეტყობინებები === null || შეტყობინებები === განუსაზღვრელია) ( დაბრუნება

შეტყობინებების ჩატვირთვა ვერ მოხერხდა. Კიდევ სცადე.
) სხვა (დაბრუნება (

თქვენ გაქვთ ( messages.length ) წაუკითხავი შეტყობინებები

( messages.map (გზავნილი => )}
); } };
Flow-მა ახლა იცის, რომ ჩვენ გავითვალისწინეთ ყველა სიტუაცია, როდესაც შეტყობინებები არის null ან განუსაზღვრელი, ამიტომ კოდის ტიპის შემოწმება ვერ ხერხდება 0 შეცდომით. ნახვამდის გაშვების შეცდომებს!

სარგებელი #7: შეამცირეთ ერთეული ტესტების რაოდენობა

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

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

Const გამოთვლა Areas = (radii) => ( // გაუმკლავდეს განუსაზღვრელ ან ნულ შეყვანას, თუ (!radii) ( გადაყარეთ ახალი შეცდომა ("არგუმენტი აკლია"); ) // დამუშავება არამასივნის შეყვანის შემთხვევაში, თუ (!Array.isArray(radii) ) ( გადაყარეთ ახალი შეცდომა ("არგუმენტი უნდა იყოს მასივი"); ) var area = ; for (var i = 0; i< radii.length; i++) { if (typeof radii[i] !== "number") { throw new Error("Array must contain valid numbers only"); } else { areas[i] = 3.14 * (radii[i] * radii[i]); } } return areas; };
ჩვენ რომ გულმოდგინე პროგრამისტები ვიყოთ, შეიძლება განვიხილავდით არასწორი გადავლილი პარამეტრების ტესტირებას იმის დასადასტურებლად, რომ ისინი სწორად არის დამუშავებული ჩვენი პროგრამის მიერ:

It("არ უნდა იმუშაოს - შემთხვევა 1", () => ( expect(() => გამოთვლა Areas()).to.throw(Error); )); it ("არ უნდა იმუშაოს - შემთხვევა 2", () => ( expect(() => გამოთვლა ფართობები(განუსაზღვრელი).to.throw(შეცდომა); )); it("არ უნდა იმუშაოს - შემთხვევა 2", () => ( expect(() => გამოთვლა Areas("hello")).to.throw(Error); ));
… და ასე შემდეგ. მაგრამ ძალიან სავარაუდოა, რომ ჩვენ დაგვავიწყდეს გარკვეული ზღვრული შემთხვევების ტესტირება - და ჩვენი მომხმარებელი იქნება ის, ვინც აღმოაჩენს პრობლემას. :(

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

მეორეს მხრივ, როდესაც ჩვენ გვჭირდება ტიპების დაყენება:

Const გამოთვლა ფართობები = (რადიუსი: მასივი ): მასივი => ( var სფეროები = ; for (var i = 0; i< radii.length; i++) { areas[i] = 3.14 * (radii[i] * radii[i]); } return areas; };
... ჩვენ არა მხოლოდ ვიღებთ გარანტიას, რომ ჩვენი მიზანი შეესაბამება რეალობას, არამედ ასეთი ტესტები უბრალოდ უფრო სანდოა. ცერის წესების ტესტებისგან განსხვავებით, ტიპები უნივერსალურია და უფრო რთული დასაძლევი.

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

სარგებელი #8: დომენის მოდელირების ინსტრუმენტი

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

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

ასე რომ, პირველ რიგში, ჩვენ გამოვიყენებთ ტიპის მეტსახელებს გადახდის სამი მეთოდისთვის:

ტიპი Paypal = ( ID: ნომერი, ტიპი: "Paypal" ); ტიპი CreditCard = ( id: ნომერი, type: "CreditCard" ); ტიპი ბანკი = ( id: ნომერი, ტიპი: "ბანკი" );
ახლა თქვენ შეგიძლიათ დააყენოთ გადახდის მეთოდის ტიპი, როგორც განცალკევებული ნაკრები სამი შემთხვევით:

აკრიფეთ PaymentMethod = Paypal | საკრედიტო ბარათი | ბანკი;
ახლა მოდით შევქმნათ სახელმწიფო მოდელი ჩვენი აპლიკაციისთვის. იმისათვის, რომ ყველაფერი მარტივი იყოს, დავუშვათ, რომ ეს აპლიკაციები შედგება მხოლოდ მომხმარებლისთვის ხელმისაწვდომი გადახდის მეთოდებისგან.

ტიპი მოდელი = (გადახდის მეთოდები: მასივი };
მისაღებია? კარგად, ჩვენ ვიცით, რომ მომხმარებლის გადახდის მეთოდების მისაღებად, თქვენ უნდა მიმართოთ API-ს და, პროცესის შედეგისა და ეტაპიდან გამომდინარე, აპლიკაციას შეუძლია მიიღოს სხვადასხვა მდგომარეობა. სინამდვილეში, შესაძლებელია ოთხი მდგომარეობა:

1) ჩვენ არ მიგვიღია გადახდის მეთოდები.
2) ჩვენ ვართ გადახდის მეთოდების მოპოვების პროცესში.
3) ჩვენ წარმატებით მივიღეთ გადახდის მეთოდები.
4) ჩვენ ვცადეთ გადახდის მეთოდების მიღება, მაგრამ მოხდა შეცდომა.

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

ჰმმმ. არის თუ არა მოდელის აგების გზა ისე, რომ განაცხადის მდგომარეობამ მიიღოს ამ ოთხი მნიშვნელობიდან ერთ-ერთი და მხოლოდ ისინი? მოდით შევხედოთ:

ჩაწერეთ AppState = (ტიპი: "NotFetched" ) | ( ტიპი: "Fetching" ) | ( ტიპი: "Failure", შეცდომა: E ) | (ტიპი: "წარმატება", გადახდის მეთოდები: მასივი };
ჩვენ გამოვიყენეთ განცალკევებული ნაკრების ტიპი AppState-ის დასაყენებლად ზემოთ აღწერილი ოთხი მდგომარეობიდან ერთ-ერთზე. ყურადღება მიაქციეთ, როგორ ვიყენებ type თვისებას, რათა დავადგინო, რომელ მდგომარეობებშია აპლიკაცია. სწორედ ამ ტიპის თვისება ქმნის განცალკევებულ კომპლექტს. მისი გამოყენებით ჩვენ შეგვიძლია გავაანალიზოთ და განვსაზღვროთ, როდის გვაქვს გადახდის მეთოდები და როდის არა.

თქვენ ასევე შეამჩნევთ, რომ მე გადავცემ პარამეტრიზებულ ტიპებს E და D აპლიკაციის მდგომარეობას. ტიპი D წარმოადგენს მომხმარებლის გადახდის მეთოდს (ზემოთ განსაზღვრული PaymentMethod). ჩვენ არ დაგვიყენებია ტიპი E, როგორც ჩვენი შეცდომის ტიპი, ასე რომ, მოდით გავაკეთოთ ეს ახლა:

ჩაწერეთ HttpError = ( id: string, message: string );
ახლა შეგიძლიათ აპლიკაციის დომენის მოდელირება:

ტიპი Model = AppState ;
ზოგადად, განაცხადის მდგომარეობის ხელმოწერა ახლა არის AppState სადაც E არის ფორმის HttpError და D არის PaymentMethod. და AppState-ს აქვს ოთხი (და მხოლოდ ეს ოთხი) შესაძლო მდგომარეობა: NotFetched, Fetching, Failure და Success.

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

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

სტატიკური ტიპების გამოყენების ნაკლოვანებები

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

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

აქ არის რამდენიმე მოსაზრება:

მინუსი #1: სტატიკური ტიპები მოითხოვს წინასწარ სწავლას

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

როდესაც პირველად ვისწავლე Elm (სტატიკურად აკრეფილი ფუნქციური ენა), ტიპები ხშირად ხელს უშლიდნენ. მე განვაგრძობდი შემდგენელის შეცდომებს ჩემი ტიპის განსაზღვრების გამო.

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

ეს განსაკუთრებით მნიშვნელოვანია დამწყებთათვის, რომლებსაც აქვთ ყველაზე მაღალი კოგნიტური დატვირთვა სინტაქსის სწავლისგან. ამ მიქსში სინტაქსის დამატება დამწყები დამწყებთათვის შეიძლება გადაჭარბებული იყოს.

მინუსი #2: შეიძლება ჩაიძიროს სიტყვიერებაში

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

მაგალითად, ამის ნაცვლად:

ასინქრონული ფუნქციის თანხა ExceedsPurchaseLimit(თანხა, getPurchaseLimit)( var ლიმიტი = დაველოდოთ getPurchaseLimit(); დაბრუნების ლიმიტი > თანხა; )
ჩვენ უნდა დავწეროთ:

ასინქრონული ფუნქციის ოდენობა ExceedsPurchaseLimit(თანხა: ნომერი, getPurchaseLimit: () => დაპირება ): დაპირდი ( var ლიმიტი = დაველოდოთ getPurchaseLimit(); დაბრუნების ლიმიტი > თანხა; )
და სამაგიეროდ:

Var user = ( ID: 123456, სახელი: "Preethi", ქალაქი: "San Francisco", );
თქვენ უნდა დაწეროთ ეს:

ტიპი User = ( id: ნომერი, სახელი: string, city: string, ); var მომხმარებელი: მომხმარებელი = ( ID: 123456, სახელი: "Preethi", ქალაქი: "San Francisco", );
ცხადია, კოდის დამატებითი ხაზები ემატება. მაგრამ არსებობს რამდენიმე არგუმენტი იმის წინააღმდეგ, რომ ეს მინუსად ჩაითვალოს.

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

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

ძნელი სათქმელია არის თუ არა სიტყვიერება რეალური არგუმენტი ტიპების წინააღმდეგ, მაგრამ გასათვალისწინებელია.

მინუსი # 3: დრო სჭირდება იმისთვის, რომ გაიგოთ ტიპების გამოყენებაში.

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

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

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

მინუსი #4: სტატიკური ტიპები შეიძლება შეაფერხონ სწრაფი განვითარება

როგორც უკვე აღვნიშნე, Elm-ის სწავლისას ცოტა შევეჯახე ტიპებს - განსაკუთრებით კოდის დამატების ან მასში ცვლილებების შეტანისას. შემდგენელის შეცდომების გამო მუდმივი ყურადღება ართულებს სამუშაოს შესრულებას და პროგრესის განცდას.

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

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

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

გამოვიყენო სტატიკური ტიპები JavaScript-ში თუ არა?


პირველი პროგრამირების ენები, რომლებიც ვისწავლე, იყო JavaScript და Python, ორივე დინამიურად აკრეფილი ენა.

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

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

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

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

  1. პროგრამა გადამწყვეტია თქვენი ბიზნესისთვის.
  2. პროგრამა სავარაუდოდ რეფაქტორირებული იქნება ახალი საჭიროებებისთვის.
  3. პროგრამა რთულია და აქვს მრავალი მოძრავი ნაწილი.
  4. პროგრამას მხარს უჭერს დეველოპერების დიდი გუნდი, რომლებსაც სჭირდებათ კოდის სწრაფად და ზუსტად გაგება.
მეორეს მხრივ, უარს ვიტყოდი სტატიკურ ტიპებზე შემდეგ პირობებში:
  1. კოდი ხანმოკლეა და არ არის კრიტიკული.
  2. თქვენ აკეთებთ პროტოტიპს და ცდილობთ რაც შეიძლება სწრაფად წინსვლას.
  3. პროგრამა არის პატარა და/ან მარტივი.
  4. თქვენ ხართ ერთადერთი დეველოპერი.
JavaScript-ის განვითარების სილამაზე ამ დღეებში არის ის, რომ ისეთი ინსტრუმენტების წყალობით, როგორიცაა Flow და TypeScript, ჩვენ საბოლოოდ გვაქვს არჩევანი გამოვიყენოთ სტატიკური ტიპები ან კარგი ძველი JavaScript.

დასკვნა

იმედი მაქვს, რომ ეს სტატიები დაგეხმარებათ გაიგოთ ტიპების მნიშვნელობა, როგორ გამოიყენოთ ისინი და რაც მთავარია... *Როდესაც*გამოიყენეთ ისინი.

დინამიურ და სტატიკურ ტიპებს შორის გადართვის შესაძლებლობა არის ძლიერი ინსტრუმენტი JavaScript საზოგადოებისთვის და საინტერესო :)

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

მაგრამ ენა არ არის ნაკლოვანებების გარეშე. მათგან ყველაზე მნიშვნელოვანი:

  1. ენა შედგენილია კოდის შესრულების დროს. ყოველ ჯერზე, როცა ხსნით საიტს, Javascript კოდი იწყებს კომპილაციას. მინიმუმ, იზრდება პროგრამის შესრულების დრო.
  2. მონაცემთა აკრეფა არ არის. პრობლემა ყველა სკრიპტირების ენაზე. სანამ კოდის შესრულება არ მიაღწევს სასურველ ხაზს, თქვენ არ იცით მუშაობს თუ არა. მაგრამ შემდგენელს შეეძლო შეცდომების პოვნის მნიშვნელოვანი ნაწილი დაეკისრა, თუ იცოდა მონაცემთა ტიპები, რომლებთანაც მუშაობს. ხოლო შესრულების სიჩქარის თვალსაზრისით, აკრეფილი კოდი უფრო სწრაფია.
  3. ობიექტის მოდელი, რომელიც არ არის ნაცნობი ბევრი პროგრამისტისთვის. კლასები და კლასის მემკვიდრეობა არსებობს, მაგრამ ისინი ძალიან განსხვავდება C++/C#/Java პროგრამირების ენების ნაცნობი იმპლემენტაციებისგან.

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

რა არის გადაწყვეტილებები? შეწყვიტო ჯავასკრიპტის გამოყენება? მაგალითად, Google-მა უკვე მოიფიქრა შემცვლელი - Google dart ენა. მაგრამ რაც შეეხება კოდს, რომელიც უკვე დაწერილია? წლების განმავლობაში ჩვენი შესანიშნავი პროგრამისტების სასარგებლო მუშაობა?

ეს ყველაფერი არც ისე სამწუხაროა.

  1. აკრეფის პრობლემა შეიძლება მოგვარდეს Google-ის საოცარი პროგრამული უზრუნველყოფით - closure compiler. აუცილებელია კოდში სპეციალურად შემუშავებული კომენტარების დამატება ცვლადების, ფუნქციების და ფუნქციის პარამეტრების გვერდით - ანოტაციები, რომლებშიც მითითებულია მონაცემთა ტიპები. და Google-ის ჭკვიანი პროგრამული უზრუნველყოფა გეტყვით სად დაუშვით შეცდომა.
  2. კოდის შედგენა ამ დროისთვის შეუძლებელია. მაგრამ თქვენ შეგიძლიათ შეამციროთ კოდის რაოდენობა მისი ლოგიკურად შეკუმშვით (ცვლადების სახელის გადარქმევა, დამატებითი ადგილების ამოღება, კოდის ტრანსფორმაცია და ა.შ.) და შეკუმშვის ალგორითმების გამოყენებით (მაგალითად, gzip). ასევე არის ადგილი ბრაუზერებისთვის. ბრაუზერებს შეუძლიათ კოდის შედგენა მხოლოდ საიტიდან პირველად ჩამოტვირთვისას და დაიმახსოვრონ უკვე შედგენილი კოდი. და შემდეგ ჯერზე, როდესაც დაიწყებთ, გამოიყენეთ უკვე შედგენილი კოდი. ტექნიკის მუშაობა ასევე შენარჩუნებულია, ახლა ტელეფონიც კი შეიძლება იყოს ისეთივე ძლიერი, როგორც უბრალო დესკტოპ კომპიუტერი.
  3. თავად javascript ენა საშუალებას გაძლევთ თავი დააღწიოთ "მოუხერხული" ობიექტის მოდელს. არსებობს შესანიშნავი ხელსაწყოები:

    კლასების აღწერა გარეგნულად უახლოვდება კლასების აღწერას C++/C#/Java ენაზე. ეს მართლაც მოსახერხებელია კოდის გასაგებად და შესანარჩუნებლად. მეორე ინსტრუმენტი წარმოგიდგენთ სრულფასოვან საჯარო, დაცულ და კერძო მეთოდებს და ამატებს კლასის სრულფასოვან თვისებებს. ყველაფერი მარტივი და ელეგანტურია.

javascript ენის ყველა ნაკლოვანება შეიძლება აღმოიფხვრას. მისი უსაფრთხოდ გამოყენება შესაძლებელია ფართომასშტაბიან პროექტებში. ენის შემცვლელი ჯერ არ არის საჭირო.

ტეგები: javascript, javascript frame

11/24/14 15.6K

პროგრამირება არ არის მხოლოდ დიდი ფულის შოვნის საშუალება და არც მთლიანად გონებრივი სამუშაოა. ეს არის შესაძლებლობა გავიგოთ, რისგან შედგება ჩვენს ირგვლივ სამყარო, დავშალოთ იგი წვრილ ნაწილაკებად და შემდეგ ისევ შევიკრიბოთ, ჩვენივე ლოგიკითა და ცოდნით ხელმძღვანელობით.

პროგრამირების ენები მხოლოდ ინსტრუმენტია, რომლითაც ადამიანი ქმნის წესებს შექმნილ სისტემებში.

ინტერნეტი წარმოგიდგენთ უამრავ შესაძლებლობებს, რომლებსაც ნათელი და სამეწარმეო გონება იყენებს. რა თქმა უნდა, ვებ დეველოპმენტს ასევე აქვს საკუთარი ინსტრუმენტები იდეების გასაცოცხლებლად. ერთ-ერთი მათგანია JavaScript პროგრამირების ენა, რომელიც ამ სტატიაში იქნება განხილული:

ზოგადი ინფორმაცია

ბევრს, მათაც კი, ვისაც არაფერი აქვს საერთო IT სფეროსთან, სმენია სიტყვა ჯავა. რევოლუციური პლატფორმისგან დამოუკიდებელი ენა, რომელშიც აქტიურად იწერება აპლიკაციები მობილური სისტემებისთვის. იგი შეიმუშავა პერსპექტიული კომპანია Sun-ის მიერ, რომელიც შემდეგ მოექცა Oracle-ის ფრთის ქვეშ. მაგრამ არცერთ კომპანიას არაფერი აქვს საერთო JavaScript-თან:

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

ვებ აპლიკაციების წერისას ყველაზე ხშირად გამოიყენება JavaScript პროგრამირება. თუ მოკლედ ჩამოვთვლით ამ ენის ძირითად მახასიათებლებს, უნდა გამოვყოთ შემდეგი:

  • ობიექტზე ორიენტაცია. პროგრამის შესრულება წარმოადგენს ობიექტების ურთიერთქმედებას;
  • მონაცემთა ტიპის კონვერტაცია ხორციელდება ავტომატურად;
  • ფუნქციები არის საბაზისო კლასის ობიექტები. ეს ფუნქცია JavaScript-ს ამსგავსებს ბევრ ფუნქციურ პროგრამირების ენას, როგორიცაა Lisp და Haskell;
  • მეხსიერების ავტომატური გასუფთავება. ეგრეთ წოდებული ნაგვის შეგროვება JavaScript-ს ამსგავსებს C#-ს ან Java-ს.

თუ ვსაუბრობთ JavaScript-ის გამოყენების არსზე, მაშინ ეს ენა საშუალებას გაძლევთ "აღორძინოთ" უმოძრაო ვებსაიტის გვერდები კოდის გამოყენებით, რომელიც შეიძლება შესრულდეს ( სკრიპტები ე.წ). ანუ შეგვიძლია ანალოგიის დახატვა მულტფილმებთან, სადაც html და css არის დახატული პერსონაჟები და JavaScript არის ის, რაც მათ მოძრაობს.

თუ ვსაუბრობთ JavaScript სინტაქსზე, მაშინ მას აქვს შემდეგი მახასიათებლები:

  • რეგისტრაცია მნიშვნელოვანია. ფუნქციები, რომელსაც ეწოდება func() და Func() სრულიად განსხვავებულია;
  • ოპერატორებს უნდა მოჰყვეს მძიმით;
  • ჩამონტაჟებული ობიექტები და ოპერაციები;
  • ადგილები არ ითვლება. თქვენ შეგიძლიათ გამოიყენოთ იმდენი ჩაღრმავება, რამდენიც გსურთ, ისევე როგორც ხაზის წყვეტები თქვენი კოდის დასაფორმებლად.

უმარტივესი JavaScript კოდი ასე გამოიყურება:

გამოყენების სფერო

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

  • ვებ აპლიკაციის შემუშავება. გსურთ დააინსტალიროთ მარტივი მრიცხველი, მოაწყოთ მონაცემთა გადაცემა ფორმებს შორის ან განათავსოთ თამაში თქვენს ვებსაიტზე? მაშინ JavaScript იქნება ერთგული თანაშემწე ამ საკითხში;
  • "აქტიური მონაწილეობა" AJAX-ში. ამ ტექნოლოგიამ შესაძლებელი გახადა მნიშვნელოვნად დააჩქაროს აპლიკაციების მუშაობა სერვერთან მონაცემთა გაცვლით "ფონზე" რეჟიმში:

  • OS. ზოგმა შეიძლება არ იცოდა, მაგრამ Windows-ს, Linux-სა და Mac-ს ჰყავთ საკუთარი ბრაუზერის კონკურენტები, რომელთა ლომის წილი JavaScript-შია დაწერილი;
  • მობილური აპლიკაციები;
  • Სწავლების სფერო. პროგრამირების ნებისმიერი სპეციალობა უნივერსიტეტში მოიცავს JavaScript-ის შესწავლას ამა თუ იმ ზომით. ეს გამოწვეულია იმით, რომ ენა თავდაპირველად შეიქმნა არც თუ ისე ძლიერი პროგრამისტებისთვის. JavaScript გაკვეთილები ლოგიკურად არის ჩაქსოვილი HTML-ის ძირითად კურსში, ამიტომ სწავლა საკმაოდ მარტივია.

Დადებითი და უარყოფითი მხარეები

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

  • ბრაუზერის ჯვარედინი თავსებადობის უზრუნველყოფის აუცილებლობა. ვინაიდან JavaScript მოქმედებს როგორც ინტერნეტ ტექნოლოგია, თქვენ უნდა შეეგუოთ წესებს, რომლებსაც მსოფლიო ქსელი ადგენს. კოდი სწორად უნდა იმუშაოს ყველა, ან თუნდაც ყველაზე პოპულარულ ბრაუზერში;
  • ენაში მემკვიდრეობითი სისტემა ართულებს იმის გაგებას, თუ რა ხდება. JavaScript ახორციელებს პროტოტიპზე დაფუძნებულ მემკვიდრეობას. ადამიანები, რომლებმაც შეისწავლეს სხვა ობიექტზე ორიენტირებული პროგრამირების ენები, მიჩვეულები არიან ნაცნობს " ბავშვის კლასი მემკვიდრეობით იღებს მშობლის კლასს" მაგრამ JavaScript-ში ასეთი ნივთები უშუალოდ ობიექტების მიერ არის დამუშავებული და ეს თქვენს გაგებას სცილდება;
  • არ არსებობს სტანდარტული ბიბლიოთეკა. JavaScript არ იძლევა ფაილებთან, I/O ნაკადებთან ან სხვა სასარგებლო ნივთებთან მუშაობის შესაძლებლობებს;
  • ზოგადად სინტაქსი ართულებს მის გაგებას. კოდის სილამაზე აშკარად არ არის JavaScript-ის ძლიერი მხარე, მაგრამ დაცულია პროგრამისტების მთავარი წესი: ” მუშაობს? არ შეეხოთ!».

ახლა უნდა აღინიშნოს რამდენიმე უპირატესობა

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

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

მათთვის, ვისაც სწავლა სურს

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

  • პირველ რიგში, HTML. თქვენ ვერ დაიწყებთ არაფრის კეთებას ინტერნეტისთვის საფუძვლების გარეშე. კასკადური სტილის ფურცლები (CSS) ასევე ძალიან გამოგადგებათ;
  • გამოიყენეთ ახალი ლიტერატურა. პროგრამირება არ არის ფიზიკა, რომლის კანონები ხელშეუხებელია და ახალი სახელმძღვანელოები ძველებს აშორებენ. IT ტექნოლოგიები მუდმივად ვითარდება და სასარგებლო განახლებები არ უნდა იყოს უგულებელყოფილი;
  • შეეცადეთ თავად დაწეროთ პროგრამის ყველა განყოფილება. თუ რაღაც არ გამოდგება, შეგიძლიათ ისესხოთ სხვისი კოდი, მაგრამ მხოლოდ მას შემდეგ, რაც პირველ რიგში გაიგებთ თითოეულ სტრიქონს თქვენთვის;
  • გამართვა თქვენი საუკეთესო მეგობარია. შეცდომების სწრაფად პოვნა პროგრამირების ერთ-ერთი ყველაზე მნიშვნელოვანი ასპექტია;
  • ნუ უგულებელყოფთ ფორმატირების წესებს. რა თქმა უნდა, კოდი არ გახდება უკეთესი ან უარესი სხვადასხვა რაოდენობის ჩაღრმავებებისა და სივრცეების გამო, მაგრამ პროგრამისტის მიერ წაკითხვისა და გაგების სიმარტივე ასევე მნიშვნელოვანი პუნქტია. კოდი ქვემოთ? ძალიან რთულია აღქმა, განსაკუთრებით თუ ის არ ხარ

  • ცვლადის სახელებს უნდა ჰქონდეს ლექსიკური მნიშვნელობა. მარტივი პროგრამების წერის პროცესში ეს საერთოდ არ ჩანს მნიშვნელოვანი, მაგრამ როცა კოდის სტრიქონების რაოდენობა ათასს აჭარბებს, ყველა ეშმაკი ფეხებს იტეხს;


გაქვთ შეკითხვები?

შეატყობინეთ შეცდომას

ტექსტი, რომელიც გაეგზავნება ჩვენს რედაქტორებს:

გაგზავნა