اشتباهاتی که من به عنوان یک برنامه نویس تازه‌کار مرتکب شدم - بخش دوم

قبل از خواندن این مقاله حتما بخش اول یعنی اشتباهاتی که من به عنوان یک برنامه نویس تازه‌کار مرتکب شدم - بخش اول را مطالعه کنیدو

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

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

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

در بخش اول ۱۱ نکته را مورد بحث قرار دادیم. در اینجا به بخش دوم، و ۱۴ نکته بعدی می‌رسیم.

در بخش دوم این مقاله همراه ما باشید:

۱۲) عدم نوشتن آزمایش‌ها (testها)

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

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

شما یک انسان هستید. پس از هر بار تغییر کد، شما قرار است که آزمایش تمام اعتبارسنجی‌های موفق پیشین را فراموش کنید. کامپیوتر را مجبور کنید که این کار را برای شما انجام دهد!

اگر می‌توانید، با حدث زدن و طراحی اعتبارسنجی‌های خود حتی قبل از نوشتن کد شروع کنید. توسعه دهی آزمایش‌گرا (TDD = Testing-driven Developement) فقط نوعی اعتیاد نیست. این نوع توسعه دهی به طور مثبت نحوه فکر کردن شما درباره امکانات، و این که چگونه یک طراحی بهتر برای آن‌ها به ذهن شما رسید را تحت تاثیر قرار می‌دهد.

TDD برای هر کسی نیست و برای هر پروژه‌ای به خوبی کار نمی‌کند. اما اگر می‌توانید آن را به کار بگیرید، بهتر است همین کار را انجام دهید.

۱۳) فرض این که اگر یک کد کار می‌کند، پس این کد صحیح است

به این تابع که امکان sumOddValues (جمع مقادیر فرد) را پیاده‌سازی می‌کند، نگاهی داشته باشید. آیا چیز اشتباهی در آن وجود دارد؟

const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (currentNumber % 2 === 1) {
      return accumulator + currentNumber;
    }

    return accumulator;
  });
};
 
 
console.assert(
  sumOddValues([1, 2, 3, 4, 5]) === 9
);

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

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

TypeError: Cannot read property 'reduce' of undefined.

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

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

TypeError: Cannot execute function for empty list.

شاید به جای نمایش یک خطا، فقط باید تابع خود را به گونه‌ای طراحی کنید که ورودی‌های خالی را نادیده بگیرد و جمع «۰» را نمایش دهد. به هر حال باید کاری برای این موقعیت انجام شود.

- مشکل ۲: هیچ راهی برای مدیریت ورودی‌های نامعتبر وجود ندارد. اگر تابع با یک رشته، مقدار integer یا یک مقدار آبجکت به جای یک آرایه فراخوانی شد، چه اتفاقی باید بیفتد؟

حال این تابع این نتیجه را نمایش خواهد داد:

sumOddValues(42);

TypeError: array.reduce is not a function

خب، این نتیجه تاسف‌آور است؛ زیرا array.reduce قطعا یک تابع است.

از آنجایی که ما آرگومان تابع را array نامگذاری کردیم، هر چیزی که شما تابع را با آن فراخوانی کنید (در مثال بالا ۴۲)، به عنوان array در داخل تابع برچسب زده می‌شود. این خطا به سادگی می‌گوید که 42.reduce یک تابع نیست.

آیا می‌بینید که این خطا به چه صورت گیج کننده است؟ شاید یک خطای کاربردی‌تر به این صورت باشد:

TypeError: 42 is not an array, dude.

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

sumOddValues([1, 2, 3, 4, 5, -13]) // => still 9

خب، «-13» یک عدد فرد است. آیا این رفتاری است که می‌خواهید این تابع داشته باشد؟ آیا این تابع باید یک خطا را نمایش دهد آیا باید اعداد منفی را در جمع نهایی شامل باشد؟ یا باید به سادگی اعداد منفی را نادیده بگیرد؟ شاید درک کنید که این تابع باید sumPositiveOddNumber (جمع اعداد مثبت فرد) نامگذاری می‌شد.

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

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

sumOddValues([2, 1, 3, 4, 5]) // => 11

مقدار 2 در بالا در جمع نهایی شامل شده بود، در حالیکه نباید می‌شد.

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

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

۱۴) زیر سوال نبردن کد موجود

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

بدتر این که اگر در کد مورد نظر از روش‌های بدی استفاده شود، کدنویس تازه‌کار ممکن است وسوسه شود که آن روش بد را در جایی دیگر تکرار کند؛ زیرا آن را از چیزی که فکر می‌کرد یک کد خوب است یاد گرفته است.

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

شما به عنوان یک توسعه دهنده، باید فرض کنید که کد سندنگاری نشده‌ای که آن را درک نمی‌کنید، کاندیدایی برای بد بودن است. آن را زیر سوال ببرید.

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

۱۵) وسواس نسبت به بهترین شیوه‌ها

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

هیچ روشی به نام «بهترین روش» وجود ندارد. تنها برخی روش‌های خوب برای یک زبان برنامه‌نویسی مورد نظر وجود دارند.

برخی از چیزهایی که ما پیش‌تر به عنوان بهترین روش‌ها در زبان‌های برنامه‌نویسی می‌شناختیم، امروزه به عنوان روش‌های بد شناخته می‌شوند.

شما همیشه اگر زمان کافی را سرمایه‌گذاری کنید، می‌توانید روش‌های بهتری بیابید. دیگر نگران بهترین روش‌ها نباشید و بر روی کاری که بهتر می‌توانید انجام دهید تمرکز کنید.

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

۱۶) وسواس نسبت به کارایی

Donald Knuth، دانشمند علوم کامپیوتر آمریکایی در سال ۱۹۷۴ گفته است:

«بهینه‌سازی نابهنگام، ریشه تمام بدی‌ها (یا حداقل اکثر آن‌ها) در برنامه‌نویسی است.»

با این که برنامه‌نویسی از زمانی که Donald Knuth این جمله را بیان کرد تغییر زیادی کرده است، به نظر من این جمله همچنان هم یک نصیحت با ارزش است.

قانون خوب که باید درباره این مسئله به یاد داشته باشید، این است که: اگر نمی‌توانید مشکل کارایی مشکوک مربوط به کد را اندازه‌گیری کنید، برای بهینه‌سازی آن تلاش نکنید.

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

البته برخی بهینه‌سازی‌های واضح وجود دارند که شما همیشه باید قبل از نوشتن کد جدید آن‌ها را در نظر داشته باشید. برای مثال در Node.js، به شدت مهم است که شما حلقه رویداد را بیش از حد پر نکنید، یا این که stack را مسدود نکنید. این نمونه‌ای از بهینه‌سازی زود هنگام است که باید همیشه در ذهن داشته باشید. از خود بپرسید: آیا کدی که من به آن فکر می‌کنم، stack را مسدود خواهد کرد؟

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

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

۱۷) هدف قرار ندادن تجربه کاربر نهایی

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

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

۱۸) عدم انتخاب ابزار مناسب برای کار مورد نظر

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

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

تکیه کردن به معروفیت یک ابزار به جای این که چقدر برای مشکل مورد نظر مناسب است، نشانه‌ای از کد یک فرد تازه‌کار است.

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

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

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

۱۹) عدم درک این که مشکلات کد، باعث بروز مشکلات در داده‌ها خواهند شد

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

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

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

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

خود را با محدودیتت‌های دیتابیس آشنا کنید و وقتی که ستون‌ها و جداولی را به دیتابیس خود اضافه می‌کنید،‌ از آن‌ها استفاده کنید:

• یک محدودیت NOT NULL (غیر خالی) بر روی یک ستون، به این معنی است که مقادیر خالی برای آن ستون رد خواهند شد. اگر برنامه شما وجود یک مقدار را برای آن فیلد تصور می‌کند، منبع آن باید به عنوان غیر خالی در دیتابیس شما تعریف شده باشد.
• یک محدودیت UNIQUIE (خاص) بر روی یک ستون، به این معنی است که ستون مورد نظر نباید مقادیر تکراری در کل جدول داشته باشد. برای مثال، این مورد برای نام‌های کاربری یا فیلدهای ایمیل در یک جدول متشکل از کاربران عالی است.
• یک محدودیت CHECK (بررسی)، یک عبارت سفارشی است که باید به صورت true ارزیابی شود تا داده مورد نظر پذیرفته شود. برای مثال اگر شما یک ستون درصد معمولی دارید که مقدارش باید بین ۰ تا ۱۰۰ باشد، می‌توانید از یک محدودیت CHECK بر روی آن استفاده کنید.
• یک محدودیت FOREIGN KEY (کلید خارجی) به این معنی است که مقادیر ستون باید با مقادیر موجود در ستون‌های جدول دیگر تطابق داشته باشند، که معمولا یک کلید اصلی (primary key) است.

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

۲۰) اختراع مجدد چرخی که از قبل اختراع شده بود (تکرار کارهای قدیمی)

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

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

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

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

۲۱) رفتار نامناسب در قبال بررسی‌های مجدد کد

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

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

شما برای همیشه یک کد آموز هستید. باید این مسئله را قبول کنید. اکثر بررسی‌های کد به شما چیزی را یاد خواهند داد که از پیش نمی‌دانستید. آن‌ها را به عنوان یک منبع یادگیری دسته‌بندی کنید.

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

۲۲) عدم استفاده از کنترل منبع

گاهی اوقات تازه‌کاران قدرت یک سیستم کنترل منبع را دست کم می‌گیرند، و منظور من از «خوب» در واقع Git است.

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

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

۲۳) استفاده بیش از حد از state به اشتراک گذاشته شده

این نکته هم درباره برنامه‌نویسی تابعی علیه الگوهای دیگر نخواهد بود. این موضوع، برای یک مقاله دیگر است.

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

چیزی که من به عنوان یک برنامه‌نویس تازه‌کار متوجه آن نشدم، این است که هر متغیری که ما تعریف می‌کنیم، نمایانگر یک state به اشتراک گذاشته شده است. این متغیر داده‌هایی را نگه می‌دارد که می‌توانند توسط تمام عناصر در scope مشابه آن متغیر تغییر یابند. هر چه scope مورد نظر globalتر باشد، چرخش این state به اشتراک گذاشته شده هم بدتر است. سعی کنید stateهای جدید را در scopeهای کوچک نگه دارید و مطمئن شوید که آن‌ها نشتی ندارند.

مشکل بزرگ مربوط به state به اشتراک گذاشته شده، وقتی که شروع می‌شود که چندین منبع باید آن state را به صورت همزمان و در حلقه رویداد مشابه (در محیط‌های بر پایه رویداد) تغییر دهند.

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

۲۴) رفتار نامناسب در قبال خطاها

خطاها یک چیز خوب هستند. معنای آن‌ها این است که شما دارید پیشرفت می‌کنید.

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

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

برخی خطاها باید به exception ارتقا یابند. Exceptionها، خطاهای تعریف شده توسط کاربری هستند که باید برای آن‌ها برنامه‌ریزی کنید. برخی خطاها را باید تنها گذاشت. آن‌ها باید برنامه را crash کنند و باعث خروج آن شوند.

۲۵) عدم استراحت

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

این یک مقاله طولانی بوده است، شما به یک استراحت نیاز دارید.

منبع