در این مقاله اختصاصی از وبسایت راکت قصد داریم در ارتباط با نکاتی صحبت کنیم توسعه‌دهندگان مخصوصا افراد مبتدی باید به خوبی آن‌ها را بدانند.
نکته ۱: به تعداد خط کدها توجه نکنید
به عنوان یک توسعه‌دهنده ممکن است در طول روز و مکالماتی که دارید چه در شبکه‌های اجتماعی و چه در دنیای واقعی، حرف‌های باورنکردنی در ارتباط با تعداد خط کدهای یک پروژه را بشنوید. هیچکدام از آن‌ها را جدی نگیرید! تعداد خط کدها یک فاکتور مضحک برای عالی بودن یک پروژه است. این درست مانند آن است که بگوییم یک کتاب هر چقدر تعداد صفحه بیشتری داشته باشد کتاب بهتری خواهد بود.
بلعکس، در حالت‌هایی پیش خواهد آمد که کم بودن تعداد خط کدها نشان خوب بودن پروژه است چرا که خواندن آن به زمان کمتری نیاز داشته و همچنین دیباگ کردن آن راحت‌تر خواهد بود. اگر دوست دارید تا در ارتباط با فاکتورهایی که برای یک نرم‌افزار عالی نیاز دارید را مشاهده کنید بهتر است به لیست زیر یک نگاهی بیاندازید:
- کدهای نوشته شده باید سازگار و همخوان باشند
- کدهای نوشته شده باید بتوانند خودشان را توضیح دهند
- کدهای نوشته شده باید به خوبی مستندسازی شده باشند
- کدهای نوشته شده باید از ویژگی‌های پایدار مدرن استفاده کنند.
- کدهای نوشته شده باید در صورت امکان ساده بوده و از پیچیده بودن فاصله بگیرند
- کدهای نوشته شده باید در امر اجرا بهینه باشند
بنابراین اگر اپلیکیشن شما فارغ از تعداد خط کد و فاکتورهای بی معنی دیگری بتوانند موارد بالا را پیاده‌سازی بکنند می‌توان به عنوان اپلیکیشنی مناسب از آن یاد کرد.
نکته ۲: زبان برنامه‌نویسی «خوب» و «بد» وجود ندارد
مطمئنا با چنین مکالماتی آشنایی دارید:
زبان برنامه‌نویسی C بهتر از X است
پایتون بهتر از PHP است
Haskell بهتر از Java عمل می‌کند
و... .
شما در حال پیاده‌سازی یک اپلیکیشن هستید نه خرید یک موبایل! البته حرف من را به اشتباه برداشت نکنید، همه ما باید این قضیه را قبول کنیم که زبان‌ها با همدیگر متفاوت بوده و استفاده‌پذیری‌های مختلفی دارند. اما این سخن که برخی از زبان‌های بی استفاده و برخی دیگر بسیار خوب هستند حرف درستی نیست. هر کدام از زبان‌ها ویژگی‌های منحصر به فرد و البته مشترکی نیز دارند. اما در نهایت شما باید این واقعیت را قبول کنید که تمام آن‌ها ابزارهایی هستند تا به ما در ایجاد یک ویژگی یا اپلیکیشن کمک کنند. شما در این روال باید در نظر داشته باشید که هر ابزار ویژگی خاص خود را دارد برای مثال شما نمی‌توانید با استفاده از یک چکش پیچ لپ‌تاپ‌تان را باز کنید و یا با یک پیچ‌گوشتی نمی‌توان یک میخ را به دیوار کوبید (البته ممکن است این مورد آخر را انجام داد اما به نظر نمی‌رسد که در حضور چکش انجام چنین کاری با یک پیچ‌گوشتی کار درستی باشد).
قبل از آنکه در ارتباط با شیوه ارزیابی زبان‌های برنامه‌نویسی صحبت کنم باید بگویم که در حالت‌های کمی پیش خواهد آمد که انتخاب زبان واقعا اهمیت داشته باشد. حالت‌هایی وجود دارد که مطمئنا شما نمی‌توانید آن‌ها را با تمام زبان‌های برنامه‌نویسی پیش ببرید (مانند همان باز کردن پیچ لپ‌تاپ با چکش!). برای مثال اگر شما قصد کار روی داده را دارید و می‌خواهید یک داده‌کاو باشید زبان‌هایی که باید انتخاب کنید شامل پایتون، R، اسکالا، جاوا و چند مورد دیگر خواهند بود. جدای از این موارد به نظر نمی‌رسد که استفاده از ابزارهای دیگر کار درستی باشد.
با این حال برای انتخاب یک زبان برنامه‌نویسی می‌توانید فاکتورهای زیر را در نظر بگیرید:
- میزان موجود بودن منابع آنلاین برای آن
- سرعت توسعه ابزار در آن
- میزان توانایی در دیباگینگ
- کیفیت و زیاد بودن اکوسیستم پکیج‌های آن
- ویژگی‌های آن از نظر کارایی
- قابلیت استخدام شدن توسط آن در شرکت‌های مختلف
نکته ۳: خواندن کدهای دیگران سخت است
برای زمان طولانی فکر می‌کردم که من تنها کسی هستم که در خواندن کدهای دیگران مشکل دارم. با این حال بعد از گذشت زمان متوجه شدم که تقریبا اغلب توسعه‌دهندگان با این مشکل سر و کار داشته و هر روز نیز تلاش می‌کنند تا این قابلیت را در خود توسعه دهند. خواندن کدهای دیگران تقریبا شبیه به خواندن یک مقاله به زبان خارجی است. حتی اگر شما شروع به خواندن کدهای مربوط به زبان برنامه‌نویسی بکنید که با آن آشنایی دارید باز هم روال کار برای‌تان سخت خواهد بود. با این حال در طول این مدت من به نکاتی برخوردم که دانستن آن‌ها در این پروسه به شما کمک خواهد کرد.
مطالعه کدهای دیگران به توانایی کدنویسی شما نیز کمک خواهد کرد. در چند سال اخیر من برای اینکه این توانایی را در خود تقویت کنم مخازن مختلف گیت‌هاب را مطالعه کردم. باید بگویم که با مطالعه هر کدام از این مخازن من موضوعات جدیدی را یاد می‌گیرد. استفاده از مخازن گیت به دلایل زیر می‌تواند بهترین راهکار شما برای تقویت این قابلیت در شما باشد:
- می‌توان هر زمان از آن‌ها استفاده کرد و آن‌ها را برای یک جلسه تمرینی مورد استفاده قرار داد. هر زمان هم که دوست داشتید می‌توانید در بهتر کردن آن‌ها مشارکت داشته باشید.
- در مطالعه مخازن گیت‌هاب نیاز است که به جزئیات کار دقت کنید. این کار باعث می‌شود تا به صورت تمرینی توانایی بالایی در مطالعه کدها را داشته باشید.
- مخازن گیت‌هاب عمدتا به صورت یکسری پروژه خواهند بود از این رو جدای از کدها می‌توان با ساختار پروژه و فایل‌های آن نیز به خوبی آشنا شوید.
نکته 4: شما هیچگاه کدهای «بی نقص» نخواهید نوشت
قبل از آنکه وارد یک تیم برنامه‌نویسی شوم به مدت ۴ سال یک «گرگ تنها» بودم. برای بیشتر اوقات در این ۴ سال فکر می‌کردم که تمام برنامه‌نویسانی که در صنعت برنامه‌نویسی حضور دارند کدهای عالی و بدون نقصی را می‌نویسند. این موضوع برای من بسیار ناخوشایند بود چرا که در تمام آن ۴ سال نتوانستم کدهای بی نقصی و کاملا ایده‌آلی را بنویسم. تا اینکه وارد یک تیم برنامه‌نویسی شدم و در آنجا مشاهده کردم که هیچکسی نمی‌تواند این کار را انجام دهد. کدها در زمان نوشتن و اجرا کردن عالی بودند اما زمانی که برای بازبینی ارسال می‌شدند متوجه می‌شدیم که راه‌های بهتری نیز برای پیاده‌سازی یک تابع خاص وجود داشت که ما از آن استفاده نکردیم!
با این حال ناامید نشوید، این موضوع را نیز در نظر بگیرید که در بیشتر اوقات کار اشتراکی و تیمی می‌تواند نتیجه بهتری را برای شما حاصل کند. در کنار این موارد همواره به انتقادات گوش داده و سعی کنید اگر موارد منطقی را شنیدید آن‌ها را عملی نمایید.
کار به نکته 5: عنوان یک برنامه‌نویس به معنای ۸ ساعت کار در روز نیست
این موضوع که برنامه‌نویسان حتما به صورت مرتب ۸ ساعت در روز و ۵ روز در هفته کدنویسی می‌کنند مسئله مضحکی است. برنامه‌نویسی بیشتر از آنکه یک کار مانند کارمند بانک و امثال این موارد باشد یک «عشق» است. با این حال برنامه‌نویسی نیازمند تمرکز بوده و برای کار کردن به عنوان یک برنامه‌نویس حتما نیازی نیست که یک زمان خاص را مشغول باشید.
در حقیقت این حالت در بین برنامه‌نویسان خیلی رایج است که به یک ساعت کاری خاص متعهد نبوده و براساس کارهای خودشان پیش می‌روند. البته این بدان معنا نیست که برنامه‌نویسان بدقول هستند و نمی‌توانند به یک موضوع متعهد باشند اما در نظر داشته باشید که آن‌ها معمولا مغز منعطفی برای کار کردن دارند.
برنامه‌نویسی چیزی فراتر از امضا کردن یکسری کاغذ و جواب دادن به یکسری مشتری است. بنابراین باید به شکلی متفاوت با یک تیم برنامه‌نویسی رفتار کرد. البته این مسئله‌ای است که برخی از مدیران پروژه به آن توجه نکرده و در نتیجه محیط چندان خلاقانه‌ای نیز ایجاد نمی‌کنند.
در پایان
این موارد نکاتی بودند که خیلی دوست داشتم کسی به من قبل از پی بردن به آن اطلاع بدهد. شاید با دانستن آن‌ها می‌توانستم زمان بیشتری را ذخیره کنم و پیشرفت بیشتری داشتم. با این حال به نظرم در نهایت پی بردن به قضیه از همه چیز مهمتر است که باید بگویم به آن رسیدم.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید