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

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

*اشتباهات در اینجا به ترتیب خاصی ارائه نشده اند.

اشتباهات رایج برنامه نویسان مبتدی

نوشتن کد بدون برنامه ریزی

محتوای با کیفیت بالا به راحتی ایجاد نمی شود. نیاز به تفکر و تحقیق دقیق دارد. برنامه های با کیفیت بالا نیز از این قاعده مستثنی نیستند.

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

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

درست مثل اینکه قبل از گفتن هر چیزی که ممکن است پشیمان شوید باید فکر کنید ، قبل از رمزگذاری هر چیزی که ممکن است پشیمان شوید باید فکر کنید. همچنین کد نویسی راهی برای برقراری ارتباط با افکار شماست.

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

توصیه های جفرسون در مورد کدگذاری نیز صدق می کند:

هنگام بازبینی کد، قبل از بازنویسی یک خط، تا 10 بشمارید، اگر کد، تست ندارد تا 100سامر بونا

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

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

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

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

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

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

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

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

دست کم گرفتن اهمیت کیفیت کد

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

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

یکی از نقل قول های مورد علاقه من در مورد برنامه نویسی این است:

همیشه طوریکد بنویسید که گویا شخصی که در نهایت کد شما را نگهداری می کند یک روانی خشن است که می داند کجا زندگی می کنید.جان وودز

نصیحت درخشان جان!

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

1234tHIS is
  WAY MORE important
than
            you think

نکته ساده دیگر استفاده از خطوط طولانی است. خواندن هر چیزی فراتر از 80 کاراکتر بسیار دشوار است. ممکن است وسوسه شوید برخی از شرایط طولانی را در همان خط قرار دهید تا یک بلاک if-statement بیشتر دیده شود. این کار را نکنید. فقط هرگز از حد مجاز 80 کاراکتر عبور نکنید.

بسیاری از مشکلات ساده مانند اینها با استفاده از ابزارهای قالب بندی به راحتی برطرف می شوند. در JavaScript ، ما دو ابزار عالی داریم که کاملاً با هم کار می کنند: ESLint و Prettier. به خود لطف کنید و همیشه از آنها استفاده کنید.

در اینجا چند اشتباه دیگر مربوط به کیفیت کد وجود دارد:

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

1const answerToLifeTheUniverseAndEverething = 42;

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

اندازه گیری پیشرفت برنامه نویسی توسط خطوط کد مانند اندازه گیری پیشرفت ساختن هواپیما بر اساس وزن است.بیل گیتس

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

انتخاب اولین راه حل

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

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

وظیفه شما به عنوان یک برنامه نویس حرفه ای یافتن راه حل برای مشکل نیست. یافتن ساده ترین راه حل برای مسئله است. منظور من از “ساده” این است که راه حل باید به درستی کار کند و عملکرد کافی را داشته باشد اما هنوز برای خواندن ، درک و حفظ آن به اندازه کافی ساده باشد.

برای طراحی نرم افزار دو روش وجود دارد. یک راه ساده سازی آن به قدری است که بدیهی است هیچ کمبودی وجود ندارد و راه دیگر پیچیدگی آن به حدی است که هیچ نقص واضحی وجود ندارد.CAR Hoare

ترک نکردن

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

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

جستجو نکردن

موارد بسیاری وجود داشته است که وقتی باید فقط در مورد آن تحقیق می کردم وقت گرانبهایی را برای تلاش برای حل مشکل از دست می دادم.

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

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

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

خطرناک ترین فکری که می توانید به عنوان یک فرد خلاق داشته باشید این است که فکر کنید می دانید چه کاری انجام می دهید.برت ویکتور

استفاده نکردن از Encapsulation

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

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

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

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

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

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

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

برنامه ریزی برای ناشناخته

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

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

نوشتن یک ویژگی به این دلیل که فکر می کنید ممکن است در آینده به آن نیاز داشته باشید کاملاً اشتباه است. انجامش ندهید.

همیشه حداقل کدی را که امروز برای راه حلی که در حال اجرا هستید ، بنویسید. موارد خاص را کنترل کنید ، مطمئناً ، اما ویژگی های خاص را اضافه نکنید.

رشد به خاطر رشد ، ایدئولوژی سلول سرطانی است.ادوارد ابی

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

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

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

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

قصد نداریم اینجا به شما ساختار دادها را بیاموزیم، اما بگذارید چند مثال سریع ذکر کنم:

مثال: استفاده از لیست (آرایه ها) به جای Map(اشیا)

رایج ترین اشتباه ساختار داده ها احتمالاً استفاده از لیست ها به جای map برای مدیریت لیستی از سوابق است. بله ، برای مدیریت لیست سوابق باید از MAP استفاده کنید.

به عنوان مثال ، در جاوا اسکریپت ، متداول ترین ساختار لیست ، یک آرایه و رایج ترین ساختار map، یک شی است (در جاوا اسکریپت مدرن نیز یک ساختار نقشه وجود دارد).

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

دلیل اصلی این مهم این است که دسترسی به عناصر در map بسیار سریعتر از دسترسی به عناصر در لیست است. دستیابی به عناصر کاری است که شما مرتباً انجام می دهید.

قبلاً لیست ها مهم بودند زیرا ترتیب عناصر را تضمین می کنند. با این حال ، ساختارهای map مدرن نیز می توانند این کار را انجام دهند.

مثال: عدم استفاده از پشته ها

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

بهینه سازی کد بازگشتی به عملکردهای بازگشتی نیز بستگی دارد. به عنوان مثال ، بهینه سازی یک تابع بازگشتی که دو یا چند تماس را به خود بازگرداند بسیار دشوارتر از بهینه سازی تابع بازگشتی است که به سادگی یک تماس را به خود بازگرداند.

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

بدتر کردن وضعیت کد، از چیزی که با آن شروع کردید

تصور کنید که به شما یک اتاق نامرتب مانند این داده شده است:

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

این کار را با کد کثیف انجام ندهید. آن را بدتر نکنید! همیشه کد را کمی تمیزتر از زمانی که شروع به کار با آن کرده اید بگذارید.

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

در اینجا چند عمل اشتباه وجود دارد که معمولاً کد را به یک مخلوط بزرگتر از آنچه در آن بود تبدیل می کند (نه یک لیست کامل):

• کپی کردن کد اگر یک قسمت کد را کپی / جایگذاری کنید تا فقط یک خط پس از آن تغییر کند ، شما به سادگی در حال کپی کردن کد هستید و یک خرابکاری بزرگتر ایجاد می کنید. این کار مانند این است که به جای سرمایه گذاری روی صندلی جدیدی که قابلیت تنظیم ارتفاع دارد ، صندلی دیگری با پایه پایین در آن اتاق آشفته معرفی کنید. همیشه مفهوم انتزاع را در ذهن خود داشته باشید و در صورت امکان از آن استفاده کنید.
• از فایلهای پیکربندی استفاده نمی کنید. اگر لازم است از مقداری استفاده کنید که به طور بالقوه در محیط های مختلف یا در زمان های مختلف متفاوت باشد ، این مقدار در یک فایل پیکربندی تعلق دارد. اگر لازم است در چندین مکان از کد خود از مقداری استفاده کنید ، این مقدار در یک فایل پیکربندی تعلق دارد. هنگامی که مقدار جدیدی را به کد وارد می کنید ، همیشه این سوال را از خود بپرسید: آیا این مقدار در یک فایل پیکربندی تعلق دارد؟ پاسخ به احتمال زیاد مثبت خواهد بود.
• استفاده از عبارات شرطی غیرضروری و متغیرهای موقتی. هر if-statement یک شاخه منطقی است که حداقل باید دوبار آزمایش شود. وقتی می توانید از شرط مشروط جلوگیری کنید بدون اینکه میزان خوانایی شما را به خطر بیندازید ، باید این کار را انجام دهید. مشکل عمده در این مورد گسترش تابع با منطق شاخه به جای معرفی تابع دیگری است. هر زمان که فکر می کنید به یک دستور if یا یک متغیر تابع جدید نیاز دارید ، باید از خود بپرسید: آیا من کد را در سطح مناسب تغییر می دهم یا باید سطح بالاتری داشته باشم؟

ر مورد اظهارات غیرضروری ، به این کد فکر کنید:

1234567function isOdd(number) {
  if (number % 2 === 1) {
    return true;
  } else {
    return false;
  }
}

تابع isOdd بالا چند مشکل دارد اما میتوانید واضح ترین آنها را ببینید:

از if-statement غیرضروری استفاده می کند. در اینجا یک کد معادل وجود دارد:

123function isOdd(number) {
  return (number % 2 === 1);
};

نوشتن Comment درباره موارد واضح

من هر وقت می توانم از نوشتن comment اجتناب می کنم. من فکر می کنم بیشتر commentها را می توان با عناصر با نام بهتر در کد جایگزین کرد.

به عنوان مثال ، به جای کد زیر:

12345678910// This function sums only odd numbers in an array
const sum = (val) => {
  return val.reduce((a, b) => {
    if (b % 2 === 1) { // if the current number is odd
      a+=b; // Add current number to accumulator
    }

    return a; // The accumulator
  }, 0);
};

همان کد را می توان بدون comment مانند این نوشت:

123456789const sumOddValues = (array) => {
  return array.reduce((accumulator, currentNumber) => {
    if (isOdd(currentNumber)) {
      return accumulator + currentNumber;
    }

    return accumulator;
  }, 0);
};

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

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

اگر شدیداً وسوسه شده اید که برای روشن کردن کد نظر خود را بنویسید ، لطفاً موارد واضح را ذکر نکنید. در اینجا مثالی از برخی نظرات تازه واردان آورده شده است:

1234567891011// create a variable and initialize it to 0
let sum = 0;

// Loop over array
array.forEach(
  // For each number in the array
  (number) => {
    // Add the current number to the sum variable
    sum += number;
  }
);

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

عدم نوشتن تست

من قصد دارم این نکته را ساده بیان کنم. اگر فکر می کنید یک برنامه نویس خبره هستید و این تفکر به شما اعتماد می کند تا بدون تست کد بنویسید ، شما تازه وارد هستید (به معنای واقعی کلمه).

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

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

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

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

TDD برای همه مناسب نیست و برای هر پروژه ای خوب عمل نمی کند ، اما اگر می توانید از آن استفاده کنید (حتی به صورت جزئی) باید کاملاً این کار را انجام دهید.

با فرض اینکه اگر همه چیز در حال کار است، همه چیز درست است

به متد زیر که امکان sumOddValues را پیاده سازی می کند نگاه کنید. چیز اشتباهی در موردش وجود دارد؟

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

    return accumulator;
  });
};

console.assert(
  sumOddValues([1, 3, 5]) === 9
);

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

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

مسئله شماره 1: هیچ شرطی برای ورودی خالی وجود ندارد. چه اتفاقی می افتد که وقتی تابع بدون هیچ مقداری فراخوانی می شود؟ در حال حاضر با خطایی مواجه می شوید که عملکرد را تابع نشان می دهد:

1TypeError: Cannot read property 'reduce' of undefined.

این معمولاً به دو دلیل اصلی نشانه کد بد است:

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

1TypeError: Cannot execute function for empty list.

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

مشکل شماره 2: هیچ شرطی برای ورودی نامعتبر وجود ندارد. اگر تابع به جای آرایه با یک رشته ، یک عدد صحیح یا یک مقدار شی فراخوانی شود ، چه اتفاقی می افتد؟

123sumOddValsue(42);

TypeError: array.reduce is not a function

خوب ، این جای تأسف دارد زیرا array.reduceقطعاً یک متد است!

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

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

شاید یک خطای مفیدتر این بوده باشد: 42 آرایه نیست .

از مشکلات شماره 1 و شماره 2 گاهی اوقات به عنوان موارد لبه ای یاد می شود. این موارد لبه های معمول برای برنامه نویسی است ، اما معمولاً موارد لبه ای کمتر مشخصی وجود دارد که باید به آنها نیز فکر کنید.

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

1sumOddValues ​​([1 ، 3 ، 5 ، -13]) // => هنوز 9 است

خوب ، 13- یک عدد عجیب و غریب است. آیا این رفتاری است که شما می خواهید این عملکرد داشته باشد؟ آیا باید خطایی ایجاد کند؟ آیا باید شامل اعداد منفی در مجموع باشد؟ یا باید فقط مثل الان اعداد منفی را نادیده بگیرد؟ شاید باید اسمش را می گذاشتند sumPositiveOddNumbers.

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

مسئله شماره 4: همه موارد معتبر مورد آزمایش قرار نمی گیرند. موارد لبه ای را فراموش کنید ، این عملکرد دارای یک مورد مجاز و بسیار ساده است که به درستی از آن استفاده نمی کند:

1sumOddValues ​​([2 ، 1 ، 3 ، 5]) // => 11

2 در مورد فوق در مجموع درج شده است که نباید بود.

اگر این مسئله شما را متعجب کرد ، سعی کنید بفهمید چرا این مشکل در کد بالا رخ داده است.

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

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

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

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

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

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

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

به عنوان یک مبتدی ، فقط باید تصور کنید که هر کدی که نمی فهمید نامزد بد بودن است. زیر سوال بریدش، در مورد آن سوال کنید، در git آن را blame کنید!

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

فقط وقتی کد را کاملاً بفهمید ، می توانید نظر بد یا خوب بودن آن را تشکیل دهید. قبل از آن چیزی فرض نکنید.

وسواس در مورد بهترین روشها

اصطلاح “بهترین اقدامات” در واقع مضر است. این بدان معنی است که نیازی به تحقیق بیشتر نیست. در اینجا بهترین روش تاکنون است. زیر سوال نبریدش! هیچ بهترین عملی وجود ندارد. امروزه و برای این زبان برنامه نویسی احتمالاً روشهای خوبی وجود دارد.

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

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

کاری را انجام ندهید به دلیل نقل قولی که در جایی خوانده اید یا اینکه شخص دیگری را دیده اید که این کار را انجام داده است ، یا اینکه کسی گفته است این بهترین عمل است!

وسواس در مورد عملکرد

بهینه سازی زودرس ریشه همه شر (یا حداقل بیشتر آن) در برنامه نویسی استDonald Knuth (1974)

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

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

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

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

با این حال ، نوع جدیدی از بهینه سازی وجود دارد که تازه کارها معمولاً انجام می دهند: بهینه سازی غیر ضروری.

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

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

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

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

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

عدم انتخاب ابزار مناسب برای کار

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

چکش ابزاری عالی برای هدایت میخ به دیوار است اما بدترین وسیله برای استفاده با پیچ است. از چکش روی پیچ استفاده نکنید فقط به این دلیل که آن چکش را “دوست دارید”. از چکش روی پیچ استفاده نکنید فقط به این دلیل که امتیاز 5 بررسی محبوب ترین چکش در آمازون است.

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

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

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

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

عدم درک اینکه مشکلات کد باعث بروز مشکلات داده می شود

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

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

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

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

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

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

• NOT NULL محدودیت بر روی یک ستون بدان معنی است که مقادیر تهی برای آن ستون را رد کرد. اگر برنامه شما وجود مقداری را برای آن قسمت فرض کند ، منبع آن باید به عنوان null در پایگاه داده شما تعریف شود.
• UNIQUE محدودیت بر روی یک ستون بدان معنی است که ستون مقادیر تکراری در سراسر جدول ندارد. به عنوان مثال ، این برای نام کاربری یا قسمت ایمیل در جدول Users بسیار مناسب است.
• CHECK محدودیت بیان سفارشی است که به منظور بررسی درستی برای داده ها، مورد قبول است. به عنوان مثال ، اگر یک ستون درصد طبیعی دارید که مقادیر آن باید بین 0 تا 100 باشد ، می توانید برای اجرای آن از یک محدودیت چک استفاده کنید.
• PRIMARY KEY یعنی محدودیتی که ارزش ستون آن هم تهی نیست و هم منحصر به فرد است. احتمالاً شما از این یکی استفاده می کنید. هر جدول در پایگاه داده باید یک کلید اصلی برای شناسایی سوابق آن داشته باشد.
• FOREIGN KEY به معنای محدودیتی است که ارزش ستون باید مطابق با ارزش یک ستون در یک جدول دیگر، که معمولا یک کلید اولیه است باشد.

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

اختراع مجدد چرخ

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

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

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

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

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

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

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

بهترین مثال در این مورد کتابخانه lodash در JavaScript است. اگر فقط باید آرایه ای را به هم بریزید (shuffle) ، فقط متد بهم ریختن را وارد کنید. کل lodash لعنتی را وارد نکنید.

داشتن نگرش غلط نسبت به بررسی کد

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

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

شما یک یادگیرنده کد برای همیشه هستید. شما باید آن را بپذیرید. بیشتر بررسی های کد چیزی را به شما می آموزد که نمی دانید. آنها را به عنوان منبع یادگیری دسته بندی کنید.

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

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

تازه کارها گاهی اوقات قدرت یک سیستم کنترل منبع (source control) خوب را دست کم می گیرند و منظور من از خوب، Git است.

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

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

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

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

استفاده بیش از حد از حالت مشترک

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

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

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

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

داشتن نگرش اشتباه درباره خطاها

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

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

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

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

عدم شکست

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

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

منبع: Beginner Programmers’ Mistakes

تحریر : صالح رضائی

نقد و بررسی فروشگاه های اینترنتی استارتاپی

اپل ویژن پرو 2024 ظهور یک امپراطوری ؟

نرم افزار CRM یا سیستم تیکتینگ؟

راهی عادلانه برای تقسیم مالکیت و سهام شرکت و استارتاپ

بهترین بازی های PS Plus Premium کدامند؟ (ژانویه 2024)