اعداد باینری

شما جزء کدام دسته هستید؟

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


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

در الکترونیک و در سیستم‌های کامپیوتری و دیجیتالی، به منظور انتقال اطلاعات از اعداد دودویی یا باینری (binary) که در قالب 0 و 1 هستند استفاده می‌شود.

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

تبدیل اعداد دسیمال به باینری

تبدیل اعداد دسیمال به باینری کار سختی نیست. تنها کاری که باید انجام بدیم تقسیم متوالی عدد مورد نظر به دو است. به عنوان مثال می‌خواهیم عدد ۱۰ را در دستگاه باینری بنویسم.

  • اول از همه عدد ۱۰ را به ۲ تقسیم می‌کنیم. خارج قسمت می‌شود ۵ و باقیمانده می‌شود ۰ پس ما عدد صفر را می‌نویسم.
  • در گام بعدی خارج قسمت را به ۲ تقسیم می‌کنیم. اینبار خارج قسمت می‌شود ۲ باقیمانده می‌شود ۱ پس عدد ۱ را می‌نویسم.
  • یکبار دیگر باقیمانده را به ۲ تقسیم میکنیم، خارج قسمت می‌شود ۱ و باقیمانده می‌شود صفر، پس یک صفر دیگر هم می‌نویسم و از آنجا که خارج قسمت برابر با ۱ است ما هم عدد یک را قرار می‌دهیم تا به ۱۰۱۰ برسیم.
تبدیل دسیمال به باینری به روایت تصویر

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

کد من به زبان #C

در دو خط اول یک عدد صحیح از کاربر میگیرم و دخل یک متغییر به نام number ذخیره میکنم. در ادامه یک متغییر موقتی به نام temp هم تعریف کردم که از جنس string هست.از خط ۶ تا ۱۷ حلقه while را داریم. اول از همه number را به ۲ تقسیم میکنیم اگر باقیمانده برابر با صفر شد ۰ را به متغییر temp اضافه میکنم در غیر اینصورت ۱ را به temp اضافه میکنیم. فکر میکنم الان مشخض شد که چرا temp را از نوع string تعریف کردم.

در نهایت مقدار number را به number / 2 تغییر میدهیم و این حلقه تا زمانی که مقدار number کوچکتر مساوی ۱ بشود ادامه دارد. اما کد ما یک مشکل کوچک دارد. عدد باینری به صورت برعکس داخل متغییر temp ذخیره می‌شود. یعنی به ازای عدد ۱۰ داخل متغییر temp عدد ۰۱۰۱ را خواهیم داشت.

در خط ۱۸ و ۱۹ متغییر temp را به Array تبدیل میکنیم و با استفاده از متد Reverse برعکسش میکنیم. بعد در خط ۲۱ تا ۲۵ Array برعکس شده را داخل یک متغییر جدید بنام newStr ذخیره میکنیم و در خط ۲۶ مقدار باینری را نمایش میدیم.

تبدیل اعداد باینری به دسیمال

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

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

تبدیل عدد باینری به دسیمال

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

کد من به زبان #C

نوشته اعداد باینری اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

دستورات شرطی در جاوا

دستورات شرطی در جاوا

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

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

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

  1. دستور if بصورت زیر تعریف می شود.

{ if (Condition)
statements;}
}

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

{ if (num>3statements)}
else if(num<0){
statements;
}

3. دستور else if به اینصورت نیز تعریف میگردد.

if (num>3){
statements;
}
else if(num<0){
statements;
}
else{
statements;
}

در اینجا اگر شرط if برقرار نبود، دستور else if اجرا میشود و اگر else if نیز برقرار نبود، else اجرا میگردد.

4. در حالتی که تعداد این دستورات تو در تو if زیاد باشد، به منظور اینکه خوانایی کد را بالا ببریم، میتوانیم از دستور switch استفاده کنیم. این دستور به شکل زیر تعریف می گردد.

switch (variable){
case value1:
statements;
break;
case value2:
statements;
break;
case value3:
statements;
break;
default:
statements;
break;
}

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

نوشته دستورات شرطی در جاوا اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

مثلث برنامه نویسی و شهوت و دوچرخه سواری

بسم الله الرحمن الرحیم

سلام علیکم

همان طوری که در جامعه مشاهده می کنیم عوامل زیادی در بازدهی یک برنامه نویس و کلا هر شغلی تاثیر گذار هستند .

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

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

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

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

فرد با تصاویر محرک و یا دیدن خانم هایی با آرایش غلیظ و لباس حسبناک و یا دیدن آقایانی با ظاهری محرک برای خانم ها , هورمونی هایی در بدن فرد تشرح می شود و او را دچار حالت شهوت و مشغول شدن ذهن می کند .

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

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

یک مقاله مرتبط با این موضوع پیشنهاد می کنیم حتما مطالعه کنید…

https://vrgl.ir/zYm97

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

نوشته مثلث برنامه نویسی و شهوت و دوچرخه سواری اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

tHIS is
  WAY MORE important
than
            you think

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

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

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

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

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

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

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

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

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

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

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

ترک نکردن

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

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

گوگل نکردن

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

// 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 مانند این نوشت:

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

    return accumulator;
  }, 0);
};

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

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

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

// 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 را پیاده سازی می کند نگاه کنید. چیز اشتباهی در موردش وجود دارد؟

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

    return accumulator;
  });
};

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

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

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

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

TypeError: Cannot read property 'reduce' of undefined.

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

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

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

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

sumOddValsue(42);

TypeError: array.reduce is not a function

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

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

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

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

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

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

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

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

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

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

sumOddValues ​​([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

نوشته اشتباهات برنامه نویسان مبتدی اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

کارهایی که هنگام یادگیری برنامه نویسی نباید انجام دهید

در اینجا لیست کارهایی است که شما نباید هنگام انجام کد نویسی انجام ندهید:

1. مقایسه خود با افراد دیگر

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

وقتی نوبت به برنامه نویسی می رسد ، مهارت های خود را با شخصی که بیش از شما برنامه نویسی کرده است مقایسه نکنید. این نقل قول را ببینید:  “فصل 1 خود را با فصل 20 شخص دیگر مقایسه نکنید”.  شخصی که به سطح 20 رسیده است در مقطعی از جایی که اکنون هستید بوده است ، منظور من در فصل 1 است.

2. جابجایی بین زبان ها و فن آوری های مختلف به جای تمرکز بر روی یکی

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

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

3. خیلی راحت تسلیم شدن

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

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

4. تلاش برای به خاطر سپردن کد

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

5. گوگل نکردن

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

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

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

نوشته کارهایی که هنگام یادگیری برنامه نویسی نباید انجام دهید اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

Hi, im new here :D

خب سلامم! من نگینم و این اولین پستیه که میگذارم :)))

دانشجوی ترم 4 برقم و علاقه زیادی به برنامه نویسی دارم و بهترین تفریحم هم دیدن فیلم و سریاله :))

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

میخواست اینجا هم فعالیت داشته باشم خصوصا راجع به برنامه نویسی , که نمیشد تا به امروز :دی

حقیقتا هدف اصلیم اینجا هم پیدا کردن دوستای جدیده که خصوصا توی برنامه نویسی بتونم از

تجربیاتشون استفاده کنم :}

همین , تا بعد ^_^


نوشته Hi, im new here 😀 اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

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

زبان انگلیسی برای برنامه نویسی

بسم الله الرحمن الرحیم

سلام علیکم

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

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

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

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

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

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

https://vrgl.ir/IMsWW

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

گردآوری توسط ایده طلایی

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

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

هر شخصی با یک هدف و انگیزه ایی زندگی میکند و برنامه و نقشه ی مسیر زندگی خود را طراحی می کند .

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

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

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


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

محل بدنیا آمدن و رشد کردن تا یک سن مطلوب دست خود شخص نیست ! شما کمتر شخصی را میبنید که در زمان کودکی به تنهایی به محیط دیگری مهاجرت کند . حداقل سن لازم ۱۸ سال است !

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

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

برای درک بهتر مثال واقعی را برای شما بازگو خواهم کرد :

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

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

داستان از این قرار هست :

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

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

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

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

بعد از چند ماه آموزش مستمر زیر نظر مستقیم تیم لید و دیگر دوستان خبره , ایشان کم و بیش با برنامه نویسی آشنا می شوند و وارد آن تیم بزرگ می شوند !

در اینجا باز باید کامنتی با این مضمون باشد :

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

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

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


سنا عبادی | چهارشنبه شب ساعت 19:10 , ششم اسفند ماه سال 1399

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

گردآوری توسط ایده طلایی

18 نکته برای نوشتن کد جاوا اسکریپت مانند یک قهرمان

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

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

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

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

هنگام برنامه نویسی باید بسیار مراقب باشید، زیرا در پروژه‌های بزرگ داشتن یک کد “نامرتب” می‌تواند یک مشکل جدی باشد.

بسیاری از برنامه نویسان از زبان جاوا اسکریپت به دلیل نداشتن یک روش کار استاندارد مانند زبان جاوا یا C + + انتقاد می‌کنند اما حقیقت این است که جاوا اسکریپت یکی از بهترین زبان‌هایی است که در این دوران مورد استفاده قرار می‌گیرد، بعضی از شرکت‌هایی که از این زبان استفاده می‌کنند فیسبوک (Facebook) و نتفلیکس (Netflix) هستند که شاید به دلیل کاربردی بودن آن برای سئو کاران باشد. کتاب‌خانه‌هایی مانند React به همراه بقیه کتاب‌خانه‌های مانند آن عملکرد Front-end را بهبود می‌دهند و از nextJs برای سرعت بالاتر در Backend استفاده می‌کنند. این ترکیب‌ها برنامه نویسان امروزه را دیوانه می‌کنند.

اصطلاح ES6 یا ES2015 که کوتاه شده عبارت ECMAScript v6 است استانداردی می‌باشد که جاوا اسکریپت از ماه ژوئن سال 2015 دنبال می‌کند. در مورد این موضوع که تا آن زمان از چه نسخه‌ای از جاوا اسکریپت در مرورگرها و Node.js استفاده می‌کردیم، در این پست صحبت خواهیم کرد.

18 نکته برای نوشتن کد جاوا اسکریپت مانند یک قهرمان

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

پس بریم سراغش!

1. در نوشتن کد جاوا اسکریپت برای مقدارهای ثابت به جای “var” از “const” استفاده کنید

مقدارهای ثابت متغیرهایی هستند که مقدار آن‌ها هیچوقت تغییر نمی‌کند، با وارد کردن این متغیرها به این روش می‌توانیم مطمئن شویم که هیچوقت تغییر نمی‌کنند.

/* Old way */
var i = 1;/* Correct */
const i = 1;

2. در نوشتن کد جاوا اسکریپت برای متغیرهایی که مقدار آن‌ها تغییر می‌کند به جای “var” از “let” استفاده کنید

عبارت Let نشان دهنده این است که بلاک متغیرها در یک اسکوپ محلی قرار دارند، این متغیر تغییر خواهد کرد:

/* Inadequate */
var myVal = 1;
for (var i; i < 10; i++){
myVal = 1 + i;
}/* Correct */
let myVal = 1;
for (let i; i < 10; i++){
myVal += i
}

3. وارد کردن اشیاء

مثال برای میانبر وارد کردن اشیاء:

/*
Old way
The Object() class makes an unnecessary function call
*/
const myObject = new Object();/* Correct */
const myObject = {};

4. وارد کردن آرایه

مثال برای وارد کردن آرایه:

/*
Old way
The Array() class makes an unnecessary function call
*/
const myArray = new Array();/* Correct */
const myArray = [];

5. به هم پیوستن رشته‌ها در نوشتن کد جاوا اسکریپت

مثال برای به هم پیوستن رشته‌ها که بسیار کمک کننده است:

/* Old way */
const myStringToAdd = “world”;
const myString = “hello ” + myStringToAdd;/* Correct */
const myStringToAdd = “world”;
const myString = `hello ${myStringToAdd}`;

6. استفاده از متد کوتاه تر شیء

مثال برای عملکردهای مفید در اشیاء:

/* Inadequate */
const customObject = {
val: 1,
addVal: function () {
return customObject.val + 1;
}
}/* Correct */
const customObject = {
val: 1,
addVal(){
return customObject.val++
}
}

7. وارد کردن مقدار یک شیء

مثال برای ساختن یک شیء به همراه مقدار:

/* Inadequate */
const value = 1;
const myObject = {
value: value
}/* Correct */
const value = 1;
const myObject = {
value
}

8. نسبت دادن یک مقدار به یک شیء

مثال برای نسبت دادن مقدارهای یک شیء به یک شیء دیگر:

/* Old way */
const object1 = { val: 1, b: 2 };
let object2 = { d: 3, z: 4 };
object2.val = object1.val;
object2.b = object1.b;/* Correct */
const object1 = { val: 1, b: 2 };
const object2 = { …object1, d: 3, z: 4 }

9. نسبت دادن یک مقدار به یک آرایه

مثال برای میانبر نسبت دادن یک مقدار به یک آرایه:

/* Inadequate */
const myArray = [];
myArray[myArray.length] = “hello world”;/* Correct */
const myArray = [];
myArray.push(‘Hello world’);

10. به هم پیوستن آرایه‌ها

مثال برای به هم پیوستن آرایه‌ها:

/* Inadequate */
const array1 = [1,2,3,4];
const array2 = [5,6,7,8];
const array3 = array1.concat(array2);/* Correct */
const array1 = [1,2,3,4];
const array2 = [5,6,7,8];
const array3 = […array1, …array2]

11. گرفتن چند مقدار از یک شیء

مثال برای ساختن یک عملکرد با ورودی یک شیء:

/* Inadequate */
function getFullName(client){
return `${client.name} ${client.last_name}`;
}/* Correct */
function getFullName({name, last_name}){
return `${name} ${last_name}`;
}

12. گرفتن مقدارها از یک شیء

مثال برای گرفتن مقدارها و ساختن متغیرها:

/* Inadequate */
const object1 = { a: 1 , b: 2 };
const a = object1.a;
const b = object1.b;/* Correct */
const object1 = { a: 1 , b: 2 };
const { a, b } = object1;

13. ساختن عملکردها

مثال برای میانبر عملکردهای با فلش:

/* Old way but good */
function myFunc() {}/* Good */
const myFunc = function() {}/* Best */
const myFunct = () => {}

// IMPORTANT: In some cases it is not recommended to use these functions with arrows to avoid reading errors

14. مقدارهای پیش فرض

مثال برای قراردادن مقدارهای پیش فرض در پارامترهای عملکرد:

/* Inadequate */
const myFunct = (a, b) => {
if (!a) a = 1;
if (!b) b = 1;
return { a, b };
}/* Correct */
const myFunct = (a = 1, b = 1) => {
return { a, b };
}

15. به جای “forEach” از “reduce” و برای مقدارهای میانگین از “for” استفاده کنید

مثال برای میانبر میانگین آرایه:

/* Inadequate */
const values = [1, 2, 3, 4, 5];
let total = 0;
values.forEach( (n) => { total += n})/* Inadequate */
const values = [1, 2, 3, 4, 5];
let total = 0;
for (let i; i < values.length; i++){
total += values[i];
}/* Correct */
const values = [1, 2, 3, 4, 5];
const total = values.reduce((total, num) => total + num);

16. موجود در آرایه:

/* Inadequate */
const myArray = [{a: 1}, {a: 2}, {a: 3}];
let exist = false;
myArray.forEach( item => {
if (item.a === 2) exist = true
})/* Correct */
const myArray = [{a: 1}, {a: 2}, {a: 3}];
const exist = myArray.some( item => item.a == 2)

17. میانبر در صورتی که Boolean باشد:

/* Inadequate */
const a = 1;
const b = 1;
let isTrue = false
if (a === b) {
isTrue = true
}/* Correct */
const a = 1;
const b = 1;
const isTrue = a === b

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

/* Inadequate */
const a = 5;
let b;
if (a === 5){
b = 3;
} else {
b = 2;
}/* Correct */
const a = 5;
const b = a === 5 ? 3 : 2;

نتیجه گیری

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

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

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

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

نوشته 18 نکته برای نوشتن کد جاوا اسکریپت مانند یک قهرمان اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی

شش روش‌ برای سرعت بخشیدن به کد پایتون

شکل ۱. افزایش سرعت اجرای کد پایتون

منتشر‌شده در: towardsdatascience به تاریخ ۲۰ فوریه ۲۰۲۱
لینک منبع: 6 Approaches to Speed Up Your Python Code

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

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

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

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

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

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

روش اول:‌ به روز باشید

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

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

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

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

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

دانستن ساختار صحیح داده برای استفاده در برنامه شما می‌تواند آن را بسیار سریع‌تر کند. برای مثال، استفاده از دیکشنری‌ها و مجموعه‌ها در برنامه‌های جستجو نسبت به لیست‌ها کارآمدتر است زیرا آن‌ها براساس جداول هش ساخته شده‌اند و همیشه به زمان O (۱) برای جستجوی هر آیتمی نیاز دارند.

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

مطالعه مقاله یونیت تست برای برنامه‌های یادگیری عمیق با پایتون توصیه می‌شود.

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

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

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

روش دیگر برای استفاده موثرتر از حلقه‌ها استفاده از درک لیست در هر زمان ممکن است؛ به عنوان مثال، ایجاد و پر کردن یک لیست از طریق درک بهتر با استفاده از روش ضمیمه انجام می‌شود. در نهایت، while loops نسبت به for loops، از نظر آماری و زمانی کارآمدتر هستند، for loops را جایگزین while loops کنید.

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

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

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

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

روش پنجم: از روش‌هایی که حافظه را کمتر اشغال می‌کنند استفاده کنید.

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

  • از ژنراتورها برای تولید مقادیر دامنه استفاده کنید زیرا آن‌ها به مصرف حافظه کمتری نیاز دارند.
  • از sort() به جای sorted() استفاده کنید زیرا sorted یک کپی جدید تکراری ایجاد می‌کند. استفاده از مرتب‌سازی شده در مورد مجموعه داده‌های بزرگ کارآمدتر است.
  • از __slots__ استفاده کنید. اسلات یک روش خاص برای اعلام متغیرهایی است که نمونه یک متغیر را در نظر می‌گیرند و تنها فضای کافی را برای حفظ ارزش آن ذخیره می‌کنند.
  • برای مقابله و انجام عملیات بر روی اعداد و ماتریس‌های بزرگ از ریاضیات و عدد پی استفاده کنید. این کتابخانه‌ها برای کارآمد بودن حافظه ساخته شده‌اند.
  • از فرمت یا روش‌های join برای الحاق رشته‌ها به جای استفاده از عملکردهای + استفاده کنید.

روش شش: از برنامه‌های تسریع کننده استفاده کنید.

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

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

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

نتیجه گیری

پایتون یکی از محبوب‌ترین زبان‌های برنامه‌نویسی موجود است؛ یادگیری برای مبتدیان و متخصصان آسان‌تر است، خواندن و درک آن ساده است، و می‌تواند تقریبا در هر برنامه‌ای که فکر می‌کنید مورد استفاده قرار گیرد. در سال ۲۰۱۹، SlashData تعداد توسعه‌دهندگان را با استفاده از پایتون به عنوان زبان برنامه‌نویسی اصلی خود به ۲ / ۸ میلیون توسعه‌دهنده تخمین زد، که تعداد آن‌ها هر روز افزایش می‌یابد.

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

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

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

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

نوشته شش روش‌ برای سرعت بخشیدن به کد پایتون اولین بار در ویرگول پدیدار شد.

گردآوری توسط ایده طلایی