یک مدل انشعاب موفق گیت – Git

در این پست مدل توسعه ای (یک مدل انشعاب موفق گیت – Git / امیری) را ارائه می کنم که حدود یک سال پیش، در برخی پروژه های م (هم پروژه های کاری و هم پروژه های شخصی) معرفی کردم؛ و مشخص شد که بسیار هم موفق بوده است. الان مدتی هست که قصد دارم درباره ش بنویسم، اما واقعا فرصتی برای انجام این کار نداشتم، تا الان. درباره ی جزئیات هیچ کدام از پروژه ها صحبتی نخواهم کرد، و صرفا درباره استراتژی انشعاب و مدیریت انتشار خواهم نوشت (این نوشته، از مقاله ای تحت عنوان A successful Git branching model نوشته Vincent Driessen ترجمه شده ست. لطفا به «پی نوشت» مراجعه کنید / امیری).

مدل انشعاب گیت

این نوشته حول گیت (Git) به عنوان ابزار نسخه بندی تمام سورس کد های ما، متمرکز است. (ترجمه نشده: By the way, if you’re interested in Git, our company GitPrime provides some awesome realtime data analytics on software engineering performance. 😉 )

چرا گیت؟

برای یک بحث کامل درباره مزایا و معایب گیت در قیاس با سیستم های کنترل سورس کد متمرکز، وب را ببینید. جنگ های آتشین زیادی آنجا در جریان است. به عنوان یک توسعه دهنده، من گیت را به همه ابزارهای دیگر امروز، ترجیح می دهم. گیت واقعا روش تفکر توسعه دهندگان را درباره ادغام و انشعاب (merging و branching) تغییر داده است. از دنیای کلاسیک CVS/Subversion که من می آیم، ادغام/انشعاب همیشه کمی ترسناک در نظر گرفته شده («از ادغام مغایرت ها بترس، اونها گازت میگیرن!»)، و چیزی ست که شما فقط هر از گاهی انجام می دهید.

اما با گیت (Git) این کارها شدیدا ارزان و ساده، و واقعا به عنوان یکی از بخش های اصلی جریان کار روزانه تان هستند. برای نمونه، در کتاب های CVS/Subversion، ادغام و انشعاب برای اولین بار در فصل های پایانی مورد بحث قرار می گیرند (برای کاربران پیشرفته)، در حالیکه در همه کتاب های گیت، این مباحث تقریبا در فصل سوم (سطح ابتدایی) پوشش داده شده اند.

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

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

غیرمتمرکز، ولی متمرکز

تنظیماتی که قرار است استفاده کنیم و با مدل انشعاب جاری، به خوبی کار می کند، تنظیمی ست با یک مخزن حقیقی مرکزی. به یاد داشته باشید که این مخزن، فقط به عنوان مخزن مرکزی «در نظر گرفته شده است» (از آن جایی که گیت یک DVCS است، از دیدگاه فنی، چیزی به نام مخزن مرکزی در آن معنی ندارد) (درباره DVCS ها امیدوارم صحبت کنیم؛ اما عجالتا: DVCS مخفف distributed version control systems به معنای «سیستم های کنترل نسخه ی توزیع شده» می باشد. DVCS ها در مقابل centralized version control systems قرار می گیرند. معروفترین DVCS ها شامل Git، Mercurial و Bazaar هستند و در CVCS ها هم به احتمال زیاد با SVN برخورد داشته اید /امیری). به این مخزن، با نام origin رجوع خواهیم کرد (این مخزن را با origin نامگذاری خواهیم کرد /امیری)، چرا که بیشتر کاربران گیت با این کلمه آشنایی دارند.

مدل انشعاب گیت

هر توسعه دهنده ای، کدش را از origin دریافت و همچنین به origin ارسال می کند (pull و push کردن). اما علاوه بر ارتباطات دریافت/ارسال مرکزی، هر توسعه دهنده می تواند با یک عضو دیگر تیم، یک جفتِ «زیر_تیم» تشکیل داده و از وی دریافت کد داشته باشد. برای نمونه، وقتی چند توسعه دهنده، قصد دارند پیش از انتشار روی origin، با یکدیگر روی یک ویژگی بزرگ و جدید کار کنند، این روش می تواند استفاده زیادی داشته باشد. در تصویر بالا، زیر_تیم هایی از Alice و Bob، از Alice و David، و همینطور از Clair و David می بینید.

از نظر فنی، فرایند فوق، چیزی بیش از این نیست که: Alice یک گیت ریموت تعریف کرده به نام bob، که در آن به مخزن Bob اشاره شده است؛ و برعکس.

انشعاب های اصلی

مدل انشعاب گیت

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

  • master
  • develop

انشعاب master روی origin باید برای هر کاربر گیت آشنا باشد. به موازات انشعاب master، یک انشعاب دیگر وجود دارد که develop نامیده می شود.

انشعاب origin/master را انشعاب اصلی در نظر میگیریم که کد منبع HEAD آن، همواره ارائه کننده یک نسخه «آماده ی ارائه به مشتری» می باشد (production-ready).

همچنین، انشعاب origin/develop را انشعاب اصلی ای در نظر میگیریم که کد منبع HEAD آن، همواره آخرین تغییرات تحویل داده شده روند توسعه را، برای release بعدی، ارائه می کند. برخی این انشعاب را، integration branch (انشعاب ادغام) می نامند. اینجا، جایی ست که همه نسخه های شبانه اتوماتیک، از روی آن ساخته می شوند.

وقتی کد منبع در انشعاب develop به یک نقطه پایدار رسیده و آماده انتشار شد (ارائه نسخه release)، همه تغییرات باید به نوعی با master ادغام شده، و با یک شماره نسخه، برچسب زده شوند. این که این کار چطور انجام می شود، در ادامه مورد بحث قرار می گیرد.

بنابراین، طبق تعریف، هر بار که تغییرات با master ادغام می شوند، یک «انتشار محصول» جدید خواهیم داشت (نسخه جدید نرم افزار). روی این مورد تمایل داریم بسیار سختگیر باشیم، بنابراین از نظر تئوری، می توانیم از یک اسکریپت hook گیت استفاده کنیم، تا هر بار که یک commit روی master داشتیم، نرم افزار مان را کامپایل و build و بسته بندی کرده، به سرور های ارائه محصول مان بفرستد.

انشعاب های پشتیبان

در کنار انشعاب های اصلی master و develop، مدل توسعه ما از انشعاب های پشتیبان متفاوتی برای: -توسعه موازی بین اعضای تیم، -سهولت ردگیری خصائص و امکانات جدید، -آماده سازی نسخه های انتشار محصول، -و کمک به رفع سریع مشکلات محصول منتشر شده (رفع اشکال های فوری – hotfix)، استفاده می کند. برخلاف انشعاب های اصلی، این انشعاب ها همیشه یک طول عمر محدود دارند؛ زیرا در نهایت حذف خواهند شد.

انوع مختلف انشعاباتی که ممکن است استفاده کنیم، این ها هستند:

  • انشعاب های ویژگی (Feature branches)
  • انشعاب های انتشار (Release branches)
  • انشعاب های رفع اشکال (هاتفیکس – Hotfix branches)

هر کدام از این انشعاب ها یک هدف مشخص (و تعریف شده) دارند و مقید به قوانین سختی هستند که تعیین می کنند کدام انشعاب ها می توانند انشعاب منشاء آن ها، و کدام انشعاب ها باید انشعاب هدف آن ها برای ادغام باشند (در ادامه این موارد را مرور خواهیم کرد).

از یک نگاه فنی، این انشعاب ها به هیچ وجه «ویژه» نیستند. نوع انشعاب ها، با توجه به این که «ما چطور از آن ها استفاده می کنیم»، دسته بندی شده اند. سد البته این ها همان انشعاب های قدیمی و معمولی گیت هستند.

انشعاب های ویژگی (Feature branches)

مدل انشعاب گیت

می توانند منشعب شوند از:
develop
باید ادغام شوند با:
develop
قرارداد نامگذاری انشعاب:
هر چیزی به جز master ، develop ، release-* ، یا hotfix-*

انشعاب های ویژگی (یا گاهی انشعاب های سرفصل نیز نامیده می شوند)، برای توسعه ویژگی های جدید برای نسخه انتشار بعدی یا نسخه ای که بعدها منتشر خواهد شد، استفاده می شود. وقتی که شروع به توسعه و پیاده سازی یک ویژگی جدید می کنیم، ممکن است نسخه انتشار هدفی که این ویژگی در آن گنجانده خواهد شد، خوب شناخته نشده باشد. ماهیت انشعاب ویژگی این است که مادامی که ویژگی در وضعیت توسعه قرار دارد، انشعاب نیز وجود دارد، اما در نهایت با develop ادغام (مسلما برای گنجاندن ویژگی در نسخه انتشار در راه)، یا دور انداخته خواهد شد (در صورتی که با یک آزمایش ناموفق یا ناامیدکننده مواجه باشیم).

انشعاب های ویژگی، معمولا در مخازن توسعه دهندگان وجود دارند، نه روی origin.

ایجاد یک انشعاب ویژگی

وقتی شروع به کار روی یک ویژگی جدید می کنید، از انشعاب develop یک انشعاب جدید بزنید:

گنجاندن یک ویژگی تکمیل شده در develop

ویژگی های تکمیل شده (که کار توسعه آن ها پایان یافته ست) می توانند در develop گنجانده شوند که مسلما آن ها را به نسخه انتشار بعدی، خواهد افزود:

پرچم no-ff-- باعث می شود فرایند ادغام همیشه یک شیئ commit جدید ایجاد کند، حتی اگر ادغام بتواند با یک fast-forward انجام شود. این امر مانع از دست رفتن تاریخچه وجود یک انشعاب ویژگی شده، و همه commit هایی که در مجموع ویژگی را افزوده اند، با یکدیگر گروه بندی می کند. جهت مقایسه، تصویر زیر را ببینید:

مدل انشعاب گیت

در وضعیت دوم، غیرممکن است که از تاریخچه گیت بفهمیم کدام اشیاء commit با یکدیگر یک ویژگی (Feature) را به وجود آورده اند – برای این منظور، مجبور می شوید همه پیام های لاگ را خودتان بخوانید؛ و واگردانی کامل یک ویژگی (در واقع یعنی گروهی از commit ها) در وضعیت های آینده یک سردرد واقعی ست. در حالی که با استفاده از پرچم no-ff-- این کار به راحتی انجام می گیرد.

بله البته این کار تعداد کمی شیئ commit (که خالی هستند) ایجاد می کند؛ اما آورده ی آن، بسیار بیشتر از هزینه ی آن خواهد بود.

انشعاب های انتشار (Release branches)

می توانند منشعب شوند از:
develop
باید ادغام شوند با:
develop و master
قرارداد نامگذاری انشعاب:
release-*

انشعاب های انتشار، از تهیه و تدارک یک «انتشار محصول» جدید پشتیبانی می کنند. تغییرات جزئی و اصطلاحا پولیش زدن های دقیقه ۹۰ را میسر می کنند. و از این گذشته، اجازه می دهند بتوانیم رفع باگ های کوچک داشته باشیم، و نیز فرا-داده (meta data) های مورد نیاز یک «انتشار» را فراهم می کنند (شماره نسخه، تاریخ ساخت، غیره). با انجام همه این کارها در یک شعبه انتشار، انشعاب develop برای دریافت ویژگی ها برای انتشار بزرگ بعدی تمیز باقی می ماند.

زمان کلیدی برای انشعاب یک شعبه انتشار جدید از develop زمانی ست که develop (تقریبا) وضعیت مورد انتظار نسخه انتشار جدید را بازتاب می کند. دستکم همه ی ویژگی هایی که نسخه انتشار پیش رو را هدف قرار داده اند، باید در این مقطع از زمان با develop ادغام شده باشند. و هیچ یک از ویژگی هایی که برای انتشارهای بعدی هدف شده اند، نباید در develop باشند – آن ها باید صبر کنند تا نسخه انتشار فعلی از develop برداشته شود (و با release ادغام شود).

دقیقا در زمان شروع یک انشعاب انتشار ست که نسخه انتشار یک شماره نسخه می گیرد – و نه زودتر. تا آن زمان، انشعاب develop تغییرات «انتشار بعدی» را بازتاب می دهد؛ ولی تا زمانی که انشعاب انتشار شروع نشده باشد، مشخص نیست که نهایتا این «انتشار بعدی» نسخه ۰٫۳ خواهد بود یا ۱٫۰. چنین تصمیمی در ابتدای انشعاب انتشار گرفته می شود، و مبتنی ست بر قوانین تداوم شماره نسخه پروژه.

ایجاد یک انشعاب انتشار

شعب انتشار از روی انشعاب develop ایجاد می شوند. برای نمونه، فرض کنید نسخه ۱٫۱٫۵ نسخه محصول منتشر شده فعلی ست، و ما یک انتشار بزرگ پیش رو داریم. وضعیت develop آماده ی «انتشار بعدی» ست، و ما تصمیم گرفتیم این انتشار، نسخه ۱٫۲ خواهد بود (به جای ۱٫۱٫۶ یا ۲٫۰). بنابراین از develop یک انشعاب میگیریم و به انشعاب انتشار (جدید) نامی می دهیم که بازتاب دهنده نسخه انتشار باشد:

بعد از ایجاد یک انشعاب جدید و سوئیچ به آن، شماره نسخه را اعلام می کنیم. در این جا، bump-version.sh یک اسکریپت پوسته (فرضی) ست که برخی فایل ها در شاخه کاری را اصلاح می کند تا نمایانگر شماره نسخه جدید باشند (این کار البته می تواند به صورت دستی انجام شود – هدف این ست که برخی فایل ها تغییر کرده باشند). سپس شماره نسخه اعلام شده، commit شده است.

این اشعاب جدید، تا زمان ارائه قطعی «نسخه انتشار»، می تواند وجود داشته باشد. در این مدت، رفع اشکالات جزئی (bug fix) می توانند در این انشعاب انجام شوند (به جای آن که روی develop انجام شوند). اضافه کردن ویژگی های گسترده و جدید در این انشعاب به شدت ممنوع است. چنین تغییراتی، باید با develop ادغام شوند، و لذا، تا انتشار بزرگ بعدی، آن جا می مانند.

پایان دادن به یک انشعاب انتشار

وقتی وضعیت یک انشعاب انتشار آماده آن شد که تبدیل به یک انتشار واقعی شود، ضرورت دارد برخی اقدامات صورت گیرد. اول، انشعاب انتشار با master ادغام می شود (از آن جایی که طبق تعریف، هر commit روی master به معنای یک انتشار جدید است – به یاد بیاورید). سپس commit روی master باید برای ارجاعات آسان در آینده به این نسخه در تاریخچه گیت، با شماره نسخه برچسب زده شود. و در پایان، تغییرات اعمال شده روی انشعاب انتشار، باید با انشعاب develop بازادغام شوند، تا انتشار های آتی نیز، این bug fix ها را شامل باشند.

دو قدم اول در گیت:

«انتشار» اکنون انجام شده، و برای ارجاعات آتی برچسب زده شده است.

همچنین، برای حفظ تغییرات اعمال شده در انشعاب انتشار، نیاز ست تا آن ها را با develop بازادغام کنیم. در گیت:

این قدم، ممکن است منجر به مغایرت در ادغام (merge conflict) شود (حتی با احتمال زیاد؛ زیرا دستکم ما شماره نسخه را تغییر داده ایم). اگر این طور شد، مغایرت را رفع، و commit کنید.

حالا، ما واقعا کار را به پایان رسانده ایم، و انشعاب انتشار (قبلی) می تواند حذف شود، زیرا بیش از این به آن نیاز نداریم:

انشعاب های رفع اشکال (Hotfix branches)

مدل انشعاب گیت

می توانند منشعب شوند از:
master
باید ادغام شوند با:
develop و master
قرارداد نامگذاری انشعاب:
hotfix-*

انشعاب های رفع اشکال (hotfix branches) بسیار شبیه انشعاب های انتشار هستند؛ زیرا این انشعاب ها هم به نوعی معنای آماده شدن و تدارک یک «انتشار محصول» جدید را می دهند؛ اگر چه این انتشار، یک انتشار برنامه ریزی شده نیست. این انشعاب ها، از ضرورت یک اقدام سریع بر مبنای وضعیت ناخواسته ی نسخه ای از محصولِ منتشرشده (باگ هایی که باید بلافاصله برطرف شوند) نشأت می گیرند. وقتی یک باگ بحرانی در یک نسخه از محصول منتشر شده وجود دارد که باید بلافاصله مرتفع شود، یک انشعاب رفع اشکال می تواند از برچسب (tag) متناظر با نسخه محصول از master منشعب شود.
اساس کار بر این است، که کار معمول اعضای تیم (روی انشعاب develop) ادامه پیدا کند، آن هم در حالی که شخصی دیگر در حال تدارک یک نسخه ی رفع باگ محصول است.

ایجاد یک انشعاب رفع اشکال

انشعاب های رفع اشکال از انشعاب master ایجاد می شوند. برای نمونه، فرض کنید نسخه ۱٫۲ نسخه منتشر شده فعلی محصول است، که به خاطر یک اشکال مهم، باعث بروز دردسرهایی شده است. اما تغییراتِ روی develop هنوز در وضعیت پایدار (و قابل ارائه ای) نیستند. در چنین وضعیتی، می توانیم یک انشعاب رفع اشکال از master گرفته، و شروع به برطرف کردن باگ و رفع مشکل کنیم:

فراموش نکنید که بعد از انشعاب، شماره نسخه را اعلام کنید.

سپس اشکال را رفع، و اصلاحات را طی یک یا چند مرحله commit میکنیم:

پایان دادن به یک انشعاب رفع اشکال

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

ابتدا، master را آپدیت کرده و نسخه انتشار را برچسب می زنیم:

سپس، رفع اشکال را در develop نیز قرار میدهیم:

یک استثناء در قانون مذکور این است که، وقتی یک انشعاب انتشار در حال حاضر وجود دارد، تغییرات «رفع اشکال» به جای develop، باید روی آن شعبه انتشار ادغام شوند. بازادغام رفع اشکال در انشعاب انتشار، نهایتا وقتی انشعاب انتشار پایان پذیرفت، در انشعاب develop نیز ادغام خواهد شد. (اگر کار روی develop فورا نیاز به این تغییرات رفع اشکال داشته و نمی تواند تا پایان گرفتن انشعاب انتشار منتظر بماند، می توانید با اطمینان و امنیت، تغییرات را در develop نیز ادغام کنید).

نهایتا، انشعاب موقت را حذف کنید:

خلاصه

در حالی که هیچ چیز جدید و تعجب برانگیزی در این مدل توسعه روی گیت وجود ندارد، مشخص شده که تصویر بزرگی که این پست با آن شروع شده، در پروژه های ما به شدت قابل استفاده و مفید است. این مدل، یک هوش ظریف را شکل می دهد که آسان-فهم بوده و به اعضای تیم اجازه می دهد، درک مشترکی از پروسه های انشعاب و انتشار داشته باشند. یک نسخه PDF با کیفیت بالا از مدل مذکور پیوست شده است (+ اینجا در سایت اصلی 😉 ). بفرمایید و آن را روی دیوارتان، برای ارجاعات سریع، آویز کنید.

پی نوشت:

متن بالا، ترجمه (نسبتا و در حد توان) وفاداری ست از بلاگ_نوشته ای تحت عنوان A successful Git branching model (یک مدل انشعاب موفق گیت) از Vincent Driessen.

پی نوشت ۲:

قرار بود درباره ی آزمون واحد بنویسم، اما درباره گیت (Git) نوشتم. البته قرار به هم نخورده است. اما بنا به ضرورتی، باید مطلبی درباره گیت آماده می کردم. مقاله بالا را حدود یک سال پیش تر، دوست و استاد بزرگوارم جناب مهندس نیلدرار، معرفی کرده بودند. از سادگی و در عین حال جامع و کارا بودن مدل، خوشم آمده بود. خیلی. با آن که نوشته ای قدیمی ست (در ۲۰۱۰ نوشته شده)، اما هنوز هم می تواند خیلی مفید باشد. در مدل کردن فرآیند، و همینطور در ارائه آن به عنوان یک مقاله، بسیار منظم و منسجم عمل کرده ست. از همان وقت، قصد ترجمه آن را داشتم. اما وقتی واقعا نبود. در ضرورت جاری، گفتم چه کاری بهتر از ترجمه این نوشته. با یک تیر، سه نشان می زنم 😉 این شد که می بینید و یحتمل می خوانید.
دست به ترجمه م بسیار بد است. برای بسیاری از اصطلاحات، جایگزین فارسی نمیشناسم. همیشه خوانده م. هیچ وقت نشد که برگردانم. اما تلاش کردم، مفاهیم را به شکل قابل فهمی جمله بندی کنم. امیدوارم مفید باشد.

در ایران روزانه چند نفر پای اینترنت می میرند؟

لری کینون کارمند اپل، از سال ۱۹۸۳ تعریف میکند که کامپیوتر تولیدی این شرکت بسیار کند و آرام بوت میشد و کاربران پس از روشن شدن کامپیوتر، باید چند دقیقه برای تست حافظه و فلاپی و … منتظر می ماندند.

استیو جابز از این مسئله دلگیر بود. یک روز عصر وارد دفتر لری شد و گفت: نمیتوانی سرعت بوت شدن کامپیوتر را بهتر کنی؟

لری دلایل متعددی آورد و توضیح داد که این کار امکان پذیر نیست.

استیو پرسید: اگر بدانی که میتوانی ده ها نفر را از مرگ نجات دهی آیا امکان دارد سرعت بوت شدن را حداقل ۱۰ ثانیه کاهش دهی؟

لری با تعجب نگاه میکرد.

استیو گفت: طی سالهای آینده، ما ۵ میلیون کاربر خواهیم داشت. هر کدام حداقل روزی یک بار کامپیوتر خود را روشن میکنند و تو با بهتر کردن سرعت بوت، میتوانی روزی ۵۰ میلیون ثانیه به عمر بشر اضافه کنی. تو در هر سال، جان ده ها نفر را نجات میدهی…

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

——————————————————

آمارها نشان میدهند که در ایران بیش از ۳۰ میلیون کاربر اینترنت وجود دارد. ظاهراً در میان نسل جوان و نوجوان میزان کاربرد در حد ۶ ساعت و بیشتر است. اما میتوان به صورت بسیار بدبینانه متوسط کاربرد روزانه را ۳۰ دقیقه در نظر گرفت.

اعمال فیل.ترا.سیون قدرتمند، کنترل ترافیک، نیاز به استفاده از فیل.تر.شکن برای ساده ترین کارها حتی چک کردن ایمیل و …، نیاز به رفرش کردن های مکرر و …، اثربخشی استفاده از اینترنت را به نظر من بیش از ۵۰% کاهش داده است.

اگر عمر متوسط یک ایرانی را ۷۰ سال در نظر بگیریم، روزانه ۲۵ نفر در ایران، در پای اینترنت کشته میشوند.

میتوان فرض کرد ماهیانه ۳ هواپیما از کاربران اینترنت در ایران، خاموش و بی صدا، سقوط میکنند…

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

هنر آزمون واحد

آزمون واحد چیست و چرا در توسعه نرم افزار حضور دارد؟ هزینه ها و آورده های ش کدامند؟ چطور آزمون واحد های خوب بنویسیم؟ ویژگی های آزمون واحد خوب کدامند؟ آیا unit testing ارزش هزینه کردن دارد؟ بنا ست راجع به این پرسش ها فکر کنم.

مدتی ست شرایط شغلی م مرا در وضعیتی قرار داده که از خیلی از مباحث دور افتاده ام. کم کم دارم انگار همه چیز را فراموش می کنم. چند روز پیشتر، در مکالمه ای، طرف گفتگو از کلمه «فَساد» استفاده کرد و خودم هم باورم نمی شد که یکی دو دقیقه طول کشید تا مغزم کلمه را به مفهوم مرتبطش ربط دهد (منظور همان «facade» است؛ اگر شما هم گیر کردید :) ). لذا تصمیم گرفتم، با نوشتن و کمی درگیری عمدی با مباحث، حداقل اگر به روز نمی شوم، فسیل هم نشوم.

از میان همه موضوعات و مباحثی که روی شان کمی تمرکز کردم، دو موضوع به نظرم مهمتر آمد: الگوهای طراحی، و آزمون واحد. شروع به بررسی کردم. ببینم در یکسال گذشته چه خبر بوده (کمی بیشتر حتی). برخوردم به کتاب الگوهای طراحی در C# 5.0 نوشته سید منصور عمرانی؛ دیدم استقبال زیاد بوده. کامنت ها حکایت از یک حرکت تاثیرگذار و سنجیده و ارزشمند می کنند. تصمیم گرفتم پای م که به انقلاب رسید، کتاب را تهیه کنم. مشخصاتش را هم به تلگرام خودم ارسال کردم. نشر پندار پارس، اگر خواستید تهیه کنید. و البته کلی مطلب ارزشمند دیگر. به نظر دوستان و همکاران به اهمیت موضوع پی برده اند. متاسفانه الگوهای طراحی آقای نصیری، آن طور که باید و شاید، و آن طور که شایسته هم آن کتاب ارزشمند و هم این مبحث مهم است، سر و صدا نکرده بود. اما به نظر می رسد بالاخره بعد از چند سال، شرایط بهتر شده.

اما درباره آزمون واحد، هنوز هم جدیت لازم بین اساتید وجود ندارد. مطالبی که وجود دارد کم است؛ گاهی حتی ناقص کاری هایی از برخی کتب، مخصوصا یکی که در ادامه عرض می کنم؛ و بیشتر از آن که بحث شناختی باشد، بحث اجرایی ست. اجرا هم مطمئنا خوب ست. بحثی نیست. اما «چگونگی» بدون دانستن «چرایی» منجر به اتفاق نیکی نخواهد شد.

چند سال پیش تر کتابی خوانده بودم «The Art of Unit Testing» (هنر آزمون واحد – unit testing) از نشر manning؛ که کتاب خوبی بود؛ و دیدم که نوشته های دوستان و اساتید، چقدر ناقص برداری کرده ند از این کتاب. نه این که خدای نکرده توهینی در کلامم باشد یا حتی بگویم چرا؟! منظور این ست که کتابی به این خوبی، حیف است که ناقص نقل شود. بریده شود. القصه؛ تصمیم گرفتم یک بار دیگر کتاب را خط به خط و کلمه به کلمه بخوانم (بماند قانون کپی رایت و گشتن توی هارد بازارمکاره م و پیدا نکردنش و گشتن توی نت و پیدا کردن لینک دانلود ش و …) و برای دوستانم نقل کنم. البته پیشاپیش بگویم، نه مترجمم؛ نه نویسنده م؛ و نه هدف ترجمه این کتاب (یا هر نوشته دیگری) ست. فقط این: خودم کتاب را بخوانم. برای دوستانم تعریف کنم. مطمئنا با حتی یک ترجمه آزاد هم طرف نیستید. فقط نقل قول است برخی جاها ش. در واقع مشق شبی ست که خودم به خودم می دهم؛ برای بهتر یاد گرفتن. زنده باشید.

پی نوشت: آیا نمی شود به جای «واحد» از واژه هایی مانند «یگان» یا «شمار» استفاده کرد (بهره برد)؟

دیباچه

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

از دست و زبان که بر آید
کز عهده شکرش به در آید

سلام. معمولا وبلاگ نویسی با پست معروف «Hello World» یا همان «سلام دنیا!» ی خودمان شروع می شود. مخصوصا این که اگر بلاگر، اصطلاحا در گروه tech-guys هم قرار بگیرد. اما فکر کردم، مگر دیباچه حضرت استاد سخن، سعدی علیه الرحمه، چه اشکالی دارد؟ هم فال ست و هم تماشا. هم غنی و پرمعنا، هم زیبا و شیوا. بنابراین این شد که می بینید.
علی ایحال؛ قبلا چندبار شروع به نوشتن کردم. در بلاگر و وردپرس و بلاگفا نوشتم. اما مشغله فراوان، بسیار فراوان، همیشه مانع نوشتن جدی شده است. یک بار هم kweb را راه انداخته بودم. اما همین مشغله مورد اشاره، باعث از دست رفتن سایت شد کلا ):
این بار هم قرار نیست نویسندگی کنم. نه وقتش، نه توانش، و نه قصدش را دارم؛ و مهمتر این که مهارتش را هم ندارم. صرفا گپ و گفتی ست با خودم، که گفتم با خواننده (گانِ) احتمالی به اشتراک بگذارم. بیشتر در حوزه ی برنامه نویسی و توسعه نرم افزار. اما مطمئنا ادبیات و فلسفیدن و موسیقی را هم فراموش نمی کنم.