این روزها ابزارهای هوش مصنوعی می‌تونن توی چند ثانیه برای ما کد تولید کنن؛ از یک Function ساده گرفته تا API، تست و حتی بخش‌هایی از یک قابلیت کامل.
همین موضوع یه سؤال مهم ایجاد کرده:
وقتی نوشتن کد هر روز راحت‌تر و سریع‌تر می‌شه، ارزش واقعی یک مهندس نرم‌افزار کجاست؟
مقالهٔ What Is Code? نوشتهٔ اونمش جوشی (Unmesh Joshi) از Thoughtworks دقیقاً سراغ همین سؤال می‌ره.
ایدهٔ اصلی مقاله اینه:
کد فقط دستورهایی نیست که کامپیوتر اجراشون کنه؛ کد مدلیه که ما با کمکش مسئله، قوانین کسب‌وکار و ساختار سیستم رو می‌فهمیم.
وقتی دربارهٔ کد حرف می‌زنیم، معمولاً اولین چیزی که به ذهنمون میاد اینه که کد باید به کامپیوتر بگه چه کاری انجام بده.
مثلاً:
اطلاعاتی رو بخونه؛
محاسبه‌ای انجام بده؛
داده‌ای رو ذخیره کنه؛
با یک سرویس دیگه ارتباط بگیره.
اما کد یک نقش مهم دیگه هم داره: توضیح‌دادن سیستم برای آدم‌ها.
یک کدبیس خوب باید به ما نشون بده:
سیستم دربارهٔ چه مفاهیمی صحبت می‌کنه؛
هر مفهوم چه معنایی داره؛
چه ارتباطی بین بخش‌های مختلف وجود داره؛
چه قانون‌هایی نباید شکسته بشن.
مثلاً در یک سیستم فروش، احتمالاً با مفاهیمی مثل مشتری، سفارش، پرداخت، ارسال و مرجوعی روبه‌رو می‌شیم.
اما فقط اینکه چند کلاس با اسم‌های Customer، Order و Payment داشته باشیم، به این معنی نیست که مدل خوبی ساختیم.
سؤال‌های مهم‌تر این‌ها هستن:
سفارش دقیقاً چه زمانی ثبت‌شده محسوب می‌شه؟
اگر پرداخت ناموفق باشه چه اتفاقی برای سفارش می‌افته؟
آیا سفارش ارسال‌شده قابل لغوه؟
چه کسی اجازه تغییر اطلاعات سفارش رو داره؟
همین قانون‌ها و رفتارها هستن که مدل واقعی سیستم رو می‌سازن.
مدل خوب فقط اسم کلاس‌ها نیست؛ ترکیبی از معنا، رفتار و قوانین کسب‌وکاره.
هر کسب‌وکاری زبان مخصوص خودش رو داره.
برای ساختن یک سیستم بانکی، فقط بلدبودن C# یا Java کافی نیست. باید مفهوم‌هایی مثل موجودی، تسویه، بدهی، تراکنش برگشتی و محدودیت اعتباری رو هم بفهمیم.
یک برنامه‌نویس در عمل بین چند زبان ترجمه انجام می‌ده:
زبان کسب‌وکار؛
زبان طراحی نرم‌افزار؛
زبان برنامه‌نویسی.
کار اصلی اینه که مفهوم‌های واقعی کسب‌وکار رو به شکلی وارد کد کنیم که هم ماشین بفهمه و هم انسان.
مثلاً مفهوم «پول» رو در نظر بگیر.
در نگاه اول شاید بگیم پول فقط یک عدد decimal هست، اما واقعاً این‌طور نیست.
پول:
مقدار داره؛
ارز داره؛
قانون‌هایی برای محاسبه و مقایسه داره.
پس اگر این مفهوم رو فقط به یک عدد ساده تبدیل کنیم، بخشی از معنی اصلی رو از دست دادیم.
کد خوب کمک می‌کنه این معنی‌ها گم نشن.
DDDاین نگاه خیلی به یکی از ایده‌های اصلی Domain-Driven Design نزدیکه.
در DDD مفهومی داریم به اسم Bounded Context.
یعنی هر بخش از سیستم می‌تونه زبان و مدل خودش رو داشته باشه.
مثلاً کلمهٔ «مشتری» در بخش‌های مختلف یک شرکت الزاماً یک معنی نداره:
در فروش، کسیه که خرید انجام می‌ده؛
در حسابداری، یک طرف حساب مالیه؛
در پشتیبانی، کسیه که قرارداد خدماتی داره.
یکی از اشتباه‌های رایج اینه که بخوایم یک مدل بزرگ به اسم Customer بسازیم و همه این معنی‌ها رو داخلش قرار بدیم.
نتیجه معمولاً یک مدل شلوغ و مبهم می‌شه که هر تغییری در یک بخش، بخش‌های دیگه رو هم تحت تأثیر قرار می‌ده.
راه بهتر اینه که هر بخش، مفهوم‌ها و قوانین خودش رو داشته باشه و ارتباط بین مدل‌ها واضح طراحی بشه.
دو چیز که اسم یکسان دارن، لزوماً مفهوم یکسانی ندارن.
یکی از نکته‌های جالب مقاله اینه که معمولاً از روز اول نمی‌دونیم بهترین طراحی سیستم دقیقاً چیه.
خیلی از چیزها وقتی روشن می‌شن که شروع به ساختن کنیم، بازخورد بگیریم و مدل ذهنی‌مون رو اصلاح کنیم.
فرآیند واقعی معمولاً این شکلیه:
مدل اولیه → پیاده‌سازی → بازخورد → اصلاح مدل → Refactoring
دو اشتباه رایج این وسط وجود داره.
اشتباه اول اینه که بخوایم قبل از اینکه مسئله رو واقعاً بشناسیم، همه‌چیز رو طراحی کنیم.
یعنی از همان اول همه Aggregateها، سرویس‌ها و مرزهای سیستم رو مشخص کنیم.
این کار معمولاً باعث ایجاد انتزاع‌هایی می‌شه که هنوز دلیل واقعی ندارن.
اشتباه دوم هم اینه که بدون هیچ مدل ذهنی فقط شروع به اضافه‌کردن قابلیت‌ها کنیم.
نتیجه معمولاً یک کدبیس پر از Handler، DTO و سرویس‌های پراکنده است که هیچ زبان مشترکی پشتش وجود نداره.
اینجا یکی از مهم‌ترین بخش‌های مقاله مطرح می‌شه.
هوش مصنوعی می‌تونه خیلی سریع ساختارهایی مثل:
Repository
Factory
Mediator
Command Handler
Domain Event
بسازه.
اما سؤال اصلی این نیست که آیا این کد اجرا می‌شه یا نه.
سؤال اصلی اینه:
آیا ما می‌دونیم چرا این ساختار رو داریم؟
اگر جواب این سؤال رو ندونیم، فقط داریم سرعت تولید پیچیدگی رو بیشتر می‌کنیم.
مقاله از این موضوع با مفهوم Cognitive Debt یا بدهی شناختی یاد می‌کنه.
یعنی وقتی ساختارها و اصطلاحات زیادی وارد سیستم می‌شن، اما تیم واقعاً معنی و دلیل وجودشون رو نمی‌فهمه.
مشکل اصلی استفاده از هوش مصنوعی نیست.
مشکل وقتی شروع می‌شه که:
سرعت تولید کد از سرعت شکل‌گیری فهم مشترک در تیم بیشتر بشه.
پیام مقاله این نیست که باید با هوش مصنوعی مقابله کنیم.
اتفاقاً برعکس؛ باید ازش استفاده کنیم.
اما ارزش یک مهندس ارشد فقط در سریع‌تر کدنویسی‌کردن نیست.
ارزش اصلی در این چیزهاست:
فهمیدن مسئلهٔ واقعی؛
پیدا کردن مفهوم‌های درست؛
انتخاب واژه‌های دقیق؛
طراحی مرزهای مناسب؛
مشخص‌کردن قوانین سیستم؛
جلوگیری از پیچیدگی‌های غیرضروری.
هوش مصنوعی می‌تونه کد تولید کنه، اما هنوز این ما هستیم که باید تصمیم بگیریم چه چیزی ارزش ساختن داره.
کد فقط چیزی نیست که کامپیوتر اجرا می‌کنه.
کد بخشی از دانش سیستم ماست؛ جایی که مفهوم‌ها، قوانین و تصمیم‌های طراحی ثبت می‌شن.
احتمالاً در آینده تولید کد خیلی ارزان‌تر و سریع‌تر می‌شه، اما فهمیدن مسئله، ساختن مدل درست و ایجاد یک سیستم قابل‌فهم همچنان یکی از مهم‌ترین مهارت‌های مهندسی نرم‌افزار باقی می‌مونه.
یک مهندس خوب کسی نیست که فقط کد بیشتری تولید کنه؛ کسیه که بتونه یک مسئله پیچیده رو به مدلی تبدیل کنه که هم انسان‌ها و هم ماشین‌ها بتونن بفهمنش.
این نوشته، برداشت و بازنویسی فارسی از ایده‌های مقالهٔ اصلیه و ترجمهٔ کلمه‌به‌کلمه نیست.
عنوان اصلی مقاله: What Is Code?
نویسنده: اونمش جوشی (Unmesh Joshi)
محل انتشار: وب‌سایت مارتین فاولر
لینک مقالهٔ اصلی:
