توسعه دادن را به حال خودش رها نکن!

پزشکان معتقدند بر اساس کتاب مقدس، خدا حوا را از بطن آدم ساخته پس جراحی قدیمی ترین حرفه است در حالیکه مهندسان مدعی اند قبل از آدم و حوا، خداوند دنیا و بهشت را از نظم دادن به یک حرج و مرج مطلق بوجود آورده، پس ساخت و ساز اولین حرفه شناخته شده در هستی است. در این بین برنامه نویس ها به صندلی خودشون با اعتماد به نفس تکیه میزنند و با تمسخر به هر دوی اونها میگویند: هیچ با خودتون فکر کردید که اون هرج و مرج رو چه کسی بوجود آورده؟؟

بله خنده دار بود اما حتما پیش اومده که بخواهید کد شخص دیگری رو ادامه بدهید اما بدلیل سردرگمی موفق نشده باشید و یا حتی ادامه پروژه ای که خودتون توسعه اش دادید غیر ممکن شده باشه. در واقع انتظار میره پروژه طوری توسعه شده باشه که اضافه کردن ویژگی جدید به اون و یا رفع باگ به راحتی قابل انجام باشه اما این اتفاق جز با ساختار دادن به روندهای انجام پروژه قابل کنترل نیست.

ساختار :‌ 1 - چگونگی ساختمان چیزی. 2 - ترتیب اجزا و بخش های یک جسم.

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

اول خوب فکر کنید

Weeks of coding can save you hours of planning.

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

“As a <role or persona>, I can <goal/need> so that <why>”

این دوره میتونه برای پیدا کردن نیاز واقعی مشتری میتونه بهتون ایده بده و برای خودتون و مشتری بهتره که ویژگی های توافق شده رو به طور مصور هم داشته باشید.

قرارداد کنید

من برای پیاده سازی روی وب، اغلب از API و استاندارد REST استفاده میکنم و برای اینکه فرمت استانداری برای فرستادن ورودی و گرفتن خروجی در این روش داشته باشم از JsonApi تبعیت میکنم و بر همین اساس مشخصه های API رو قرارداد میکنم:

حالا برای ثبت این قرارداد باید اون رو داکیومنت کرد ولی همیشه نوشتن داکیومنت (هم برای نویسنده و هم خواننده) کار سختیه. البته به کمک swagger ، نوشتن داکیومنت نه تنها سریع بلکه قابل خوندن هم میشه. به این شکل که فایلی با پسوند .yaml رو با رعایت استاندارد OpenApi Specification به شکل زیر مینویسیم:

openapi: 3.0.1
info:
  title: ProductAPI
  version: 1.0.0
  servers:
      - url: https://localhost.com/v
paths:
  /products:
    post:
     requestBody:
     content:
     application/json:
       schema:
           required:
               - meta
               type: object
               properties:
                meta:
                type: object
                properties:
                title:
                type: string
                price : integer 
                required: false
        responses:
        200:
        description: invitation issued successfully
        content:
        application/json:
        schema:
        required:
          - meta
                  type: object
                  properties:
                      meta:
                        type: object
                          properties:
                            message:
                            type: string
        400:
        description: invitation failed
        content:
        application/json:
        schema:
        required:
        - errors
            type: object
             properties:
             errors:
             type: array
                 items:
                 type: object
                  properties:
                      title:
                         type: string

و به جای متن های طولانی، یک نمونه قابل اجرا از داکیومنت خواهدید داشت که میتونید نمونه در اینجا امتحان کنید.

به قرارداد پایبند شوید

هر توسعه دهنده نرم افزار باید ساختار و رفتار سیستم را در توسعه در نظر داشته باشد. در واقع قراردادی موفق خواهد بود که ابزاری برای متعهد بودن به انجامش هم پیدا کنید. با استفاده از تست های رفتاری BDD ، میتوان رفتار سیستم را بر مبنای انتظار مشتری مورد تست قرار داد این تست ها که با زبان gherkin قابل پیاده سازی است تضمین میکند که بعد از پیاده سازی سیستم [به هر نحوی] رفتار آن همانی خواهد بود که از ابتدا برای آن قرارداد کرده بودیم.

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

نمونه اولیه بسازید

همیشه مشتری ها برای دریافت محصول عجله دارند پس با ساختن یک نمونه از API، به تیم frontend اجازه دهید پیش از تمام شدن کار توسعه backend، کار خود را پیش ببرند و محصول نهایی را آماده ارائه کنند.

ابزارهای مثل https://app.mocklab.io این امکان رو میدهند تا روی سرور اونها مشخصه های api رو داکیومنت کنید و هر بار که بر اساس اون مشخصه درخواست بدهید به شما پاسخی مطابق با داکیومنت بدهند.

دست نگه دارید

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

بنظرم داشتن ایده ای در معماری سیستم که حتی خیلی هم دقیق نباشه بهتر از نداشتن اونه.

قطعه های لگو را به هم وصل کنید

حالا نوبت به انجام قسمت های درونی است. قطعا کنترل بخش های کوچک، کار ساده تری است پس روش تقسیم و غلبه رو تا جای ممکن پیاده سازی کنید و یونیت تست بنویسید و در نهایت هم اینتگریشن تست. اما خود تست ها هم نیاز به کنترل و ساختاردهی دارند. sandi mentz روشی رو ارائه پیشنهاد میده که سیستم با تبادل پیام بین متدها کار میکند(خروجی یک متد، ورودی متد دیگری است) و عملکرد متدها به دو نوع دسته بندی میشه:

کوئری Query : مقداری را برمیگردانند اما چیزی را نباید تغییر دهند.

دستوری Command : مقداری را تغییر میدهند اما نباید چیزی را تغییر دهند.

البته بعضی اوقات رعایت این تقسیم بندی هم ممکن نیست. جدول زیر نشان میدهد که لازم نیست همه چیز را تست کنیم:

کنترل کنید

به پروژه، سیستم کنترل ورژن مثل گیتهاب رو اضافه کنید و هر issue یا مسئله ای رو روی یک branch جداگانه ببرید و هر نسخه stable (وقتی مطمئن هستید سیستم دقیق و مطابق قرارداد کار میکنه) از master رو تگ بزنید تا بتونید بر روی چیزی که توسعه میدهید کنترل داشته باشید.

دستها را بالا بگیرد

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

حالا میتونید نسخه تگ خورده از گیت (یا هر کنترل ورژن دیگه ای) رو روی سروس pull کنید. اما صبر کنید!! قبل از اون باید همه تست ها پاس بشن.

ابزارهای CI/CD به شما این امکان رو میدهند تا از شر کار تکراری تست کردن قبل از هر pull ریکوئست هم خودتون رو خلاص کنید. من از drone استفاده میکنم و احتمال خطای انسانی موقع deploy رو کم میکنم. اینطوری که هر وقت من تگی به گیت میزنم و push میکنم drone به گوش نشسته و وقتی متوجه تغییرات شد، بصورت اتوماتیک تستها رو اجرا میکنه و در صورت پاس شدن، اخرین تگ رو رو سرور pull میکنه.

از وقتی که برای خوندن این مطلب گذاشتید سپاسگزارم. این روش من بود و فکر میکنم مثل هر شغل دیگه ای کار برنامه نویسی هم نیاز به مدون شدن داره تا بشه اون رو کنترل کرد ولی این روش ها میتونه متفاوت باشه و هدف پیدا کردن این روش ها بر اساس نیاز و توانایی همگام شدن با اون هاست. پس شما هم روش های خودتون رو کامنت بذارید یا به توییتر من پیام بدید.