https://virgool.ir/feed/@m.azad65I am a Software Developer ...fa2026-11-11 03:02:50https://files.virgool.ir/upload/users/4721/avatar/FaXbAW.jpghttps://virgool.ir/@m.azad65https://virgool.ir/@m.azad65/داستان-واقعی-یک-پروژه-تشکیل-تیم-nvlozv3t3cqxحدود سه سالی هست که درگیر توسعه یک سیستم بانکی بودیم و به تازگی این سیستم عملیاتی شد. درنظر دارم بتونم تجربیات و نکات مهمی که به عنوان مسئول فنی تو سه سال بدست آوردم رو به اشتراک بذارمیکی از مهمترین قدم های شروع پروژه تشکیل یک تیم یکدست و دارای فرهنگ مشابه در کار تیمی هست به جرات میتونم بگم با کوتاهی تو این مورد شانس موفقیت پروژه رو تا حد زیادی کاهش دادید. اما برای تشکیل تیم چه نکاتی مهمی رو باید در نظر بگیریم؟در صورت امکان از نفراتی استفاده کنید که از قبل باهاشون کار کردید و کاملا می شناسیدشون این افراد اصولا بهترین انتخاب هستندحتما دنبال افرادی باشید که به فرهنگ تیمی شما نزدیک باشند مثلا اگر قراره پروژه بصورت اسکرام مدیریت بشه کسایی رو تو که قبلا تو یک تیم اسکرام بودن گزینه مناسبی هستند ، البته بد نیست ببینید که روش پیاده سازیشون چقدر به روش شما نزدیک هست.برای نمونه در تیم ما جلسات اسکرام روزانه و بازبینی اسپرینت خیلی مهم بود ولی بعضی از بچه ها رو باید بزور تو جلسات نگهشون میداشتی و مشارکت ضعیفی داشتن و هر ازگاهی با نق زدن تمرکز تیم رو بهم می زدند.بهترین راه برای یکدست کردن تیم از لحاظ فنی برگزاری دوره آموزشی برای افراد تیم هست مواردی مانندی ویژگی معماری استفاده شده و تعاریف موجود در اون، نحوه و قوانین کد نویسی در معماری پروژه ، نحوه نوشتن تست و .. باید در این آموزش لحاظ بشه .برگزاری این دوره تا حد زیادی از بوجود اومدن بحث های بی مورد فنی جلوگیری میکنهحتما در مورد قوانین تیمی مانند نحوه برگزاری جلسات، نحوه رفت و آمد ،تعریف تیم از اتمام تسک و ... برای افراد جلسه توجیهی برگزار کنیدحتما برای هر پوزیشن اصلی یک شخص مشخص بشه ،مثلا مسئولیت مدیر فنی و اسکرام مستر یا مالک محصول و اسکرام مستر به عهده یک نفر نباشهپ ن: موارد مثل سن افراد تیم هم تا حدی مهمه که باید در صورت وجود اختلاف زیاد نسبت به جذب فرد تو تیم وسواس بیشتری داشت البته این امر در صورت وجود فرهنگ کاری مشابه میتونه خیلی به چشم نیادmohammad azadmohammad azadFri, 15 Mar 2019 14:28:24 +0330https://virgool.ir/@m.azad65/تا-توانی-تست-بنویس-کد-نوشتن-هنر-نیست-۳-kpb9qtnzyuz0در دو نوشته قبلی در باره اهمیت و انواع تست صحبت شد. از این به بعد می خوام تمام موارد گفته شده رو بصورت عملی بررسی کنم.سعی می کنم کد هر جلسه رو توی گیت هاب قرار بدنم تا دوستان بتونن ازش استفاده کنند.معمولا اولین مثالی که برای آموزش تست میزنند مثال ماشین حساب هستش که بنظر من مثال خوبی نیست و مثال باید بیشتر به دنیای واقعی نزدیک باشه برای همین با توجه به اینکه چند سالی هست درگیر توسعه سیستم بانکی هستم مثالم رو از بیزنس های بانکی میارم که واقعی تر و ملموس تر باشه.شما یک موسسه مالی اعتباری رو در نظر بگیرید که افراد(مشتری) اونجا حساب بازمی کنند و بر اساس میانگین امتیاز موجودیشون تو مدت مشخص میتونن تسهیلات دریافت کنند.خب الان می خوایم برای دریافت وام تست بنویسیم . برای ثبت یک درخواست وام موارد زیر باید بررسی بشهمیانگین امتیاز موجودی مشتری باید برای دریافت وام به حد کافی رسیده باشه وام گیرنده نباید خودش وامی داشته باشه که اقساطش پرداخت نشدهکد مربوطه بصورت زیر میشه https://gist.github.com/mtaboy/0ab6b6e5c5f9fa0be58271a53a839b34 همانطور که در بالا می بینید متد ایجاد درخواست وام برای انجام کار خود به دو متد دیگر وابسته میباشدmohammad azadmohammad azadFri, 04 Jan 2019 16:01:32 +0330https://virgool.ir/@m.azad65/تا-توانی-تست-بنویس-کد-نوشتن-هنر-نیست-2-gohdxvqyqxjrدر پست قبلی در مورد اهمیت و ارزش تست در توسعه نرم افزار صحبت کردیم حالا می خواهیم انواع تست رو بر اساس هرم تست معرفی کنیم.هرم تست نرم افزارهرم بالا انواع سطوح تست و اهمیت و هزینه و سرعت هر سطح را بیان میکندتست واحد (unit test) : تست یک بخش کوچک از کد (تابع)بدون در نظر گرفتن وابستگی (فراخوانی دیتابیس ،فراخوانی وب سرویس و...) های اون قطعه کد ،یعنی اگر وابستگی در تکه کد ما وجود داره تست ما شامل اون وابستگی نمیشه و ما اون رو درنتیجه تست حساب نمی کنیم و رفتارشون رو در تست تقلید میکنیم (نشان دهنده ایزوله بودن تست واحد). همانطور که در هرم تست مشاهده می کنید تست واحد در انتهای هرم قرار دارد که نشان دهنده بالا بودن تعداد آنها در یک نرم افزار می باشد.این تست ها توسط توسعه دهنده سیستم ایجاد شده و سرعت انجام تست بالا می باشد و در صورت شکست نقطه وقوع شکست تست براحتی قابل مشاهده هست.تست پذیر بودن یک معماری در نوشتن تست های واحد بیشتر به چشم می آید و کمک زیادی به عملیات mocking میکندتست یکپارچگی (Integration Test یا Api Test): در این نوع تست اون بخش از کد رو که بصورت ایزوله تست کردیم و وابستگی های اون رو mock کردیم اینبار باید بصورت واقعی و بدون mock کردن تست کنیم . این تست نسبت به تست واحد کندتر هستش و یک یا چند تست واحد رو شامل میشه.این تست در درجه دوم اهمیت از نظر هرم تست می باشد و همانند تست واحد توسط توسعه دهنده سیستم نوشته می شود.تست مورد کاربری (GUI Test یا End To End Test): در این نوع تست یک UseCase را از ابتدا تا انتها تست میکنیم. این تست ها نسبت به موارد بالا کند تر و همچنین هزینه نگهداری آنها بسیار بالا تر می باشد.در این تست با ابزارهای مخصوص تمام اکشن های کاربر برای انجام یک سناریو توسط نرم افزار ضبط می شود و بعد نرم افزار بصورت خودکار این مراحل را اجرا می کند نرم افزار هایی که در تین زمینه معروف هستند عبارتند از selenium, Coded UI , Ranorex در ادامه بصورت عملی این موارد رو بررسی می کنیمmohammad azadmohammad azadFri, 07 Dec 2018 18:20:22 +0330https://virgool.ir/@m.azad65/تا-توانی-تست-بنویس-کد-نوشتن-هنر-نیست-bdlqyzqk9ztj همیشه وقتی تو یک بحث فنی اگر کسی به یک طراحی ایراد میگیرفت و میگفت قابلیت تست پذیری این کد پایینه تو دلم میگفتم: خب باشه آخه کی حوصله تست نوشتن داره که داری گیر میدی!!!شاید اگر کسی تو یک پروژه بزرگ با بیزینس پیچیده درگیر نبوده باشه هیچوقت مقوله تست براش اهمیت پیدا نمیکنه .تو این جور پروژه ها با یک تغییر تو یک مولفه از سیستم یه مولفه دیگه دچار خطا میشه ، و اگر توقع داشته باشیم تستر بتونه باگ رو پیدا کنه باید وقت کافی بعد از تغییر جدید داشته باشیم تا سیستم بخوبی تست بشه تازه بشرطی که تست کیس هامون از قبل آماده باشه و تستر حوصله کنه همشون رو صفر تا صد بره جلو و خطای انسانی هم در کار نباشه میتونیم با خیال راحت نسخه جدید رو منتشر کنیم!!!حالا چطور میشه این فرآیند طولانی و خسته کننده رو با ضریب خطای خیلی کمتر و سرعت بیشتری انجام داد؟تست اتوماتیک تنها راه حل برای این مسله هست. هزینه تست اتوماتیک در زمان توسعه سیستم داده میشه اما نتیجه اصلی در فاز نگهداری سیستم خیلی به چشم میاد مخصوصا زمانی که سیستم داره توسط مشتری استفاده میشه و ما یک تغییر جدید رو آماده کردیم تا با ورژن جدید به مشتری بدیم و با این تغییر جدید قابلیت های قبلی سیستم دچار خطا بشه!!!! اعتبار شرکت براحتی زیر سوال میره.اگر تست همراه با روند توسعه نوشته بشه که بسیار عالیه اما اگر یک سیستم قدیمی در اختیارمون باشه و تستی در کار نباشه باید دعا کنیم معماری سیستم جوری باشه که قابلیت تست نوشتن برای این سیستم وجود داشته باشه اونوقت بازم میشه بعد از یه مدت تست های خوبی داشت که ضریب اطمینان مارا برای نسخه دادن بالا ببره.چندین جا که به عنوان مشاور فعالیت داشتم مخصوصا اونهایی که سیستمشون دست مشتری بود بزرگترین دغدغشون در بخش پشتیبانی بود و میگفتن تیم توسعه وقتی یک قابلیت جدید می نویسه نصف تماسهایی که گرفته میشه بخاطر کار نکرن بخشی از سیستم هست که قبلا کار میکرد و کلا قابلیت جدید تن و بدن کل شرکت رو می لرزوند . بعضی از این دوستان سیستمشون قابلیت تست نوشتن براش وجود داشت و شروع به نوشتن تست کردن ، چابکی و سرعت انجام تغییراتشون تا حد قابل ملاحظه ای بالا رفته بود و کلی از مشکلاتی که بعداز انتشار نسخه جدید شرکت باهاش درگیر بود کم شد.در ادامه درباره انواع تست و اینکه چطور برای یک سیستمی که تست نداره تست خوب بنویسیم صحبت میکنیmohammad azadmohammad azadThu, 29 Nov 2018 10:27:27 +0330