من بیش از پانزده سال است که یک توسعه دهنده هستم. من احتمالاً متعلق به نسل “گذشته” توسعه دهندگان هستم-آن زمان های قدیمی که به صورت دستی کد را به زبانهای سطح بالا مانند جاوا ، PHP ، JavaScript و GO نوشتند. من متوجه شده ام که در انتخاب ابزارها و فناوری های خود برای پروژه هایی که مسئولیت آن را بر عهده دارم ، به طور فزاینده ای محافظه کار می شوم. به همین دلیل من با احتیاط و شک و تردید به AI Hype ، Copilots ، عوامل و موارد مشابه نزدیک می شوم.
اما من تصمیم گرفتم که آن را امتحان کنم – و می خواهم مشاهدات خود را به اشتراک بگذارم: چه چیزی کار می کند و چه نمی کند. من می گویم مقدم: در کل ، من آن را دوست داشتم. حتی می گویم تحت تأثیر قرار گرفته ام.
من مدتی سعی کردم به کپی ها عادت کنم ، اما نتوانستم. پیشنهادات درون خطی عمدتاً تحریک و آهسته من است. حداقل در زبان اصلی من – برو – به نظر من نوشتن کد به جای بررسی و اصلاح آنچه مدل ایجاد کرده است ، ساده تر و سریعتر می دانم.
مکان نما نیز برای من کار نکرد – احتمالاً به این دلیل که من سالهاست که از jetbrains ides استفاده می کنم و نمی خواهم از رابط کاربری و ابزار آشنا دست بکشم. در نهایت ، برای آزمایشات من ، من در ترکیبی مستقر شدم: مشتری Claude Code مبتنی بر کنسول و Jetbrains Goland.
ایده برای یک پروژه حیوان خانگی برای آزمایش به طور غیر منتظره ای به وجود آمد. من در حال گپ زدن با یک دوست قدیمی بودم – ما در مورد “شرکای زندگی” خود ، که با آنها پیدا کردن زمینه مشترک دشوار است ، از یکدیگر شکایت می کردیم. و سپس به من ضربه زد: حل تعارض هوش مصنوعی!
تا صبح دوشنبه ، نمونه اولیه آماده بود. (می توانید اینجا را امتحان کنید: theudra.com)
من با یک سلب مسئولیت شروع می کنم: این اولین تجربه جدی من با استفاده از هوش مصنوعی در توسعه است ، بنابراین من احتمالاً همه چیز را اشتباه انجام داده ام. در صورت تمایل اظهار نظر کنید – به من بیاموزید که چگونه باید انجام شود.
من با ایجاد یک پروژه در نسخه وب کلود شروع کردم. ایده این بود: من یک “مدیر محصول” دارم که PRDS (سند مورد نیاز محصول) و “توسعه دهنده” – کد کلود – را تولید می کند – که کد را بر اساس این مستند می نویسد.
اول ، من مفهوم کلی را تدوین کردم: چشم انداز ، مأموریت ، مخاطب هدف و غیره ، و سند حاصل را در پروژه ذخیره کردم. سپس ، همراه با کلود ، ما یک PRD اساسی را تهیه کردیم که جریان اصلی کاربر را توصیف می کند.
اجرای هر ویژگی به این شکل بود:
- در نسخه وب Claude ، با استفاده از اسناد موجود ، یک سند جداگانه را تهیه می کنم که این ویژگی را توصیف می کند. این سند به فهرست ./docs در مخزن پروژه اضافه شده است.
- من از Claude Code می خواهم که یک برنامه پیاده سازی ایجاد کند. سپس جزئیات ، ترتیب مراحل و غیره را روشن می کنیم.
- Claude Code گام به گام طرح را پیاده سازی می کند. بعد از هر مرحله ، من به صورت دستی نتیجه را تأیید می کنم.
- در نسخه وب کلود ، لیستی از موارد آزمایش را تدوین می کنم.
- در کد Claude ، ما تست ها را می نویسیم و اجرای آن را صیقل می دهیم.
- متعهد شوید – و به ویژگی بعدی بروید. ممکن است عجیب به نظر برسد که تست ها تا پایان باقی مانده اند. در زیر توضیح می دهم که چرا این رویکرد را انتخاب کردم.
معماری و منطق تجارت
هنگامی که حجم کد از 2-3 هزار خط فراتر رود ، LLM ها با تصمیم گیری صحیح معماری شروع به مبارزه می کنند. از Claude Code انتظار نداشته باشید که به خودی خود درک کند که چه موقع و چگونه مدل های DTO و سطح دامنه را جدا کنید ، یا در آن منطق باید در آن اقامت داشته باشد – در مخزن یا سرویس. همه اینها باید به صورت دستی توضیح داده شود ، و پس از آن شما هنوز هم باید خودتان همه چیز را تمیز کنید. در غیر این صورت ، شما با یک آشفتگی به پایان می رسید.
منطق پیچیده تجارت (در مورد من – زیر سیستم ترجمه محتوا و تشخیص زبان داده های ورودی) به یک رویکرد مخصوصاً دقیق نیاز دارد. اگر یک ویژگی شامل تعداد زیادی ایالت (به عنوان مثال ، ترکیبی از محلی انتخاب شده و زبان ورودی) باشد ، این خطر وجود دارد که LLM شروع به تولید مزخرفات با چندین شاخه کند ، در منطق سردرگم شود و فقط هنگام تلاش برای رفع همه چیز بدتر شود.
چنین منطقی باید به صورت دستی تجزیه شود ، معماری از طریق آن ، در بین مؤلفه ها توزیع می شود و به هضم ترین شکل ممکن ارائه می شود.
تست
من قبلاً تا حدی این نکته را ذکر کردم. اگر از LLM بخواهید که در روح TDD کار کند و ابتدا تست ها را تولید کند – این کار نخواهد کرد. این مزخرف ایجاد می کند ، و سپس Claude Code یک چرخه بی پایان و بی معنی از تنظیم متقابل کد و آزمایش وارد می کند.
اگر پس از آماده شدن کد ، تست هایی ایجاد کنید – مجموعه ای را دریافت می کنید که جزئیات اجرای زیادی را آزمایش می کند. از آنجا که Claude Code کد را در متن می بیند ، قطعاً از این به نفع خود استفاده خواهد کرد.
رویکردی که برای من کار می کرد این بود: تهیه موارد آزمون در نسخه وب کلود بر اساس PRD و سپس تبدیل این موارد به کد.
من همچنین مجبور شدم دستورالعمل های خاصی را در claude.md اضافه کنم تا از ابتکارات خود به خودی دستیار جلوگیری کنم:
## Test Guidelines
- NEVER modify test files unless explicitly asked to do so
- Tests are used to validate code changes and ensure functionality
- Breaking tests makes it difficult to validate other changes
- If you need a test changed or updated, ask for explicit permission first
- Do not attempt to run and fix test issues yourself - wait for guidance
بدون این دستورالعمل ها ، دستیار دائماً سعی می کرد به محض اینکه یکی از آنها شروع به کار کرد ، آزمایشات را برطرف کند.
نتیجه یک نمونه اولیه کاملاً کاربردی بود: theudra.com.
نکات بسیاری وجود دارد که می توان مورد انتقاد قرار گرفت ، اما در کل – این مناسب است.
ترکیبی که من امتحان کردم برای توسعه نمونه های اولیه به خوبی کار می کند. آیا می توان از آن برای ایجاد یک MVP تمام عیار استفاده کرد؟ من نمی دانم … شاید با تجربه خاصی – بله.
احساس من این است که در این کار شتاب تقریباً 3-5 بار بود. علاوه بر این ، من متوجه پتانسیل خوبی برای بهبود ابزار شدم. به عنوان مثال ، کد Claude اغلب در هنگام نیاز به یافتن استفاده از یک نماد خاص ، کد منبع را “Greps” می کند. به نظر می رسد که ادغام با LSP یا ابزارهای مشابه می تواند به طور قابل توجهی کیفیت نتیجه را بهبود بخشد – این چیزی است که بلافاصله از آن برجسته می شود.
و البته ، ما باید انتظار توسعه بیشتر خود LLM ها را داشته باشیم. حکم: من آن را دوست داشتم. قطعاً چیزی برای آن وجود دارد.
در اصل در رسانه منتشر شده است.
