https://virgool.io/feed/@amirmehdinaghavi لینکدین من: https://www.linkedin.com/in/mehdi-naghavi-82955911b/ fa 2026-06-17 17:46:37 https://files.virgool.io/upload/users/86668/avatar/avatar.png?height=120&width=120 https://virgool.io/@amirmehdinaghavi https://virgool.io/@amirmehdinaghavi/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%DA%A9%D8%A7%D8%B1-%D8%AF%D8%B1-%D9%87%D8%B2%D8%A7%D8%B1%D8%AF%D8%B3%D8%AA%D8%A7%D9%86-nm8nnemiytkb هلدینگ هزاردستان که با محصولات بازار، دیوار و بلد شناخته میشه، در حال کار روی محصولات و ایده های دیگری هم هست و من هم سه ماه هست که عضوی از تیم محصول جدیدشون که در حوزه ی رایانش ابری و هوش مصنوعی ست، مشغولم. مفید دونستم که تجربه سه ماه کاری خودم را در این شرکت به اشتراک بگذارم.هدف از این متن، خاطره گویی نیست بلکه ایده دادن به شرکت ها و افراد برای بهبود فرایندها و معماری های سازمانی شون هست. مواردی که گفته میشه، چیز هایی هست که بسیار ازشون خوشم اومد و با توجه به شناختی که از شرکت های ای تی ایرانی دارم، در جاهای بسیار کمی پیاده سازی شده. قطعا نگفتن نکته منفی به این معنی نیست که مشکلی در هلدینگ نیست،چون قطعا تو هر شرکتی مشکلاتی وجود داره!نمایی از شرکت۱. سیستم ارزیابی عالی و تعیین حقوق عادلانه و خارج از تبعیضهزاردستان به حقوق بالای میانگین در بازار کار معروفه اما مساله ای که برای من جذابه، نحوه تعیین حقوق هست. در هر نوع شغلی ، ۹ رده وجود دارد که ما ان را شبیه یک ماتریس می بینیم. ۲۲ ۲۱ ۲۰۱۲ ۱۱ ۱۰۰۲ ۰۱ ۰۰هر شش ماه یک بار شرکت ها فرایند ارزیابی دارند که این فرایند شامل ۴ مرحله س. تمامی مراحل در یک سایت هست و همه چی شفاف هست و بخش خصوصی ای وجود ندارد!ابتدا هر شخص ۵ مورد از wow ترین کارهایی که در آن شش ماه کرده می نویسد. هم تیمی ها و هر کسی که با ان شخص کار کرده، نظراتش چه مثبت چه منفی درباره ان موارد و ان شخص را می نویسد.همه اطلاعات در کمیته ارزیابی و توسط لیدر ها بررسی می شود و سطح کارمندان با توجه به ماتریس شایستگی که براساس نوع شغل ست، مشخص می شود. در هر نوع شغل، هر رده حقوق مشخصی دارد. مثلا در نوع شغل برنامه نویس backend رده ۱۱ حقوق x دارد و همیشه شرکت در تلاش و رصد ست که رده شغلی هر کس به درستی مشخص شود تا از تبعیض جلوگیری شود.( رده شغلی در هنگام ورود توسط ارزیابان استخدام تعیین می شود و باز هم حقوق براساس ان تعیین می‌شود نه براساس چونه زدن بین کارمند و شرکت!)به عملکرد ۶ ماهه هر شخص نیز نمره تعلق می گیرد که به ان هم action هایی تعلق می‌گیرد. بسیار فراتر از انتظار، فراتر از انتظار، در حد انتظار و کمتر از انتظار. ۲. سیستم حقوق و پاداش و سهمدر هلدینگ سیستم حقوق شامل ۳ offer ست.حقوق ثابت ماهیانهپاداش که هر سه ماه یکبار پرداخت می شود.سهم از هلدینگ که بصورت مستمر تا ۴ سال بصورت مستمر و بخش بخش واگذار می شود.اینکه پاداش هر سه ماه یک بار پرداخت می شود، نگرانی عدم پرداخت پاداش سالیانه توسط شرکت را نیز برطرف می‌کند( دیده شده شرکت های بسیار معروفی که حتی پس از تسویه حساب هم پاداش را نمی‌دهند)۳. تیم های فوق self organizedتیم ها هویت دارند و این هویت صرفا برای شوآف نیست. واقعا دارای قدرت و اختیار هستن و این باعث خلاقیت و حس تعلق می شه که خیلی دلچسبه. تنها کاری که مدیریت می‌کنه تعریف اهداف کوارتر به کمک تیم و لیدر و رصد آن با دمو های ماهانه ست! برنامه ریزی ها و نحوه رسیدن به اهداف توسط تیم تصمیم گیری میشن و کیفیت محصول گاهی توسط چپتر مربوطه بحث و اندازه گیری میشه.حتی بحث دیپلویمنت و sla تیم ها توسط خود تیم کامل هندل میشه و هیچ تیم devops مرکزی ای وجود نداره که مسئولیت تمام و کمال دیپلویمنت ها و شرایط محیطی را داشته باشه. یک تیم بنام NOC وجود داره که فقط مواقع downtime رصد می‌کنه و چک میکنه که دیگه اون مشکل پیش نیاد و همچنین تیم ها از sla شون عبور نکنن!نتیجه این معماری، هم دل شدن و صمیمی شدن اعضای تیمه.راستی یک بودجه ماهیانه ۱۰۰ هزار تومن به ازای هر نفر، توسط سازمان بعنوان بودجه تیم سازی تخصیص داده میشه که اعضای تیم ها میتونن با دورهمی رفتن و خرج کردنش! بیشتر همو بشناسن و با هم دوست بشن. تیم سازی میتونه هر چیزی باشه، رستوران یا تفریح و سفر یا حتی پیتزا در اسکایپ خوردن مخصوص ایام قرمز کرونایی!۴. چالش های زیاد نرم افزاری و فرصت r&d و خلاقیت زیاداول اینو بگم که من java spring کار می‌کردم ولی هیچ جا تو هلدینگ جاوا نمیزنن. چیزی که در مراحل مصاحبه مهم بوده و هست مهارت حل مساله س. نکته ای که وجود داره بخاطر چالش های زیاد نرم افزاری، تکنولوژی های استفاده شده خیلی زیادن و هر تیمی با چند تاشون عمیقا درگیره و با بسیاریشون در حد سطحی و usage باید کار کنه. من در تیمی که هستم به محض ورود django, golang, kubernetes, hdfs, kafka و چند مورد دیگه را باید یاد می‌گرفتیم و هیچ فشار و یا عجله ای در کار نبود. و برای همه ی اینها، یک سری مراحل اموزشی و داکیومنت برای یادگیری بهتر توسط چپتر تولید شده بود.جا برای خلاقیت تو انجام تسک ها و معماری ها هست و بسیار با روی باز با انها برخورد میشه. همیشه در planning ها یه بخشی برای خلاقیت و ایده های جدید وجود داره.۵. برنامه ریزی های دور از استرسمشکلی که تو اکثر تیم های نرم افزاری هست اینه که کارفرما محصول را خیلی خیلی سریع میخاد و فرصت تست نمیده و حتی پیش میاد مواردی که در حین پیاده سازی فراموش میشن و به انها فکر نمیشه و بعد ها باعث خرابکاری میشن. اینجا، وقت زیاد به انجام تسک ها داده میشه تا بچه ها انواع تست را انجام بدن، وقت کافی برای خوندن merge request های دیگران داشته باشن و به همه ملاحظات جانبی پیاده سازی فکر بکنند و چیزی را جا‌نگذارند.۶. قوی بودن چپتر و انتقال دانشهر هفته جلسه چپتر برگزار میشه و بسیار مفید و جدیدن. حس لبه تکنولوژی بودن کاملن در چپتر ها حس میشه و بچه ها مطالب جذابی برای انتقال دانش تولید میکنن و به اشتراک میگذارن. نکته ای که هست اینه که همیشه یک وقت ۱۰-۲۰ دقیقه ای قبل از ارائه، بچه ها در مورد معماری ها و مشکلات چپتر و نکات کاری صحبت می‌‌کنن و راه حل هارا با هم به اشتراک میذارن.۷. تمام ریموت بعلاوه مخلفات اضافیشرکت کاملا ریموت هست و فقط در صورت تمایل شخصی، کارمندان میتونن حضوری در شرکت کار کنند. البته گاهی تیم ها برای تیم سازی با هم در یک روز توافق می‌کنند که در شرکت با هم حضور پیدا کنند.ابزار های ارتباطی ریموت هم بنظرم کافی و کامل ست.برای چت از اسلک استفاده میشه. ( هیچ پیام رسان دیگری استفاده نمیشه)برای تماس تصویری و جلسات زیر ۵۰ نفر از اسکایپ. برای مدیریت تسک از ترلو. برای مدیریت درخواست ها از سامانه پیگیر.تجهیزات دور کاری هم توسط شرکت کامل تامین میشن و در صورت درخواست از طرف کارمند، حتی تا درب منزل ارسال میشه. تجهیزاتی شامل میز کامپیوتر، صندلی، مانیتور و ماوس و کیبرد و ... ( لپتاپ هم by default موقع ورود به شرکت تخصیص داده میشه)امیدوارم از این مطلب خوشتون اومده باشه و خوشحال میشم تجربه های خیلی خوبتون در شرکت هایی که هستین را زیر همین پست ببینم! مهدی نقوی مهدی نقوی Sat, 13 Feb 2021 12:51:47 +0330 https://virgool.io/@amirmehdinaghavi/%D9%81%D8%B1%D8%A7%DB%8C%D9%86%D8%AF-%D9%87%D8%A7%DB%8C%DB%8C-%DA%A9%D9%87-%D8%A8%D9%87-%DB%8C%DA%A9-%D8%AF%DB%8C%D9%BE%D9%84%D9%88%DB%8C-%D9%85%D9%88%D9%81%D9%82-%D9%85%D9%86%D8%AC%D8%B1-%D9%85%DB%8C%D8%B4%D9%88%D9%86%D8%AF-aqv09cnedcth در اردیبهشت ماه سال جاری بود که پس از یک دیپلوی اشتباه در سرویس ارتباطی با یک OMS، شرکت تحلیلگر امید خسارتی بالغ بر چند صد میلیون ریال متحمل شد. این خسارت به تنهایی می‌تواند یک شرکت را ورشکست کند اما در کنار خسارت مالی، بی اعتماد شدن مشتریان ضربه‌ی مهلک تری بود. پس از آن ما به بازنگری به فرایند های انتشار محصول پرداختیم و سعی کردیم نه‌تنها چابکی در اضافه کردن فیچر به محصول بیشتر شود، اطمینان از محصول نیز به صددرصد برسد.۱. بدهی فنی‌بزرگترین اشتباهی که یک تیم چابک می تواند گرفتار آن شود، بدهی فنی ست. برخلاف تفکر اشتباه بسیاری از اجایل کاران ایران که بدهی فنی را لازمه‌ی چابکی می‌دانند و آن را مترداف با کاهش کیفیت و کنارگذاشتن بعضی از فرایند ها می‌دانند، هیچ متدولوژی چابکی کاهش کیفیت را مجاز نمی‌داند. فقط در مواقع نادری که محصول باید سریعتر از موعد مشخص برسد و نیاز بازار به محصول بسیار زیاد است، خرد کردن و کوچک کردن فیچر، مجاز شمرده شده است.بدهی فنی مفهومی در توسعه نرم افزار است که منعکس کننده هزینه ضمنی کار اضافی ای ناشی از انتخاب یک راه حل آسان در زمان حال به جای استفاده از یک رویکرد بهتر که طولانی تر خواهد بود ‌می باشد. بعنوان مثال اگر فیچر در آینده‌ی ۳ ماهه به تحمل کردن بار ۱۰هزار کاربر نیاز دارد، می‌توان در ابتدا به گونه ای محصول را ارائه کرد که تحمل بار کمتری داشته و در اینده به افزایش scalability محصول فکرکرد، اما هرگز نباید کیفیت ارایه محصول و تست و رابط کاربری آسیب ببیند.‌ پس در گام اول سعی کنید فرهنگ غلط بدهی فنی را از تیم خود پاک سازی کنید. سپس در گام بعدی جدولی شامل ۳ ستون عنوان بدهی فنی، میزان نفر برساعت و الویت بسازید و تمامی بدهی های فنی سیستم خود را شناسایی کرده و در هر iteration برای رفع آنها برنامه ریزی کنید.۲. تست‌بزرگترین اشتباه یک برنامه نویس تست نکردن کد خود و دومین اشتباه بزرگش تحویل بدون تست کد به تستر هست( زیرا باعث افزایش رفت و برگشت بین برنامه نویس و تستر و کند شدن فرایند توسعه می شود! ) برنامه نویس باید تست را یکی از وظایف خود بداند و کد خود را بدون تست حتی به محیط تست نرم افزار (staging) منتقل نکند. تست نوشتن برای برنامه ای که تست های بسیار زیادی برای آن نوشته شده، ساده و آسان است اما احتمال اینکه پروژه ای که شما هم اکنون روی آن کار می کنید، تست نداشته باشد زیاد است. برنامه نویسان برای تست پروژه های بدون تست اشتباهات پرتکراری می کنند در حین اضافه کردن تست به کد های پیشین، هرگز فراموش نکنید که کد جدید بدون تست به پروژه اضافه نکنید. از بزرگترین مشکلات برنامه نویسان جوگیری ست:)) کسی که تا چندی قبل برای کد خود تست نمی‌نوشته، به TDDروی می آورد ! توسعه تست محور به دلایل بسیار زیادی از قبیل کند کردن مراحل توسعه نرم افزار و ضربه زدن به دید کلی و معماری سطح بالای نرم افزار، مدت زیادی است منسوخ شده است. البته استثنا نیز وجود دارد و این روش برای پیدا کردن باگی که از سمت کاربر گزارش شده بسیار مناسب است. یعنی شرایط رخ دادن باگ را ماک کرده و سعی کنید باگ را reproduce‌کنید. این گونه یک TDD موفق خواهید داشت. اگر تا بحال تست ننوشتید و در تیم شما فرهنگ نوشتن تست جا نیفتاده، هرگز به سراغ تکنیک BDD برای نوشتن تست نروید. نوشتن تست همانند نوشتن کد فرایندی ست که در آن داشتن تجربه امری پراهمیت ست و در صورتی که تجربه ای در آن نداشته باشید می تواند بسیار کند و فرسایشی باشد و حتی به شکست بینجامد. پس به نوشتن unit test با دیدگاه BDD یعنی ( given when then ) بپردازید و پس از گرفتن حداقل ۶۰ درصد code coverage در صورت نیاز (و تمایل زیرا به عقیده من bdd به نوشتن تست های بهتر نمی انجامد) به bdd بپردازید.شروع تست نوشتن برای یک پروژه بدون تست، سرگیجه آور است چون نمی دانیم از کجا شروع کنیم. برای این کار از use case diagram و user story های مهم استفاده کنید. به قانون ۸۰ ۲۰ (قانون پارِتو) ایمان بیاورید! با نوشتن تست برای تنها ۲۰ درصد از یوزر استوری ها میتوانید به محصولتان، ۸۰ درصد اطمینان کنید ! از integration test غافل نشویدتست های جامعی که تمامی اجزای کد و ارتباط کلاس ها و دیتابیس و دیگر اجزای سیستم را یکجا تست بگیرد، coverage زیادی برای شما به ارمغان می‌آورد و تست های کاملتری محسوب می‌شوند.ضبط کردن فرایند های پرتکرار به کمک ابزار های تست ui و اجرا کردن آنها بعد از تغییرات، بسیار فرایند تست ساده و سریعی ست که به اعتقاد من، حتی یک مدیر محصول که دانش برنامه نویسی هم ندارد می تواند انجام دهد! این گونه تست ها هم Integration test‌ حساب می‌شود و هم فرایند های سطحی و ساده ی سیستم را به خوبی تست می‌کند.۳. بازنگری به فرایند deployآیا فکر می‌کنید که با تست همه چیز خوب می شود. قطعا نه! باز هم احتمال وجود باگ در سیستم وجود دارد. با بازنگری به فرایند دیپلوی می توانید احتمال بروز باگ را کمتر از قبل کنید.حتما از ابزار های ci cd استفاده کنید. به عقیده من بهترین آن gitlab می باشد. به کمک آن اشتباهات ساده در فرایند ساخت و تست خودکار و همچنین دیپلوی را به صفر برسانید. در صورتی که node ها و سرور هایی که کاربران از آنها استفاده می‌کنند و نرم افزار باید در هر انتشار بر آنها deploy شود، حتما از ansible استفاده کنید که هم در وقتتان صرفه جویی شود و هم از اشتباهات پرتکرار و ساده ای چون فراموش کردن یک node یا یک دستور جلوگیری کنید. حتما AB test کنیدبهتر است محیطی فراهم کنید که نسخه ی جدید محصولتان ابتدا برای ده درصد از کاربرانتان فعال گردد و سپس پس از گرفتن بازخورد آنها، برای باقی کاربران فعال کنید. ما در تحلیلگر امید از مدل Facebook برای انتشار نسخه جدید محصول الهام گرفتیم. ابتدا نسخه جدید را برای همکاران خود در داخل شرکت فعال می‌کنیم. پس از خوب بودن بازخورد ها برای ده درصد مشتریان، سپس برای ۳۰ درصد مشتریان و در مرحله آخر برای تمامی مشتریان نسخه جدید را ارائه می‌کنیم.سیاست rollbackهمیشه بدترین حالت را در نظر داشته باشید. فرض کنید محصول را لانچ کردید و فهمیدید مشکلی دارد که می تواند میلیارد ها تومان ضرر به شما وارد کند. چه می‌کنید؟ سرور را خاموش می کنید !؟ دست به کد می شوید و در همان لحظه دیپلوی مجدد می‌کنید؟!( آنهم بدون تست !!!) خیر، راه درست، revert کردن سیستم به آخرین زمان stable ست! اگر از git و ci cd آن استفاده کنید، این کار با چند کلیک ساده انجام پذیر است. اما فرض کنید در ورژن جدید محصولتان تغییری در دیتابیس دادید یا کاری کردید که ورژن جدیدتان revertable نیست ! آنگاه چه می‌کنید!؟ + راه حل: در این شرایط هرگز دیپلوی نکنید! - پس چه کنیم؟ تا آخر عمر محصول فیچر نزنیم؟!+ خیر، سیاست rollback بنویسید تا در صورت مشکل خوردن دیپلوی بتوانید محصول خود را revert کنید. سپس دیپلوی کنید!شاید برایتان جالب باشد اما ما برای هر ورژن محصول یک نسخه برای rollback طراحی می کنیم و سپس نسخه جدید را منتشر می کنیم !اینها از جمله اقداماتی ست که تحلیلگر امید را به امن ترین سامانه معاملاتی کشور تبدیل کرده است !امیدوارم با این توصیه ها شما نیز در فضایی پر از آرامش کد بزنید و دیپلوی کنید. مهدی نقوی مهدی نقوی Sat, 18 Jan 2020 22:02:10 +0330 https://virgool.io/@amirmehdinaghavi/%D8%A8%D8%A7-%D8%B3%DB%8C%D9%84-%D8%B9%D8%B8%DB%8C%D9%85-%D9%88%D8%B1%D9%88%D8%AF-%D8%A8%D8%A7%DA%AF-%DA%86%D9%87-%DA%A9%D9%86%DB%8C%D9%85-%D9%BE%D9%86%D8%AC-%D8%B1%D8%A7%D9%87-%DA%A9%D9%87-%D8%A8%D9%87-%D9%BE%D8%A7%DB%8C%D8%AF%D8%A7%D8%B1-%DA%A9%D8%B1%D8%AF%D9%86-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%AA%D8%A7%D9%86-%DA%A9%D9%85%DA%A9-%D9%85%DB%8C%DA%A9%D9%86%D8%AF-p7wn5jyszqyw معمولا بعد از اولین انتشار عمومی یک محصول نرم افزاری، شاهد هجوم گزارش های باگ از سمت کاربران هستیم. هیچ محصولی مطلقا بدون باگ نخواهد بود اما این موضوع برای تیم های نرم افزاری، ممکن است استرس آور باشد و آنها را دستپاچه کند. در این مواقع از دست دادن ابتکار عمل و انجام کار های نسنجیده ممکن است مشکلات شما را بیش از پیش افزایش دهد. در این مقاله سعی دارم تجربه های خودم را در مواجهه با هجوم باگ ها در شرکت تحلیلگر امید برای شما بازگو کنم. ما در تحلیلگر امید الگوریتم های معاملاتی برای بازار سرمایه ایران تولید می‌کنیم. این الگوریتم ها به ساده سازی فرایند معامله گری افراد و شرکت های فعال در بازار سرمایه کمک می‌کند. ما پس از انتشار نسخه اول متوجه شدیم که سیستم به شدت باگ دارد، با اینکه تیم ساعت ها و با دقت روی توسعه محصول کار کرده بود. تجربه به صفر رساندن باگ ها در شرایط بحرانی آن زمان، مرا به این واداشت که مهم ترین اقدام هایی که باید برای به حداقل رساندن باگ ها و بهبود فرایند توسعه محصول تان انجام دهید را در این مقاله با شما به اشتراک بگذارم.گزارش دقیقی از تعداد و انواع باگ ها در بیاوریدهرگز بدون داشتن نگاه جامع و سطح بالا از مشکلات سیستم، دست به رفع اشکال آن نزنید. ابتدا گزارش کاملی از باگ های سیستم بنویسید. ممکن است واسط خوبی برای گرفتن تجربه کاربرهایتان و باگ هایی که در هنگام استفاده از سیستم، به آنها بر می خورند نداشته باشید. می‌توانید صفحه ای بعنوان گزارش باگ در محصول خود طراحی کنید یا از ابزار هایی مانند Hotjar یا jira script استفاده کنید.تعداد و انواع باگ ها، اینکه شما چقدر در بحران هستید را بهتر گزارش می‌کنند. سپس باگ ها را root cause کرده و بر اساس ریشه ی وقوع شان دسته بندی کنید. ما برای اینکار از سایت coggle استفاده کردیم و به این نمودار رسیدیم.آنالیز بخشی از باگ های سیستم معمولا مشاهده خواهید کرد که ۸۰ درصد باگ ها برای بیست درصد سیستم است! که به آن قانون پارتو میگوییم! به کمک این روش، با دیدی دقیقتر و بهتر میتوانید برای کاهش باگ ها برنامه ریزی کنید.‌‌خارج از برنامه حرکت نکنیدبعد از برنامه ریزی برای ریفکتور و حل مشکلات سیستم، برای تیم خود یک گارد درست کنید. معمولا اگر استفاده کنندگان سیستم به نیرو های فنی توسعه دهنده سیستم دسترسی داشته باشند، به آنها مدام مراجعه می‌کنند و خواستار رفع باگ می شوند و تمرکز را از تیم فنی می گیرند. باید اینگونه دسترسی هارا قطع کرده و سعی کنید فضای با آرامشی برای تیم فنی درست کنید تا با تمرکز،‌ و به دور از task switching های پرتکرار، به رفع مشکلات سیستم بپردازند.‌لاگ را جدی بگیریدبهتر است در بخش هایی که باگ دارند، از تمامی تحرکات سیستم در پایین ترین سطح کد یعنی هر فانکشن لاگ بگیرید. برای این کار حتما از Aspect oriented programming استفاده کنید. در این دیدگاه از برنامه نویسی، بعنوان مثال می توانید بگویید تمامی function ها با سطح دسترسی public که در پکیج x وجود دارد لاگ شوند. بهتر است فرمت لاگ، فرمتی خوانا باشد تا خواندن و سرچ زدن آن راحت باشد. می توانید از فرمت json استفاده کنید و در هر لاگ، اسم فانکشن، ورودی ها و خروجی، مدت زمان اجرا شدن و زمان صدا خوردن را لاگ کنید. برای مدیریت و جستجو در لاگ ها از elasticsearch و پنل کیبانا استفاده کردیم که در پیدا کردن باگ ها بسیار به ما کمک کرد.پنل کیبانا تست، مهمترین عامل پایداریحتی اگر توانستید باگ های سیستم را به صفر برسانید، تا زمانی که تست اتوماتیک نداشته باشید، تضمینی برای برگشت ناپذیری به حالت ناپایداری و buggy بودن سیستم وجود ندارد. Automated test به شما کمک می کنند که در هربار build و deploy نرم افزارتان در سرور، از صحت عملکرد نرم افزارتان اطمینان حاصل کنید. برای من بسیار اتفاق افتاده که با تغییر در کد بخشی از محصول، تست های بخش دیگری از محصول fail شده اند. این اتفاق طبیعی است و اهمیت تست اتوماتیک را نشان می‌دهد. اگر تیم شما تابحال برای نرم افزار خود تست ننوشته است، آنها را ملزم به یادگیری unit test و integration test بکنید.مهمتر از تست نوشتن و تست کردن، پیاده سازی فرهنگ تست نوشتن در تیم فنی ست. همه برنامه نویسان تیم باید توانایی نوشتن تست برای کدی که خود می‌نویسند را داشته باشند و هیچ کدی بدون تست، نباید به دست کاربر برسد. برای پیاده سازی این فرهنگ این مراحل بسیار راه گشاست: حتما پس از تعریف هر تسک، سناریو تست های آن مشخص باشد و برنامه نویس موظف به نوشتن unit test برای آن باشد.به code coverage اهمیت بدهید. درست است که تضمین کننده ی تست خوب نیست و یک تست ساده برای یک سناریو موفق می تواند coverage زیادی برای شما به ارمغان بیاورد، اما به شما در به صفر رساندن باگ های ساده کمک می کند. بهتر است بصورت دوره ای برای محصولتان integration test بنویسید و تمام اجزای سیستم را بصورت جامع تست بگیرید. integration test بسیار در تولید کد های بدون باگ کمک می‌کند.حتما در فرایند دیپلوی محصولتان، تمام تست ها اجرا شوند و در صورت خطا خوردن، محصولتان دیپلوی نشود.‌اگر به جنگل رفتید، نه تنها آشغال نریزید، بلکه دور و بر خودتون رو هم تمیز کنید!علاوه بر محصولی که تولید می‌کند، کدِ شما نیز یکی از محصولات تیم است. پس به کیفیت کد نیز حتما نگاه ویژه ای داشته باشید. سعی داشته باشید از این به بعد که باگی تولید نمی‌کنید و برای کدهایتان تست می‌نویسید، به کیفیت کد های نوشته شده نیز توجه کنید و کد های قبلی را نیز refactor کنید. در این مرحله به چند مورد ساده حتما توجه کنیدقواعد ساده ی refactor کردن مانند نامگذاری درست، فانکشن های کوتاه، کلاس های خرد شده را در تیم خود جا بیندازید. برای یادگیری این قواعد از سایت refactoring می‌توانید استفاده کنید.از sonarlint برای سنجش کیفیت کدتان استفاده کنید. می توانید آن را بعنوان پلاگین در IDE خود نصب کنید و همچنین در فرایند CI/CD تان از آن استفاده کنید به گونه ای که اگر تعداد issue های کد، از حدی بالاتر رفت، برنامه build و deploy نشود.برای merge کردن کدهایتان، از سیستم approval استفاده کنید. قواعد را به گونه ای بنویسید که حداقل دو نفر برای مرج کردن یک کد باید تایید بدهند.و حرف آخر: زمانی که علایم بیماری از بین رفت، مصرف دارو هارا قطع نکنیدیک سیستم نرم افزاری به سادگی می‎تواند سرما بخورد! و باگ خیز شود. برای اینکه همیشه stable باشید، نباید توصیه های بالا را متوقف کنید یا در انجام آن کاهلی کنید. بصورت دوره ای (حتی اگر از متدولوژی های agile استفاده نمی‌‌کنید) بررسی کنید که ۵ مورد بالا حتما در تیم های فنی تان انجام می شوند.در نهایت لازم می‌دانم از دوست و معلم خودم، اسد صفری تشکر کنم که در ۴ ماه گذشته، به من و تمامی تیم تحلیلگر امید، کمک کرد تا این تجربه ارزشمند بدست‌آید.اگر شما هم تجربه ای در این زمینه دارید، دوست دارم درباره ش بشنوم و باهم بحث و گفتگو کنیم. مهدی نقوی مهدی نقوی Wed, 04 Dec 2019 12:16:05 +0330