برنامه نویسی چیست؟

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: همه‌ چیز با یک آری شروع می‌شود!

از یک دید کلی می‌توان پرسنل فروشگاه‌های را به ۲ گروه مختلف تقسیم‌بندی کرد: گروهی از فروشندگان که نیمهٔ پر لیوان را می‌بینند و گروه مقابل که صرفاً روی نیمهٔ خالی متمرکز هستند! به نظر می‌رسد که برای روشن‌تر شدن این مسأله، باید از یک مثال روزمره کمک گرفت.

وقتی که به یک فروشگاه زنجیره‌ای برای خرید می‌رویم، برخی فروشندگان هستند که وقتی سؤالی عجیب و غریب از ایشان می‌پرسیم، مثلاً نوعی شربت که بسیار کم‌مصرف است و فقط تعدادی فروشگاه خاص آن را عرضه می‌کنند، درخواست ما به عنوان یک مشتری را هرگز رد نکرده و فوراً با گفتن جمله‌ای همچون «خیر. متأسفانه ما این محصول را نداریم!» به قضیه فیصله نمی‌‌دهند بلکه این درخواست در ظاهر عجیب و غریب ما را به عنوان یک فرصت نگاه کرده،‌ اگر هم خودشان در این رابـ ـطه اطلاعی نداشته باشند از سایر همکارانشان کمک گرفته تا بلکه ایشان بتوانند راهنمایی کنند و در نهایت هم اگر کمکی از دست هیچ‌کس برنیاید، نام و مشخصات محصول مد نظرتان را گرفته تا برایتان تهیه کنند.

در نقطهٔ مقابل این دست فروشندگان، گروهی دیگر قرار دارند که اصلاً مشتری‌مدار نیستند و صرفاً با گفتن جمله‌ای همچون «خیر. نداریم!» خود را خلاص می‌کنند.

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

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

خیلی از اوقات با بله گفتن به درخواست‌هایی که از طرف مدیرعامل، مدیر محصول، مدیر پروژه، مشتری و یا حتی کاربران می‌آیند، اصلاً نیازی به کدزنی قابل‌توجهی نیست بلکه با چند تغییر کوچک، می‌توان به درخواست ارسال شده جامعهٔ عمل پوشید.

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: آشنایی با قانون Single Responsibility

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

از دید فنی، به چنین قابلیتی Single Responsibility Principle (اصل تک وظیفه‌ای) یا به طور خلاصه SRP گفته می‌شود. به عبارت دیگر، این اصل حاکی از آن است که یک ماژول، کلاس، فانکشن یا هر چیزی می‌بایست وظیفه‌ای واحد داشته، متمرکز بر یک تسک بوده و صرفاً به یک دلیل تغییر یابند نه اینکه به محض مواجه با یک نیاز در هر بخشی از نرم‌افزار، نیاز داشته باشیم تا آن را دستخوش تغییر سازیم. برای روشن‌تر شدن این مسأله، کلاسی فرضی تحت عنوان Employee که دارای ۳ فانکش مختلف است را در نظر می‌گیریم:

public class Employee
{
public function calculatePayment();
public function reportHours();
public function save();
}
برخی برنامه‌نویسان بر این باورند از آنجا که این ۳ فانکشن به نوعی مرتبط با یکدیگر هستند، می‌بایست در قالب یک کلاس تعریف شوند اما این در حالی است که طبق قانون SRP، این ۳ فانکشن بنا به دلایلی کاملاً متفاوت ممکن است نیاز به تغییر کردن داشته باشند. برای مثال، فانکشن ()calculatePayment زمانی می‌بایست تغییر یابد که حقوق و مزیا کم‌ و زیاد شوند، فانکشن ()reportHours هم زمانی تغییر خواهد یافت که نحوهٔ گزارش‌دهی به مدیران تغییر کند و فانکشن ()save هم هر موقع که دیتابیس یا اسکمای برخی جداول تغییر یابد باید ریفکتور شود.

می‌بینیم که ۳ دلیل مختلف برای تغییر یافتن فانکشن‌ها پیش‌ روی ما است و این باعث می‌گردد که کلاس Employee بنا به هر دلیلی و به خاطر تغییر در سـ*ـیاست‌های مرتبط با هر یک از ۳ فانکشن زیرشاخه‌اش دستخوش تغییر قرار گیرد و نکتهٔ مهم‌تر اینکه اگر در دیگر بخش‌های کد وابستگی به این کلاس وجود داشته باشد و کلاس‌های دیگری از این کلاس ارث‌بری کرده باشند، آنها هم دستخوش تغییر خواهند شد!

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

اگر بخواهیم مجدد به مثال فوق بازگردیم، چنانچه کلاس Employee توسط دیگر کلاس‌های ماژول‌های مختلف پروژه استفاده شده باشد، بنابراین اعمال هرگونه تغییر در این کلاس، کلاس‌های دیگر را تحت‌الشعاع خود قرار خواهد داد که در بسیاری از مواقع منجر به ایجاد باگ می‌شود. حال اگر بخواهیم کلاس فوق را بر اساس قانون SRP ریفکتور کنیم، خواهیم داشت:

public class Employee
{
public function calculatePayment();
}

public class EmployeeReporter
{
public function reportHours();
}

public class EmployeeRepository
{
public function save();
}
می‌بینیم که در کد فوق دارای ۳ کلاس مجزا از یکدیگر هستیم که هر کدام از آن‌ها متمرکز بر تسکی اختصاصی هستند. به عبارت دیگر، تمامی فانکشن‌های مرتبط با گزارش‌دهی را می‌توان در کلاس EmployeeReporter قرار داد، تمامی فانکشن‌های مرتبط با دیتابیس را در کلاس EmployeeRepository نوشت و هر آنچه که مرتبط با Business Rules (قوانین کاری) است را در کلاس Employee.

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: هرچه تعداد خطوط کد کمتر، بهتر!

یکی از خصیصه‌های دولوپرهای تازه‌کار این است که به محض مواجه با یک مشکل و یا نیاز به افزودن یک فیچر جدید و دیگر کارهایی از این دست، سریعاً شروع به کدنویسی و افزودن بخش‌های جدیدی من‌جمله متغیرهای جدید، فانکشن‌های جدید و در یک کلام خطوط بیشتری به سورس‌کد می‌کنند که چنین خصیصه‌ای در نهایت منجر به حجیم شدن سورس‌کد و بالتبع پیچیدگی بیشتر آن می‌شود!

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

لذا در حین کدنویسی می‌بایست تمام تلاش خود را به کار بست تا حداقل تعداد متغیر، کلاس، فانکشن و در یک کلام، حداقل تعداد خطوط کد را داشت.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: وابستگی‌های زیاد دشمن ریفکتورینگ هستند!

در اغلب موارد، به‌ منظور دستیابی به پرفورمنس بیشتر، افزودن فیچرهای جدید و یا دیباگ کردن بخشی از نرم‌افزار بایستی کدها را دستکاری (ریفکتور) کرد اما این در حالی است که بخش‌هایی از کد که دارای Dependency (وابستگی‌) زیادی به دیگر بخش‌ها هستند تمام تلاش‌های ما را نقش بر آب خواهند کرد و هرچه این میزان وابستگی گسترده‌تر و ناواضح‌تر باشد، احتمال پی بردن به آن هم به‌ مراتب دشوارتر خواهد شد!

به خاطر داشته باشیم که کدهای کثیف،‌ نامنظم و اسپاگتی هم اوضاع را بیش از پیش وخیم خواهند کرد به‌ طوری که وابستگی‌های زیاد در سورس‌کد به علاوهٔ کدهای اسپاگتی، یک تغییر کوچک که به نظر ۲ الی ۳ ساعت بیشتر زمان نمی‌برد، به یک فرایند دشوار، خسته‌کننده و گاهی‌اوقات غیرممکن چند هفته‌ای مبدل می‌سازد.

برای جلوگیری از مشکلاتی این چنین، می‌بایست در حین طراحی معماری نرم‌افزار تا حد ممکن میزان وابستگی‌ها را به حداقل رساند. گرچه به صفر رساندن میزان وابستگی عملاً غیرممکن است، اما هرچه میزان وابستگی مابین بخش‌های مختلف سورس‌کد کمتر باشد، و یا این وابستگی‌ها حداقل در حوزهٔ یک ماژول باشند و نه بیشتر، ریفکتورینگ کد به مراتب راحت‌تر خواهد شد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تا حد ممکن از Singleton Pattern استفاده نکنید

نیاز به توضیح نیست که Singleton Pattern مشکل‌گشای بسیاری از مشکلات شما در حین کدنویسی است؛ درواقع، زمانی که شما مطمئن باشید که فقط و فقط یک آبجکت از روی کلاس مدنظرتان نیاز خواهید داشت، می‌بایست از این الگو استفاده کنید اما این در حالی است که این تضمین باید وجود داشته باشد تا قبل از آنکه آن آبجکت مورد استفاده قرار گیرد، اصطلاحاً Initialize شده باشد.

اما تجربه نشان داده است که این نوع دیزاین پترن (الگوی طراحی) بیش از آنکه مفید واقع گردد، باعث دردسر خواهد شد چراکه توسعهٔ کد در آینده را دچار مشکل می‌کند!

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

نکتهٔ دیگری که در ارتباط با الگوی طراحی سینگلتون وجود دارد این است که این الگو دیپندنسی‌هایی (Dependency یا وابستگی) میان ماژول‌های مختلف پروژه‌ٔ شما به صورت انتزاعی ایجاد می‌کند و همین مسأله مشکل‌زا خواهد شد چرا که از یک سو این وابستگی‌ها خیلی به‌وضوح قابل مشاهده نیستند و از سوی دیگر بخش‌های مختلف سورس‌کد را به یکدیگر وابسته می‌سازند و همین مسأله منجر به این خواهد گشت که در آینده به‌سادگی نتوانیم از سورس‌کد خود در سایر پروژه‌ها استفاده کنیم.

چنین وابستگی‌هایی همچنین منجر به این خواهند شد که تست کردن نرم‌افزار با Unit Test که نیازمند وابستگی حداقلی مابین اجزای مختلف سورس‌کد است هم با مشکل مواجه شود.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تا حد ممکن دست به اختراع مجدد چرخ نزنید!

شاید وقتی پای توسعهٔ نرم‌افزار به میان می‌آید بارهاوبارها شنیده باشید که «تا حد ممکن باید از کدهای موجود استفاده کرد و اختراع مجدد چرخ کار احمقانه‌ای است!» حال ممکن است این سؤال پیش بیاید که چرا در دنیای توسعهٔ نرم‌افزار دوباره‌ کاری این‌قدر بد دیده می‌شود؟ پاسخ به این سؤال و سؤالات دیگری از این دست بسیار ساده است و آن‌ هم چیزی نیست جز این که کدهای موجود کار می‌کنند و در یک کلام، آزمون خود را پس داده‌اند.

اختراع مجدد چرخ صرفاً به این مسأله اشاره نمی‌کند که چگونه کدی بزنیم که نیاز ما را مرتفع سازد بلکه دارای ریزه‌کاری‌های بسیاری است که اگر ساده به این قضیه نگاه کنیم، شاید هیچ‌وقت متوجه آن‌ها نشویم! به‌طور مثال، سیستم‌هایی که پیش از این نوشته شده‌اند به‌طور کامل تست شده و توسط صدها دولوپر مورد استفاده قرار می‌گیرند و این درحالی است که به غیر از این‌ که کد کار می‌کند، در مورد مسائل فنی‌تر همچون پرفورمنس، معماری ساخت، الگوهای طراحی، توسعه‌پذیری و بسیار مسائل دیگر هم روی آن‌ها فکر شده است.

وقتی دولوپری قصد دارد دست به اختراع مجدد چرخ بزند و این درحالی است که در مورد مسائل پیچیدهٔ توسعه‌ٔ نرم‌افزار -همچون مواردی که در بالا بدان‌ها اشاره شد- آگاهی ندارد، نتیجه این شده که نرم‌افزاری تولید می‌شود که کار می‌کند و نیازهای خود دولوپر یا مشتری‌اش را مرتفع می‌سازد اما به احتمال زیاد در آینده زمانی‌که بار زیادی روی نرم‌افزار بیاید، نیاز به توسعه یا ریفکتورینگ آن باشد یا قرار باشد با دیگر نرم‌افزارها ادغام شده و دیگر مسائلی از این دست، به مشکل خواهد خورد.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: تعاملات اجتماعی کلید موفقیت است!

آدم‌ها با کمک دیگر آدم‌ها برای آدم‌های دیگر کدنویسی می‌کنند! شاید چنین جمله‌ای در نگاه اول کمی عجیب به‌نظر برسد، اما واقعیت دارد. درواقع، این جمله تأکیدش برروی ارتباط افراد با یکدیگر و کار گروهی است.

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

با این حال، برخی از دولوپرها را می‌بینیم که به‌نوعی از جامعه بریده شده و در انزوا کد می‌زنند و این درحالی است که دیگر دولوپرهایی که اجتماعی‌تر بوده،‌ به کار تیمی اعتقاد دارند و قبل از آن‌که برنامه‌نویس باشند، یک «موجود اجتماعی» هستند می‌توانند علاوه‌بر زندگی شخصی، در حرفهٔ برنامه‌نویسی‌شان نیز بیشتر پیشرفت کنند.

به‌طورکلی، دولوپرهایی که در پروژه‌های اپن‌سورس شرکت می‌کنند، در رویدادهای کدنویسی مشارکت دارند و دانسته‌های خود را با دیگر دولوپرهای غالباً تازه‌کار به اشتراک می‌گذارند، وبلاگ‌نویسی می‌کنند و به هر شکلی به تعامل با دیگر افراد می‌پردازند، تأثیر به‌مراتب بیشتری در صنعت نرم‌افزار می‌توانند داشته باشند.

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

درنتیجه، همواره به‌خاطر داشته باشیم که در صنعت توسعهٔ نرم‌افزار تعملات اجتماعی همچون هر حرفه‌ٔ دیگری دارای اهمیت بسیار بالایی است؛ از تعامل ما مشتریان گرفته تا مدیر پروژه، تستر نرم‌افزار و دیگر دولوپرها، همواره می‌بایست روی مهارت ارتباطات و مذاکره کار کرده و در این حوزه هم علاوه بر مهارت‌های کدنویسی تسلط یابیم.

*KhatKhati* · 18/9/20

نود و هفت چیزی که هر برنامه‌نویسی باید بداند: کدخوانی کنید!

اکثر دولوپرها از کدزنی لـ*ـذت می‌برند اما زمانی‌که پای کدخوانی به میان می‌آید، کمتر کسی را می‌توان یافت که از این کار لـ*ـذت ببرد! از آنجا که کدزنی به‌مراتب لـ*ـذت‌بخش‌تر از کدخوانی است و همچنین فرایند کدخوانی کاری سخت، طاقت‌فرسا و گاهی‌اوقات غیرممکن است، دولوپرها معمولاً تمایلی به انجام این کار ندارند مگر آن‌که مجبور شوند!

به‌عنوان یک قانون کلی، معمولاً خواندن کدهایی که توسط دیگر دولوپرها نوشته شده است سخت است البته این بدان معنا نیست که دیگر دولوپرها کار خود را بلد نیستند بلکه این سختی بدین دلیل است که هیچ ۲ دولوپری همچون یکدیگر به یک Problem (مسأله) به شکلی یکسان نگاه نکرده و مشابه یکدیگر آن‌را حل نمی‌کنند.

آیا کدخوانی منجر به بهبود کدنویسی می‌شود؟
وقتی سورس‌کدی را می‌خوانید، همواره این سؤال را از خود بپرسید که آیا این فرایند راحت است یا دشوار؟ اگر پاسخ به چنین سؤالی «دشوار» بود،‌ بایستی بیابید که دلیل اصلی دشواری کدخوانی چیست، آیا فرمت‌ سورس‌کد مناسب نیست یا نامگذاری کلاس‌ها، متدها، متغیرها و … نامناسب است و یا این که زبان برنامه‌نویسی مدنظر به‌طورکلی دارای سینتکسی دشوار است!

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

اگر هم خواندن سورس‌کدی را «راحت» یافتیم، بازهم درس‌هایی می‌توان از آن آموخت. شاید از دیزاین پترنی استفاده شده که تاکنون از آن مطلع نبوده‌اید، شاید فانکشن‌ها کوتاه‌تر به‌همراه نامگذاری بهینه‌تری هستند و چیزهایی از این دست.

به‌طورکلی، پروژه‌های اپن‌سورس فراوانی را در گیت‌هاب و دیگر پلتفرم‌ها می‌توان یافت که نمونه‌های خوبی از کدنویسی حرفه‌ای هستند که با دنبال کردن استراتژی‌های چنین دولوپرهایی، می‌توانیم خود را به یک Role Model برای دیگر دولوپرهای تازه‌کار مبدل سازیم.

جالب است بدانید کدخوانی سورس‌کدهایی که چندین سال پیش نوشته‌ایم نیز می‌تواند درس‌های بسیاری برایمان به‌ ارمغان آورد بدین شکل که متوجه خواهید شد قدیمی‌ترین کدهایی که نوشته‌اید تحت هیچ عنوان مورد پسند شما -با استانداردهای کدنویسی کنونی‌تان- نیستند و گاهی‌اوقات هم اصلاً خوانا و قابل‌فهم نیستند!

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

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

*KhatKhati* · 18/9/20

نود و هفت چیزی که برنامه‌نویسی باید بداند: ماوس و کیبورد را کنار بگذارید!

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

دلیلی که پشت این قضیه نهفته این است که وقتی شما درحال کدنویسی هستید، بخش منطقی مغز شما (سمت چپ مغز) فعال بوده و بخش احساسی مغز (سمت راست مغز) غیرفعال؛ مادامی‌که بخش منطقی مغز -که از قضا مسئول یافتن راه‌کار یا رفع باگ است- استراحت کافی نداشته باشد، هرگز قادر به کمک برای یافتن راه‌کاری مناسب نیست!

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

به‌عنوان راه‌کاری عملی، می‌توان گفت که پس از گیر کردن در یافتن یک باگ و یا به‌طورکلی پس از چندین ساعت کدنویسی، کمی استراحت کردن شامل گوش دادن به موسیقی مورد علاقه،‌ نوشیدن چای یا قهوه و کارهایی از این دست می‌تواند انرژی مورد نیاز برای ادامهٔ کارمان را تأ‌مین سازد. به‌عبارت دیگر، گاهی‌اوقات بهترین روش حل مسأله، کنار گذاشتن ماوس و کیبورد است.

*KhatKhati* · 18/9/20

نود و هفت چیزی که برنامه‌نویسی باید بداند: از ورژن کنترل غافل نشوید!

یکی از نشانه‌های حرفه‌ای بودن در صنعت توسعهٔ نرم‌افزار، استفاده از Version Control است. گرچه درظاهر سوییچ کردن به ورژن کنترل کمی دشوار به‌نظر می‌آید اما پس از آن‌که مزایای چنین کاری بر دولوپرها -اعم از تازه‌کار و باتجربه- آشکار شد، ثابت می‌شود که یادگیری کار در چنین فضایی ارزشش را دارا است.

از جمله پلتفرم‌های ورژن کنترل رایج می‌توان به Git و SVN اشاره کرد(لازم‌ به‌ذکر است که گیت توسط لینوس توروالدز -خالق کِرنِل لینوکس- طراحی شده است و امروزه به‌عنوان معروف‌ترین و محبوب‌ترین سیستم کنترل نسخه شناخته می‌شود).

امروزه وب‌سایت‌های زیادی هم اقدام به ارائهٔ خدمات ورژن کنترل می‌کنند که از معروف‌ترین آن‌ها می‌توان به گیت‌هاب و گیت‌لـ*ـب اشاره کرد (برای آشنایی بیشتر با نحوهٔ عمل‌کرد ورژن کنترل، می‌توانید به مقالهٔ ورژن کنترل (Version Control) چگونه کار می‌کند؟ مراجعه نمایید).

زمانی که شما به ورژن کنترل مهاجرت می‌کنید، به‌سادگی می‌توانید به تاریخچه‌ای از تغییرات صورت گرفته در پروژه دسترسی یافته و مهم‌تر از آن، ببینید که کدام‌یک از اعضای تیم و در چه زمانی آن تغییرات را ایجاد کرده‌‌اند. باتوجه به این‌که کلیه‌ٔ تغییرات صورت گرفته در سورس‌کد، ریفکتورینگ‌ها، باگ فیکس‌ها و … تحت ورژن کنترل ذخیره می‌شوند، دولوپرها بدون هیچ‌گونه نگرانی و دغدغه‌ای می‌توانند دست به اعمال تغییرات در سورس‌کد پروژ‌هایش بزنند چراکه این اطمینان خاطر را دارند که نسخه‌های پیشین پروژه را ذخیره دارند.

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

علاوه‌بر این، در ورژن کنترل مفهومی داریم تحت‌عنوان Branch (برنچ یا شاخه) که بااستفاده از آن می‌توان نسخه‌هایی موازی از پروژه‌ای واحد ایجاد کرد مثلاً یکی تحت‌عنوان Development (توسعه) و یک یا تعدادی برنچ دیگر تحت‌عنوان Maintanance (نگهداری) بدین شکل که کدنویسی پروژه روی برنچ توسعه صورت می‌گیرد و چنانچه پس از اعمال تغییرات و یا افزودن فیچر جدید به پروژه و ریلیس کردن آن نرم‌افزار و برخورد کردن به مشکلی خاص، به‌سادگی و درصورتی‌که نیاز به نسخه‌های قبلی باشد، می‌توان به یکی از برنچ‌های نگهداری مراجعه کرد.

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

زمانی که قصد دارید پروژه‌ای را روی یک سرویس ورژن کنترل -مثل گیت‌لـ*ـب که رایگان هم هست- قرار دهید، اصلاً خساست به‌خرج ندهید! به‌عبارت دیگر، تمامی فایل‌های پروژه از سورس‌کد گرفته تا تصاویر، مستندات، اسکمای دیتابیس + دیتای اولیه جهت تست، ابزارها و … را روی ورژن کنترل ارسال کنید (حتی توصیه می‌شود لایبرری‌ها که معمولاً به‌اصطلاح Ignore هستند و به‌صورت اتوماتیک روی سرور ارسال نمی‌شوند را هم آپلود کنید). با اتخاذ چنین رویکردی، این اطمینان حاصل می‌شود که همواره نسخه‌ای کامل از پروژه به‌صورت بکاپ در اختیار خواهیم داشت (فرض کنیم که سیستم‌عامل خود را تغییر می‌دهیم و یا کلاً سیستم‌مان عوض می‌شود که بااستفاده از چنین رویکردی، به‌راحتی می‌توان کل پروژه را از پلتفرم ورژن کنترل مدنظر گرفته و به‌کار خود ادامه داد).

معرفی استراتژی‌های به‌منظور بهره‌وری بیشتر از Version Control
زمانی‌که شما به ورژن کنترل مهاجرت کردید و مزایای آن‌را درک نمودید، یکسری استراتژی‌ها و به‌اصطلاح Best Practice وجود دارد که چنانچه از آن‌ها پیروی کنید، می‌توانید اطمینان حاصل نمایید که از تمام پتانسیل یک سیستم ورژن کنترل استفاده می‌نمایید که عبارتند از:
- تغییرات اساسی در نرم‌افزار را در قالب یک Commit (کامیت) مجزا روی سرور بفرستید. چنانچه چند تغییر نامرتبط با یکدیگر را در قالب یک کامیت درنظر بگیرید، در آینده یافتن تاریخچهٔ پروژه کار دشواری خواهد شد.

- برای هر کامیت، توضیحاتی واضح و شفاف درنظر بگیرید (اگر هم این کار برایتان دشوار است، حداقل توضیح دهید که چه‌چیزی را تغییر داده‌اید). این دست توضیحات می‌توانند در آینده چنانچه نیاز به نسخه‌های قبلی نرم‌افزار شد، بسیار مؤثر واقع شوند.

- تحت هیچ عنوان کدی را قبل از تست کردن کامل و اطمینان حاصل کردن از این‌که نرم‌افزار به‌طور کامل کار می‌کند کامیت نکنید چراکه این‌کار در دراز مدت اعتبار شما در دید دیگر دولوپرهایی که روی پروژه کار می‌کنند را کم خواهد کرد.

خوش آمدید به رمان ۹۸ | بهترین انجمن رمان نویسی

ما را در شبکه‌های اجتماعی دنبال کنید

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

مدیر بازنشسته رمان ۹۸

ما را در شبکه‌های اجتماعی دنبال کنید

درباره ما

لینک‌های پیشنهادی رمان ۹۸

آمار آنلاین