از QA تا معمار کامپوننت
ویرایشگرهای کد مبتنی بر هوش مصنوعی اکنون بیشتر کدهای تکراری (boilerplate) را مدیریت میکنند. این موضوع یک باور غلط و خطرناک ایجاد میکند. تیمها فکر میکنند اگر هوش مصنوعی کد را بنویسد و کد کامپایل شود، پس کار میکند.
این طرز فکر برای ویژگیهای کوچک جواب میدهد، اما برای سیستمهای طراحی (design systems) شکست میخورد.
یک کامپوننت در سیستم طراحی، یک ویژگی گذرا نیست؛ بلکه زیرساخت است. یک دکمه یا یک فیلد ورودی، قرار است به میلیونها کاربر در صدها محصول خدمترسانی کند.
مزیت واقعی در سرعت نوشتن کد نیست، بلکه در میزان پیشبینی شما از شکستهاست.
شما باید از طرز فکر «سازنده» به طرز فکر «شکستدهنده» (breaker mindset) تغییر مسیر دهید. باید تستنویسی از طریق TDD، BDD و توسعه مبتنی بر مشخصات (Spec-Driven Development) را در آغوش بگیرید.
اکثر تیمها برای «مسیر خوشبینانه» (Happy Path) میسازند. آنها فقط فایل Figma را با کد مطابقت میدهند و کار را تمام میکنند. اما کامپوننتها باید در آشفتگیهای دنیای واقعی دوام بیاورند.
یک تیم قدرتمند قبل از نوشتن کد، سوالات سختی میپرسد:
- طراحان: اگر یک رشته متنی ۴۰۰ کاراکتر باشد چه میشود؟ آیا رابط کاربری (UI) از هم میپاشد؟
- مهندسان: اگر کاربر در هر ثانیه ده بار روی یک سوئیچ (toggle) کلیک کند چه میشود؟ آیا وضعیت (state) دچار اختلال میشود؟
- دسترسیپذیری (Accessibility): یک صفحهخوان (screen reader) چگونه این منوی کشویی (dropdown) را تنها با استفاده از کیبورد مدیریت میکند؟
ابزارهای هوش مصنوعی در کدنویسی خوب هستند اما در پیشفرضسازی ضعیفاند. آنها کامپوننتهای شکنندهای تولید میکنند.
از این گردش کار (workflow) برای محافظت از کار خود استفاده کنید:
- مشخصات را تعریف کنید (Tokens، Accessibility، API).
- ابتدا تستها و استوریها را بنویسید تا مرزها مشخص شوند.
- از هوش مصنوعی برای تولید کد در محدوده آن مرزها استفاده کنید.
روش TDD فرآیند را معکوس میکند. به جای رفع باگها در مراحل بعدی، شما از ابتدا مرزها را تعیین میکنید. سپس هوش مصنوعی آن تستها را پاس میکند.
توسعه رفتار-محور (BDD) نیز کمک میکند. این روش از زبان انسانی برای پر کردن شکاف بین طراحی و مهندسی استفاده میکند.
مثال:
- با فرض اینکه کاربر اتصال کندهای دارد،
- وقتی روی دکمه ارسال کلیک میکند،
- آنگاه دکمه باید حالت در حال بارگذاری (loading) را نشان دهد و کلیکها را غیرفعال کند.
برخی مدیران میترسند که تستنویسی سرعت را کاهش دهد. این یک اشتباه است.
کدنویسی اولیه تنها ۵٪ از هزینه یک کامپوننت است. ۹۵٪ باقیمانده صرف نگهداری و رفع باگها میشود.
داشتن طرز فکر تستمحور به شما این موارد را میدهد:
- پسرفتهای (regressions) کمتر هنگام بازنویسی کد (refactor).
- یک سیستم خودخدمت برای سایر توسعهدهندگان.
- اعتماد سازمانی.
در دنیای هوش مصنوعی، سرعت کدنویسی امری رایج است، اما تفکر سیستمی (Systems thinking) کمیاب است.
تلاش برای سریعتر ساختن را متوقف کنید. ساختن برای شکست خوردن را شروع کنید.
تیم شما چگونه بین سرعت و تابآوری (resilience) تعادل برقرار میکند؟ در کامنتها به من بگویید.