پیچیدگی فضای داده شده را پر می کند

Summarize this content to 400 words in Persian Lang
می خواهم درباره ایده ای صحبت کنم که در طول کارم شروع به دیدن آن در همه جا کردم. برای معرفی آن، در اینجا تعدادی از موارد وجود دارد که فشار بیش از حد در فرآیند توسعه نرم‌افزار منجر به طراحی‌های خاص و شاید نامطلوب می‌شود.

شما یک الگوریتم کمی کند دارید، اما قدرت پردازش کافی برای مدیریت آن را دارید، بنابراین آن را همانطور که هست رها می کنید (زمان اجرا، قدرت محاسباتی داده شده را پر می کند)
همین امر در مورد حافظه نیز صدق می‌کند، هر میم مربوط به استفاده از رم کروم را ببینید
شما یک کلاس بزرگ با مسئولیت های بسیار زیاد دارید، اما آن را از هم نمی پاشید (معمولا این منجر به اسپاگت شدن کد می شود)
کلاسی را می‌بینید که واقعاً نباید وجود داشته باشد، بسیار ساده است و فقط در یک یا دو مکان استفاده می‌شود، اما ممکن است بعداً به آن نیاز داشته باشید، بنابراین آن را آنجا بگذارید (موضوع این پست)

آخرین مورد در اینجا چیزی است که می خواهم در مورد آن صحبت کنم زیرا فکر می کنم بیشتر زیر نظر رادار می رود. کلاسی که متدهای کمی دارد (در حال حاضر) “فضا” است و پیچیدگی آن چیزی است که باعث می شود پایگاه کد تمیز و خوب طراحی شده شما به آرامی در طول زمان پوسیده شود. چون تو اراده در آینده به آن کلاس کوچک نیاز دارم. این مکان عالی برای افزودن یک ویژگی جدید، یا رفع یک باگ کوچک است، و تا زمانی که متوجه شوید “وای ما واقعاً باید این را از بین ببریم” رشد می کند و رشد می کند، بنابراین دسته ای از کلاس های کوچک جدید ایجاد می کنید و چرخه دوباره تکرار می شود. این یکی از مشکلات اصلی است که اصولی مانند YAGNI و KISS سعی در رفع آن دارند. اما مانند بسیاری از اصول، اگر واقعاً مشکلی را که برای حل آنها وجود دارد، درک نکنید، استفاده از آنها ممکن است جزم‌آمیز به نظر برسد، و اغلب می‌توانند نادرست اعمال شوند.

من نمی توانم پیدا کنم که چه کسی آن را در ابتدا گفته است، اما یک مشاهدۀ صمیمی که در مورد این موضوع صدق می کند این است که:

چیزی به نام وجود ندارد کم اهمیت پایگاه کدهای قدیمی

به این معنا که: اگر پایگاه کد خود را کوچک نگه دارید، بدون در نظر گرفتن سن آن، هرگز به چیزی تبدیل نخواهد شد که ما آن را “میراث” می نامیم.

(اگر فکر می کنید که میکروسرویس ها یا هر معماری بسیار پراکنده دیگری راه حل است، به خاطر داشته باشید که “codebase” به تمام فایل ها، برنامه ها، سرویس ها، تعاریف کانتینر و غیره اشاره دارد که یک تیم واحد نیاز به مدیریت دارد. monolith یا 124 API کوچک REST تفاوت بسیار کمی دارد.)

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

کاهش تکرار کد با مشتاقانه. اصولی مانند DRY ما را تشویق می‌کند که تعداد کدهایی را که کپی و جای‌گذاری می‌کنیم محدود کنیم. مطمئناً ارزشمند است و یک روش رایج برای پیاده‌سازی DRY، کلاس‌های زیادی با طرح‌های وراثت پیچیده، یا توابع کمکی تنها با یک یا دو کاربرد است. این موارد مملو از فضا هستند. فضایی برای قرار دادن کمی رفع اشکال پچ. فضایی برای اضافه کردن یک تبدیل نوع اضافی یا بررسی ایمنی که واقعاً به آن نیاز ندارید. کد “خوب” مانند این به راحتی قابل توسعه است، در واقع آنقدر آسان است که ما اغلب تا زمانی که به کد بد تبدیل شود، توسعه می دهیم. (که اتفاقاً بسیار شبیه به اصل پیتر است)

انتخاب استفاده از یک زیر شاخه به جای فایل. به عنوان مثال در پایتون، دایرکتوری‌های فرعی یا «زیر ماژول‌ها» به شما این امکان را می‌دهند که کد خود را در بلوک‌های مفهومی سازماندهی کنید که باید خود را به خوبی به هم متصل کنند. هر زیرشاخه فضای جدید و فوق‌العاده‌ای برای پر کردن فایل‌ها و حتی زیر شاخه‌های بیشتر است. میل طبیعی “این فایل ها خیلی زیاد است، باید راهی برای ادغام برخی از مسئولیت های آنها پیدا کنیم” در دریایی از فضای جدید گم شده است که می توان از آن استفاده کرد. من همیشه تحت تاثیر قرار می‌گیرم که چگونه کتابخانه‌های محبوب/استاندارد اغلب کاملاً مسطح هستند، با تعداد کمی دایرکتوری تودرتو، در حالی که معادل‌های توسعه‌یافته داخلی اغلب عمیقاً تودرتو هستند و فایل‌های کمی در هر پوشه دارند.

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

بیماری اصلی در اینجا زمانی است که این پیچیدگی می شود غیر ضروری. مشکلات سخت معمولاً به راه حل های پیچیده نیاز دارند. البته، گاهی اوقات وجود دارد است یک فرمول ریاضی زیبا برای توصیف یک مسئله، اما اغلب وجود ندارد (مخصوصاً زمانی که شما در حال ساختن چیزی با دید انسان هستید). وجود راه حل پیچیده برای یک مشکل پیچیده، شرم آور نیست. با این حال، اغلب اوقات، پیچیدگی فقط به دلیل فضای موجود است، صرف نظر از سختی مشکل موجود. احساس غیرقابل حل شدن خواهد داشت، نظرات “همیشه اینطور بوده است” مرتباً مطرح می شود. بدبینی و بی تفاوتی در تیم و بسیاری از پروژه ها گسترش می یابدیا بمیرید یا وارد نوعی حالت حمایت از زندگی شوید.

آیا می توانیم آن را درست کنیم؟

(این در حال ورود به قلمروی است که بیشتر از قبل مورد نظر بود)

معمولا، نه. من واقعاً معتقدم که پروژه ای با پیچیدگی بیش از حد غیرضروری بهتر است دوباره راه اندازی شود. اما لازم نیست همه این کارها یکجا انجام شود. تشخیص این که باید همه چیز را از نو انجام دهید به این معنی نیست که باید همین الان همه چیز را کنار بگذارید. احتمالاً گران‌تر خواهد بود، اما اگر نتوانید آن را از پایه بسازید، گاهی اوقات می‌توانید یک سیستم جدید در کنار آن بسازید. هنوز هم نیاز به جراحی رادیکال دارد اما می توان آن را انجام داد. (تویتر در حال حاضر این کار را انجام می دهد و باید دید که آیا کار می کند یا خیر.)

آیا می توانیم در وهله اول از وقوع آن جلوگیری کنیم؟

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

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

من توماس ویلسون هستم و روی یک کتابخانه داخلی پایتون کار می کنم، این نظرات مربوط به خودم هستند و غیره.