انتخاب تکنولوژی برای محصول: چطور بدون وسواس تصمیم بگیریم
بحث بر سر «بهترین فریمورک» معمولاً وقت تلف کردن است. معیارهای مهمتر اینها هستند: تیم، عمر محصول، هزینهی تغییر و قابلجایگزینی بودن. اینجا چارچوب تصمیم را میبینید.
خواندن مقالهموضوع
معماری نرمافزار به زبان تصمیم: لایهها، مرزها، ثبت تصمیم و ساخت سامانهای که بشود بعداً تغییرش داد.
۸ مقاله
بحث بر سر «بهترین فریمورک» معمولاً وقت تلف کردن است. معیارهای مهمتر اینها هستند: تیم، عمر محصول، هزینهی تغییر و قابلجایگزینی بودن. اینجا چارچوب تصمیم را میبینید.
خواندن مقالهلازم نیست میان «سریع بسازیم» و «درست بسازیم» یکی را انتخاب کنید. اگر مرزهای سامانه از ابتدا درست کشیده شوند، میشود پشت هر مرز سادهترین پیادهسازی را گذاشت و بعداً بدون بازنویسی رشد کرد.
خواندن مقالهپرداخت، پیامک، پایگاه داده و هوش مصنوعی روزی عوض میشوند. الگوی «درگاه و مبدل» کمک میکند این تغییر با عوض کردن یک فایل انجام شود، نه با بازنویسی محصول. توضیح ساده با مثال واقعی.
خواندن مقالهشش ماه بعد کسی یادش نیست چرا این پایگاه داده یا این ساختار انتخاب شد. ثبت تصمیم معماری یا ADR، سندی یکصفحهای است که دلیل هر تصمیم مهم را نگه میدارد و جلوی بحثهای تکراری را میگیرد.
خواندن مقالهبدهی فنی همیشه بد نیست. مثل وام، اگر آگاهانه گرفته شود و برنامهی بازپرداخت داشته باشد، میتواند به سرعت محصول کمک کند. تفاوت بدهی خوب و بد، و روش مدیریت آن بدون توقف توسعه.
خواندن مقالهدر یک محصول SaaS، چند مشتری از یک سامانه استفاده میکنند و دادهی هیچکدام نباید به دیگری برسد. سه الگوی اصلی چندمستاجری، مزایا و هزینهی هر کدام، و اشتباههایی که به نشت داده میرسند.
خواندن مقالهوقتی قرارداد API پیش از پیادهسازی نوشته شود، تیمهای رابط کاربری و سرور همزمان کار میکنند، اختلافها زودتر پیدا میشوند و یکپارچهسازی آخر پروژه غافلگیری نمیشود. روش کار و نکتههای طراحی.
خواندن مقالهامنیت قابلیتی نیست که بعداً اضافه شود. چند تصمیم ساده در ابتدای کار، مثل اعتبارسنجی ورودی، مدیریت درست رمز و کلید، کمترین دسترسی و سرتیترهای امنیتی، جلوی بیشتر حادثههای رایج را میگیرد.
خواندن مقاله