https://virgool.ir/feed/@rezvaniamirsamrozveltrفعال در حوزه های هوش مصنوعی .علوم داده . رایانش امن و ابری . دانش آموخته دانشگاه صنعتی امیرکبیر . مدیر تست نفوذ و امنیت شبکه .کارشناس امنیت شرکت فناوری اطلاعات نوین ،fa2026-11-11 16:02:31https://files.virgool.ir/upload/users/3306441/avatar/avatar.pnghttps://virgool.ir/@rezvaniamirsamrozveltrhttps://virgool.ir/Programme-1-developer/فرمتینگ-مناسب-در-پایتون-rgqtkumrymgcفرمتینگ مناسب در پایتون (تجربه)همیشه برام دغدغه بود که چه فرمتر (formatter) یا ابزار فرمت‌بندی کد رو برای پروژه‌های پایتون (Python) انتخاب کنم. فرمترها ابزارهایی هستند که کد منبع را مطابق با دستورالعمل‌های استایل خاصی تجزیه و تحلیل و بازنویسی می‌کنند تا خوانایی و یکنواختی کد افزایش پیدا کنه. این ابزارها به ما کمک می‌کنند تا اطمینان حاصل کنیم که کد ما نه تنها درست کار می‌کند، بلکه به زیبایی و به شکل استاندارد نوشته شده. برای پایتون سه تا formatter اصلی وجود داره.همیشه بین این سه گزینه گیر می‌کردم: Black، autopep8، و YAPF. هر بار در پروژه‌های یکی رو انتخاب می‌کردم ولی یه بار رفتم اساسی بررسی کردم اینا چه تفاوتهایی دارن. هر کدوم قابلیت‌ها و ویژگی‌های منحصر به فرد خودشون رو دارند و انتخاب بین این‌ها واقعا سخته. اما بزارید یه نگاه دقیق‌تر به هر کدوم بندازیم:1. Blackفرمتر Black به شدت خودکار و بی‌طرفانه (opinionated) عمل می‌کنه. این فرمتر با اینکه خیلی سفت و سخته (uncompromising)، ولی به خاطر همین خصوصیتش خیلی هم محبوب شده. نظم خاصی به کد می‌ده و تقریبا هیچ جایی برای بحث و جدل در مورد سبک کدنویسی باقی نمی‌ذاره. ویژگی بارزش بخاطر این سختی‌گیری نسبت به yapf متعین(deterministic) بودنشه یعنی اگر روی یک کد اجرا کنی حتما به یک شکل مشخص در میاره. برای یک کد چند تا حالت مختلف رو به عنوان حالت معتبر از نظر فرمت در نظر نمی‌گیره ولی yapf اینطوری نیست جلوتر توضیح میدم. یک مشکل بزرگ داره انعطاف‌پذیری کمی داره (less flexible) و شاید برای پروژه‌هایی که نیاز به سبک خاصی دارند مناسب نباشه.2. autopep8فرمتر autopep8 دقیقا روی استانداردهای PEP 8 (PEP 8) تمرکز داره. این فرمتر کدها رو به شکلی استاندارد و خوانا (readable) درمیاره ولی فقط مطابق autopep8. کد را آنالیز می‌کند و خطاهای استایل را اصلاح می‌کند تا با استانداردهای PEP 8 همخوانی داشته باشد. گاهی اوقات نمی‌تونه به اندازه Black یا YAPF انعطاف‌پذیر باشه (not as flexible) و ولی تعداد قوانین‌ش به اندازه‌ی black‌ زیاد نیست.معنی انعطاف پذیر بودنش اینه که اگر یک کدی با black فرمت شده باشه اینقدر قوانین خیلی سفت و سختی داره (strict rules) که قوانین Autopep هم درش رعایت شده مثلا PEP8 میگه طول خط از 79 بیشتر نشه ولی black میاد اینقدر طول خط رو کوتاه میکنه که از 79 خیلی کمتر و قواعد هر دو تا استاندارد رو پاس میکنه.3. YAPFفرمتر YAPF خیلی قابل تنظیم و انعطاف‌پذیره (highly configurable). این فرمتر بر اساس یک پروفایلی که شما تعیین می‌کنید، کد رو فرمت می‌کنه. YAPF کد را بازبینی کرده و بر اساس پروفایل تعیین شده تغییرات لازم را اعمال می‌کند تا کد هم خوانا و هم زیبا باشد. اگر دنبال سفارشی‌سازی ددقیق فرمت کدتان هستید (customization)، YAPF انتخاب خوبیه. خصوصا توی پروژه‌ها. البته اگر کسی باشه بشینه استاندارهای فرمت رو همه رو کانفیگ کنه.اما گاهی اوقات تنظیمات می‌تونه خیلی پیچیده بشه (complex configuration) و این ممکنه باعث سردرگمی شود.خیلی ساده بخوام بگم YAPF بیشتر یک ابزار کانفیگ فرمته تا فرمتر با قواعد مشخص! یعنی میتونی یه جوری کانفیگ کنی که خروجی بشه مثه خروجی هر کدوم از دوتا قبلی، میتونی هم طوری کانفیگ کنی که اصلا هیچ شبیه دو تا قبلی نشه.چند تا قطعه کد ببنید یه کم حس بگیرید به حرفام:این کد رو در نظر بگیرید که فرمت خیلی بدی داره:def compute(value1,value2,value3):return value1+value2+value3Formatted by autopep8def compute(value1, value2, value3): return value1 + value2 + value3Formatted by Blackdef compute(value1, value2, value3): return value1 + value2 + value3اما اینکه میگم به جز black اون دو تا دیگه متعین نیستن مثالش اینطوریه که فرض کنید کد ورودی این سه تا باشه. در این صورت با اینکه تابع یک چیزه ولی هر سه تا اینا قواعد YAPF رو رعایت کرد و هر سه تا میتونه تو پروژه باشه!def function(arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10): print(arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10)def function(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10): print(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10)def function( arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10): print(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10)طبق تجربه میگم اگر گیت در پروژه تون نقش پررنگی داره قواعد فرمتیگ رو همون اول ست کنید وسط پروژه اعمال کردن فرمت شدیدا روی مرج کانفلیکت میده!قواعد black به نظر من از جهت deterministic بودن خیلی خوبن ولی در زمینه‌ی طول خط خیلی کوتاه و سختگیرانه است.تجربه شما چیه؟amirsamrozveltr rezvaniamirsamrozveltr rezvaniThu, 06 Jun 2024 10:09:21 +0330https://virgool.ir/Programme-1-developer/درس-هایی-راجب-برنامه-نویسی-از-زبان-matt-butcher-g9xhn1yxubnpدرس هایی راجب برنامه نویسی از زبان Matt Butcherیادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!این حرف خیلی معنی داره که تو ادامه می‌گم:- برنامه نویسی به عنوان صنعتگری- چرخ رو از اول اختراع نکن- هزینه پیچیدگی- کاهش نیازهای آینده برای نگهداری- چرا خود آیندتون (و دیگران) قدردان کد امروزنبرنامه نویسی به عنوان صنعتگری«صنعتگری» به معنی تعهد به یه حرفه است، جایی که مهارت با گذشت زمان و از طریق تلاش سخت و تمرین مداوم به وجود میاد. نوشتن کد، با تمام دیباگ و تست کردن و بازنویسی‌هاش، یه کار کاملاً عملیه. ساختن نرم‌افزار خوب به مهارت، دانش و تمایل مداوم برای پیشرفت نیاز داره. وقتی کد می‌نویسین، وقت بذارین که کارتون رو خوب انجام بدین. درسته که «کمالگرایی دشمنه» و باید کد بزنین که کارتون راه بیفته. اما رعایت اصول درست کد نویسی، اسم‌گذاری درست متغیرها و فکر کردن به مشکلی که دارین حل می‌کنین، همه اینا باعث می‌شه که نگهداری از کدتون تو دراز مدت راحت‌تر بشه.پشتیبانی از کد ضعیف یه درده. اما نگهداری از کد خوب، از لحاظ فکری خیلی راضی‌کننده‌ست.چرخ رو از اول اختراع نکنیه کتابخونه یا ابزاری هست که کار رو راه می‌ندازه، ولی خب، ما میتونیم بهتر انجامش بدیم!فکر می‌کنم هر مهندس نرم‌افزاری حداقل یه بار این کار رو کرده و همیشه یه جور توجیه هم هست:کتابخونه‌های دیگه‌ای هم بودن، اما سنگین/پر از باگ/پیچیده/و …یه راه جدید دارم که بقیه بهش فکر نکرده بودن.انجام دادنش خودم بیشتر یاد می گیرم تا اینکه از کد بقیه استفاده کنم (حرفت درسته، اما با هزینه‌ای خیلی بیشتر از اون چیزی که فکرشو می‌کردی).تو همه این موارد، دو تا چیز نادیده گرفته میشن:چقدر بقیه زمان صرف کرده بودن که قبلاً مشکل رو حل کنن. (پختگی اون کد)منِ آینده چقدر باید وقت بذاره واسه درست کردن و نگهداری اون کد.پس وقتی که ابزار آماده هست، اما فکر می‌کنین شاید خودتون بهتر انجامش بدین، از خودتون بپرسین چقدر برای نگهداری از اون کد تو چند سال آینده اشتیاق دارین؟ آیا استثناهایی برای این قضیه وجود داره؟ بله! اما اونم بعد از اینکه واقعاً بررسی کردین که آیا راه‌حل‌های موجود به اندازه کافی برای انجام کار خوب هستن یا نه.هر چی کدت پیچیده‌تر، دیباگش سخت‌ترهفرض کنید یه تابع می نویسید که یه عملیاتی رو انجام میده ولی کدش پیچیدس و حالا برای دفاع از خودتون میگید تست نوشتید. و کدتون ار نظر فرمت بی‌نقص و  خیلی خوب کار میکنه. بعد یه روز یه آسیب‌پذیری پیدا میشه. یه هکر بتونه تابعی که نوشید رو مجبور کنه که بیشتر از حافظه‌ی سیستم، حافظه اختصاص بده. بعد از چند سال که اصلاً به این کد دست نزدید، باید درستش کنید. وقتی کد رو میخونید، انگار یه چیز کاملاً غریبس , باید بفهمید چطور می‌تونید اون باگ رو درست کنید.شاید مجبور بشین خط‌های بیشتری کد بنویسین (چون کارهای پیچیده رو به تابع‌های کوچیک‌تر تقسیم می‌کنین)، اما اگه نتیجه‌ش بشه کدی که دیباگ و نگهداریش راحت‌تره، ارزشش رو داره.کاهش نیازهای آینده برای پشتیبانیهر سیستم خوبی یه سری کنترل کیفیت داره. کد هم باید همین‌طور باشه. باید یه استراتژی برای تست نوشتن پیدا کنید،‌به هر حال، مهم نیست استراتژی شما چیه، اگه الان تست نکنین، بعداً باید دیباگ کنین.خودت آیندت یادش نمیاد که خودت الانت به چی فکر میکردهپس همه‌چی رو مستند کن! آدما یه جور پیش‌فرض عجیب دارن. فکر می‌کنیم که فردا همه چیزایی که امروز اتفاق افتاده رو یادمون می‌مونه. خود آینده‌ت جزئیات ریز اینکه چرا امروز این کد رو به این شکل نوشتی، یا چرا اون متغیر رو fhr اسم گذاشتی، یا چرا کامنت // FIXME later رو رو خط ۲۳۵ جا گذاشتی، یادش نمیاد.بهترین راهی که می‌تونی با محدودیت‌های حافظه‌ت مقابله کنی اینه که کدت رو واضح بنویسی. این یعنی:کامنت بذار.اسم‌ها رو خوب انتخاب کن.مستندات خوب بنویس.کامیت‌مسیج‌های مفید بنویس.خود آینده‌ت ازت ممنون می‌شه. یا حداقل از دستت عصبانی نمی‌شه.نتیجه گیری: اگه بقیه نتونن اونو بفهمند، همیشه مشکل شما باقی می‌مونهپس طوری مستندش کن که بقیه بتونن اونو بفهمند.اگه کدتون راحت‌فهم نباشه، مثل یه کابوس برمی‌گرده سراغتون. چون بقیه نمی‌تونن اونو بفهمند. کدتون رو انقدر راحت‌فهم کنین که یه نفر دیگه بتونه اونو درست کنه بدون اینکه حتی نیاز باشه شما بفهمین!نتیجه گیریاین قانون رو به عنوان یه راه برای ترغیب کردن خودتون به بهبود کدتون پیشنهاد می‌دم:یادتون باشه هر خط کدی که می‌نویسین باید بعدا ازش پشتیبانی کنین!این کار باعث صرفه‌جویی در زمان و انرژی شما در آینده می‌شه. باعث می‌شه همکاراتون عصبانی نشن. تغییر دادن کد امروز به کد فردا رو راحت‌تر می‌کنه. و به احتمال زیاد باعث می‌شه همه فکر کنن شما هم یکی از اون برنامه‌نویس‌های فوق حرفه‌ای هستین.amirsamrozveltr rezvaniamirsamrozveltr rezvaniThu, 06 Jun 2024 02:16:52 +0330https://virgool.ir/Programme-1-developer/زبان-های-برنامه-نویسی-s5mb1uuxcdbaبحث داغ زبان‌های برنامه‌نویسی: چرا اصلاً مهم نیست؟یه بحث همیشگی توی دنیای برنامه‌نویسی هست که توی انجمن‌ها، جلسات تکنولوژی و حتی تو خواب و خیال برنامه‌نویس‌ها هم ول نمی‌کنه: آخرش کدوم زبان برنامه‌نویسی از همه بهتره؟ بشینید پای صحبت های کسایی که از وقتی اینترنت با خط تلفن وصل می‌شد کد می‌نوشتن، تا حالا میگن که کلی زبان برنامه‌نویسی اومده و رفته. از اسکریپت‌های Perl که مثل وردهای جادویی بودن تا TypeScript امروزی که مثل آب خوردن می‌مونه، احتمالا همه جور کدی نوشتن. بعد از شنیدن حرف های ریش سفید های این کار میتونیم بفهمیم: وقتی میخوایم یه مشکلی رو حل کنیم، اصلاً مهم نیست از چه زبانی استفاده می‌کنیم. بله، درست شنیدید! اول یه چیزی رو روشن کنم: بله، یه سری زبان‌ها برای یه کارهایی بهتر از بقیه هستن. مثلاً اگه می‌خواید یه پلتفرم معاملاتی پر سرعت بسازید، بعید می‌دونم از PHP استفاده کنید. یا اگه می‌خواید یه برنامه iOS بنویسید، Swift بهترین دوست شما می‌تونه باشه. ولی نکته اینجاست که موفقیت پروژه‌تون بیشتر به نحوه استفاده از زبان بستگی داره تا خود زبان. مثلاً اینکه چکش بهتره یا پیچ‌گوشتی، بستگی به این داره که می‌خواید با میخ کار کنید یا پیچ.یهویی چی شد؟ یهو همه گیر دادن به پرفورمنس!طرفدارای یه زبان میگن: "زبان X از زبان Y سریع‌تره!" آره بابا، یه سری تست و بنچمارک نشون میده که یه ذره سرعت اجرا یا مصرف حافظه تو زبونا فرق می‌کنه. ولی بیخیال، واسه 99 درصد برنامه‌ها این فرق‌ها مثه اینه که موقع کدنویسی جوراب قرمز بپوشی یا آبی! مهم معماری، الگوریتم و استراتژی بهینه‌سازیه که کارو راه میندازه. یه سیستم بد طراحی‌شده، چه با Rust نوشته بشه چه با Ruby، آخرش بد و ناکار آمد هستش.یادگیری زبون برنامه‌نویسی سخته؟یه حرف دیگه هم که میزنن اینه که یه زبون‌ها یادگیریشون سخته. آره، قبول دارم، یه زبون‌ها واسه مبتدی‌ها راحت‌ترن، که این عالیه واسه اینکه آدمای بیشتری رو به برنامه‌نویسی جذب می‌کنه. ولی یادگیری یه زبان فقط اولش سخته. مهم اینه که بتونی مثل یه برنامه‌نویس فکر کنی، بتونی مساله حل کنی و الگوریتم بنویسی. وقتی اینارو یاد گرفتی، یادگیری یه زبان جدید فقط یه ذره قلق و یه ذره اصطلاحات جدید داره.لاتاری کتابخونه یکی از دلایلی که خیلی‌ها یه زبان برنامه‌نویسی رو به یه زبان دیگه ترجیح می‌دن، به خاطر امکانات و ابزارهای اون زبونه. یه زبان خوب، کتابخونه‌ها، فریم‌ورک‌ها و ابزارهای قوی و باکیفیتی داره که می‌تونه سرعت و کیفیت کار شما رو خیلی بالا ببره. اما یه رازِ قشنگ هم هست: اکثر زبان‌های محبوب، امکانات و ابزارهای خیلی خوبی دارن. اگه یه کتابخونه یا ابزار برای یه زبان وجود داشته باشه که برای یه زبان دیگه نباشه، این یه فرصته که شما به جامعه اون زبان کمک کنید. یادتون باشه، یه برنامه‌نویس خوب، مشکل‌حل‌کنه؛ نه اینکه بشینه منتظر بمونه تا یه نفر دیگه مشکلش رو حل کنه.حرف آخردر نهایت، زبان برنامه نویسی فقط یه ابزاره. یه وسیله برای رسیدن به یه هدف، نه خود هدف. بهترین زبان برای پروژه شما زبانیه که شما و تیمتون باهاش راحت ترید و بیشتر میتونید باهاش کار کنید. زبانی که به درد نیازهای پروژه شما میخوره و میتونید توی طول زمان ازش مراقبت کنید و ارتقاشش بدید. مهم نیست طرفدار کدوم زبان هستید، پایتون، جاوا اسکریپت یا گو؛ مهم اینه که بتونید مشکل رو حل کنید.پس دفعه بعد که یه بحث داغ زبانی پیش اومد، یه نفس عمیق بکشید و یادتون باشه: مهم زبانی که استفاده میکنید نیست، مهم کاریه که باهاش انجام میدید. اگه کسی هم خواست بهتون چیز دیگه ای رو بگه، این پست رو نشونش بدید و بعد با خیال راحت برگردید به نوشتن کدهای خفنتون به هر زبانی که دوست دارید.amirsamrozveltr rezvaniamirsamrozveltr rezvaniThu, 06 Jun 2024 02:05:34 +0330