۱۰ عادت بدی که دیگر توسعه‌دهندگان را فراری می‌دهد!

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

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

۱. نام گذاری های آشفته

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

حالت اول، رمزنویسی ظاهری و نام گذاری متغیر ها است. چرا تا زمانی که می توانیم نام یک متغیر را handleFormSubmit بگذاریم، آن را به شکل hndlfrmsub بنویسیم؟ اگر این کار را انجام بدهید توسعه دهندگان دیگر برای درک کد شما باید تمام سورس کد را از ابتدا مطالعه کنند تا بفهمند هر متغیر از کجا آمده است. این رفتار جدا از آزار و اذیتی که برای دیگر توسعه دهندگان دارد، زمان با ارزش تیم را نیز هدر می دهد.

حالت دوم، رمزنویسی معنایی است. مثلا فرض کنید یک کوئری به پایگاه داده ارسال می کنید که کاربرانی را دریافت می کند که هنوز حساب کاربری شان تایید نشده است. نام متغیری که نتایج در آن ذخیره می شود را چه می گذارید؟ یک برنامه نویس حرفه ای نامی شبیه به uncofirmedUsers (به معنی «کاربران تایید نشده») را انتخاب می کند در حالی که برنامه نویسان مبتدی و به اصطلاح «باحال!» نامUsrs یا users را انتخاب می کنند که به معنی «کاربران» است. طبیعتا برنامه نویسان دیگر ممکن است متوجه این موضوع نشوند و تصور کنند شما در حال دریافت تمام کاربران از پایگاه داده هستید و بر همین اساس کدی بنویسند که تمام برنامه را بهم بریزد.

مسئله بعدی در دسته نام گذاری، رعایت casing یا بزرگی و کوچکی حروف است. شما باید طبق همان casing ای عمل کنید که کل تیم قبول کرده اند. مثلا اگر به زبان جاوا اسکریپت کدنویسی می کنید باید با camelCase پایبند باشید نه اینکه در هر بخشی از برنامه به یک شکل خاص عمل کنید. موضوع دیگری نیز وجود دارد و آن درک درست از casing است. نام idUser مشکلی ندارد اما اگر همان را به شکل IDUser بنویسید ممکن است باعث ایجاد ابهام شود چرا که خواندن آن دشوار است.

۲. کدنویسی پیچیده

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

یک مثال ساده از این رفتار، استفاده از شرط های تو در تو و ترکیب آن با اپراتور های عجیب و غریب است. مثلا برای دریافت تاریخ در جاوا اسکریپت می توانید از دستور ()Date.now استفاده کنید اما برخی افراد اصرار دارند از دستوراتی شبیه به ()new Date+ استفاده کنند. هر دو دستور دقیقا یک کار را انجام می دهند اما همه با حالت دوم آشنا نیستند. مثال دیگر استفاده از توابع بازگشتی یا recursion در مواقعی است که اصلا نیازی به آن نداریم.

۳. تقسیم بیش از حد پروژه

نوشتن کدهای تمیز و خوانا یک استاندارد عالی برای هر توسعه دهنده ای است اما هر چیزی حد و حدودی دارد! یکی از تکنیک های نوشتن کدهای خوانا این است که فایل های بسیار بزرگ را به فایل های کوچک تر تقسیم کنیم اما منظورمان از «خیلی بزرگ» واقعا «خیلی بزرگ» است! اگر فایل شما فقط ۳۰۰ خط است هیچ نیازی به شکستن آن به فایل های کوچک تر نیست.

مشکل اینجاست که تقسیم هر فایل به فایل های کوچک تر باعث تولید دستورات import و require زیادی می شود. اگر شما از توسعه دهندگان وب (مثلا جاوا اسکریپت یا PHP) باشید حتما می دانید که در هر پروژه ای تعداد زیادی import و require خواهیم داشت بنابراین دو برابر کردن تعداد این دستورات با تقسیم پروژه اصلا کار عاقلانه ای نیست. اگر توسعه دهنده دیگری بخواهد یک ویژگی ساده در کد شما را بخواند مجبور خواهد بود بین ده فایل جا به جا شده و ده دستور import مختلف را مطالعه کند تا فقط متوجه بشود یک متغیر ساده در کد شما از کجا آمده است!

فرض کنید صفحه یا کامپوننتی به نام UserSubscriptions (عضویت کاربر در بخش خاصی از برنامه) در برنامه react ای خود دارید. آیا درست است که یک فایل جداگانه به نام calculateTimeToSubscriptionEnd را بسازیم که زمان عضویت کاربر را محاسبه می کند؟ آیا درست است که این فایل را که یک کد منطقی و عملیاتی است را درون پوشه مربوط به آن کامپوننت خاص قرار بدهیم؟ ساخت چنین توابع کمکی باعث دردسر های زیادی می شود و بهتر است تحت هر شرایطی از آن ها دوری کنید.

۴. کد یکسان، رفتار متفاوت

یادتان باشد که برنامه نویسی یک هنر است اما ما کار هنری نمی کنیم! قلب برنامه نویسی بر اساس منطق بنا شده است بنابراین همه چیز باید از نظر عقلی یکپارچه باشد. بسیاری از برنامه نویسان مبتدی کدهایی می نویسند که در ظاهر یکسان هستند اما کار متفاوتی انجام می دهند. رایج ترین مثال این دسته از مشکلات، تعریف دو تابع با نام های یکسان یا شبیه به هم است که دو کار متفاوت را انجام می دهند. مثلا توابع createUser و generateUser را در نظر بگیرید. تابع اول یک کاربر را در پایگاه داده ایجاد می کند در حالی که تابع دوم یک کاربر جعلی را در مموری ایجاد می کند تا کدهایمان را تست کنیم.

یکی دیگر از جنبه های این رفتار بد، دریافت پارامتر های توابع  به شکل های مختلف است. مثلا در یک تابع نام کاربری و رمز عبور را به صورت دو پارامتر جداگانه دریافت می کنید اما در یک تابع دیگر آن ها را به صورت یک پارامتر واحد (یک شیء) دریافت خواهید کرد. مثلا فرض کنید یک API برای سایت خود نوشته اید که در آن یک endpoint برای دریافت کاربران وجود دارد اما در بخش پنل ادمین یک endpoint دیگر برای دریافت کاربران با داده های حساس وجود دارد. داده های مورد نیاز برای دریافت یک کاربر باید در هر دو endpoint یکسان باشد؛ مثلا هر دو id کاربر را دریافت کنند، نه اینکه یکی id کاربر و دیگری ایمیل او را دریافت کند.

۵. دستگاه فتوکپی

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

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

۶. قالب بندی کدها

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

به کد ساده زیر توجه کنید:

<!DOCTYPE html>

<html>

<body>




<h2>JavaScript Arrays</h2>




<p>The Array.forEach() method calls a function for each element in an array.</p>




<p id="demo"></p>




<script>

let text = "";

const fruits = ["apple", "orange", "cherry"];

fruits.forEach(myFunction);




document.getElementById("demo").innerHTML = text;




function myFunction(item, index) {

  text += index + ": " + item + "<br>";

}

</script>




</body>

</html>

این یک کد HTML ساده است که مقدار جاوا اسکریپت نیز دارد. تمام این کد جاوا اسکریپتی بدین شکل است که آرایه ای از سه عنصر داریم. بین این آرایه گردش کرده و سپس ایندکس هر عضو از آرایه را به همراه مقدارش درون متغیر text قرار می دهیم. در نهایت این مقدار را در صفحه نمایش می دهیم.

حالا همین کد را در یک خط می نویسیم:

<!DOCTYPE html><html><body><h2>JavaScript Arrays</h2><p>The Array.forEach() method calls a function for each element in an array.</p><p id="demo"></p><script>let text="";const fruits=["apple", "orange", "cherry"];fruits.forEach(myFunction);document.getElementById("demo").innerHTML=text; function myFunction(item, index){text +=index + ": " + item + "<br>";}</script></body></html>

خواندن این کد بسیار آزاردهنده است و باید چندین برابر زمان را صرف خواندن آن کنیم.

۷. بعدا تصحیح می کنم

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

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

۸. عدم تعامل با دیگر اعضای تیم

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

مشکل اصلی عدم تعامل و صحبت با دیگر اعضای تیم است که می تواند مشکلات مختلفی را به وجود بیاورد. به طور مثال سوال پرسیدن از اعضای تیم درباره مشکلات مختلف برنامه، علاوه بر بالا بردن مهارت شما به عنوان یک توسعه دهنده می تواند به یکپارچگی تیم کمک بزرگی کند. همچنین اگر بدون مشورت با دیگر اعضای تیم شروع به کدنویسی کنید احتمال دارد به مشکلات بزرگی برخورد کنید. به طور مثال تیم front-end و تیم back-end باید با هم ارتباط داشته باشند تا ساختار تبادلات داده را بدانند و کدها را طوری بنویسند که با کدهای دیگران تداخل پیدا نکند. اگر تیم front-end انتظار دریافت JSON داشته باشد اما تیم back-end کدهای HTML برایشان ارسال کند چطور؟ در این حالت باید زمان زیادی را صرف بازنویسی کدهایتان کنید.

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

۹. ننوشتن کد بد

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

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

۱۰. تملک عاطفی کدها

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

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

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

منبع: وب سایت tsh.io