https://virgool.io/feed/@mohammada_315 fa 2026-06-07 08:34:40 https://files.virgool.io/upload/users/62947/avatar/FMqCTR.png?height=120&width=120 https://virgool.io/@mohammada_315 https://virgool.io/fboard/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3-%D8%AE%D9%88%D8%B4%D8%AD%D8%A7%D9%84-acfc4gyqyn4s این نوشته میتوانست عنوانی مثل «چرا برنامه نویس باید کد خود را تست کند؟» داشته باشد.  به این خاطر که به شیوه با بهتر بگویم آسیبی در برنامه نویسی اشاره میکند که شاید در بسیاری از شرکتهای نرم افزاری پیشرفته سالهاست که دیگر دیده نمیشود. Happy path در واقع روشی ابتدایی در برنامه نویسی است که در آن برنامه نویس ابتدا خواسته های که یک feature مانند صفحه احزار هویت یک وب سایت، باید تامین کند را بررسی میکند و سپس کد آن را طوری مینوسید که خواسته های عملکردی (functional) برآورده شود. یعنی به نام کاربری و رمزعبور صحیح اجازه دسترسی میدهد. در واقع تمرکز برنامه نویس برروی برآورده کرده عمکلرد منطقی است. Happy path نیز همین انجام use case اولیه است. برنامه نویس حتی میتواند برای کدی خود unit test نیز به صورت happy هم بنویسد. مثلاً User:aa Password:Complic@ted را قبول و چیزی غیر از آن را رد کند. ولی خب، مگر این به تنهایی تست کاملی است؟ این کد بر روی سخت افزار و تنظیمات مشخص وب سرور قرار است به چه میزان درخواست همزمان پاسخ دهد؟ در صورتی که یک Fuzzer شروع به بمباران آن با attack vector های مختلف کرد، عکس العمل آن چیست؟ آیا تلاشهای موفق و ناموفق را برای بررسی های آینده log میکند؟این موضوع که شاید برای عده ای بسیار ابتدایی بنظر برسد درواقع exception ها، condition error ها و نیازهای غیرعملکردی مانند امنیت، سادگی استفاده یا کارایی را در نظر نمیگیرد. اما با این وجود happy path حتی در میان برنامه نویسان و تست نویسان با تجربه هم دیده میشود. برای خود من بارها پیش آمده که قسمتی از نرم افزار با وجود داشتن تست های اتوماتیک در سطوح مختلف باز هم به خاطر موارد پیش پا افتاده در محیط مشتری دچار مشکل شده است. ولی بررسی های بعدی نشان میدهد که این تست ها happy path بوده و روشهای مختلفی که ممکن است کاربر در تجربه روزانه یا به اشتباه از آن استفاده کند را پوشش نداده است. Crash ها نرم افزاری حاصل همین شیوه غلط است. اما آیا happy path تا اندازه ای ذاتی و برخواسته از شیوه تفکر یک برنامه نویس نیست؟ یک برنامه نویس میخواهد کدی را بنویسد که فقط نیاز عملکردی یا functional درخواست کننده را برآورده کند. در نظر او کاربر تنها قرار است از نرم افزار به شیوه ای که او در ذهن دارد استفاده کند. قرار نیست کسی نرم افزار را هک کند. قرار نیست افراد زیادی در آن واحد از آن استفاده کنند. قرار نیست RAM ها پرشوند، سرعت شبکه پایین بیاید.قرار نیست شرکت بخاطر bug های نرم افزار مشتری را از دست بدهد. در واقع برنامه نویس قصه ما یک انسان خوشحال است ?هرچند با پیشرفت برنامه نویسی و رقابتی شدن هرچه بیشتر بازار، برنامه نویسان هم امروزه بیشتر به فکر بالا بردن کیفیت کدهای خود هستند ولی در هر صورت شیوه تفکر happy path در برنامه نویسی به ذات وجود دارد. در کتاب مرجع ISTQB چهار سطح  از لحاظ جدایی برنامه نویس و تست کننده از یکدیگر در مواجهه با happy path در نظر گرفته شده است:برنامه نویس کد خود را تست کند.برنامه نویسی در همان تیم کد را تست کند.برنامه توسط تیم تست شرکت بررسی شود.برنامه برای تست به جایی غیر از شرکت فرستاده شود.این چهار درجه از جدایی برنامه نویسی و تست که انجام آن از بالا به پایین پرهزینه تر میشود بر این اصل بنا شده است که تست کننده هر چه بیشتر از برنامه نویس فاصله داشته باشد، برنامه را با ذهنی مستقل تر و نقادانه تر تست میکند. در اینجا باز هم مدیران نرم افزار هستند که باید با توجه به بودجه، تواناییهای داخلی، حساسیت نرم افزار و بازار مصرف برای استفاده از ترکیبی از موارد بالا تصمیم گیری کنند محمدامین خزاعی محمدامین خزاعی Sun, 01 Dec 2019 05:35:03 +0330 https://virgool.io/@mohammada_315/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D8%A7%D9%88%D9%84%DB%8C%D9%86-%D8%B1%D9%88%D8%B2-%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%DB%8C-%D8%AF%D8%B1-%D9%81%D9%84%D8%A7%D8%AA%D8%B1-atcwhbbt6ljr سلام دوستان ، وقتتون بخیر (قسمت اول )خب قبل از اینکه تجربه خودمو از زبان فلاتر بنویسم قبلش میخوام راجب خودم بگممن خیلی به برنامه نویسی اندروید علاقه دارم و تقریبا همجا سرک کشیدم :( اندروید استدیو ، بیسیک فور اندروید و ... ولی هیچکدوم به اندازه فلاتر برای من جالب نبوده .طبق عادت چند وقت پیش داشتم توی سایت راکت وبگردی میکردم که با یک دوره آموزشی با عنوان فلاتر آشنا شدم تا قبل این چیزی راجبش نشنیده بودم .و بنظرم خیلی جالب اومد چونکه همزمان میشد خروجی اندروید و ای او اس گرفت ( البته اینو قبلا راجب ریکت نتیو شنیده بودم و خیلی دوست داشتم اون رو یاد بگیرم ولی ی مشکلی بود اونم این که روند رسیدن به دانش ریکت نیتیو یکم برای من سخت بود چون زیاد از مباحث JS سر در نمیاوردم و نیاز بود ی زبان برنامه نویسی جدید و کار کردن با چندتا فریم ورک و کتابخانه رو یادبگیرم البته جدا از CSS و اینا برای همین دنبال ی جایگزین بودم که به زبان های سطح بالا مثل C شباهت داشته باشه . ی موضوع دیگه که خیلی برام مهم بود زیبایی توی UI بود که با تجربه قبلیم توی B4A که اصلا ازش توی این حوزه راضی نبودم خیلی حالم گرفته شده بود . ولی فلاتر توی این حوزه خیلی خوب عمل کرده و توی سایتش هم ی شعار دیدم که نوشته بود با ما اپ های زیبا بسازید .اینجا بود که دیدم فلاتر از زبان برنامه نویسی دارت استفاده میکنه و این زبان خیلی شبیه به ++C واسه همین انتخاب خودمو کردم .رفتم توی سایت فلاتر و ی چند دقیقه ای داکتشو خوندم و راجب مراحل نصبش یکم اطلاعات کسب کردم . خب رسیدم به چالش ها :)اولین چالش من انتخاب ی ادیتور مناسب بود میخواستم هم سریع باشه هم راحت و انتخاب های زیادی داشتم اولینش اندروید استدیو بود که خود فلاتر و چندتا از دوستان برنامه نویس اونو پیشنهاد دادن ولی چون یکم سنگینه و کد زدن توی اون شرایط بیشتر اعصاب آدمو خورد میکنه بیخیالش شدم . و رفتم سراغ انتخاب بعدی یعنی intellij که ی ادیتور راحت و قشنگه ولی بعد از نصب دیدم اینم از اندروید استدیو تو مصرف منابع کم نمیاره . واسه همین vscode رو انتخاب کردم چون هم سبک بود و اینکه راحت با فلاتر ست میشد .سرتون رو درد نیارم ادامش باشه واسه قسمت بعدی ... :) محمدامین خزاعی محمدامین خزاعی Wed, 06 Nov 2019 14:32:08 +0330