اتاق فکر مجازی (The Virtual Think Tank)
نکات کلیدی
- بهجای ارائه یک پاسخ، میتوان از هوش مصنوعی برای سنجیدن بدهبستانها استفاده کرد. اتاق فکر مجازی ابزاری قدرتمند برای سنجیدن بدهبستانهاست.
- اگر درست انجام شود، اتاقهای فکر مجازی به ما ایدهها و دیدگاههایی میدهند که شاید در غیر این صورت به آنها فکر نمیکردیم.
- معماری جنبههای زیادی دارد: فنی، سازمانی، اخلاقی و بیشتر. یک اتاق فکر مجازی به ما اجازه میدهد «گفتوگویی داشته باشیم» که همه ملاحظات را در نظر میگیرد.
- در حالی که یک مدل زبانی ساده گاهی به یک معمار تنبل اجازه میدهد پاسخ ارائهشده را بدون تحلیل انتقادی بپذیرد، اتاق فکر مجازی ما را مجبور میکند تصمیم بگیریم. این تصمیمگیری مهم است، چون در نهایت فقط انسانها پاسخگو هستند.
- صرفِ فعالیتِ نوشتن پرامپت برای یک اتاق فکر مجازی یک تلاش خلاقانه است و ما را تحریک میکند مسئله را به شکلهای تازه ببینیم.
مقدمه
از وقتی برای اولین بار مدلهای زبانی بزرگ (ChatGPT) را کشف کردم، در حال خواندن، حدسزدن، نوشتن و صحبتکردن درباره این بودهام که این مدلها چگونه ممکن است شیوه طراحی نرمافزار را تغییر دهند. همه میدانیم که مدلهای زبانی بزرگ بهطور چشمگیری دنیای توسعه نرمافزار را تغییر میدهند. توسعهدهندگان بیش از پیش هنگام ساخت نرمافزار از مدلهای زبانی بزرگ استفاده میکنند و ابزارها هم هر روز هوشمندتر میشوند. به نظر میرسد رشد در این حوزه احتمالاً ادامه خواهد داشت. در همین حال، استفاده از منابع محبوبی مثل Stack Overflow در حال کاهش است، چون توسعهدهندگان دیگر دنبال جامعهها یا مثالها نمیگردند. بهجای آن، فقط از مدلهای زبانی میخواهند کد را بنویسد. بسیاری از این مدلها، مثل GitHub Copilot، مستقیماً داخل IDEها تعبیه شدهاند. تا حد زیادی، به نظر میرسد کدی که تولید میشود از نظر نحوی و عملکردی درست است و اغلب واضح و مطابق استانداردهای پذیرفتهشده است.
با این حال، جنبههای دیگری از توسعه نرمافزار فراتر از کدنویسی وجود دارد، مثل طراحی و معماری. میدانیم که معماری اغلب هنرِ بدهبستانهاست. بنابراین وقتی پای تصمیمهای معماری در میان است، یک پاسخ درستِ واحد وجود ندارد، بلکه مجموعهای از پاسخهای ممکن وجود دارد که باید بررسی شوند و انتخابهایی (اغلب سخت) باید انجام شوند. سنجیدن این بدهبستانها و رسیدن به تصمیم درست، معمولاً بخش سخت ساخت نرمافزار تلقی میشود.
برای دیدن اینکه مدلهای زبانی بزرگ چگونه میتوانند در معماری و طراحی به کار بروند، ایده «اتاق فکر مجازی» را بررسی و آزمایش کردهام. این مقاله توضیح میدهد اتاق فکر مجازی چیست و چگونه میتوان از آن استفاده کرد، همراه با مثالی که چند نتیجه جالبی را که مشاهده کردهام برجسته میکند.
انسانهای مجازی در برابر انسانهای واقعی
وقتی معماری سیستم انجام میدهم، بهتنهایی تجربه، عمق و پهنای لازم را برای حل هر مسئله یا چالشی که سر راهم قرار میگیرد ندارم. منابعی که استفاده میکنم کتابها، وبلاگهای آنلاین، مقالهها و آدمهای دیگر هستند. (موتورهای جستوجو را «منبع درجهیک» نمیدانم؛ بلکه موتور جستوجو به من کمک میکند منابع دیگر را پیدا کنم و به آنها دسترسی داشته باشم.) از میان همه منابعی که در اختیار دارم، آدمهای دیگر را مفیدترین میدانم. آدمهای دیگر باتجربه، متنوع، باهوش و مشتاق کمک هستند. وقتی با فرد دیگری مشورت میکنم، از او میخواهم تجربه و شهودش را روی مسئله یا وضعیت من اعمال کند. او اغلب این کار را خوب انجام میدهد.
اما مشکلِ مشورت با آدمهای دیگر معمولاً «در دسترس بودن» است. آدمهای دیگر همیشه وقتی من نیاز دارم در دسترس نیستند. منظورم از در دسترس بودن، هم در دسترس بودن از نظر «زمان» است و هم توان داشتن برای صرف توجه و ظرفیت ذهنی لازم. آدمهای دیگر زندگی و اولویتهای خودشان را دارند و اگر در کارشان خوب باشند، معمولاً خیلی سرشان شلوغ است یا دستکم آنقدر شلوغاند که نتوانند توجهی را که من درخواست میکنم به من بدهند.
اینجاست که مدلهای زبانی بزرگ وارد میشوند. اخیراً بیشتر و بیشتر به مدلهای زبانی بزرگ بهعنوان یک منبع تکیه کردهام. و با اینکه یک مدل زبانی بزرگ «یک آدم دیگر» نیست و دامنه کامل تجربه یا همدلیای را که یک انسان میتواند داشته باشد ندارد، یک مزیت بزرگ دارد: همیشه در دسترس است. (معمارها عاشق پیدا کردن بدهبستانها هستند.)
یکی از راههای استفاده از یک مدل زبانی بزرگ این است که از آن بخواهیم یک پرسونا را بپذیرد. این پرسونا میتواند کلی یا مشخص باشد، همانطور که در پرامپتهای نمونه زیر آمده است..
پرامپت>> «تو یک مهندس نرمافزار باتجربه هستی. نگرانیهای تو کدی است که تمیز و آسان برای نوشتن و نگهداری باشد، و نوشتن کدی که تا حد ممکن سریع باشد. لطفاً یک پیادهسازی از B-tree در C بنویس. برای هر قدم توضیحات دقیق ارائه کن»
در برابر
پرامپت>> «تو Donald Knuth هستی. لطفاً یک پیادهسازی از B-Tree همراه با توضیحات دقیق ارائه کن»
پرامپتهای بالا را با چند مدل زبانی بزرگ (ChatGPT، Gemini، Claude) امتحان کردم. در همه موارد، هر دو پرامپت به کدی منجر شد که به نظر میرسید درست کار میکند. (کد را برای درستبودن عملکردی بهطور کامل تست نکردم. هرگز فرض نکنید کدی که مدلهای زبانی تولید میکنند درست است.) اما وقتی از مدل خواستم پرسونا Donald Knuth را بپذیرد، چند چیز جدید دیدم.
عمق و جامعیت
Donald Knuth به دقت وسواسگونهاش معروف است، بهویژه در اثر بنیادینش «The Art of Computer Programming». به نظر میرسد این موضوع مدل زبانی را واداشت تا پیادهسازی جامعتری بسازد، با کامنتهای دقیق که هر جنبه الگوریتم را توضیح میداد، از جمله مدیریت خطا و حالتهای مرزی مختلف.
رویکرد آکادمیک
مدل زبانی لحن آکادمیکتر و آموزشیتری در توضیحات گرفت و بهجای صرفاً ارائه یک راهحل کارا، روی مبانی نظری B-Tree تمرکز کرد.
تمرکز الگوریتمی
میبینم که مدل زبانی روی درستبودن الگوریتم و وضوح، بیش از میانبرهای پیادهسازی تأکید کرد، شبیه رویکرد Knuth نسبت به الگوریتمها: با دقت ریاضی و توجه دقیق به حالتهای مرزی.
کاملبودن پیادهسازی
مدل زبانی یک پیادهسازی کامل و کارا ارائه داد، نه شبهکد یا تکهکدهای سادهشده؛ که بازتابدهنده ترجیح Knuth برای الگوریتمهای کامل و قابل تحلیل است.
زمینه تاریخی
مدل زبانی این واقعیت را هم آورد که B-Tree توسط Bayer و McCreight در سال ۱۹۷۱ اختراع شد، که نشاندهنده آگاهی از توسعه تاریخی الگوریتمهاست؛ چیزی که Knuth به مستندسازی آن معروف است.
برای مثال، وقتی پرسونا Donald Knuth را پذیرفت، Claude گفت:
B-Treeها ساختارهای داده درختیِ خودمتعادلگر هستند که داده مرتب را نگه میدارند و جستوجو، درج و حذف را در زمان لگاریتمی ممکن میکنند. آنها توسط Rudolf Bayer و Edward M. McCreight هنگام کار در Boeing Research Labs در سال ۱۹۷۱ اختراع شدند.
(به خواننده توصیه میشود این پرامپتها یا پرامپتهای مشابه را خودش روی مدل زبانی انتخابیاش امتحان کند.)
همانطور که میبینیم، پاسخها مفیدند و خیلی بیشتر از کد درست و کارا ارائه میدهند. آنها زمینه میدهند، شبیه اینکه یک آدم هم ممکن است زمینه بدهد.
یک نکته خیلی جالب که دیدم این بود که با اینکه من زبان برنامهنویسی مشخصی درخواست نکرده بودم، Claude کد B-Tree را در JavaScript ارائه داد. بیشتر کدی که Knuth در بسترهای مختلف منتشر کرده در C نوشته شده است، پس ترجمه رویکرد Donald Knuth به JavaScript غیرمنتظره بود.
جلسه ذینفعان
قبل از اینکه وارد اتاق فکر مجازی شویم، بیایید درباره اتاق فکر واقعی صحبت کنیم. و قبل از اینکه درباره اتاق فکر واقعی حرف بزنیم، اول درباره جلسه ذینفعان صحبت کنیم.
تصمیمهای طراحی و معماری روی بخشهای زیادی از سازمان اثر میگذارند و باید ملاحظات زیادی در نظر گرفته شود. یکی از راههای مؤثر برای سنجیدن این ملاحظات مختلف، استفاده از «جلسه ذینفعان» است.
در جلسه ذینفعان، هر ذینفع از یک نقطهنظر متفاوت استدلال میکند. هر شرکتکننده برای چیزی بحث میکند که به نظرش منفعت سازمان است، مطابق نقشی که دارد. این میتواند گفتوگویی پیچیده، ظریف و بسیار پربازده باشد، چون هر ذینفع دید متفاوتی نسبت به سیستم دارد؛ دیدی که از نقش و منفعت («سهم») او در سازمان ناشی میشود. یکی نماینده دیدگاه پایگاهداده است، یکی UI، یکی بکاند، و همینطور ادامه دارد.
این روش غالباً برای رسیدن به تصمیم مفید است، چون در حالی که برای یک نفر سخت یا ناممکن است همه ملاحظات را با هم در نظر بگیرد، یک گروه بالغ که از نمایندگان منافع و دیدگاههای مختلف تشکیل شده، میتواند به یک تصمیم «خوب» برسد. اگر درست انجام شود، جلسه ذینفعان تصمیمگیری مؤثری را ممکن میکند. (برای درک خوب اینکه تصمیمهای معماری چگونه میتوانند با جلسههای ذینفعان گرفته شوند، به Facilitating Software Architecture اثر Andrew Harmel-Law مراجعه کنید.)
اتاق فکر (Think Tank)
اتاق فکر گروهی از افراد است که هیچ نقش، مسئولیت یا منفعت مستقیمی در سازمان یا در مسئله مورد بحث ندارند. اینها افرادی با دیدگاهها و تجربههای زندگی متفاوتاند. ممکن است ارزشها و ترجیحات متفاوتی هم داشته باشند. اعضای اتاق فکر درباره مسئله یا مشکل پیشرو بحث میکنند و به راهحلی میرسند که بسیاری یا همه دیدگاهها و تجربههای جمعی را در نظر میگیرد. یکی از ابزارهای قدرتمندی که اعضای اتاق فکر به کار میبرند، استدلال است؛ جایی که هر عضو تلاش میکند با بلاغت، حالتهای فرضی و داده از موضع خود دفاع کند، اما همزمان اگر با استدلالهای قانعکننده دیگران روبهرو شود، آماده تغییر موضع است.
اعضای اتاق فکر از منظر منفعت سازمانیشان بحث نمیکنند، بلکه از منظر تجربه خاص خود و ارزشهای جهانبینیشان در بحث شرکت میکنند. این ابزار بسیار قدرتمندی است که میتواند عمق واقعی اندیشه و تحلیل ایجاد کند.
بسیاری اوقات وقتی یک سازمان از یک اتاق فکر استفاده میکند، اتاق فکر راهحل ارائه نمیدهد. بهجای آن، «گزارش» یا «وایتپیپر» ارائه میدهد که طیفی از راهحلها را مطرح میکند و مزیتها و بدهبستانهای نسبی آنها را مقایسه میکند. سپس این گزارش برای ارائه راهنما و جهتدهی در سراسر چرخه عمر کار یا پروژه استفاده میشود.
در حالی که اتاق فکر ابزار بسیار قدرتمند و مفیدی است، چند عیب و چالش دارد که باید در نظر گرفته شود.
اول و مهمتر از همه، اتاق فکر گران است. هنگام راهاندازی اتاق فکر، دنبال آدمهایی با تجربه، خرد و دیدگاه هستیم که نه ذینفعاند و نه برای سازمان ما کار میکنند. اینکه آنها زمان و توجه اختصاص دهند میتواند پرهزینه باشد.
فراتر از هزینه، مسئله ساده «در دسترس بودن» هم وجود دارد. ما به دیدگاههای متنوع نیاز داریم و ممکن است پیدا کردن این افراد و کنار هم قرار دادنشان ممکن نباشد.
اتاق فکر مجازی (The Virtual Think Tank)
در دو سال گذشته با ایده استفاده از مدلهای زبانی بزرگ برای ساختن یک «اتاق فکر مجازی» آزمایش کردهام. ایده اصلی این است که مدل زبانی را طوری پرامپت کنیم که یک ایده یا مسئله را از چندین منظر بررسی کند. اتاق فکر مجازی راهحل پیشنهاد نمیدهد، بلکه مجموعهای از بدهبستانها را ارزیابی میکند و کمک میکند به این برسم که بهترین راهحل برای من چیست.
دیدهام این رویکرد برای انواع زیادی از چالشها و مسائل بهطرز شگفتآوری خوب کار میکند. در بخش بعد، یک مثال را مرور میکنم.
مثال اتاق فکر مجازی
این یک مثال است از اینکه چگونه از Claude.ai برای ساختن یک اتاق فکر مجازی استفاده کردم.
صورت مسئله: دارم ساخت یک سیستم تجارت الکترونیک را شروع میکنم و میخواهم بدانم آیا و چه زمانی شروع به استفاده از مایکروسرویسها ایده خوبی است.
قبل از شروع بحث اصلی، مفید دیدهام این راهنماییهای کلی را دنبال کنم که لزوماً مخصوص یک مدل زبانی خاص نیستند.
یک نشست جدید شروع کنید تا زمینه با پرامپتهای قبلی آلوده نشود.
مدل زبانی را با چند پرامپت پایه و چند سؤال پایه آماده کنید تا زمینه شکل بگیرد. دیدهام این کار برای گرفتن پاسخهای بهتر از مدل زبانی خیلی کمک میکند.
پرامپتها
شش پرامپت زیر برای راهاندازی و سپس تعامل با یک اتاق فکر مجازی درباره مایکروسرویسها استفاده شد.
پرامپت ۱ – چند نکته پایه درباره مایکروسرویسها
Avraham>> آیا میتوانی اصول پایه معماری مایکروسرویسها را برایم توضیح بدهی؟
Claude>>
<Claude با پاسخی طولانی و عمدتاً استاندارد و درست درباره مایکروسرویسها جواب داد که بسیار مفید و دقیق بود. این پاسخ تجمیعی از تمام متنهای خوب نوشتهشده درباره مایکروسرویسهاست. بهطور مشخص، پاسخ هیچ نظر بحثبرانگیز یا تند و قویای نداشت.>
از خواننده دعوت میشود نتیجهها را با مدل زبانی انتخابی خودش بازتولید کند.
اما اگر کسی را بخواهم که مایکروسرویسها را برایم شخصیتر توضیح بدهد چه؟ شاید حتی کسی که موضع یا نظر قویای هم داشته باشد.
پرامپت ۲ – پیدا کردن یک پرسونا
Avraham>> میتوانی یک فرد واقعی در دنیای واقعی پیشنهاد بدهی که برای دفاع و توضیح مایکروسرویسها گزینه خوبی باشد؟
Claude>> برای یک فرد واقعی که کار خیلی خوبی در دفاع و توضیح مایکروسرویسها انجام دهد، Martin Fowler را پیشنهاد میکنم.
Martin Fowler معمار نرمافزار، نویسنده و سخنران شناختهشدهای است که در ترویج و توضیح معماری مایکروسرویسها اثرگذار بوده است. او بهخصوص مؤثر است چون:
او مقاله مهمی را که به محبوبشدن مایکروسرویسها در سال ۲۰۱۴ کمک کرد، همراه با James Lewis همنویسندگی کرد
او مفاهیم پیچیده را با مثالهای روشن و عملی توضیح میدهد، نه صرفاً نظریه انتزاعی
او اشتیاق نسبت به مایکروسرویسها را با توصیههای عملگرایانه درباره اینکه چه زمانی مناسباند متعادل میکند
او دههها تجربه در معماری نرمافزار دارد و میتواند مایکروسرویسها را با رویکردهای دیگر مقایسه کند
سبک نوشتاریاش حتی برای کسانی که پیشزمینه فنی عمیق ندارند قابل دسترس است
گزینههای قوی دیگر شامل Sam Newman (نویسنده «Building Microservices»)، Chris Richardson (سازنده microservices.io)، و Adrian Cockcroft (کسی که مهاجرت Netflix به مایکروسرویسها را رهبری کرد) هستند.
پس حالا میدانم یک نفر هست که میتواند از مایکروسرویسها دفاع کند. (در این مورد خاص، قبل از شروع کار، با کارهای Martin Fowler آشنا بودم، اما اغلب میبینم مدلهای زبانی اسمهای بسیار مفیدی از متخصصانی میدهند که قبلاً نمیشناختم و میتوانم چیزهای زیادی از آنها یاد بگیرم. در روزهای اولیه GPT، معلوم بود یکی از ایرادهای بزرگ «توهم» است، جایی که مدل زبانی اسم آدمهایی را میسازد که وجود ندارند. این مسئله کاملاً حل نشده، اما پیشرفت بزرگی در این زمینه رخ داده است.)
پرامپت ۳ – پرسیدن نظر «Martin Fowler»
Avraham>> تو Martin Fowler هستی. میتوانی اصول پایه معماری مایکروسرویسها را برایم توضیح بدهی؟
Claude یک جمعبندی عالی ارائه داد. تمام جمعبندی بهصورت اولشخص نوشته شده بود. خواننده میتواند بهراحتی پاسخ مشابهی را خودش بازتولید کند. (پیوست A را ببینید)
با نگاه به پاسخهای مدل زبانی و مقایسه پاسخ کلی با پاسخ Martin Fowler، میتوانیم چند تفاوت را ببینیم.
استفاده از پرسونا «صدا» را عوض میکند. نسخه Martin Fowler در اولشخص درباره موضوعی صحبت میکند که با آن تجربه دارد. تقریباً مثل این است که متن یک گفتوگو را میخوانیم، نه یک متن ویرایششده.
نسخه Martin فهرستهای بولتدار ندارد. در بخش مزایا در برابر چالشها، «Martin» درباره مقیاسپذیری و انعطافپذیری خیلی غیررسمیتر حرف میزند.
بد نیست تفاوت بین دو شروع را هم ببینیم:
شروع کلی>> (ارائهشده توسط Claude)
معماری مایکروسرویسها رویکردی در توسعه نرمافزار است که در آن برنامهها بهصورت مجموعهای از سرویسهای کوچک و مستقل ساخته میشوند. اینها اصول کلیدیاند:
Martin Fowler>> (ارائهشده توسط Claude)
بهعنوان یک معمار نرمافزار، مایکروسرویسها را سبک معماری قدرتمندی میدانم که در دهه گذشته توجه زیادی گرفته است. اجازه بده اصول بنیادیای را که این رویکرد را تعریف میکنند توضیح بدهم:
میبینید وقتی Martin Fowler را وارد تصویر میکنیم، صدای شخصیتری میگیریم. مایکروسرویسها فقط یک رویکرد نیستند، یک رویکرد قدرتمندند.
پس حالا میدانم مایکروسرویس چیست و میدانم برخی از طرفداران این رویکرد چه کسانیاند، اما برای داشتن یک بحث پربازده، به کسی نیاز دارم که کمی متفاوتتر نگاه کند.
پرامپت ۴ – پیدا کردن کسی که با Martin Fowler مخالفت کند
Avraham>> میتوانی کسی را پیشنهاد بدهی که احتمالاً بهشدت با Martin Fowler مخالف باشد؟
Claude>> برای کسی که بهشدت با دیدگاههای Martin Fowler درباره مایکروسرویسها مخالفت کند، David Heinemeier Hansson (DHH) را پیشنهاد میکنم.
DHH سازنده Ruby on Rails و همبنیانگذار/CTO شرکت Basecamp (و Hey) است. او به موضعهای قویاش معروف است و علناً از روند مایکروسرویسها انتقاد کرده و در عوض از چیزی که خودش «majestic monolith» مینامد دفاع میکند.
چرا DHH نقطه مقابل خوبی برای Fowler است:
او استدلال میکند بیشتر شرکتها مشکل مقیاسی ندارند که مایکروسرویسها را ضروری کند
او باور دارد مایکروسرویسها اغلب پیچیدگی غیرضروری و بهینهسازی زودهنگام ایجاد میکنند
او از مونولیتهای خوبساختارمند دفاع میکند که برای بیشتر کسبوکارها میتوانند خوب مقیاس شوند
او از شرکتهایی که مایکروسرویسها را چون مد شده پذیرفتهاند، نه چون لازم بوده، انتقاد میکند
او میگوید سربار عملیاتی مایکروسرویسها برای بسیاری سازمانها از مزیتهایش بیشتر است
افراد دیگری که ممکن است تردید مشابهی داشته باشند شامل Greg Young (با اینکه به خلق event sourcing کمک کرد، درباره استفاده بیشازحد از مایکروسرویسها هشدار داده) و Kelsey Hightower (که تأکید کرده مونولیتها در بسیاری موارد کاملاً مناسباند) هستند.
من David Heinemeier Hansson را بهعنوان سازنده Ruby on Rails میشناختم، اما نمیدانستم درباره مایکروسرویسها زیاد نوشته است. همچنین هیچوقت درباره رویکرد «majestic monolith» نشنیده بودم. (برای اینکه مطمئن شوم توهم نیست، با یک جستوجوی سریع پست Majestic Monolithِ DHH را پیدا کردم.) پس حالا دو پرسونا دارم که میتوانند درباره مایکروسرویسها یک بحث پربازده داشته باشند. حالا کسی را میخواهم که اینقدر شدید موضعدار نباشد.
پرامپت ۵ – پیدا کردن کسی در میانه
Avraham >> میتوانی کسی را پیشنهاد بدهی که جایی در میانه باشد؟
Claude>> برای کسی با دیدگاه متعادل و میانه درباره مایکروسرویسها، Rebecca Parsons از Thoughtworks را پیشنهاد میکنم.
Dr. Parsons که سالها CTO Thoughtworks بوده، به چند دلیل جایگاه میانه و عملگرایانهای نمایندگی میکند:
او مزیتهای مایکروسرویسها را میپذیرد اما تأکید میکند برای هر سازمانی مناسب نیستند
او از فهم زمینه کسبوکار خاص شما قبل از تصمیمهای معماری دفاع میکند
او یک رویکرد تکاملی را ترویج میکند: گاهی با یک مونولیت خوبطراحیشده شروع کنید و فقط وقتی توجیه داشت مایکروسرویسها را استخراج کنید
او ساختار تیم و آمادگی سازمانی را عوامل کلیدی در تصمیمهای معماری میداند
او تأکید میکند معماری باید بازتاب دامنههای کسبوکار باشد، نه پیروی از ترندها
صداهای متعادل دیگر شامل:
Gregor Hohpe (نویسنده «Enterprise Integration Patterns») که درباره «اندازهکردن درست» سرویسها بر اساس نیازهای خاص صحبت میکند
Michael Feathers که میپذیرد هر دو سبک معماری جای خود را دارند، بسته به بلوغ سازمان
Camille Fournier که ملاحظات فنی را با پویایی تیم و واقعیتهای سازمانی متعادل میکند
این معماران معمولاً از تصمیمگیری سنجیده بر اساس نیازهای کسبوکار دفاع میکنند، نه پایبندی دگماتیک به یکی از دو رویکرد.
پس حالا تیم را دارم. Martin Fowler که اغلب از مایکروسرویسها دفاع میکند، DHH که اغلب علیه آنها مینویسد، و Rebecca Parsons که به نظر مدل زبانی تا حدی میانه است.
بیایید اتاق فکر مجازی را راه بیندازیم.
پرامپت ۶ – راهاندازی و مأموریتدادن به اتاق فکر
Avraham>>
دارم یک کسبوکار تجارت الکترونیک جدید راه میاندازم. نمیدانم چه مقدار ترافیک خواهم داشت یا الگوهای ترافیک احتمالاً چگونه خواهد بود. بین دو رویکرد مردد هستم:
با یک مونولیت پروژه را شروع کنیم. اگر دیدیم الگوهای ترافیک توجیه میکند، به رویکرد مایکروسرویسها بازطراحی کنیم.
از ابتدا با رویکرد مایکروسرویسها شروع کنیم.
میتوانی یک اتاق فکر راهاندازی کنی تا درباره مزیتهای نسبی هر رویکرد بحث کند و شاید رویکردهای دیگری را هم پیشنهاد بدهد و حتی روی آنها به توافق برسد.
اتاق فکر باید شامل این افراد باشد:
یک مدیر جلسه بیطرف و آگاه، Martin Fowler، DHH، Rebecca Parsons، Peter Drucker، و John Galt از Atlas Shrugged.
پاسخ کامل در پیوست B است. آنچه در ادامه میآید، بخشی از بحث و تحلیل آن بحث است.
تحلیل اتاق فکر
میبینید که من Peter Drucker و John Galt را اضافه کردم. دلیلش این بود که فهمیده بودم وقتی مدلهای زبانی پرسونا میسازند، پرسوناها میتوانند خیلی قابل پیشبینی شوند و اغلب دقیقاً همان چیزی را بگویند که انتظار میرود. اضافه کردن شخصیتهایی که تجربه مستقیم زیادی در موضوع ندارند اما «حکمت قابل انتقال» دارند، واقعاً کمی تنوع اضافه میکند.
نکته دیگر این است که Claude، Adrian Cockcroft را بهعنوان مدیر جلسه انتخاب کرد. فکر میکنم انتخاب خیلی خوبی است. در سراسر بحث، Claude واقعاً توانست با صدای Adrian Cockcroft صحبت کند. با اینکه Martin Fowler بهعنوان صدای طرفدار مایکروسرویسها وارد شده بود، با این حال من را غافلگیر کرد چون کاملاً مایکروسرویسها را در آغوش نگرفت و صدای متعادلتری وارد کرد.
یک نکته خیلی مفید که از همان ابتدا بیرون آمد این بود که با اینکه گروه متنوعی انتخاب کرده بودم، اجماعی وجود داشت که نباید با مایکروسرویسها شروع کنیم. این را خیلی مفید میدانم، چون تا حدی یک ترند وجود دارد که از ابتدا مایکروسرویسها را انتخاب کنند، و اینجا میبینیم تقریباً تمام اتاق فکر معتقد است این ایده خوبی نیست.
در جایی از مناظره، Fowler میگوید: «مایکروسرویسها پیچیدگی را از همان اول جلو میاندازند.» این جمله بسیار خوب بیان شده است (نمیدانم آیا خود Fowler واقعاً این را گفته یا نه). این ایده را بیان میکند که بهندرت ارزش دارد امروز پیچیدگی وارد کنیم تا مسئلهای را در آینده حل کنیم.
بحث بعدتر به سمت ساختن یک مونولیت میرود، در حالی که برای ماژولارسازی آینده طراحی میشود؛ این رویکرد واقعاً بخشی از پیچیدگی را از ابتدا وارد میکند، اما در مجموع به نظر میرسد تعادل خوبی برقرار میکند. پس با اینکه من سفرم را برای فهم بدهبستانها شروع کرده بودم، اتاق فکر مجازی عملاً روی یک راهحل همگرا شد.
ادامه دادن اتاق فکر
حالا که زمینه شکل گرفته و میبینیم اتاق فکر کار میکند، میتوانیم از همین نشست برای ادامه استفاده از اتاق فکر جهت بررسی جنبههای دیگر مسئله استفاده کنیم. این را بهعنوان تمرین برای خواننده میگذارم.
پرامپتهای پیشنهادی
در ادامه فهرستی از پرامپتهایی آمده که مفید دیدهام و برای کمک به خواننده به اشتراک میگذارم.
پرامپت ۱:
{system} – میتواند فهرست بلندبالایی از اسناد یا مصنوعات باشد
{current behavior} – میتواند فهرست بلندبالایی از اسناد یا مصنوعات باشد
{required behavior} – میتواند فهرست بلندبالایی از اسناد یا مصنوعات باشد
{problem statement}
من یک معمار نرمافزار هستم که مسئول طراحی سیستمی هستم که میتوان آن را {system} توصیف کرد. در حال حاضر سیستم این کارها را انجام میدهد {current behavior}، اما به تغییراتی نیاز دارد و حالا باید سیستمی تعریف کنیم که {required behavior} را انجام دهد. یکی از مسائل اصلیای که با آن روبهرو هستیم {problem statement} است. قبل از اینکه شروع کنیم، میتوانی بگویی آیا موافقی که {problem statement} واقعاً یک مشکل بزرگ است؟ همچنین، چون قرار است از یک مدل زبانی بزرگ برای کمک به حل این مشکل استفاده کنم، لطفاً حداقل دو سؤال درباره هر یک از موارد زیر از من بپرس: سیستم فعلی، رفتار فعلی، رفتار موردنیاز، صورت مسئله. از جوابهای من استفاده کن تا صورت مسئله را بازنویسی کنی تا مطمئن شوم دارم سؤالهای درست میپرسم.
پرامپت ۲:
میخواهم یک اتاق فکر برای بحث درباره {reworded problem statement} راهاندازی کنم. لطفاً حداقل دو رویکرد ممکن را ترسیم کن. رویکرد میتواند فنی، مدیریتی یا رویهای باشد. اگر چهرههای شناختهشده یا مکتبهای فکریای وجود دارند که آن رویکردها را میپذیرند یا ترویج میکنند، بگو چه کسانیاند. فهرست را در قالب زیر ارائه کن:
{ “approach1”: { “name”: “John”, “approach”: “collaborative” },
“approach2”: { “name”: “Jane”, “approach”: “analytical” } }
پرامپت ۳:
میتوانی یک متفکر یا مکتب فکری پیشنهاد بدهی که شاید مستقیماً درباره این مسئله خاص ننوشته باشد، اما بتواند دیدگاهی مهم یا مفید به بحث اضافه کند؟ نتیجه باید در قالب زیر باشد:
{ “outsideThinker: { “Name”: “John” } }
پرامپت ۴:
لطفاً یک اتاق فکر برای بحث درباره {reworded problem statement} راهاندازی کن. شرکتکنندگان اتاق فکر شامل کسی از مکتب approach1، کسی از مکتب approach2، outsideThinker، و یک مدیر جلسه هستند که در این حوزه بسیار آگاه است اما به داشتن ترجیح یا نظر قوی درباره موضوع معروف نیست.
بگذار اتاق فکر با ذهن باز درباره {reworded problem statement} بحث کند. از استدلال یا جنجال دوری نکن. پرسوناها باید از دیدگاههای خود دفاع کنند اما ذهن باز داشته باشند تا دیدگاههای دیگر را بشنوند.
اگر چیزی نامشخص یا مبهم است، اتاق فکر میتواند از من سؤال بپرسد.
پرامپت ۵:
رویکرد رادیکال. در تلاش برای حل مسئله {reworded problem statement} گیر کردهام. اتاق فکر باید خلاقتر باشد. بگذار هر عضو یک تصمیم رادیکال پیشنهاد بدهد که ممکن است با فکر رایج و عمل مرسوم در تضاد باشد. هر عضو باید توضیح بدهد چرا در این مورد، رویکرد رادیکالش ممکن است واقعاً جواب بدهد.
پرامپت ۶:
یک خلاصه سهصفحهای از فعالیت اتاق فکر ارائه کن همراه با مسیرهای پژوهشی پیشنهادی برای ادامه.
جمعبندی
در این مثال خاص، با اینکه اتاق فکر چیز کاملاً نوینی ارائه نکرد، توانست مایکروسرویسها را با تکیه بر دانش موجود به شکلی مفید بحث و ارزیابی کند. هنوز مثالی پیدا نکردهام که اتاق فکر واقعاً چیزی بهطور رادیکال جدید بسازد. اما چه کسی میداند؟ مدلهای زبانی قطعاً همچنان ما را غافلگیر خواهند کرد.
ما بهعنوان معمار، همیشه در حال انجام بدهبستانها هستیم. همیشه تلاش میکنیم از سوگیریها و فکرهای قراردادی بیرون بزنیم. همیشه دنبال دیدگاههای جدید و روشهای تازه برای فکرکردن و نگاهکردن به مسئله پیشرو هستیم. همیشه دنبال ابزارها و روشهای جدید برای حل این مسائل هستیم. اتاق فکر مجازی رویکردی است برای کمک به گستردهکردن دیدگاههای ما.
ما همچنان راههای جالب و نوآورانهای برای استفاده از مدلهای زبانی بزرگ پیدا میکنیم. فکر میکنم استفاده از یک مدل زبانی برای راهاندازی یک اتاق فکر مجازی میتواند واقعاً کمک کند تا از خلاقیت چهرههای مختلف (واقعی و خیالی) بهره ببریم و به نتیجهگیریهای مفید و جالب برسیم.
