რამდენიმე წლის წინანდელი პროგნოზი ცუდად დაბერდა: «AI დაწერს კოდს, ამიტომ დიზაინ-პატერნების სწავლა მოძველებულია». პირველი ნახევარი ახდა — diff-ების დიდი წილი, რომლებსაც დღეს review-ს ვუკეთებ, დაგენერირებული იყო და არა ხელით აკრეფილი. მეორე ნახევარი კი თავდაყირა დადგა. ახლა, როცა ინჟინრები კოდის ნაკლებ ნაწილს წერენ თავად, სტრუქტურის ერთი შეხედვით ამოცნობის უნარი — თქმა «ეს Strategy-ა», «ეს Decorator-ად ყოფნას ითხოვს», «ეს Singleton-ია, სტატიკურ კლასში დამალული» — ჩუმად იქცა ყველაზე მაღალი ბერკეტის უნარად review-ის მთელ ჯაჭვში.
აი, არგუმენტი — ადამიანისგან, რომელიც პატერნებს ასწავლის და ყოველდღე AI-ინსტრუმენტებით უშვებს კოდს.
რატომ ხდის AI-ით დაგენერირებული კოდი პატერნებს უფრო მნიშვნელოვანს და არა პირიქით?
იმიტომ, რომ ბოთლის ყელის როლში წერა review-მ ჩაანაცვლა, პატერნები კი review-ის ლექსიკაა. როცა კოდს თავად წერდით, სტრუქტურული გაგება უფასოდ მოდიოდა — ყველა გადაწყვეტილება თქვენ გქონდათ მიღებული. დაგენერირებული diff გადაწყვეტილებების გარეშე მოდის: დამაჯერებელი, კომპილირებადი და სტრუქტურულად შეუმოწმებელი. Reviewer-ი, რომელსაც შეუძლია დაასახელოს ის, რასაც უყურებს, 400-სტრიქონიან diff-ს წუთებში აფასებს («Factory — კარგი; მაგრამ ეს retry-ლოგიკა Decorator-ად ყოფნას ითხოვს და არა კოპი-პასტს ექვს handler-ში»). Reviewer-ი, რომელსაც არ შეუძლია, სტრიქონ-სტრიქონ კითხულობს — ან უარესი: გადაათვალიერებს და ამტკიცებს.
დასახელება კომპრესიაა. «აქ Strategy უნდა იყოს» ცვლის ოცწუთიან ახსნას, თუ რატომ იტკენს თავს switch ქცევის ტიპებზე — ზუსტად ის საუბარი, რომელსაც დაგენერირებული კოდის review-ზე ისევ და ისევ ვაწარმოებ, რადგან მოდელები თავიანთი სასწავლო მონაცემების ყველაზე გავრცელებულ გადაწყვეტას იმეორებენ, ყველაზე გავრცელებული გადაწყვეტა კი if-ების გროვაა.
განა მოდელებმა ისედაც არ იციან პატერნები?
მათ პატერნები ისე იციან, როგორც ბიბლიოთეკამ — თავისი წიგნები. სთხოვეთ Strategy-ის იმპლემენტაცია და სახელმძღვანელოსას მიიღებთ. მაგრამ პატერნების რთული ნაწილი არასდროს ყოფილა იმპლემენტაცია — რთულია არჩევა: იმის ცოდნა, რომ პირობითობების ეს გორგალი სამი სტრატეგიაა ერთ ლაბადაში, ან რომ «მოქნილი» აბსტრაქტული ქარხანა, რომელიც მოდელმა დააგენერირა, სპეკულაციური განზოგადებაა ამოცანისთვის ზუსტად ერთი ვარიანტით. მოდელები არჩევის შეცდომას ორივე მიმართულებით უშვებენ: ნაკლებ-პატერნიანი დუბლირება, როცა პრომპტი ვიწროა, და ზედმეტ-პატერნიანი ცერემონია, როცა პრომპტი ამბობს «გააკეთე გაფართოებადი».
არჩევა მოითხოვს იმ ძალების ცოდნას, რომლებსაც პატერნი აგვარებს, და იმ ფასისას, რომელსაც ის ახდევინებს — სწორედ ამ ნაწილს უთმობს დროს პატერნების კურსი: არა «აი UML», არამედ «აი სუნი, აი მომენტი, როცა პატერნი თავის სირთულეს იმსახურებს, და აი მომენტი, როცა — არა». სწორედ ეს განსჯაა ის, რასაც აქირავებთ, როცა დაგენერირებულ diff-ს review-ს უკეთებთ.
რომელი პატერნები იძლევა ყველაზე მეტ სარგებელს AI-დახმარებით შექმნილ კოდბაზებში?
კომპოზიციის პატერნები — Strategy, Decorator, Adapter, Facade — რადგან სწორედ ისინი არ აძლევენ განმეორებით გენერაციას განმეორებით დუბლირებად ქცევის საშუალებას. მოდელი, რომელსაც სთხოვეს «დაამატე ლოგირება ამ ექვს handler-ს», სიამოვნებით ჩასვამს ერთსა და იმავე try/log/rethrow-ს ექვს ადგილას; reviewer-ი, რომლის ლექსიკაშიც Decorator-ია, ამას ერთ wrapper-ად აქცევს. Adapter და Facade თავიანთ ფასს სწორედ AI-სისტემების საზღვრებზე ამართლებენ: ინსტრუმენტების ინტერფეისები აგენტებისთვის კონსტრუქციითვე Adapter-ებია, ხოლო ყოველი საღი LLM-ინტეგრაცია პროვაიდერს Facade-ის უკან მალავს, რომ ვენდორის შეცვლა კოდბაზისთვის შეუმჩნეველი იყოს.
და კიდევ — წლის «დამკვირვებელი»: Chain of Responsibility, ხელახლა დაბადებული როგორც middleware ყველა აგენტურ ფრეიმვორკში. თუ მოდურ გარსში კლასიკურ სტრუქტურას ხედავთ, ფრეიმვორკების ცვლა თავიდან სწავლას წყვეტს და ამოცნობა ხდება — იმავე მიზეზით, რის გამოც C#-ინჟინრებმა პატერნების თავისუფალი ფლობით agentic-ვორკფლოუები ყველას მოლოდინზე სწრაფად აითვისეს: hooks-ები, სუბ-აგენტები და pipeline-ები ის პატერნებია, რომლებისთვისაც მათ სახელები უკვე ჰქონდათ.
კონკრეტულად, აი ის ცხრილი, რომელიც მინდოდა დაგენერირებული კოდის ყოველ reviewer-ს მონიტორზე მიწებებული ჰქონოდა. მესამე სვეტი ყველაზე მნიშვნელოვანია: დასახელებული მოთხოვნა ქმედითია, «რაღაც არეულია» — არა.
| პატერნი | სუნი დაგენერირებულ კოდში | რა თქვათ review-ზე |
|---|---|---|
| Strategy | switch ან if-else ჯაჭვი ქცევის ტიპებზე, რომელიც ყოველ სპრინტში იზრდება | «ეს ტოტები სტრატეგიებია — გამოყავი თითო თითოეულ ქცევაზე» |
| Decorator | ერთი და იგივე try/log/retry ბლოკი, ჩასმული ექვს handler-ში | «ეს ერთი wrapper-ია და არა ექვსი ასლი» |
| Adapter | პროვაიდერის SDK-ის ტიპები თქვენს დომენურ კოდში ჟონავს | «დადეთ adapter საზღვარზე; დომენმა ვენდორი არ უნდა იცოდეს» |
| Facade | გამომძახებლები ხუთ ქვესისტემურ გამოძახებას მკაცრი თანმიმდევრობით აორკესტრირებენ | «დამალეთ ეს თანმიმდევრობა ერთი შესვლის წერტილის უკან» |
| Factory | კონკრეტული ტიპების პირდაპირი კონსტრუირება, გაფანტული გამოძახების ადგილებში | «მოაქციეთ შექმნა ერთ ადგილას; გამომძახებელი იმპლემენტაციებს არ უნდა ირჩევდეს» |
| Chain of Responsibility | ერთი ფუნქცია თანმიმდევრობით აკეთებს auth-ს, ვალიდაციას, ლოგირებას და ბიზნეს-ლოგიკას | «ეს middleware-ია — თითო ეტაპი თითო საზრუნავზე» |
| Speculative generality (ანტიპატერნი) | აბსტრაქტული ქარხანა და ინტერფეისების იერარქია, რომლებიც ზუსტად ერთ იმპლემენტაციას ემსახურება | «ერთ ვარიანტს იერარქია არ სჭირდება — წაშალეთ აბსტრაქცია, სანამ მეორე არ გამოჩნდება» |
როგორ უნდა გაუკეთოთ დაგენერირებულ კოდს სტრუქტურული review რეალურად?
გააკეთეთ review ორ გავლად, სხვადასხვა კითხვით. პირველი გავლა, სტრუქტურული: რომელი პატერნი ცდილობს ეს იყოს? არის დუბლირება, რომელიც სახელს ითხოვს? არის ცერემონია, რომელიც წაშლას ითხოვს? სტრიქონებს ჯერ არ კითხულობთ — ფორმებს კითხულობთ, და ეს წუთებს მოითხოვს. მეორე გავლა, სემანტიკური: ახლა წაიკითხეთ სტრიქონები, რომლებმაც პირველ გავლას გაუძლეს. გუნდების უმეტესობა მხოლოდ მეორეს აკეთებს — ამიტომაც გროვდება დაგენერირებული დუბლირება: სტრიქონ-სტრიქონ კითხვა ამოწმებს, რომ თითოეული ასლი ცალკე აღებული სწორია, და ვერასდროს ამჩნევს, რომ ისინი ექვსია.
შეაფასებთ მხოლოდ იმას, რასაც სახელი შეგიძლიათ დაარქვათ. პატერნების ცოდნა აღარ არის არქიტექტურული არჩევითი საგანი — ეს ის კითხვის უნარია, რომელიც წყვეტს, რთული პროცენტით იზრდება AI-დახმარებით დეველოპმენტი თუ უბრალოდ გროვდება.
გახადეთ სტრუქტურული გავლა სასწავლი მისი ვერბალიზაციით: reviewer-ები პატერნს (ან სუნს) review-ის კომენტარში ასახელებენ. «ამოიღე აქ Strategy» ქმედითი და სასწავლოა; «რაღაც არეულია» — ვერცერთი. გუნდები, რომლებიც დასახელების ჩვევას ითვისებენ, საერთო სტრუქტურულ ლექსიკას კვარტალში აშენებენ — და ეს ლექსიკა რთული პროცენტით იზრდება, რადგან C#-ის გაღრმავებული კურსის მასალა reflection-ზე, generics-სა და async-პატერნებზე სულ სხვანაირად ჯდება, როცა GoF-ის საძირკველი უკვე ადგილზეა.
ინვერსია, პირდაპირ ნათქვამი
ადრე პატერნებს იმისთვის ვსწავლობდით, რომ უკეთესი კოდი დაგვეწერა, და თავად წერა პატერნების პრაქტიკა იყო. ახლა წერა სულ უფრო უფასოა, რაც ნიშნავს, რომ პრაქტიკა გაქრა — და განსჯა მიზანმიმართული სწავლიდან უნდა მოვიდეს, რადგან review-ა ის ადგილი, სადაც განსჯა ვარჯიშდება. პატერნების ცოდნა 2026 წელს არქიტექტურული არჩევითი საგანი აღარ არის; ეს ის კითხვის უნარია, რომელიც განსაზღვრავს, AI-დახმარებით დეველოპმენტი სუფთა კოდბაზად დაგროვდება თუ ლამაზად დაფორმატებულ ნაგავსაყრელად. ისწავლეთ იმის დასახელება, რასაც ხედავთ. მოდელები ამ ნაწილს თქვენ მაგივრად არ გააკეთებენ.
