درس های آموخته شده - مجله Smashing

منبع باز ستون فقرات توسعه نرم افزار مدرن است. به عنوان فردی که عمیقاً درگیر جامعه محور و منبع باز شرکت محور است، این امتیاز را داشته ام که رویکردهای متنوع آن را از نزدیک تجربه کنم. این مقاله با تمرکز بر کتابخانه های JavaScript جلویی مانند TresJS و ابزارهایی که من در Storyblok در آنها مشارکت کرده ام، به نحوه نگارش مدرن OSS (متن باز) می پردازد.

اما بگذارید واضح بگویم:

هیچ کتاب بازی جهانی برای OSS وجود ندارد. هر زبان، چارچوب، و پروژه گردش کار، قوانین و فرهنگ خاص خود را دارد - و این اشکالی ندارد. این تغییرات همان چیزی است که منبع باز را بسیار سازگار و متنوع می کند.

هنر تألیف OSS

نوشتن یک پروژه منبع باز اغلب با خارش خود شروع می شود - حل مشکلی که به عنوان یک توسعه دهنده با آن روبرو هستید. اما همانطور که "آزمایش" شما جذابیت پیدا می کند، چالش به سمت پرداختن به موارد استفاده متنوع و در عین حال حفظ سادگی و تمرکز ایده اصلی تغییر می کند.

TresJS را به عنوان مثال در نظر بگیرید. تنها چیزی که می خواستم این بود که 3D را به مجموعه Nuxt شخصی خود اضافه کنم، اما در آن زمان، جایگزین حفظ شده و غنی از ویژگی های React Three Fiber در VueJS وجود نداشت. بنابراین، تصمیم گرفتم یکی را ایجاد کنم. به اندازه کافی خنده دار است، پس از دو سال پس از راه اندازی کتابخانه، نمونه کارها من ناتمام باقی مانده است.

با ادامه TresJS به عنوان نمونه ای از پروژه OSS مبتنی بر جامعه، این انجمن بخش جدایی ناپذیر رشد آن بوده است، ایده ها ارائه می دهد، پرونده های مربوط به پرونده (در مجموع حدود 531 مورد) و ارسال درخواست های کشش (حدود 936 PR) که 90٪ آن است. در نهایت به تولید رسید. به عنوان یک نویسنده، این بهترین چیزی است که می تواند اتفاق بیفتد - احتمالاً این یکی از بزرگترین دلایلی است که من عاشق منبع باز شدم. همکاری مستمر محیطی را ایجاد می کند که در آن ایده های جدید می توانند به مشارکت های معنادار تبدیل شوند.

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

به عنوان نویسندگان، این وظیفه ماست که چشم انداز کتابخانه را روشن نگه داریم - حتی اگر این به معنای نه گفتن به ایده های عالی جامعه باشد.

با گذشت زمان، برخی از ثابت ترین همکاران، بخشی از یک تیم اصلی شدند و به سهیم شدن مسئولیت نگهداری کتابخانه و اطمینان از همسویی آن با اهداف اصلی اش کمک کردند.

یکی دیگر از جنبه های مهم مقیاس بندی یک پروژه، به خصوص پروژه ای مانند TresJS، که به اکوسیستمی از بسته ها تبدیل شده است، توانایی تفویض اختیار. هرچه پروژه بیشتر گسترش یابد، توزیع مسئولیت ها بین مشارکت کنندگان ضروری تر می شود. تفویض اختیار به کاهش بار سنگین کاری کمک می کند و به مشارکت کنندگان در مالکیت بگیرد از مناطق خاص به عنوان یک نویسنده اصلی، به همان اندازه مهم است که ابزارهای لازم، گردش کار CI، و قراردادهای واضح را فراهم کنید تا فرآیند مشارکت تا حد امکان ساده و کارآمد باشد. یک بنیاد کاملاً آماده تضمین می کند که همکاران جدید و موجود می توانند بر آنچه واقعاً مهم است تمرکز کنند - پیشبرد پروژه.

تألیف OSS مبتنی بر شرکت: دیدگاه Storyblok

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

من در شرکت های قبلی با منبع داخلی و منبع باز تجربه داشتم، بنابراین قبلاً درک درستی از نحوه عملکرد OSS در زمینه محیط شرکت داشتم. با این حال، معنی دارترین تجربه من بعداً به دست می آید، به ویژه اوایل امسال، زمانی که نقشم را از DevRel به یک مهندس تجربه توسعه دهنده تمام وقت تغییر دادم و می گویم «تمام وقت» زیرا قبل از بازی کردن نقش، قبلاً در این نقش مشارکت داشتم. اکوسیستم SDK Storyblok.

در Storyblok، منبع باز نقش مهمی در نحوه تعامل ما با توسعه دهندگان و نحوه استفاده یکپارچه از محصول ما با چارچوب مورد علاقه خود ایفا می کند. هدف ما ارائه همان تجربه توسعه دهنده بدون در نظر گرفتن طعم و مزه است و تجربه استفاده از Storyblok را تا حد امکان ساده، مؤثر و لذت بخش می کند.

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

یکی از مزایای منحصر به فرد منبع باز شرکت محور این است در دسترس بودن منابع:

• زمان اختصاصی مهندسی،
• زیرساخت (که بسیاری از نویسندگان OSS اغلب قادر به پرداخت آن نیستند)،
• دسترسی به دانش تیم های داخلی مانند طراحی، QA و مدیریت محصول.

با این حال، این راه اندازی اغلب با چالش برخورد با پایگاه های کد قدیمی همراه است - معمولاً توسط توسعه دهندگانی که ممکن است با اصول OSS آشنا نباشند نوشته شده اند. این می تواند منجر به ناسازگاری در ساختار، آزمایش و مستندات شود که قبل از اینکه پروژه بتواند با بهترین شیوه های منبع باز هماهنگ شود، نیاز به بازسازی قابل توجهی دارد.

من دوست دارم OSS مبتنی بر جامعه را مانند موسیقی جاز تصور کنم - فرم آزاد، بداهه، و عمیقاً مشارکتی. در مقابل، OSS مبتنی بر شرکت شبیه یک ارکستر است، با یک رهبر که اجرا را هدایت می کند و اطمینان می دهد که همه قطعات به طور یکپارچه در کنار هم قرار می گیرند.

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

جالب است که عکس این موضوع نیز صادق است: OSS مبتنی بر شرکت می تواند به طور قابل توجهی از نوآوری سریع که در پروژه های جامعه محور دیده می شود بهره مند شود.

بسیاری از پیشرفت هایی که از زمان پیوستن به اکوسیستم Storyblok ارائه کرده ام، از ایده هایی الهام گرفته شده اند که برای اولین بار در TresJS بررسی شدند. به عنوان مثال، مهاجرت اکوسیستم TresJS به pnpm workspaces نشان داد که چگونه مدیریت وابستگی ساده می تواند جریان های کاری توسعه مانند زمین های بازی و e2e را بهبود بخشد - رویکردی که بعداً به تدریج برای اکوسیستم Storyblok اقتباس کردیم.

به طور مشابه، انتقال تست Storyblok از Jest به Vitest، با عملکرد بهبود یافته و تجربه توسعه دهنده، تحت تأثیر نحوه رویکرد آزمایش در پروژه های جامعه محور قرار گرفت. به همین ترتیب، جابجایی ما از Prettier به پیکربندی مسطح v9 ESLint با تعمیر خودکار به ادغام پرده بندی و قالب بندی در یک جریان کاری واحد کمک کرد و بهره وری توسعه دهنده را ساده تر کرد.

حتی فرآیندهای دانه دارتر، مانند نوسازی گردش های کاری CI، راه خود را به Storyblok پیدا کردند. تکامل TresJS از یک اقدام انتشار یکپارچه به مراحل دانه ای برای پر کردن، آزمایش و ساختن، طرحی برای تقویت خطوط لوله ما در Storyblok ارائه کرد. ما همچنین شیوه های انتشار مداوم را با الهام از آن اتخاذ کردیم pkg.pr.new، امکان تحویل سریعتر تغییرات افزایشی و انتشار بسته های آزمایشی در پروژه های مشتری واقعی برای جمع آوری بازخورد فوری قبل از ادغام PRs.

گفتنی است، TresJS همچنین از تجربیات من در Storyblok که دارای اکوسیستم بالغ تر و آزمایش شده تر بود، به ویژه در پذیرش فرآیندهای خودکار بهره برد. به عنوان مثال، ما Dependabot را برای به روز نگه داشتن وابستگی ها ادغام کردیم و از ادغام خودکار برای کاهش مداخلات دستی برای به روز رسانی های جزئی استفاده کردیم، و زمان مشارکت کنندگان را برای کارهای معنادارتر آزاد کردیم. ما همچنین یک خط لوله انتشار خودکار را با استفاده از GitHub Actions، با الهام از گردش های کاری Storyblok، اجرا کردیم، و از انتشار روان تر و مطمئن تر برای اکوسیستم TresJS اطمینان حاصل کردیم.

چالش های نگارش OSS مدرن

در طول این مقاله، چندین چالش مدرن OSS را لمس کرده ایم، اما اگر کسی شایسته تاج باشد، مدیریت تغییرات شکسته و حفظ سازگاری. ما می دانیم که سرعت فناوری به ویژه در وب چقدر سریع است و کاربران انتظار دارند کتابخانه ها و ابزارها با آخرین روندها هماهنگ باشند. من اولین کسی نیستم که می گویم توسعه مبتنی بر تبلیغات می تواند سرگرم کننده باشد، اما ذاتاً مخاطره آمیز است و بهترین متحد شما در هنگام ساختن نرم افزار قابل اعتماد و با کارایی بالا نیست - به ویژه در زمینه های سازمانی.

تغییرات شکستن وجود دارد. به همین دلیل است که نسخه سازی معنایی وارد عمل می شود تا زندگی ما را آسان تر کند. با این حال، به همان اندازه مهم است تعادل نوآوری با ثبات. این امر هنگام معرفی ویژگی های جدید یا اصلاح مجدد برای عملکرد بهتر، شکستن APIهای موجود، بسیار مهم تر می شود. یکی از درس های کلیدی که آموخته ام - به ویژه در طول مدتی که در Storyblok بودم - اهمیت آن است ارتباط شفاف. تغییرات، راهنمای مهاجرت، و هشدارهای منسوخ شدن ابزارهای ارزشمندی برای هموار کردن انتقال برای کاربران هستند.

یک مثال عملی:

اولین پروژه من به عنوان یک مهندس تجربه توسعه دهنده، معرفی بود @storyblok/richtext، کتابخانه ای برای پردازش متن غنی که (در زمان نوشتن) حدود 172 هزار بار در ماه می بیند. این کتابخانه در زمان من به عنوان DevRel ساخته شد، اما انتقال کاربران به آن از اجرای متن غنی قبلی در اکوسیستم نیاز به برنامه ریزی دقیق داشت. از آنجایی که کتابخانه به یک وابستگی به JS SDK اساسی تبدیل می شود - و از آنجا به همه SDK های چارچوبی انتشار می یابد - به همراه مدیر من، ما یک انتقال چند ماهه با یک دوره سازگار با یکپارچه سازی را قبل از انتشار اصلی برنامه ریزی کردیم. این شامل کمپین های ارتباطی، مستندسازی کامل و پذیرش تدریجی برای به حداقل رساندن اختلال بود.

با وجود این تلاش ها، اشتباهاتی رخ داد - و این اشکالی ندارد. در طول انتقال متن غنی، مواردی وجود داشت که به روزرسانی ها به موقع دریافت نمی شدند یا ارتباطات و اسناد به طور موقت هماهنگ نبودند. این امر منجر به سردرگمی در جامعه شد که ما با ارائه پشتیبانی به موقع در مورد مشکلات GitHub و Discord آن را برطرف کردیم. این لحظات به عنوان یادآوری بود که حتی با نسخه سازی معنایی، معماری های مدولار و برنامه ریزی دقیق، نوشتن OSS هرگز کامل نیست. اشتباهات بخشی از فرآیند هستند.

و این ما را به نقطه زیر می برد.

نتیجه گیری

تالیف متن باز یک سفر یادگیری مداوم است. هر گام اشتباه فرصتی برای بهبود ارائه می دهد و هر موفقیت ارزش همکاری و آزمایش را تقویت می کند.

هیچ راه "عالی" برای انجام OSS وجود ندارد، و زیبایی آن در همین است. هر پروژه دارای مجموعه ای از گردش کار، چالش ها و ویژگی های خاص خود است که توسط جامعه و مشارکت کنندگان آن شکل می گیرد. این تفاوت ها منبع باز را سازگار، پویا، سرگرم کننده و مهمتر از همه تاثیرگذار می کند. مهم نیست که چیزی کاملاً جدید می سازید یا در یک پروژه موجود مشارکت می کنید، به یاد داشته باشید که پیشرفت، نه کمال، هدف است.

بنابراین، به مشارکت، آزمایش و به اشتراک گذاری کار خود ادامه دهید. هر درخواست کششی، مسئله و ایده ای که مطرح می کنید، نه تنها برای پروژه شما، بلکه برای اکوسیستم گسترده تر، ارزش و ارزش به ارمغان می آورد.

کد نویسی مبارک!

(Yk)