نوشتن کد ETL قابل حفظ: توانمندسازی پشتیبانی و جلوگیری از سیلو دانش

وقتی کد ETL را می نویسیم ، تمرکز ما معمولاً روی منطق تجارت ، دقت داده ها و عملکرد است. و در حالی که اینها بسیار مهم هستند ، جنبه دیگری به همان اندازه مهم وجود دارد که اغلب از آن غافل می شویم: حفظ قابلیتبشر

قطعه ای از منطق ETL که امروزه کاملاً کار می کند ، اگر به گونه ای نوشته شود که درک ، عیب یابی یا اصلاح آن دشوار باشد ، ممکن است باعث ایجاد اصطکاک شود. به یاد داشته باشید: شما فقط برای خودتان کد می نویسید – شما آن را برای آن می نویسید تیم حامی، مهندس، و توسعه دهنده بعدی چه کسی آن را انتخاب می کند

بیایید از این طریق بپردازیم که چرا نوشتن کد ETL روشن و قابل حفظ و چگونگی انجام درست آن را انجام می دهیم.

چرا قابلیت حفظ باید اولویت شما باشد

تصور کنید که کار ETL شما در ساعت 3 صبح انجام نمی شود. تیم پشتیبانی صفحه می شود. آنها کار را باز می کنند و یک نمودار عظیم و بدون مستند پر از لایه ها ، تبدیل های تو در تو و اسکریپت های سفارشی را می بینند. بدون نظر بدون اشاره هیچ جریان مشخصی وجود ندارد.

آنها چه می کنند؟ به احتمال زیاد: آن را تشدید کنید.

این بدان معناست که این مسئله به توسعه یا حتی منبع اصلی که آن را ساخته است ، باز می گردد – که هدف از داشتن یک مدل پشتیبانی 24×7 را شکست می دهد. شما نه تنها وضوح را کاهش داده اید ، بلکه به دلیل تأخیر ، تأثیر تجارت را نیز افزایش داده اید.

اینجاست وضوح هوشمندی را می زندبشر

هزینه پنهان عدم اشتراک دانش

متأسفانه ، بسیاری از توسعه دهندگان کد ETL پیچیده را می نویسند اما وقت خود را برای به اشتراک گذاشتن دانش یا مستند سازی کار خود نمی گیرند. این ایجاد می کند وابستگی های غیر ضروری در چند نفر کلیدی اگر این افراد در دسترس نباشند – به تعطیلات ، استعفا یا حتی یک بیماری ساده – کل سیستم می تواند متوقف شود.

این سیلو دانش یک خطر عمده برای هر شرکت است که به طور بالقوه منجر به قطع طولانی مدت یا آتش نشانی پرهزینه می شود.

خوشبختانه ، ما وارد دوره جدیدی هستیم. با پیشرفت در هوش مصنوعی ، اکنون ابزارهایی در دسترس هستند که می توانند کد پیچیده را به طور خودکار اسکن ، تفسیر و توضیح دهیدبشر این بدان معنی است که حتی اگر مستندات پراکنده باشد ، هوش مصنوعی می تواند به تیم های پشتیبانی و توسعه دهندگان جدید کمک کند تا جریان کار ETL را سریعتر از گذشته درک کنند.

با این وجود ، تکیه فقط به هوش مصنوعی جایگزین مستندات خوب و کد پاک نیست. هوش مصنوعی یک دستیار قدرتمند است – اما بهترین روش برای نوشتن کد تمیز ، قابل درک و به اشتراک گذاری دانش به صورت پیشرو است.

آن را ساده نگه دارید ، حتی اگر پیچیده باشد

گردش کار ETL می تواند ذاتاً پیچیده باشد ، به خصوص هنگام برخورد با چندین سیستم ، قوانین تجاری و وابستگی. اما پیچیدگی در عمل لازم نیست به معنای پیچیدگی در باشد رمزبشر

در اینجا چند اصل برای دنبال کردن وجود دارد:

1 طراحی برای خواننده

کد ETL خود را بنویسید که گویی کسی که آن را بسازد ، باید ساعت 2 صبح آن را اشکال زد. این مخاطبان شماست.

• برای نمودارها ، مؤلفه ها و پارامترها از نامهای معنی دار استفاده کنید.
• از راه حل های بیش از حد جمع و جور یا “هوشمند” که خطوط شما را نجات می دهد اما دیگران را گیج می کند ، خودداری کنید.
• اجزای گروهی از نظر منطقی و از طرح/حاشیه نویسی استفاده می کنند تا جریان را به وضوح نشان دهند.

2 سند جایی که مهم است

اگر منطق شما شامل انشعاب مشروط ، قوانین تحول یا اسکریپت های پوسته است ، وقت خود را برای مستند کردن آنها اختصاص دهید.

• نظرات را مستقیماً در بلوک های نمودار یا اسکریپت اضافه کنید.
• یک سند به سبک README را حفظ کنید که تصمیمات اصلی طراحی را تشریح می کند.
• برای نمودارهای قابل استفاده مجدد یا بسته بندی ها ، ورودی ها ، خروجی ها و انتظارات را توضیح دهید.

3 برای هر کار یک کتاب رونوشت ارائه دهید

بوها کتاب یک مین طلای برای تیم پشتیبانی است. این به آنها می گوید وقتی همه کارها اشتباه می شوند ، بدون نیاز به درگیر کردن DEV چه کاری باید انجام دهند.

یک دفترچه خوب ETL شامل موارد زیر است:

• هدف از کار (چرا وجود دارد)
• برنامه (وقتی اجرا می شود)
• وابستگی های بالادست و پایین دست
• سناریوهای شکست مشترک و نحوه رسیدگی به آنها
• چگونه دوباره آن را با خیال راحت اجرا کنیم (دستورات یا مراحل)
• در صورت نیاز به افزایش تماس با مخاطبین هشدار

این باعث اعتماد به نفس و استقلال تیم پشتیبانی می شود.

وقتی باید منطق پیچیده ای بنویسید …

بعضی اوقات ، شما فقط نمی توانید از پیچیدگی جلوگیری کنید-شاید این یک الزام نظارتی یا یک ارکستراسیون متقابل پلتفرم است. در این موارد:

• منطق را در نمودارهای کوچکتر و مدولار یا اسکریپت ها بشکنید.
• شامل a Doc طراحی سطح بالا با تصاویر یا نمودارهای جریان.
• در هنگام تحویل با تیم پشتیبانی خود از طریق آن قدم بزنید.

اگر نمی توانید کد را ساده کنید ، درک از آن ساده

افکار نهایی

شغل شما به عنوان یک توسعه دهنده ETL فقط برای جریان داده ها نیست. این است که اطمینان حاصل کنید که سیستم در حال اجرا است –حتی وقتی اطراف نیستیدبشر

کد قابل نگهداری ، مستندات مناسب و یک دفترچه راهنمای کامل “خوب و خوب” نیست. آنها بخشی از انجام کار درست هستند.

تیم های پشتیبانی شرکای شما در تولید هستند. آنها را برای موفقیت تنظیم کنید ، و کمتر تشدید ، تماس های کمتری در اواخر شب و زمان بیشتری برای تمرکز روی ساختن چیزهای جدید به جای اصلاح موارد قدیمی خواهید داشت.

و به یاد داشته باشید: با ظهور ابزارهای دارای هوش مصنوعی ، آینده امیدوار کننده برای تجزیه سیلوهای دانش است. اما تا آن زمان ، بهترین روش روشن است –کد تمیز ، به خوبی سند بنویسید و دانش را با صراحت به اشتراک بگذاریدبشر

📌 آن را تمیز بنویسید. آن را خوب مستند کنید. آن را به طور گسترده به اشتراک بگذارید. و همیشه دنباله ای را ترک کنید که دیگران می توانند از آن پیروی کنند.