چند توصیه به برنامه‌نویسان و مدیران پروژه

نویسنده : سید ایوب کوکبی ۲۱ خرداد ۱۳۹۸
چند توصیه به برنامه‌نویسان و مدیران پروژه

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

نوشتن کدِ درست آسان است

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

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

بنابراین چالش اصلی در برنامه‌نویسی نوشتن کدهایی خوانا و قابل نگهداری است.

نوشتن کدِ خوب سخت است

با این حساب چطور باید کدی بنویسیم که در عین درستی خوانایی مناسبی داشته باشد و از Best Practiceها نیز پیروی کرده باشد. ابتدا بررسی کنیم منظور از کد خوب چیست؟ در ادامه شاخصه‌های یک کدِ خوب را معرفی می‌کنیم.

کدِ خوب قابل فهم است

کدِ خوب کدی است که همکاران شما (همکاران فعلی و آینده) و حتی خودتان در زمان آینده به راحتی بتوانید بفهمید. کدهایی که چنین ویژگی داشته باشند قطعاً کار توسعۀ نرم‌افزار را سرعت می‌بخشند. به عنوان مثال می‌توانید بهبود کد را با نام‌گذاری درست متغیرها، توابع یا خطاها شروع کنید. این کارِ به ظاهر ساده تأثیر بسیار مطلوبی روی خوانایی کدها دارد. از همه بدتر زمانی است که تابعی مطابق نام‌گذاری‌اش عمل نکند. موضوع بعدی در درک آسان کد، انتخاب معماری مناسب است. معماری کد، هم در سطح کدها مطرح می‌شود (MVVM, MVC و …) و هم در سطح نام‌گذاری فایل‌ها و تقسیم‌بندیشان در فولدرها مختلف. فایل‌ها را طوری دسته‌بندی کنید که با یک نگاه بتوان به ساختار کلی پروژه پی برد.

بخوانید  برنامه‌نویسان حرفه‌ای چه می‌کنند

کدِ خوب خطاها را به خوبی مدیریت می‌کند

کدِ خوب با هر خطایی از کار نمی‌افتد. خطاها را باید مدیریت یا اصطلاحاً هندل کرد. خطا جزئی از نرم‌افزار است و این ماهیت طبیعی هر برنامه‌ای است. ممکن است کاربر طوری از برنامه استفاده کند که پیش‌بینی آن را نکرده‌اید. مثلاً در یک فیلد متنی حداکثر طول رشته را محدود نکرده باشید و کاربر رشته‌ای بسیار طولانی وارد کند که برنامه قادر به استفاده از آن نباشد. یا داده‌ها در فرمتی وارد برنامه شوند که برنامه قادر به شناسایی آن نباشد. یا حتی مشکلات خارج از کنترل برنامه، مثلاً کمبود حافظه، خطاهای شبکه، خرابی دیسک و … .

کدِ خوب برای هر خطایی پیش‌بینی لازم را کرده است، مثلاً در هنگام اتصال به دیتابیس، عملیات ارتباط با دیتابیس را باید در یک try-catch قرار داد تا در صورت بروز خطای ارتباطی برنامه از کار نیفتند و به جای آن پیامی صادر شود که مثلاً دوباره تلاش کنید یا به خاطر فلان خطا فعلاً امکان ارتباط با دیتابیس میسر نیست. همۀ خطاها قابل پیش‌بینی نیستند ولی با لاگ کردن خطاهای پیش‌بینی نشده می‌توانید متوجه علت بروز خطا شوید. به این نکته هم توجه داشته باشید که هیچ گاه در سطح بالا از یک try-catch استفاده نکنید. استثناها را از پایین‌ترین لایه‌ها دریافت و به صورت طبقه‌بندی شده لاگ کنید تا دقیقاً ریشۀ مشکل را شناسایی کنید.

کدِ خوب مستندسازی شده است

برای صرفه‌جویی در زمان خودتان هم که شده کدها را مستندسازی کنید. کدی که هیچ توضیحی ندارد قطعاً سوالات زیادی روانۀ شما خواهد کرد. به جای توضیح عملکرد کد روی چرایی آن تمرکز کنید. مثلاً بیان کنید که چرا از فلان کد استفاده کرده‌اید. فایل Readme و دیاگرام‌های معماری و کامنت‌ها را همیشه به روز نگه دارید.

بخوانید  چه زمانی کد ننویسیم؟

کدِ خوب قابل نگه‌داری است

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

چگونه کدِ خوب بنویسیم

حالا که فهمیدید کدِ خوب چیست چگونه باید دیگران را در نوشتن کدِ خوب یاری کنیم؟ با پیروی از دو مکانیزم می‌توان به این مهم دست یافت: درک حدود پروژه و بازبینی کدها.

درک حدود پروژه

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

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

به محض تعیین اسکوپ پروژه، می‌توانید سراغ بحث‌های فنی بروید؛ چیزهایی مثل نامِ کامپوننت‌ها، API Routes، فرمت داده‌ و … . نیازی نیست در این مقطع، وقت زیادی برای جزئیات مثلاً نام‌گذاری فانکشن‌ها صرف کنید. بیشتر باید روی معماری کلی برنامه و چگونگی ارتباط بخش‌های مختلف با یکدیگر بحث کنید. این کار باعث می‌شود تا برخورد سلیقه‌ای به حداقل برسد و خوانایی و کیفیت کد افزایش یابد.

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

بازبینی کد

در git flowهای معمول، هر فیچر جدید در یک شاخۀ فیچر اضافه می‌شود و پول ریکوئست‌ها قبل از مرج کردن کدها در شاخۀ اصلی پروژه صورت می‌گیرد. بازبینی کد به فرایند بررسی تغییرات کد گفته می‌شود (یعنی git diffs). اعضای تیم می‌توانند دربارۀ وضوح و بهینگی کدها بحث کنند. این کار در ابتدا ممکن است غیرضروری و زمان‌بر به نظر برسد ولی به مرور متوجه خواهید شد که در بلندمدت باعث صرفه‌جویی زمان خواهد شد.

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

دردسرهای کار تیمی

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

سید ایوب کوکبی

نویسنده و مترجم...

مطالب مرتبط

0 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *