არ დაეთანხმოთ იმის განვითარებას, რაც არ გესმით

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

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

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

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

გაგების პირველი დონე: რატომ არ მუშაობს?

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

სტანდარტული სქემა ასე გამოიყურება:

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

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

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

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

გაგების მეორე დონე: რატომ მუშაობს ეს?

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

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

შემდეგ გადადიხართ B სცენარზე. თქვენ იმეორებთ სცენარს შეცდომის პროვოცირების მცდელობაში, მაგრამ - სიურპრიზი! - ახლა ყველაფერი ისე მუშაობს, როგორც უნდა. თქვენი ვარაუდის დასადასტურებლად, თქვენ გააუქმებთ A-ზე მუშაობისას განხორციელებულ ცვლილებებს და შეცდომა B ბრუნდება. თქვენმა ხარვეზმა გადაჭრა ორივე პრობლემა. Იღბლიანი!

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

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

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

გაგების მესამე დონე: რატომ მუშაობს ეს?

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

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

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

და რაღაც მომენტში უცებ ხვდები - ან შეიძლება ვინმესგან გაიგოთ - რომ შესაძლოა F Framework საერთოდ არ მოგცემთ თავსებადობას X მახასიათებელთან. შესაძლოა მთელი ეს დრო და ძალისხმევა სრულიად არასწორად იყო დახარჯული ამისთვის.

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

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

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

გაგების მეოთხე დონე: ???

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

წყარო: www.habr.com