چه زمانی کد ننویسیم؟

نویسنده : سید ایوب کوکبی ۴ مرداد ۱۳۹۸
چه زمانی نباید کد بنویسیم؟

اغلب برنامه‌نویس‌ها حتی سنیور دولوپرها گرفتار یک معضل اساسی هستند : کدنویسیِ مازاد! یعنی بیشتر از نیاز کد می‌نویسند و توانایی نه گفتن به خواسته‌های بی‌پایان مشتری را ندارند.

بخش مهمی از فرایند ساخت و توسعۀ نرم‌افزار، کدنویسی است و طبیعتاً دولوپرها باید توانایی مدیریت درخواست‌های متعدد را داشته باشند. ولی یک سوال:

آیا باید تمام درخواست‌ها را بپذیریم؟ آیا باید همۀ فیچرهایی درخواست شده از سوی مشتری را پیاده‌سازی کنیم؟

پاسخِ این سوال، مهم‌ترین مهارتِ برنامه‌نویسی را به ما گوشزد می‌کند:

مهم‌ترین مهارتی که یک توسعه‌دهنده می‌تواند یاد بگیرد این است که بداند چه زمانی نباید کد بنویسد.

The Art Of Readable Code

برنامه‌نویسی یعنی هنرِ حلِ مسئله. وقتی مسئله‌ای جلوی برنامه‌نویس‌ها قرار می‌دهید هیجان وصف‌ناپذیری برای حل مسئله و کدنویسی دارند. چنین علاقه‌ای نعمت است و اساساً یکی از ضروریات برنامه‌نویسی است. اما…

اما همین نعمت زیادش باعث وبال می‌شود. عشق به هر چیزی آدم را کور می‌کند؛ موجب می‌شود برخی از واقعیت‌ها را نبیند. واقعیت‌هایی که ممکن است آیندۀ کاری و زندگی او تحت تأثیر قرار دهد.

از چه واقعیت‌هایی حرف می‌زنیم؟

هر کدی که به برنامه اضافه می‌کنید:

  • باید برای سایرِ برنامه‌نویس‌ها خوانا و قابل فهم باشد؛
  • آزموده و بدون خطا باشد؛
  • احتمال بروز نقص و باگ در برنامه را افزایش می‌دهد.

ریچ اسکرنتا (Rich Skrenta) در مقالۀ «کد دشمن ماست» این چنین نوشته است:

کد واقعاً چیز مزخرفی است. مدام باید نگهداری‌اش کنید. باگ‌های ناشناخته‌اش را کشف کنید. هنگام اضافه کردن فیچرهای جدید باید حواستان به از کار نیفتادن فیچرهای قدیمی باشد. هرچه کد بیشتری می‌نویسید باگ‌های پنهانِ بیشتری نمایان می‌شود.

کدِ بیشتر یعنی زمانِ بیشتر برای کامپایل و چک‌اوت. یعنی نیروی بیشتر برای نگه‌داری و راهبری سیستم. در مواردی که نیاز به ریفکتور باشد اوضاع بدتر هم می‌شود. کدِ بیشتر یعنی انعطاف کمتر. عملکردِ کندتر. کدِ بیشتر یعنی نیاز به مهندسان بیشتر.

افزایشِ قابلیت‌های سیستم، هزینۀ نگه‌داری پروژه را افزایش می‌دهد.

code is our enemy

احتمالاً شما هم به عنوان یک برنامه‌نویس حرف‌های ریچ اسکرنتا را درک می‌کنید و بارها در پروژه‌هایتان تجربه کرده‌اید!

بخوانید  خصوصیات افرادی که مناسب کار تیمی نیستند

بهره‌وری مناسب زمانی حاصل می‌شود که توسعه‌دهنده بداند چه زمانی نباید کد بنویسد و نگه‌داری نرم‌افزار زمانی به سهولت میسر خواهد بود که حاوی کدهای غیرضروری نباشد.

چیزی به اسمِ «بهترین کد» نداریم. توسعه‌دهندۀ خوب و کارآمد به فردی گفته می‌شود که بداند چه زمانی نباید کد بنویسد.

چه زمانی نباید کد بنویسیم؟

همانطور که بالاتر گفتم هیجان در پروژه‌ها طبیعی است. همۀ برنامه‌نویس‌ها به محض اینکه روی پروژه‌ای کار می‌کنند دوست دارند تمام قابلیت‌ها و امکاناتی که به ذهنشان می‌رسد را به برنامه اضافه کنند. ولی واقعیت این است که در بیشترِ موارد توسعه‌دهنده‌ها درکِ درستی از قابلیت‌های ضروریِ برنامه ندارند؛ به عبارتی در تشخیص این موضوع که برنامه به چه فیچرهایی نیاز دارد غلو می‌کنند.

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

اولین قدم در تشخیص اینکه که چه زمانی نباید کد بنویسید فهمِ درستِ هدفِ برنامه و تعریفِ دقیقِ کارکرد اصلیِ آن است.

به عنوان مثال در یک نرم‌افزارِ مدیریت ایمیل قابلیت‌های ضروری ارسال و دریافت ایمیل است. اینجا نباید انتظار داشت برنامه امکان مدیریت to-do لیست هم داشته باشد.

بنابراین در برابر هر فیچر ریکوئستِ بی‌ربطی مقاومت کنید و صریحاً بگویید: نه. این دقیقاً جایی است که باید کد ننوشتن را بیاموزید.

هیچگاه هدفِ اصلیِ برنامه را گسترش ندهید.

با آگاهی از قابلیت‌های ضروری برای فیچرهای جدید هوشیارتر تصمیم خواهید گرفت. دقیقاً می‌دانید فلان ویژگی در چارچوب اهدافِ برنامه می‌گنجد یا نه. آیا فلان کدها ارزش اضافه کردن به کدبیس برنامه را دارند. روی این سوالات حساسید چون می‌دانید کدِ بی‌مصرف چه بلاهایی که سرِ پروژۀ شما نمی‌آورد.

دانستن اینکه چه زمانی کد ننویسید باعث کوچک ماندن کدبیس شما خواهد شد.

تصویر از کتابِ The Art Of Readable Code

ابتدا همه چیز عالی است. کلِ پروژه چند تا فایل بیشتر نیست. سرعتِ کامپایل بسیار بالاست. IDE سریعاً بارگذاری می‌شود و در عرضِ چند ثانیه خروجی می‌گیرید. می‌دانید هر کدی وظیفه‌اش چیست و کجا قرار دارد.

بخوانید  افکار و نگرش‌هایِ یک برنامه‌نویسِ خوب

با پیشرفتِ پروژه، فایل‌های بیشتری اضافه می‌شود. فولدر پروژه کم کم شلوغ می‌شود. به آرامی سروکلۀ فولدرهای تودرتو پیدا می‌شود. ناچارید فایل‌های مختلف را در پوشه‌های جدا طبقه‌بندی کنید. اکنون هر فایلی بیش از صدها خط کد دارد و درکشان سخت شده است.

دیگر مثل سابق راحت نمی‌توانید بفهمید کدام فانکشن کدام فانکشن را فراخوانی می‌کند. برای کوچک‌ترین کارها باید زمان بگذارید. پیدا کردن باگ‌ها به کابوس شبانه تبدیل می‌شود. مدیریت و نگه‌داری پروژه خودش به یک کارِ تمام وقت تبدیل می‌شود. به این فکر می‌افتید که به دنبالِ برنامه‌نویس‌های جدید بگردید تا به شما در توسعه و نگه‌داری پروژه کمک کنند.

افرادِ بیشتر، خود باعثِ سربارهای ارتباطی و کندی فرایند توسعۀ پروژه خواهد شد. آن پروژۀ شادابی که هر روز جست و خیز می‌کرد اکنون به یک لاک‌پشتِ فرتوت و پیر تبدیل شده که حوصله ندارد از عرض خیابان رد شود.

در پایان، یک پروژۀ بزرگ بر جای مانده که افزودن فیچرهای جدید به آن بسیار سخت و هراس‌انگیز شده است. حتی کوچکترین تغییری ساعت‌ها وقت می‌برد. حلِ باگ‌های گزارش شده اغلب باعث بروزِ باگ‌های جدید می‌شود. اکنون سررشتۀ کار و ددلاین‌ها از دستتان در رفته و زندگی برایتان سخت شده. چرا؟

چون نه گفتن بلد نبودید. هر فیچر ریکوئستی را با روی گشاده می‌پذیرفتید. شما کور شده بودید. اشتیاقتان به کدنویسی باعث شد بسیاری از حقایق را نادیده بگیرید و به این حال و روز بیفتید.

متن بالا داستانِ یک فیلمِ ترسناک نبود؛ مستندِ واقعی زندگی شماست اگر در برابر هر درخواستی بگویید: بله.

پس نه گفتن را از همین امروز تمرین کنید. کدهای اضافه را از پروژۀ خود حذف کنید. این کار زندگی را برای شما شیرین‌تر و نرم‌افزار را برای مدتِ بیشتری قابلِ استفاده می‌کند.

پربازده‌ترین روزِ من روزی است که ۱۰۰۰ خط کد حذف کنم.

کن تامپسون (Ken Thompson)

فهمیدن اینکه چه زمانی نباید کد بنویسیم حتی برای سنیور دولوپرها کار سختی است. شاید درکِ مطالبی که در این مقاله نوشتم برای برنامه‌نویسان جونیور سخت باشد که البته طبیعی است.

بخوانید  تجربۀ سال‌ها برنامه‌نویسی

می‌دانم که تازه شروع به کدنویسی کرده‌اید و از این کار لذت می‌برید. خیلی هم خوب ولی هرگز اجازه ندهید این هیجان و علاقه، چشمتان را بر روی واقعیات این شغل ببندد. چیزی که خواندید ثمرۀ تجربیات چندسالۀ من بود. شما می‌توانید مثلِ یک برنامه‌نویس معمولی مشکلاتِ من و دیگران را تجربه کنید ولی عاقلانه‌تر این است که مثلِ یک برنامه‌نویسِ زیرک از تجربیات دیگران درس بگیرید و زمانِ ارزشمندتان را به هدر ندهید.

کدنویسی کنید ولی بدانید چه زمانی نباید کد بنویسید.

منبع: مدیوم

سید ایوب کوکبی

نویسنده و مترجم...

2 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *




    علی دیلمی

    چهارشنبه ۱۶ مرداد ۱۳۹۸

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

      سید ایوب کوکبی

      چهارشنبه ۱۶ مرداد ۱۳۹۸

      خوشحالم که براتون مفید بوده.