با توسعه چیزی که درک نمی کنید موافقت نکنید

از ابتدای سال 2018، من سمت سرپرست/رئیس/توسعه‌دهنده اصلی را در تیم دارم - آن را هر چه می‌خواهید بنامید، اما نکته اینجاست که من کاملاً مسئول یکی از ماژول‌ها و همه توسعه‌دهندگانی هستم که کار می‌کنند. بر روی آن. این موقعیت به من دیدگاه جدیدی در روند توسعه می دهد، زیرا در پروژه های بیشتری شرکت می کنم و فعالانه تر در تصمیم گیری شرکت می کنم. اخیراً به لطف این دو مورد، ناگهان متوجه شدم که معیار درک چقدر روی کد و برنامه تأثیر می گذارد.

نکته ای که می خواهم به آن اشاره کنم این است که کیفیت کد (و محصول نهایی) ارتباط نزدیکی با میزان آگاهی افرادی که در حال طراحی و نوشتن کد هستند از کاری که انجام می دهند دارد دارد.

ممکن است در حال حاضر فکر کنید، "متشکرم، سرپوش. البته خوب است که به طور کلی آنچه را که می نویسید درک کنید. در غیر این صورت، ممکن است گروهی از میمون‌ها را استخدام کنید تا کلیدهای دلخواه را بزنند و آن را رها کنید.» و کاملا حق با شماست. بر این اساس، این را بدیهی می‌دانم که متوجه می‌شوید داشتن یک ایده کلی از کاری که انجام می‌دهید ضروری است. این را می توان سطح صفر درک نامید و ما به تفصیل آن را تحلیل نمی کنیم. ما به تفصیل به این خواهیم پرداخت که دقیقاً چه چیزی را باید درک کنید و چگونه بر تصمیماتی که هر روز می گیرید تأثیر می گذارد. اگر از قبل این چیزها را می دانستم، باعث صرفه جویی در وقت تلف شده و کد مشکوک می شد.

اگرچه شما حتی یک خط کد را در زیر نمی بینید، من هنوز معتقدم که همه چیزهایی که در اینجا گفته می شود برای نوشتن کدهای باکیفیت و رسا اهمیت زیادی دارد.

سطح اول درک: چرا کار نمی کند؟

توسعه دهندگان معمولاً خیلی زود در حرفه خود به این سطح می رسند، حتی گاهی اوقات بدون هیچ کمکی از جانب دیگران - حداقل در تجربه من. تصور کنید که یک گزارش باگ دریافت کرده اید: برخی از عملکردها در برنامه کار نمی کند، باید اصلاح شود. چگونه پیش خواهید رفت؟

طرح استاندارد به این صورت است:

1. قطعه کدی را که مشکل را ایجاد کرده است بیابید (چگونگی انجام این کار یک موضوع جداگانه است، من آن را در کتاب خود درباره کدهای قدیمی توضیح می دهم)
2. تغییراتی در این قطعه ایجاد کنید
3. اطمینان حاصل کنید که باگ برطرف شده است و هیچ خطای رگرسیونی رخ نداده است

حالا بیایید روی نکته دوم تمرکز کنیم - ایجاد تغییرات در کد. دو رویکرد برای این فرآیند وجود دارد. اولین مورد این است که در مورد آنچه دقیقاً در کد فعلی اتفاق می‌افتد تحقیق کنید، خطا را شناسایی کرده و آن را برطرف کنید. دوم: حرکت بر اساس احساس - مثلاً 1+ را به یک عبارت شرطی یا حلقه اضافه کنید، ببینید آیا تابع در سناریوی مورد نظر کار می کند یا خیر، سپس چیز دیگری را امتحان کنید، و به همین ترتیب ad infinitum.

رویکرد اول درست است. همانطور که Steve McConnell در کتاب Code Complete خود توضیح می دهد (که اتفاقاً من به شدت توصیه می کنم)، هر بار که چیزی را در کد تغییر می دهیم، باید بتوانیم با اطمینان پیش بینی کنیم که چگونه روی برنامه تأثیر می گذارد. من از حافظه نقل قول می کنم، اما اگر یک رفع اشکال آنطور که انتظار داشتید کار نکند، باید بسیار نگران باشید و باید کل برنامه اقدام خود را زیر سوال ببرید.

برای خلاصه کردن آنچه گفته شد، برای انجام یک رفع اشکال خوب که کیفیت کد را کاهش نمی دهد، باید هم ساختار کل کد و هم منبع مشکل خاص را بدانید.

سطح دوم درک: چرا کار می کند؟

این سطح به طور شهودی بسیار کمتر از سطح قبلی درک می شود. من، در حالی که هنوز یک توسعه دهنده مبتدی بودم، به لطف رئیسم آن را یاد گرفتم و متعاقباً مکرراً ماهیت موضوع را برای تازه واردان توضیح دادم.

این بار، بیایید تصور کنیم که شما دو گزارش اشکال را به طور همزمان دریافت کرده اید: اولی در مورد سناریوی A، دومی در مورد سناریو B است. در هر دو سناریو، یک اشتباه اتفاق می افتد. بر این اساس، ابتدا باگ اول را برطرف می کنید. با استفاده از اصولی که برای درک سطح XNUMX ایجاد کردیم، کد مربوط به مشکل را عمیقاً بررسی می‌کنید، متوجه می‌شوید که چرا باعث می‌شود برنامه همانطور که در سناریوی A رفتار می‌کند، و تنظیمات معقولی را انجام دهید که نتیجه‌ای را که می‌خواهید ایجاد کند. . همه چیز عالی پیش میره

سپس به سناریوی B می‌روید. در تلاش برای ایجاد خطا، سناریو را تکرار می‌کنید، اما - تعجب! - اکنون همه چیز همانطور که باید کار می کند. برای تأیید حدس خود، تغییراتی را که در حین کار بر روی اشکال A ایجاد کرده‌اید لغو می‌کنید و اشکال B باز می‌گردد. رفع اشکال شما هر دو مشکل را حل کرد. خوش شانس!

تو اصلا روی این موضوع حساب نکردی شما راهی برای رفع خطا در سناریوی A ابداع کرده‌اید و نمی‌دانید که چرا برای سناریوی B جواب داده است. در این مرحله، بسیار وسوسه‌انگیز است که فکر کنید هر دو کار با موفقیت انجام شده‌اند. این کاملاً منطقی است: نکته حذف خطاها بود، اینطور نیست؟ اما کار هنوز تمام نشده است: شما هنوز باید بفهمید که چرا اقدامات شما خطا را در سناریوی B تصحیح کرد. چرا؟ زیرا ممکن است بر روی اصول اشتباه کار کند و سپس باید به دنبال راه دیگری باشید. در اینجا چند نمونه از این موارد وجود دارد:

• از آنجایی که راه حل برای خطای B تنظیم نشده است، با در نظر گرفتن همه عوامل، ممکن است ناخودآگاه تابع C را شکسته باشید.
• ممکن است یک باگ سوم نیز در جایی در کمین باشد که مربوط به همان عملکرد است و رفع اشکال شما برای عملکرد صحیح سیستم در سناریوی B به آن بستگی دارد. در حال حاضر همه چیز خوب به نظر می رسد، اما یک روز این سومین باگ متوجه و رفع خواهد شد. سپس در سناریوی B خطا دوباره رخ می دهد، و اگر فقط وجود داشته باشد خوب است.

همه اینها هرج و مرج را به کد اضافه می کند و روزی بر سر شما می افتد - به احتمال زیاد در نامناسب ترین لحظه. شما باید اراده خود را جمع آوری کنید تا خود را مجبور کنید زمانی را صرف درک این موضوع کنید که چرا به نظر می رسد همه چیز کار می کند، اما ارزشش را دارد.

سطح سوم درک: چرا کار می کند؟

بینش اخیر من دقیقاً به این سطح مربوط می شود، و احتمالاً اگر زودتر به این ایده می رسیدم، این سطح است که بیشترین سود را به من می داد.

برای روشن تر شدن موضوع، اجازه دهید به یک مثال نگاه کنیم: ماژول شما باید با تابع X سازگار باشد. شما با تابع X آشنایی خاصی ندارید، اما به شما گفته شد که برای سازگاری با آن باید از چارچوب F استفاده کنید. ماژول هایی که با X ادغام می شوند دقیقاً با او کار می کنند.

کد شما از روز اول زندگی اصلاً با فریمورک F در تماس نبوده است، بنابراین پیاده سازی آن چندان آسان نخواهد بود. این عواقب جدی برای برخی از قسمت های ماژول خواهد داشت. با این حال، خود را وارد توسعه می‌کنید: هفته‌ها را صرف نوشتن کد، آزمایش، انتشار نسخه‌های آزمایشی، دریافت بازخورد، رفع خطاهای رگرسیون، کشف عوارض پیش‌بینی‌نشده، رعایت نکردن مهلت‌های توافق شده اولیه، نوشتن کد بیشتر، آزمایش، دریافت ارتباط بازخورد، می‌کنید. تصحیح خطاهای رگرسیون - همه اینها به منظور اجرای چارچوب F.

و در نقطه‌ای ناگهان متوجه می‌شوید - یا شاید از کسی بشنوید - که شاید چارچوب F به هیچ وجه به شما سازگاری با ویژگی X را نمی‌دهد. شاید این همه زمان و تلاش برای آن کاملاً اشتباه بوده است.

یک بار در حین کار روی پروژه ای که من مسئولیت آن را بر عهده داشتم، چنین اتفاقی افتاد. چرا این اتفاق افتاد؟ چون درک کمی از تابع X و ارتباط آن با فریمورک F نداشتم. باید چه کار می کردم؟ از شخصی که وظیفه توسعه را محول می کند بخواهید به طور واضح توضیح دهد که چگونه مسیر عمل مورد نظر منجر به نتیجه مطلوب می شود، به جای اینکه صرفاً آنچه را برای ماژول های دیگر انجام شده است تکرار کند یا قول خود را بپذیرد که این همان چیزی است که ویژگی X باید انجام دهد.

تجربه این پروژه به من آموخت که از شروع فرآیند توسعه امتناع کنم تا زمانی که درک روشنی از اینکه چرا از ما خواسته می شود کارهای خاصی را انجام دهیم. صراحتا خودداری کنید وقتی کاری دریافت می کنید، اولین انگیزه این است که فوراً آن را به عهده بگیرید تا زمان را تلف نکنید. اما سیاست "تجمع کردن پروژه تا زمانی که به تمام جزئیات وارد شویم" می تواند زمان تلف شده را با دستورات بزرگی کاهش دهد.

حتی اگر سعی می کنند به شما فشار بیاورند، مجبورتان کنند کار را شروع کنید، اگرچه دلیل این کار را نمی فهمید، مقاومت کنید. ابتدا بفهمید که چرا چنین وظیفه ای به شما داده می شود و تصمیم بگیرید که آیا این مسیر درستی برای رسیدن به هدف است یا خیر. من باید همه اینها را به سختی یاد می گرفتم - امیدوارم مثال من زندگی را برای کسانی که این را می خوانند آسان تر کند.

سطح چهارم درک: ???

در برنامه نویسی همیشه چیزهای بیشتری برای یادگیری وجود دارد، و من معتقدم که من فقط سطح مبحث درک را خراشیده ام. چه سطوح دیگری از درک را در طول سال ها کار با کد کشف کرده اید؟ چه تصمیماتی گرفتید که تأثیر مثبتی بر کیفیت کد و برنامه داشت؟ چه تصمیماتی اشتباه بود و درس ارزشمندی به شما داد؟ تجربه خود را در نظرات به اشتراک بگذارید.

منبع: www.habr.com