شکست در مصاحبه فنی و تولد یک ویرایشگر متن اختصاصی
داستان تبدیل شکست در مصاحبه فنی به ساخت یک ویرایشگر متن اختصاصی مشابه گوگلداکس با استفاده از معماری ایونت سورسینگ و چالشهای مدیریت صفحات دیجیتال.
بسیاری از ما تجربه تلخ رد شدن در مصاحبههای شغلی را داریم. گاهی سوالات به قدری انتزاعی هستند که پاسخ دادن به آنها در یک جلسه چهل دقیقهای غیرممکن به نظر میرسد. این دقیقا همان اتفاقی بود که برای یک توسعهدهنده رخ داد. سوال ساده بود: یک ویرایشگر سند شبیه به گوگلداکس طراحی کن. اما پاسخ دادن به آن، به جای یک استخدام ساده، به مسیری طولانی برای درک عمیق ساختار اسناد دیجیتال ختم شد. او پس از شکست در مصاحبه، به جای ناامیدی، آستینها را بالا زد تا واقعا یکی از آنها را بسازد.
ساختن یک ویرایشگر متن برخلاف ظاهرش، اصلا شبیه به ساختن یک فرم ساده نیست که چند ورودی متنی داشته باشد. در اکثر ابزارهای رزومهساز معمولی، شما فیلدهایی را پر میکنید و در نهایت یک خروجی تحویل میگیرید. اما در یک ویرایشگر واقعی، کاربر باید بتواند مستقیما روی صفحه کلیک کند، بنویسد و چیدمان را تغییر دهد. چالش اصلی زمانی شروع میشود که بخواهید محتوا را در صفحات مجزا تقسیمبندی کنید و مطمئن شوید آنچه روی نمایشگر دیده میشود، دقیقا همان چیزی است که چاپ خواهد شد.
معماری رویدادمحور و چالش پایداری دادهها
اولین قدم برای ساخت چنین سیستمی، انتخاب یک معماری مناسب برای مدیریت تغییرات بود. استفاده از روشهای سنتی ذخیرهسازی که در هر لحظه کل وضعیت سند را در پایگاه داده جایگزین میکنند، برای ویرایشگری که در هر ثانیه دهها کاراکتر در آن تایپ میشود، فاجعهبار است. راهکار جایگزین، استفاده از الگوی منبعدهی رویداد یا همان ایونت سورسینگ بود. در این مدل، ما به جای ذخیره نسخه نهایی سند، تمام تغییرات کوچک و بزرگ را به صورت یک زنجیره از اتفاقات ذخیره میکنیم.
تصور کنید در حال نوشتن یک نامه اداری در یک شرکت ایرانی هستید. وقتی کلمهای را پاک میکنید یا فونت یک تیتر را تغییر میدهید، سیستم فقط همین تغییر کوچک را ثبت میکند. این کار نه تنها سرعت برنامه را بالا میبرد، بلکه امکان پیادهسازی قابلیت بازگشت به عقب یا همان آندو را به سادگی فراهم میکند. بدون این ساختار، مدیریت همزمانی و پایداری دادهها در پروژههای بزرگ تقریبا غیرممکن است.
کابوس تقسیمبندی صفحات و مدیریت فضا
شاید سختترین بخش کار، طراحی الگوریتمی برای برنامهریزی صفحات باشد. در مرورگرها، متنها به صورت جاری و پشت سر هم قرار میگیرند، اما در دنیای چاپ، ما با ابعاد فیزیکی مثل کاغذ آ چهار سر و کار داریم. وقتی کاربر در حال تایپ است و به انتهای صفحه میرسد، محتوا باید به صورت هوشمند به صفحه بعدی منتقل شود. این انتقال نباید باعث بریده شدن ناشیانه یک خط یا جدا شدن تیتر از پاراگراف زیرینش شود.
برای حل این مشکل، نیاز به یک موتور محاسبهگر وجود دارد که در لحظه، ارتفاع تمام عناصر موجود در صفحه را اندازه بگیرد. این موتور باید بداند که اگر یک تصویر بزرگ در انتهای صفحه قرار دارد و فضای کافی برای آن نیست، کل تصویر را به صفحه بعد ببرد و فضای خالی را با متنهای بعدی پر نکند. این محاسبات هندسی در محیط وب که فونتها و اندازهها بر اساس رزولوشنهای مختلف تغییر میکنند، یک چالش مهندسی واقعی است.
تطابق کامل نمایشگر با نسخه چاپی
بسیاری از ابزارهای آنلاین ویرایش متن، در ظاهر عالی به نظر میرسند اما وقتی دکمه خروجی پیدیاف را میزنید، همه چیز به هم میریزد. فاصله خطوط تغییر میکند و ناگهان میبینید که رزومه شما که در سایت یک صفحه بود، در فایل نهایی به دو صفحه تبدیل شده است. برای حل این مشکل، باید از تکنولوژیهایی استفاده کرد که موتور رندرینگ مرورگر را مستقیما به فایل خروجی متصل کنند.
استفاده از کتابخانههایی که لایههای اچتیامال را مستقیما به دستورات گرافیکی پیدیاف تبدیل میکنند، تنها راه چاره است. در این پروژه، هدف این بود که پیکسل به پیکسل آنچه کاربر روی صفحه میبیند، در فایل نهایی تکرار شود. این دقت بالا، تفاوت بین یک پروژه آماتور و یک ابزار حرفهای را مشخص میکند. ساختن چنین ابزاری ثابت کرد که گاهی یک شکست در مصاحبه، میتواند بهترین بهانه برای یادگیری عمیقترین مفاهیم برنامهنویسی باشد.
منبع: dev.to