https://virgool.io/feed/@devoker من مهدی صمدانی هستم. درحال کسب مهارت در حوزه ی مدیریت محصول ام. تجربیاتم رو باهاتون به اشتراک میگذارم? fa 2026-07-08 01:52:53 https://files.virgool.io/upload/users/26865/avatar/O5nuaa.jpeg?height=120&width=120 https://virgool.io/@devoker https://virgool.io/javacup/git-workflow-centralized-workflow-vcniikmnww07 ? مراقب باشیم!زﻣﺎﻧﯽ ﮐﻪ ﻣﺒﺤﺚ workflow ﻣﻄﺮح ﻣﯿﺸﻪ، ﺗﺼﻤﯿﻢ‌ﮔﯿﺮی اﯾﻦ ﻣﻮﺿﻮع ﺧﯿﻠﯽ ﺑﺴﺘﮕﯽ ﺑﻪ ﻓﺮﻫﻨﮓ ﺗﯿﻢ ﯾﺎ culture داره. ﺑﺎ اﺿﺎﻓﻪ ﺷﺪن workflow اﯾﻦ اﻧﺘﻈﺎر ﻣﯿﺮه ﮐﻪ، ﮐﺎراﯾﯽ ﺗﯿﻢ اﻓﺰاﯾﺶ ﭘﯿﺪا ﮐﻨﻪ! ﮔﺮدش ﮐﺎر ﻣﯿﺘﻮﻧﻪ ﯾﻪ مسئولیت اﺿﺎﻓﻪ روی ﺗﯿﻢ اﯾﺤﺎد ﮐﻨﻪ و ﻃﺒﯿﻌﺘﺎ ﮐﺎﻫﺶ productivity در ﺗﯿﻢ و ﻣﺤﺼﻮل رو ﺑﻬﻤﺮاه داره.انتخاب استراتژیبرای انتخاب استراتژی مناسبِ تیم و محصول خودمون، باید این موارد رو درنظر بگیریم:? آیا این workflow مناسب سایز تیم یا محصول من هست؟? اگه به اشتباه یا خطایی برخورد کردم، این workflow به داد من میرسه؟? آیا این workflow با اضافه شدنش، سربار ذهنی غیرضروری جدیدی به تیم وارد میکنه؟ورک‌فلِو متمرکز | Centralized Workflowمیشه گفت این استراتژی در git، ساده ترین روش برای مدیریت codebase محصول به حساب میاد. در این روش، یک default branch وجود داره و اون master نامیده میشه. در این روش فقط یک نقطه ی ورود برای همه ی تغییرات در پروژه وجود دارد. درسته که این روش فرق چندانی با نگهداری کد بصورت local نداره، ولی باعث میشه برنامه نویس ها فارق از بقیه ی تغییرات اعمال شده توسط بقیه افراد تیم، بتونن کد بزنن و فیچر خودشون رو به repository اضافه کنند.#نظرشخصی: این روش بنظر من واسه تیم های کوچک و کمتر از ۵ نفر مناسبه⚫️ ایجاد تغییرات و commitزمانی که توسعه دهنده repository رو clone میکنه، میتونه با استفاده از فرآیند های گیت مثل edit،stage،commit تغییرات جدیدی رو بصورت local در repository اعمال کند.برای بررسی تغییرات میتوانید از این دستور استفاده کنید:⚫️ انتقال کامیت های جدید به central repositoryزمانی که تغییرات جدیدی در local repository کامیت شد، نیازه که این تغییرات با بقیه ی برنامه نویس های محصول، به اشتراک گذاشته شود. با اجرا کردن این فرمان کامیت های جدید، در برنچ master که از اون بعنوان central repository استفاده میکنیم، push میشه. این احتمال وجود داره که تغییرات جدید کد، باعث بشه هم تیمی شما هنگام push کردن کدهای جدید به خطای مغایرت یا conflict error برخورد کنه!⚫️ اولین راهِ چارهاولین راهکار برای رفع conflict در این شرایط اجرای git pull هست که در ادامه راهکار جامع تری رو توضیح میدم.⚫️ مدیریت conflictsاگه local commit های توسعه با central repository هم‌خوانی نداشته باشه، گیت از push کردن تغییرات خودداری میکنه به این دلیل که این امکان وجود داره که central repository دچار overwrite شود.? یک مثال از این ورک‌فلوبیایید یک مثال کلی در مورد چگونگی همکاری یک تیم کوچک معمولی با استفاده از این گردش کار بیاوریم. خواهیم دید که چگونه دو برنامه نویس ، John و Mary ، می توانند روی ویژگی های جداگانه کار کنند و مشارکت های خود را از طریق یک مخزن متمرکز به اشتراک بگذارند.توسعه feature توسط Johnدر local repository خود ، John می تواند فیچر خود را با استفاده از فرآیند استاندارد Git توسعه دهد. به یاد داشته باشید از آنجا که این دستورات کامیت های local را ایجاد می کنند ، John می تواند این روند را هر چند بار که بخواهد تکرار کند بدون اینکه نگران تغییرات موجود در central repository باشد.توسعه feature توسط Maryدر همین حال ، Mary با استفاده از همان فرایند در حال کار بر روی feature خود در local repository خود است. برای Mary مانند John مهم نیست که در central repository چه می گذرد و اهمیتی ندارد که John مشغول چه کاری است. زیرا همه repository ها local و خصوصی هستند.انتشار feature توسط Johnهنگامی که John فرآیند توسعه ی feature خود را به پایان رساند باید local commit های خود را در central repository منتشر کند تا سایر اعضای تیم بتوانند به آن دسترسی پیدا کنند. او می تواند این کار را با دستور git push انجام دهد:انتشار feature توسط Maryبیایید ببینیم اگر Mary سعی کنه feature خود را انتشار دهد، پس از اینکه John با موفقیت تغییرات خود را در central repository منتشر کرد ، چه اتفاقی می افتد. اون نیز مانند John از دستور git push استفاده میکند ولی با خطا مواجه میشود:استفاده از rebase توسط Maryکاری که Mary میتواند انجام دهد استفاده از git pull است. با این کار تغییراتی که قبلا John در central repository منتشر کرده است، به local repository مری انتقال می‌یابد و کامیت های John هم با کامیت های Mary ادغام میشود:در دستور بالا، با اضافه کردن rebase-- پس از یکسان سازی local repository با central repository، تمام کامیت های Marry به ابتدای برنچ master انتقال می‌یابد: رفع یک تداخل ( merge conflict ) توسط Marryفرآیند rebasing با انتقال هر کامیت local به برنچ master انجام میشود. این به این معناست که تداخلات کد بجای حل شدن در یک merge commit بزرگ، کامیت به کامیت حل میشوند. این قابلیت به نگهداری تمیز تر کد کمک زیادی میکند. از طرف دیگر، این امر باعث میشود که ریشه ی اشکالات را راحت‌تر پیدا کنید و درصورت نیاز، بازگرداندن تغییرات ( roll back ) با کمترین تاثیر بر روی پروژه و محصول انجام شود.اگر Mary و John روی دو feature مختلف کار کنند، بعید بنظر میرسد که روند rebasing دچار تداخل شود. درغیر اینصورت git فرایند را با این پیام متوقف میکند:نکته ی جالب در مورد git این است که هر کس میتواند merge conflict خود را حل کند. در مثال ما، Mary به سادگی با اجرای git status میتواند فایل های دارای تداخل را در بخش Unmerged paths مشاهده کند:سپس فایل (ها) را همانطور که میخواهد ویرایش میکند. زمانی که به نتیجه ی مطلوب رسید، میتواند فایل ها را به stage اضافه کند و اجازه دهد git rebase بقیه ی کاراها را انجام دهد:این تنها کاری است که باید انجام شود. git به commit بعدی میرود و این فرایند را تکرار میکند تا همه ی تداخلات برطرف شود.اگر در این فرآیند به مرحله ای رسیدید که نمیدانید چخبر است، وحشت نکنید! فقط دستور زیر را اجرا کنید و به همان مکانی که شروع کردید برمیگردید:انتشار موفق feature توسط Maryبعد از انجام مراحل قبل و همگام سازی هر دو ریپوزیتوری ( local و central ) Mary میتواند تغییرات خود را با موفقیت منتشر کند.? در پست های آینده راهکار های مناسب تیم های بزرگ تر را ارائه میکنم.خوش حال میشم از شبکه های اجتماعیم دیدن کنید و نظراتتون رو بنویسید ❤️https://zil.ink/devoker devoker devoker Sat, 29 May 2021 23:34:21 +0430 https://virgool.io/javacup/%DA%A9%D8%AF%D8%A7%D9%85-%D9%84%D8%A7%DB%8C%D8%B3%D9%86%D8%B3-%D8%B1%D8%A7-%D8%A7%D9%86%D8%AA%D8%AE%D8%A7%D8%A8-%DA%A9%D9%86%DB%8C%D9%85-gwbxrzkroyiz اخیرا، خبر تغییر لایسنس فیسبوک برای برنامه نویسان بسیار هیجان انگیز بود.تیم توسعه‌ی فیسبوک لایبرری های بسیاری از محصولات خود را از BSD-3 patents به MIT تغییر داد.این خبر بنظر خوب میاد، ولی به چه معناست؟لایسنس های متنوع دنیای متن باز چه تفاوتی باهم دارند؟در این مقاله قصد دارم به برخی از لایسنس های محبوب اشاره کنم.همچنین روش انتخاب این لایسنس ها در گیت هاب را نیز آموزش میدم.تحت مسئولیت ؟بیشتر لایسنس های محبوب دنیای متن باز یک جنبه ی مهم و مشترک دارند. تایید توسط Open Source Initiative. درسال ۱۹۹۸ OSI با هدف اصلی ترویج نرم افزار‌های متن باز تشکیل شد.با شکل گیری این مجمع اصلی ترین سوال ینی تعریف متن باز بودن پاسخ داده شد.برخی از لایسنس هااکثر لایسنس های متن باز از ۴ اصل پیروی میکنند:۱- نرم افزار را میتوان تغییر داد، مورد استفاده ی تجاری قرار داد و توزيع کرد.۲- نرم افزار را میتوان تغییر داد و بصورت شخصی استفاده کرد.۳- لایسنس و کپی رایت باید در نرم افزار موجود باشد.۴- نویسندگان نرم افزار هیچ ضمانتی در برابر نرم افزار ندارند و برای هیچ چیزی مسئول نیستند.در ادامه برخی از لایسنس ها از کمترین محدودیت ها تا بیشترین مجازارت ها را بررسی میکنیم.(از نگاه کاربران!)GNU General Public License, version 3 (GPLv3)یکی از محدودترین لایسنس ها GPLv3 می باشد.این لایسنس حمایت شدیدی را برای نویسندگان نرم افزار فراهم میکند.هر زمان نرم افزار مورد تولید قرار گرفت، سورس کد نیز باید عمومی شود.تغییرات نرم افزار نیز باید تحت همین لایسنس انجام گیرد.تغییرات انجام شده در سورس کد حتما باید مستند باشد.اگر از Patent در ساخت نرم افزار استفاده شده باشد، کاربران نیز حق استفاده از آنها را دارند.اگر کاربری از Patent سو استفاده کند، آنها حق استفاده از نرم افزار را از دست میدهند.درست مانند این لایسنس، GPLv2 نیز بسیار محبوب است.تفاوت این لایسنس با نسخه ی ۳ شرایط استفاده از Patent ها می باشد.این شرایط برای جلوگیری از افزایش تعداد کاربران شرکت ها به منظور استفاده از Patent ها در نسخه ی ۳ قرار گرفت.از پروژه های محبوبی که از این GPLv3 استفاده میکنند میتوان به Bash و GIMP اشاره کرد.سیستم عامل Linux از GPLv2 استفاده میکند!Richard StallmanApache License 2.0کاربران بوسیله ی Apache License 2.0 انعطاف پذیری بیشتری را تجربه میکنند.هر زمان نرم افزار مورد تولید قرار گرفت، نیاز به عمومی کردن سورس کد نیست.تغییرات نرم افزار میتواند تحت هر لایسنس دیگری انجام گیرد.تغییرات انجام شده در سورس کد حتما باید مستند باشد.حفاظت از Patent های مورد استفاده مانند GPLv3 می باشد.به صراحت استفاده از نام های تجاری موجود در پروژه ممنوع است.پروژه های محبوبی از قبیل Android ، Apache و Swift از این لایسنس استفاده میکنند.Berkeley Software Distribution (BSD)لایسنس BSD شامل دو ورژن اصلی میشود: دوشرطی و سه شرطی. هردو ورژن این لایسنس انعطاف پذیری بیشتری را نسبت به Apache License 2.0 برای کاربران فراهم میکند.هر زمان نرم افزار مورد تولید قرار گرفت، نیاز به عمومی کردن سورس کد نیست.تغییرات نرم افزار میتواند تحت هر لایسنس دیگری انجام گیرد.تغییرات انجام شده در سورس کد نیاز به مستند شدن ندارد.جایگاه مشخصی برای استفاده از Patent درنظر نگرفته شده است.لایسنس و کپی رایت باید در مستندات ورژن کامپایل شده ی سورس کد قرار گیرد.(برخلاف قانون اصلی سایر لایسنس ها)در BSD سه شرطی عنوان شده است که، استفاده از نام های نویسندگان (author) و همکاران (contributors) در ترویج مشتقات آن نرم افزار بدون اجازه ممنوع است.پروژه هایی که از لایسنس BSD استفاده میکنند: Go ، Pure.css و SentryMIT Licenseیکی دیگر از لایسنس های قابل قبول و میتوان گفت محبوب ترین لایسنس، MIT می باشد.کمترین میزان محافظت را برای نویسندگان نرم افزار فراهم میکنم.هر زمان نرم افزار مورد تولید قرار گرفت، نیاز به عمومی کردن سورس کد نیست.تغییرات نرم افزار میتواند تحت هر لایسنس دیگری انجام گیرد.تغییرات انجام شده در سورس کد نیاز به مستند شدن ندارد.جایگاه مشخصی برای استفاده از Patent درنظر نگرفته شده است.پروژه های محبوبی مانند Angular.js, jQuery, Rails, Bootstrap و بسیاری دیگر از لایسنس MIT استفاده میکنند.پروژه ی React.js که از محصولات Facebook می باشد تا ۲۵ سپتامبر تحت لایسنس BSD-3 plus قرار داشت.این لایسنس در حقیقت همان BSD سه شرطی است که شروط بیشتری را در بخش بکارگیری Patent دارا است.بطور خلاصه، اگر شما از Facebook یا سایر شرکت های تابع آن سو استفاده میکردید اجازه ی استفاده از React یا سایر نرم افزارهایی که از این لایسنس استفاده میکردند را نداشتید.پس از پیوستن React به لایسنس MIT شما پس از سواستفاده از فیسبوک، باز هم میتوانید از React استفاده کنید! چقدر خوب :)روش افزودن لایسنس به پروژه های متن باز خودتاناین کار بسیار ساده است. تنها کاری که باید بکنید افزودن یک فایل LICENSE یا LICENSE.txt یا LICENSE.md در دایرکتوری روت پروژه ی گیت هابتونه!گیت هاب این کار رو راحت تر کرده:۱- ریپوزیتوری پروژه رو توی گیت هاب باز کنید.۲- توی دایرکتوری روت پروژه بر روی Create new file کلیک کنید.۳- نام فایل رو “LICENSE” قرار بدید.۴- بر روی Choose a license template کلیک کنید.۵- لایسنس موردنظرتون رو انتخاب کنید.۶- بعد از اینکه انتخاب کردید روی Review and submit کلیک کنید.۷- در انتها فایل افزوده شده رو Commit کنید!سعی کردم متن رو راحت ترجمه کنم.خوش حال میشم نظراتتون رو بنویسید!منبع:https://www.freecodecamp.org/news/how-open-source-licenses-work-and-how-to-add-them-to-your-projects-34310c3cf94/گیت هاب! devoker devoker Tue, 19 Feb 2019 00:59:24 +0330 https://virgool.io/@devoker/%D8%B3%D9%87-%D8%A7%D8%B5%D9%84-%D8%B3%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%AF%D8%B1-%DA%A9%D8%AF-kiss-yagni-dry-xghxybaz7fre در سال های زیادی که من در دنیای برنامه نویسی بوده ام با کد های پیچیده ی زیادی را مشاهده کرده ام که حسی در من بوجود نیاورده اند.به عبارت دیگر کدهایی را دیده ام که تنها برنامه نویسش میداند چجوری کار میکنید.با این حال وقتی از برنامه نویس پرسیده میشه این کد چجوری داره میکنه در جواب میگه: فقط خدا میدونهمشخصا همه میدونن سناریو های زیادی وجود نداره واسه مسائلی که در نگاه اول حل کردنشون سخت بنظر میرسه، ولی این سوال بوجود میاد که چرا برنامه نویس باید اون رو مسئله رو با کدنویسی پیچیده تر کنه؟؟برای همین دوس دارم راجع به چند تا اصل (بسیار کاربردی) صحبت کنم.اصولی که توی زندگی هم به کار میاد!KISS“Keep It Simple, Stupid”اصل KISS در برنامه نویسی بسیار اهمیت دارد.سعی کنید این اصل را سعی کنید به خاطر بسپارید و برای حفظ آن تلاش کنید.هرچقدر کد ساده تر باشد نگهداری آن در آینده ساده تر است.افراد دیگری که بخواهند کد شما را مورد ارزیابی قرار دهند در آینده با استقبال بیشتری این کار را انجام میدهند.اصل KISS توسط Kelly Johnson پایه گذاری شده است و سیستم های خوب به جای پیچیدگی، به سمت ساده سازی پیش میروند.از این رو سادگی، کلید طلایی طراحی است و باید از پیچیدگی های غیرضروری دوری کرد.The Minimal Mountain - Alex HolmYAGNI“You Aren’t Gonna Need It”گاهی اوقات تیم های توسعه و برنامه نویسان در مسیر پروژه تمرکز خود را بر روی قابلیت های اضافه ی پروژه که "فقط الان به آن نیاز دارند" یا "در نهایت به آن نیاز پیدا میکنند" میگذارند.در یک کلام :اشتباه است!در اکثر مواقع شما به آن نیاز پیدا ندارید و نخواهید داشت. "شما به آن نیازی ندارید".اصل YAGNI قبل از کدنویسی بی انتها و بر پایه ی مفهموم "آیا ساده ترین چیزی است که می تواند احتمالا کار کند" قرار دارد.حتی اگر YAGNI را جزوی از کدنویسی بی انتها بدانیم، بر روی تمام روش ها و فرآیند های توسعه قابل اجرا است.با پیاده سازی ایده‌ی "شما به آن نیازی ندارید" میتوان از هدر رفتن وقت جلوگیری کرد و تنها رو به جلو و در مسیر پروژه پیش رفت.هر زمان اضطراب ناشناخته ای در کد حس کردید نشانه ی یک امکان اضافی بدون مصرف در این زمان است.احتمالا شما فکر میکنید یک زمانی این امکان اضافی را نیاز دارید.آرامش خود را حفظ کنید! و تنها به کارهای موردنیاز پروژه در این لحظه نگاه کنید. شما نمیتوانید زمان خود را صرف بررسی آن امکان اضافی کنید چون در نهایت مجبور به تغییر، حذف یا احتمالا پذیرفتن هستید ولی در نهایت جزو امکانات اصلی محصول شما نیست.DRY“Don’t Repeat Yourself”تا الان چندین بار به کد های تکراری در پروژه برخورد کرده اید؟ اصل DRY توسط Andrew Hunt و David Thomas در کتاب The Pragmatic Programmer پایه گذاری ده است.خلاصه ی این کتاب به این موضوع اشاره میکنید که "هر بخش از دانش شما در پروژه باید یک مرجع معتبر، یکپارچه و منحصربفرد داشته باشد". به عبارت دیگر شما باید سعی کنید رفتار سیستم را در یک بخش از کد مدیریت کنید.از سوی دیگر زمانی که از اصل DRY پیروی نمیکنید، در حقیقت اصل WET که به معنای Write Everything Twiceیا We Enjoy Typing دامن گیر شما شده است! ( لذت بردن از وقت تلف کردن )استفاده از اصل DRY در برنامه نویسی بسیار کارآمد است. مخصوصا در پروژه های بزرگ که کد دائما در حال نگهداری و توسعه استممکن است علاقه ای به رعایت اصل DRY نداشته باشید ولی اصول قبلی (YAGNI, KISS) را حتما بخاطر بسپارید.منبع : https://www.itexico.com/blog/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life devoker devoker Sun, 17 Feb 2019 22:17:52 +0330