# برنامه نویسی عملی: چگونه می توان مدل های ذهنی و شیوه های خوب را توسعه داد تا یک توسعه دهنده نرم افزار موفق باشد؟

مقدمه

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

فهرست مطالب

یادگیری و رشد

یادگیری مداوم

“هرچه نرم افزار ، فناوری ها ، زبانهایی که می دانید متفاوت تر باشید ، با ارزش تر خواهید بود.”

در صنعت ما ، آنچه امروز داغ است ممکن است فردا منسوخ شود. برای ماندن و ارزشمند ماندن:

• حداقل هر سال حداقل یک زبان جدید بیاموزید – زبان های مختلف مشکلات را به روش های مختلف حل می کنند و تفکر شما را گسترش می دهند
• با افراد خارج از دایره فوری خود با افراد صحبت کنید – شبکه در شرکت خود یا در جلسات محلی ؛ برای افزایش دید و حضور با جامعه فنی ، به ویژه اگر کمتر نماینده باشید ، درگیر شوید
• مهارت های خود را به طور مرتب مرور و تعادل دهید – ارزیابی کنید که کدام فناوری ها را برای مسواک زدن نیاز دارید و ممکن است زمان آن باشد

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

سازمان و طراحی کد

ارتوگونی بودن را در آغوش بگیرید

اگر تغییر در یک نفر بر هیچ یک از دیگران تأثیر نگذارد ، دو یا چند چیز متعامد است. در یک سیستم خوب طراحی شده ، مؤلفه ها مستقل و جدا شده هستند.

“در یک سیستم خوب طراحی شده ، کد پایگاه داده برای رابط کاربری متعامد خواهد بود: شما می توانید رابط کاربری را بدون تأثیرگذاری در پایگاه داده تغییر دهید و بدون تغییر رابط ، پایگاه داده ها را عوض کنید.”

وقتی سیستم ها متعامد هستند:

• تغییرات بومی سازی می شوند
• زمان توسعه و آزمایش کاهش می یابد
• استفاده مجدد از کد تبلیغ می شود
• دوباره پیکربندی سیستم ها آسانتر است

یک رویکرد معماری لایه ای را در نظر بگیرید:

┌─────────────────────┐
│   User Interface    │
├─────────────────────┤
│   Business Logic    │
├─────────────────────┤
│   Data Access       │
├─────────────────────┤
│   Database          │
└─────────────────────┘

نوشتن مؤلفه های نسبتاً کوچک و دارای خود ساده تر از یک بلوک بزرگ از کد ساده تر است. اجزای ساده می توانند طراحی ، کدگذاری ، آزمایش شده و سپس فراموش شوند – نیازی به تغییر کد موجود نیست که کد جدید را اضافه می کنید.

دستورالعمل های سازمان بهتر کد

1. از داده های جهانی خودداری کنید – هر بار که کد شما به داده های جهانی مراجعه می کند ، خود را به سایر مؤلفه هایی که این داده ها را به اشتراک می گذارند ، پیوند می زند
2. از عملکردهای مشابه خودداری کنید – کد تکراری نشان دهنده مشکلات ساختاری است
3. اگر به اندازه کافی برای جهانی بودن مهم است ، آن را در یک API بپیچید
4. طراحی کد خجالتی – مؤلفه ها فقط باید با چیزهایی که مستقیماً درباره آنها می دانند مقابله کنند
5. اصل خشک را دنبال کنید – همراه با جداسازی و پیکربندی خارجی ، این به جلوگیری از تصمیمات مهم و برگشت ناپذیر کمک می کند
6. اتصال در دنیای واقعی را در نظر بگیرید – به شناسه های خارجی که نمی توانید کنترل کنید تکیه نکنید (شماره تلفن ، کدهای پستی ، SSN ، آدرس ایمیل)

از نمونه های اولیه و تخمین استفاده کنید

• نمونه های اولیه نرم افزار را بسازید برای تجزیه و تحلیل و افشای ریسک در کاهش هزینه ، به ویژه برای هر چیز تأیید نشده ، تجربی یا بحرانی
• مهارت های تخمین را توسعه دهید برای درک بصری امکان سنجی راه حل های پیشنهادی

برنامه نویسی دفاعی

به هیچ کس اعتماد نکنید ، حتی خودتان نیست

“برنامه نویسان عملی نیز به خود اعتماد ندارند. دانستن اینکه هیچ کس کد کاملی را نمی نویسد ، آنها در برابر اشتباهات خود دفاع می کنند.”

شیوه های کلیدی:

• برای جلوگیری از غیرممکن ها از ادعاها استفاده کنید – وقتی فکر می کنید “این هرگز نمی تواند اتفاق بیفتد” ، کد را اضافه کنید تا آن را بررسی کنید
• طراحی با قرارداد – به وضوح تعریف کنید که هر مؤلفه وعده تحویل و آنچه را که در عوض انتظار دارد
• منابع را به طور مداوم مدیریت کنید – طرحی برای تخصیص منابع و جابجایی منابع تهیه کنید
• پیکربندی خارجی – مقادیری را که ممکن است بعد از استقرار در خارج از برنامه شما تغییر کند ، نگه دارید

def transfer_money(source_account, target_account, amount):
    # Assert our preconditions
    assert amount > 0, "Transfer amount must be positive"
    assert source_account.balance >= amount, "Insufficient funds"

    # Perform the transfer
    source_account.withdraw(amount)
    target_account.deposit(amount)

    # Assert our postconditions
    assert source_account.original_balance == source_account.balance + amount, "Source balance inconsistent"
    assert target_account.original_balance + amount == target_account.balance, "Target balance inconsistent"

تفکر تحول گرا

برنامه ها در مورد داده ها است

“برنامه نویسی در مورد کد است ، اما برنامه ها در مورد داده ها هستند.”

تمرکز روی تحولات – تبدیل ورودی به خروجی ها:

1. برای تعریف عملکرد کلی برنامه با الزامات شروع کنید
2. مراحلی را پیدا کنید که از ورودی به خروجی منتهی شود
3. برنامه خود را به عنوان یک سری تحولات بسازید

این رویکرد منجر به:

• کد پاک کننده
• توابع کوتاه تر
• طرح های چاپلوسی

آزمایش و اشکال زدایی

آزمایش مربوط به یافتن اشکالات نیست

آزمایش بازخوردی در مورد طراحی کد ، API ، اتصال و موارد دیگر ارائه می دهد. مزایای اصلی ناشی از آن است فکر کردن و نوشتن تست ها ، نه فقط اجرای آنها.

“یک آزمایش اولین کاربر کد شماست”

چرخه توسعه آزمایش محور:

1. در مورد یک قطعه کوچک از عملکرد تصمیم بگیرید
2. آزمایشی بنویسید که پس از اجرای آن گذشت
3. تست ها را اجرا کنید تا تأیید کنید که فقط آزمایش جدید شما انجام نمی شود
4. حداقل کد را بنویسید تا آزمون بگذرد
5. بازپرداخت و اطمینان از گذراندن تست ها هنوز

طرز فکر اشکال زدایی

به یاد داشته باشید که اشکال زدایی حل مسئله است. هنگام مواجهه با مشکلات:

1. پیام خطا را با دقت بخوانید
2. اشکال را برای یک همکار توضیح دهید
3. علت اصلی را به جای اینکه فقط علائم را درک کنید
4. اشکال را بومی سازی کنید
5. اشتباهات خود را به جای سرزنش کردن کتابخانه های خارجی انجام دهید
6. در نظر بگیرید که آیا شرایط مشابه در جای دیگری از سیستم وجود دارد

حلقه های بازخورد

همیشه مراحل کوچک و عمدی را انجام دهید ، قبل از ادامه کار ، بازخورد و تنظیم را بررسی کنید. در نظر بگیرید که میزان بازخورد محدودیت سرعت شماست. هرگز یک قدم یا کار را که “خیلی بزرگ” است بردارید.

پذیرش تغییر

تصمیمات برگشت پذیر بگیرید

“جفت شدن دشمن تغییر است.”

استراتژی های انعطاف پذیر:

• کد کمتری بنویسید – هر خط پتانسیل اشکالات را معرفی می کند
• از اتصال محکم خودداری کنید – اجزای فردی باید تا حد امکان به چند مؤلفه دیگر متصل شوند
• داده های پیکربندی را در خارج از برنامه خود قرار دهید
• معماری های رویداد محور را در آغوش بگیرید:
  1. ماشینهای دولتی محدود
  2. الگوی ناظر
  3. انتشار/مشترک شدن
  4. برنامه نویسی واکنشی

تغییر شکل

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

چه زمانی به Refactor:

• هنگامی که شما تکثیر (نقض خشک) پیدا کردید
• وقتی طراحی متعامد نیست
• وقتی دانش یا الزامات تغییر می کند
• هنگامی که الگوهای استفاده اولویت های جدید را نشان می دهد
• هنگامی که عملکرد نیاز به پیشرفت دارد
• وقتی تست ها می گذرد

حکمت عملی

به طور تصادفی برنامه نکنید

برنامه عمداً توسط:

• آگاهی از کاری که انجام می دهید
• درک کد خود به اندازه کافی برای توضیح آن
• اقدام از یک طرح
• فقط به چیزهای قابل اعتماد متکی است
• مستند سازی و آزمایش فرضیات شما
• اولویت بندی تلاش در جنبه های مهم

به غرایز خود گوش دهید

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

به عملکرد الگوریتم فکر کنید

حتی اگر به ندرت الگوریتم های مرتب سازی را از ابتدا بنویسید ، درک پیچیدگی محاسباتی به شما کمک می کند تا مسائل مربوط به عملکرد را پیش بینی کنید:

• حلقه های ساده: o (n)
• حلقه های تو در تو: o (n²)
• در نظر بگیرید که N در متن خاص شما چقدر بزرگ است

به یاد داشته باشید که سریعترین الگوریتم همیشه بهترین نیست – برای مجموعه داده های کوچک ، راه حل های ساده تر اغلب خوب کار می کنند.

چابک یک صفت است ، نه یک اسم

“چابک این است که شما چگونه کاری انجام می دهید. شما می توانید یک توسعه دهنده چابک باشید. شما می توانید در تیمی باشید که شیوه های چابک را اتخاذ می کند ، تیمی که پاسخ به تغییر و مشکلات با چابکی می کند.”

چابکی در توسعه نرم افزار در مورد پاسخ به تغییر و ناشناخته هایی است که پس از تنظیم با آنها روبرو می شوید. مقادیر مانیفست چابک:

• افراد و تعامل در فرآیندها و ابزارها
• نرم افزار کار بر روی مستندات جامع
• همکاری مشتری در مورد مذاکره قرارداد
• پاسخ به تغییر در پیگیری یک طرح

پایان

جوهر برنامه نویسی عملی ترکیب تعالی فنی با سازگاری است. با در آغوش گرفتن از طراحی متعامد ، تکنیک های برنامه نویسی دفاعی ، تفکر تحول گرا و بازخورد مداوم ، می توانید نرم افزار بهتری بنویسید و به طور مؤثرتر پاسخ دهید تا تغییر کند.

اقدامات کوچک و عمدی را انجام دهید ، به غرایز خود گوش دهید و به یاد داشته باشید که برنامه نویسی سفر یادگیری و سازگاری مداوم است.

چه اصولی از این مقاله را قبلاً تمرین می کنید؟ دوست دارید کدام یک را در گردش کار خود وارد کنید؟ افکار خود را در نظرات به اشتراک بگذارید!