نوشته های WebPajooh

آنچه هر برنامه‌نویس تازه‌کاری باید بداند!

WebPajooh — Wed, 06 Jul 2022 17:49:15 +0430

این ویرگول، ترجمه‌ای خوب و روان (?) از پستی است که در سایت dev.to دیده بودم. اگر در ادامه با نویسنده مخالف باشم، نظر خودم را هم اضافه می‌کنم و اگر این پست را می‌بینید، یعنی مخالفتمان خیلی جدی نبوده است!یک جایی از مسیر کاریمان را به گذشته نگاه می‌کنیم؛ اینکه چگونه شروع کردیم، چگونه پیشرفت کردیم و چه چیزی برای مای کم‌تجربه خیلی مفید و سودمند بود. اکنون تصمیم گرفته‌ام که برخی نکات را -که ترتیب آنها بی‌اهمیت است- با شما که یک برنامه‌نویس تازه‌کار هستید، در میان بگذارم.وقت خود را در جنگ زبان‌ها تلف نکنید!بله، درست خواندید! این کار را نکنید! هر زبانی، چیزی دارد که برخی با آن مشکل داشته باشند و شما -به عنوان تازه‌کار- جزو آن «برخی» نیستید! یکی را انتخاب کنید و با آن پیش بروید، و تصمیم‌گیری‌های بعدی را به زمانی در آینده موکول کنید که باتجربه شده‌اید!هر جوابی که در Stackoverflow تایید شده، به درد مورد شما نمی‌خورد!می‌دانم که ناخودآگاه به دنبال پاسخ‌های تیک‌خورده می‌گردید، اما همیشه جواب درست و مناسب شما در آن نیست. دیگر جواب‌ها و حتی کامنت‌ها را بخوانید؛ زیرا در کامنت‌ها هم چیزهای خوبی را متوجه خواهید شد.قبل از کپی‌پیست‌کردن، بپرسید که این کد چگونه کار می‌کند!در هر چالش غیر قابل حل، فرصتی برای یادگیری چیزهای جدید وجود دارد، پس با pasteکردن راه‌حل، این فرصت را از دست ندهید! سعی کنید شیوۀ کار کد را بفهمید و خوب درک کنید!آموزش‌دیدن بدون تمرین‎‌کردن، اتلاف وقت است!مطمئنم که دربارۀ دوزخ آموزش (tutorial hell) شنیده‌اید و هیچ بعید نیست که این اتفاق برای شما بیفتد! اگر یک برنامه‌نویس باتجربه نیستید که هدفش از دیدن آموزش، افزایش دانش است، پیش از شروع‌کردن هر دورۀ آموزشی، بررسی کنید که آیا تمرینات عملی در آن هست یا نه؛ زیرا یادگیری واقعی در تمرین‌کردن اتفاق می‌افتد. البته تمرین هم کافی نیست، باید بگذارید که ذهنتان فعال شود و به این پرسش بپردازد که آنچه آموخته‌اید در کجا می‌تواند کاربردی شود.دانشگاه مهم است!شاید دردناک به نظر برسد، ولی تحصیلات دانشگاهی در بازار کار یک مزیت به شمار می‌رود و حتی اگر خیلی‌ها بگویند مهم نیست، در عمل چنین برخورد نمی‌کنند و ممکن است به خاطر «نداشتن بک‌گراند کافی برای نیازمندی‌ها» یک فرصت شغلی را از دست بدهید! همیشه در حال مطالعه و بهبود دانش خود باشید.مترجم: کتاب‌خواندن سرمایه‌گذاری خوبی است و باعث می‌شود که به جای آزمایش و خطا، از تجارب بزرگان حوزۀ مهندسی نرم‌افزار استفاده کنید. لیستی از کتاب‌های خوب را جمع‌آوری کنید، اولویت‌بندی کنید و بعد بخوانید. اگر مهارت قابل قبولی در زبان انگلیسی ندارید، حتما برای آن وقت بگذارید.اینکه کد کار می‌کند، به معنای خوب‌بودنش نیست!یک حقیقت دردناک دیگر! همیشه تلاش کنید که از برنامه‌نویسان باتجربه و کهنه‌کار دربارۀ کدهایی که می‌نویسید بازخورد بگیرید. اگر چنین کنید، سرعت یادگیری شما به مراتب بیشتر می‌شود و جلوتر می‌افتید.مترجم: خواندن کتاب‌هایی مثل Clean Code اثر Robert Martin و Refactoring اثر Martin Fowler می‌تواند بسیار مفید باشد. در هر زبانی، استانداردهایی مربوط به Style کدها وجود دارد که می‌توانید خود را با آنها وفق دهید.شرکت در مصاحبه‌های شغلی، خسته‌کننده هستند!جاده بسیار باریک است، پس خود را برای رد شدن آماده کنید! ممکن است سه مرحله مصاحبه را بگذرانید، و در آخر بگویند که تا نگویید فلان سیستم را چه کسی ابداع کرده، به مرحلۀ بعد نخواهید رفت! گاهی مصاحبه و شغل با هم مطابقت ندارند؛ مثلاً در نهایت با ORM کار خواهید کرد اما سؤالات عجیب SQL مطرح خواهد شد، یا اینکه قرار است REST API ساده‌ای بنویسید، اما از شما دربارۀ اینکه Node.js چگونه ساخته شد بپرسند!قوی و آماده باشید!زبان و فریمورک را بشناسید!اینکه با یک زبان یا کتابخانه، اپلیکیشن‌های CRUDمحور بسازید، کافی نیست! سعی کنید درک بهتری از سیستم به دست بیاورید، زیرا وقتی به جاهای بهتری برسید، احتمالا ابزارهایی خواهید ساخت که توسط دیگران استفاده شوند و دانشی که از این راه به دست می‌آورید، فوق‌العاده خواهد بود!مترجم: خواندن documentation بسیار بیشتر از آنچه فکر می‌کنید مفید است. همچنین ضرری ندارد که گاهی کد فریمورک یا لایبرری‌هایی که استفاده می‌کنید را بخوانید و از طرز کار آنها سر در بیاورید.تنها در حد چالش‌هایی که داشته‌اید خوب هستید!به طور ساده، تفاوت میان Junior و Senior در تجربه است! چیزهای خیلی زیادی برای آموختن هست. گاهی از خود می‌پرسید: چه چیزی بسازم؟ و وقتی با موانع رو به رو شوید، چیزهای جدیدی خواهید آموخت.بنویسید، داکیومنت کنید و وبلاگ داشته باشید!آنچه یاد می‌گیرید و تجربه می‌کنید را با دیگران هم به اشتراک بگذارید. قرار نیست که همیشه دربارۀ یک مفهوم، حق با شما باشد و حرف درست را بزنید. خیلی اوقات از بخش کامنت‌ها چیزهای زیادی یاد گرفته‌ام و بعد با خود فکر کرده‌ام که اگر نویسنده آن پست را منتشر نمی‌کرد، دیگران هم آن کامنت‌های خوب و مفید را نمی‌نوشتند!مترجم: نوشتن کامنت برای کدهایتان را هم تمرین کنید. پروژه‌هایتان را مستندسازی کنید، Readme بنویسید و طرز کار آنها را توضیح دهید.رابطه‌سازی را شروع کنید!با توسعه‌دهندگان ملاقات کنید، در رویدادها شرکت کنید، به انجمن ها بپیوندید و با دیگران تعامل داشته باشید. در آینده به مشکلاتی خواهید خورد و این آنها هستند که در را به رویتان باز می‌کنند! شبکۀ اجتماعی Linkedin ابزار مناسبی برای برندسازی و وصل‌شدن به دیگران است.شما توصیۀ دیگری دارید؟ کامنت بگذارید!

پیام خطای عجیب لاراول: هست ولی نیست!

WebPajooh — Thu, 30 Jun 2022 23:51:52 +0430

پنیر نداریم ولی پنیر داریم!امروز گرم کارکردن بودم که اتفاق عجیبی افتاد؛ خیلی وقت بود که از Blade استفاده نکرده بودم و بعد از returnکردن ویو، پیام خطایی شبیه تصویر بالا دیدم. می‌گفت ویوی x را پیدا نکردم، منظورت ویوی x نیست؟ مطمئن بودم که ویو وجود دارد، وگرنه چنین پیشنهادی نمی‌داد، اما چرا باید نام ویویی که پیدا نشده را پیشنهاد دهد؟! اگر foo.bar وجود نمی‌داشت، بی‌معنا بود که foo.bar را به عنوان شکل درست آن پیشنهاد دهد.برای اینکه بدانیم چه اتفاقی افتاده است، باید اول بپرسیم که لاراول چگونه ویوها را پیدا می‌کند؟ وقتی از هلپر فانکشن view استفاده می‌کنیم:return view('blog.post');چگونه فایل مربوط به آن را پیدا می‌کند؟ آن هم وقتی پسوند فایل را ذکر نکرده‌ایم؟ برای درک این مطلب، سراغ کلاس Illuminate\View\FileViewFinder می‌رویم:protected $extensions = ['blade.php', 'php', 'css', 'html']; protected function getPossibleViewFiles($name) { return array_map(function ($extension) use ($name) { return str_replace('.', '/', $name).'.'.$extension; }, $this->extensions); }متد getPossibleViewFiles نام ویو (در مثال ما blog.post) را دریافت می‌کند و سپس حالت‌های ممکن (یعنی نام فایل به همراه پسوندهایی که در پراپرتی extensions آمده است) را به عنوان یک آرایه برمی‌گرداند. اگر دقت کنیم، از فانکشن str_replace استفاده شده است تا نقطه را تبدیل به slash کند. یعنی blog.post تبدیل به blog/post می‌شود، و به این صورت لاراول می‌تواند یک ویو را از پوشه‌های تو در تو پیدا کند.وقتی چنین باشد، ما نمی‌توانیم از نقطه در نام خود فایل استفاده کنیم! این نکته در داکیومنتیشن هم آمده است:View directory names should not contain the . character.به مثال قبلی برگردیم: نام ویو را foo.bar گذاشته بودم و لاراول تصور می‌کرد که چنین فایلی باید در این مسیر باشد:resources/views/foo/bar.{blade.php/php/css/html}از آنجا که ویویی به نام bar در آن مسیر وجود ندارد، متد findInPaths به اینجا می‌رسد:throw new InvalidArgumentException("View [{$name}] not found.");تا اینجای کار همه‌چیز طبیعی است و مشکل در کارکرد این کلاس نبود. مشکل از آنجا شروع می‌شود که پکیج facade/ignition به برنامه‌نویس پیشنهاداتی می‌دهد؛ مثلاً اگر در نوشتن نام ویو خطای تایپی داشته باشید، سعی می‌کند نام اصلی فایل را پیدا کند و پیشنهاد دهد.این اتفاق، در کلاس Facade\Ignition\SolutionProviders\ViewNotFoundSolutionProvider می‌افتد:public function getSolutions(Throwable $throwable): array { $suggestedView = $this->findRelatedView($missingView); if ($suggestedView) { return [ BaseSolution::create("{$missingView} was not found.") ->setSolutionDescription("Did you mean `{$suggestedView}`?"), ]; } return [ BaseSolution::create("{$missingView} was not found.") ->setSolutionDescription('Are you sure the view exists and is a `.blade.php` file?'), ]; }قسمت‌هایی از کدهای متد را حذف کرده‌ام تا قسمت‌هایی که مربوط به موضوع ما هستند را ببینید. با کمک متد findRelatedView تلاش می‌شود تا ویوی مرتبط با ویوی درخواست‌شده پیدا شود. اگر پیدا شد، عبارت Did you mean... برگردانده می‌شود (یعنی حالتی که کاربر خطای تایپی داشته است و ویویی با نام مشابه وجود دارد) و در غیر این صورت به کاربر پیشنهاد می‌شود که مطمئن شود که چنین ویویی وجود دارد.از آنجا که ما foo.bar را واقعاً ساخته بودیم، متد findRelatedView آن را پیدا می‌کند و سناریوی اول اتفاق می‌افتد: پیشنهاددادن!foo.bar was not found. Did you mean foo.bar?شاید الآن خنده‌دار و جالب به نظر برسد، ولی من در ابتدا گیج شده بودم و حتی فکر می‌کردم که این دو با هم فرق دارند و چشم من از فرط خستگی قادر به تشخیص تفاوتشان نیست! اما واقعاً یکی بودند: foo.bar را پیدا نکردم، نکند که منظورت foo.bar بوده باشد؟! ?بعد از ظهر، ساعت کاری‌ام تمام شده بود و دوباره کنجکاو شدم که مشکل آن را حل کنم. به سرعت متوجه شدم که این مشکل از کلاس خود لاراول نیست، بلکه از پکیجی است که لاراول برای نمایش خطاها استفاده می‌کند. ریپازیتوری را فورک کردم و تغییرات لازم را برای حل این مشکل انجام دادم: https://github.com/facade/ignition/pull/457 خوشبختانه ساعتی قبل این pull request تایید شد و پیام Freek شبم را ساخت:Thanks!نتیجه‌گیریِ اخلاقیِ پست این بود که همیشه داکیومنتیشن را بخوانید تا اشتباهات عجیبی مانند آنچه صبح مرتکب شدم -استفاده از نقطه در نام ویو- را مرتکب نشوید؛ نقطه ممنوع!

فهمیدن LSP - یک‌بار برای همیشه!

WebPajooh — Mon, 27 Jun 2022 17:58:37 +0430

مقدمهاگر به دنبال یادگیری اصول SOLID بوده باشید، احتمالا فهم اصل سوم برایتان دشوار بوده است. مقالات بسیاری در فضای مجازی فارسی وجود دارند که غالبا حق مطلب را ادا نکرده و تنها مطالب سایت‌های دیگر را تکرار می‌کنند و همین باعث شده که بعد از خواندنشان دچار سرگردانی و گیجی شویم یا اینکه به اشتباه فکر کنیم که این اصول را فهمیده‌ایم، با اینکه چیزی دست‌گیرمان نشده است!این اصل، نام عجیبی دارد که احتمالا آدم را بترساند، اما حداقل فهمیدن نام آن سخت نیست! منظور از کلمۀ اول این عبارت (Liskov)، باربارا لسکوف است که یک دانشمند حوزۀ کامپیوتر بود و کلمۀ دوم (Substitution) به معنای استفاده‌کردن چیزی به جای چیزی دیگر است. کلمۀ دوم برای ما مهم است، زیرا کلید فهم این اصل در همین‌جاست: جایگزینی!تعریفLet Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.یا واضح‌تر از آن، اینکه:If S is a subtype of T, then objects of type T may be replaced with objects of type S, without breaking the program.بیایید T را superclass (مثل Animal) و S را یک subclass فرض کنیم (مثل Cat)؛ اگر آبجکتی از T را در جایی استفاده می‌کنیم، باید آبجکتی از S هم بتواند جایگزین آن شود و کار همچنان ادامه بیابد. اگر این جابه‌جایی دردسرساز شد، یعنی LSP نقض شده است.مثال‌هامثال 1: مستطیل و مربعمثال مشهور مستطیل و مربع! به کد زیر دقت کنید:width = $width; $this->height = $height; } public function setWidth($width) { $this->width = $width; } public function setHeight($height) { $this->height = $height; } public function getArea() { return $this->width * $this->height; } } $shape = new Rectangle(2, 3); $shape->setWidth(4); $shape->setHeight(6) assert($shape->getArea() == 24); // 4 x 6 = 24همه‌چیز خوب کار می‌کند و همه خوشحال‌اند، تا اینکه مشتری تماس می‌گیرد و پشتیبانی از مربع را هم می‌خواهد! با خودمان فکر می‌کنیم که هر مربع را می‌شود مستطیل هم در نظر گرفت، پس کلاس مربع می‌تواند از کلاس مستطیل که قبلاً ساخته بودیم، ارث‌بری کند. از آنجا که طول و عرض مربع برابر است، نباید به کاربر اجازه داد تا از مربع، مستطیل بسازد! کد مربوط به کلاس مربع را ببینیم:width = $width; $this->height = $width; } public function setHeight($height) { $this->height = $height; $this->width = $height; } }سپس... جابه‌جایی مستطیل با مربع اتفاق می‌افتد:$shape = new Square (2, 2); $shape->setWidth(4); $shape->setHeight(6); assert($shape->getArea() == 24); // fatal error, 6 x 6 = 36کلاس مربع، رفتار کلاس پدر خود یعنی مستطیل را تغییر داده است و چنین اتفاق غیر منتظره‌ای افتاد. این یعنی آبجکتی از Square نمی‌تواند جایگزین آبجکتی از Rectangle شود و همین نشان می‌دهد که در طراحی اشتباه کرده‌ایم!مثال 2: اسلحه وسیلۀ بازی نیست!این، شکل دیگری از مثال معروف اردک است. به کد زیر دقت کنید:shot(); }کد استفاده‌کننده از Gun، انتظار هیچ Exceptionای را نمی‌کشیده است و تغییر رفتار Gun توسط ToyGun اصل سوم SOLID را نقض کرد. اصلاً چه کسی گفته که تفنگ اسباب‌بازی باید از تفنگ ارث‌بری کند؟ ارتباط در Inheritance، یک is-a است اما:Toy gun is not a gun!چنین مواردی به ما گوشزد می‌کنند که is-a راه‌حل همیشگی نیست و گاهی باید سراغ has-a برویم، یعنی: Composition! اما بگذریم... نکتۀ مثال دوم این است که اگر کلاس پدر یک نوع از Exception را throw کرد، کلاس‌های فرزند نباید چیزی فراتر از آن را throw کنند زیرا کد استفاده‌کننده (Client) آمادگی چنین چیزی را ندارد! آقای Alexander Shvets می‌گوید:Types of exceptions should match or be subtypes of the ones that the base method is already able to throw.یعنی نوع Exceptionها باید دقیقاً همان‌هایی باشد که بوده، یا زیرمجموعۀ آنها باشد و دیگر از Exception جدیدی استفاده نشود. اگر تا الآن خبر نداشتید که در PHP خودمان می‌توانیم Exception بسازیم و از آنها ارث‌بری کنیم، این بخش از داکیومنتیشن را بخوانید!مثال 3: آپلودر جدید!به کد زیر دقت کنید:upload($file);این کد به خوبی کار می‌کند، اما تصور کنید کلاس جدیدی بر اساس کلاس Uploader به نام FTPUploader بسازیم و متد upload را override کنیم. LSP به ما می‌گوید که نوع آرگومانی که به این متد داده می‌شود، باید همان Document یا چیزی عام‌تر از آن باشد.کلاس File از کلاس Document عام‌تر است؛ زیرا هر Document یک File حساب می‌شود اما هر File لزوماً یک Document نیست. همچنین کلاس Document از کلاس PDFDocument عام‌تر است، زیرا هر PDFDocument یک Document هم حساب می‌شود، اما Document می‌تواند علاوه بر pdf، فرمت docx یا txt هم داشته باشد.بعد از فهمیدن پاراگراف بالا، کلاس جدید را ببینید:class FTPUploader extends Uploader { public function upload(... $file) { // 100 lines of code } }جای یک Type در ... خالی است! با توضیحاتی که گفته شد، متدِ کلاسِ جدید می‌تواند Document و همچنین File را بپذیرد (File از Document عام‌تر است)، اما PDFDocument از نوع پارامتری که کلاس پدر می‌گرفت خاص‌تر است و LSP را نقض می‌کند. اگر PDFDocument را به جای Type قرار دهیم، و کلاس FTPUploader را جایگزین کلاس Uploader کنیم:$file = new Document; $uploader = new FTPUploader; // Look at here $uploader->upload($file);با خطای زیر مواجه خواهیم شد:Fatal error: Declaration of FTPUploader::upload(PDFDocument $file) must be compatible with Uploader::upload(Document $file)اما اگر Type را File در نظر بگیریم، این خطا را نمی‌بینیم؛ زیرا Document هم یک File است و در نتیجه کد به درستی کار خواهد کرد!مثال 4: کالکشن به جای آرایه!این مثال را در ویدئویی از Jeffrey Way دیده بودم و شاید از مثال‌های گذشته قابل‌درک‌تر باشد. در لاراول، کلاسی به نام Collection داریم که چیزی شبیه آرایه اما بسیار قدرت‌مندتر ارائه می‌کند. اگر superclass یک متد با خروجی array دارد، همان متد در subclass هم باید خروجی array داشته باشد؛ زیرا اگر چنین نباشد، در صورت جایگزین‌کردن subclass با superclass، امکان بروز خطا وجود خواهد داشت:$scores = (new SubClass())->getScore(); // Returns a collection return array_sum($scores);از آنجا که فانکشن array_sum با آرایه‌ها کار می‌کند و کدی که از کلاس استفاده می‌کرد، توقع یک آرایه را از متد getScore داشت، با گذاشتن subclass به جای superclass، خطای زیر را خواهیم دید:array_sum(): Argument #1 ($array) must be of type array, Illuminate\Support\Collection givenمثال 5: اما و اگر نداریم!کلاس A متدی به نام submitPoints دارد که یک آرگومان int را می‌پذیرد. اگر کلاس B طوری آن را override کند که تنها اعداد مثبت را بپذیرد:public function submitPoints(int $points) { if ($points < 1) { throw new Exception('I want you to give me positive numbers!'); } // Logic here }قوی‌کردن پیش‌شرط‌ها خوب نیست و کدی که با کلاس قبلی کار می‌کرده و اعداد منفی هم وارد آن می‌شده، با جایگزین‌شدن کلاس جدید، به مشکل خواهد خورد!مثال 6: کانکشن‌های باز و کلاس دردسرساز!این مثال شبیه مثال قبلی است، اما به پس‌شرط‌ها (post-conditions) مربوط می‌شود. مثال Shvet این است که کلاس A کانکشن‌های دیتابیس را بعد از استفاده می‌بسته، اما کلاس جدید چنین نمی‌کند و کانکشن‌ها را برای استفادۀ مجدد، زنده نگه می‌دارد! کدی که از کلاس استفاده می‌کرده، از قصد برنامه‌نویس خبر ندارد و وقتی جایگزینی B به جای A صورت بگیرد، کانکشن‌های باز زیادی باقی خواهد ماند!البته ما اهمیت خاصی به بستن کانکشن‌های MySQL نمی‌دادیم و دلیلش را هم می‌دانید، اما به نظرم مثال خوب و واضحی است.نتیجه‌گیریبا اصل سوم SOLID یعنی Liskov Substitution Principle طراحی‌های بهتری خواهیم داشت و ارث‌بری را صرفاً برای افزودن متدهای جدید امتحان نخواهیم کرد. در یک زنجیره (برای نمونه، زنجیرۀ حیوانات را تصور کنید)، آبجکت هر کلاس باید بدون مشکل با آبجکتی از کلاس دیگری که subtype است جایگزین شود و کد به کار خود ادامه دهد. امیدوارم این مقاله به شما کمک کرده باشد و فهم بهتری از LSP به دست آورده باشید.منابع:Dive Into Design Patterns, by Alexander Shvets.Clean Architecture, by Robert Martin.https://laracasts.com/series/solid-principles-in-php/episodes/3

قابلیت کرم‌چاله در تست لاراول

WebPajooh — Thu, 14 Apr 2022 18:08:46 +0430

کرم‌چاله را می‌توان به صورت تونلی تصور کرد که پایانه‌های آن در نقاط مجزایی از فضا-زمان قرار دارند.صورت مسئلهدر حال ساختن وب‌سایت برای یک رویداد خیلی مهم هستیم. افراد برای این رویداد خیلی مهم صندلی رزرو می‌کنند و مهلت رزرو بلیت تا آخر ماه آوریل است. کد زیر یک مثال برای کنترل این وضعیت است:کد رزرواسیوناکنون می‌خواهیم برای این کد، تست بنویسیم...نوشتن تست و مشکل زمانبا صرف نظر از Validation، دو حالت قابل تصور است:تاریخ امروز قبل از سی‌ام آوریل است و یک id در پاسخ برگردانده می‌شود.تاریخ امروز بعد از سی‌ام آوریل است و پیام خطا مشاهده می‌شود.پس ما باید زمان فعلی را اصطلاحاً fake کنیم تا بتوانیم برای این دو حالت فرضی تست بنویسیم، وگرنه زمان فعلی، همان زمان اجرای تست در نظر گرفته خواهد شد و باید تا روز اول ماه می صبر کنیم و بعد دوباره تست را اجرا کنیم تا مطمئن شویم که سناریوی دوم درست کار می‌کند! (چه احمقانه)استفاده از متد setTestNowکتابخانۀ Carbon یک static method به نام setTestNow به این منظور نوشته بود که قبلاً استفاده می‌شد. با همین روش دو تست برای حالت‌های اول و دوم می‌نویسیم:public function test_people_can_reserve_before_the_deadline() { $data = [ 'email' => 'alireza@gmail.com', 'age' => 25, ]; Carbon::setTestNow(Carbon::createFromDate(2022, 04, 29)); $this->post('/api/reservations', $data) ->assertJsonStructure(['id']); }public function test_people_can_reserve_after_the_deadline() { $data = [ 'email' => 'parsa@gmail.com', 'age' => 23, ]; Carbon::setTestNow(Carbon::createFromDate(2022, 04, 30)); $this->post('/api/reservations', $data) ->assertJson(['error' => "It's too late!"]); }کرم‌چالۀ لاراولدر لاراول 8 قابلیتی اضافه شد که سفر در زمان را آسان‌تر کرد. کلاس TestCase از تریت Concerns\InteractsWithTime استفاده می‌کند که متدهایی را برای تغییر زمان پیاده کرده‌اند. اکنون به جای متد setTestNow به صورت زیر عمل می‌کنیم:$this->travelTo(Carbon::createFromDate(2022, 04, 29));گاهی نیاز داریم که زمان را به طور نسبی تغییر دهیم، مثلاً پنج ساعت قبل را شبیه‌سازی کنیم. در اینجا از متد travel استفاده می‌کنیم که عددی را به عنوان ورودی می‌گیرد و آبجکت Wormhole را برمی‌گرداند که متدهای جالبی روی آن پیاده شده است:$this->travel(-5)->hours();اگر بخواهیم به زمان حال برگردیم، از متد travelBack استفاده می‌کنیم:$this->travelBack();همچنین اگر بخواهیم که زمان را در هنگام اجرای تعدادی از دستورات متوقف کنیم، متد freezeTime را استفاده می‌کنیم که یک closure به عنوان آرگومان می‌پذیرد.انتخاب عنوان‌هایی مثل travel یا Wormhole که بیشتر از انتزاع به واقعیت نزدیک است می‌تواند ایدۀ جالبی باشد و حتی خوانایی کدها را به نحوی بالاتر ببرد. چنین قابلیت‌هایی نوشتن تست را آسان‌تر کرده و به گسترش فرهنگ تست‌نویسی کمک می‌کنند.برای مطالعۀ بیشتر، به مستندات رسمی لاراول مراجعه کنید:https://laravel.com/docs/9.x/mocking#interacting-with-time

Pruning Models

WebPajooh — Sat, 30 Oct 2021 21:24:32 +0330

تا به حال در پروژه‌ای نیاز به این داشته‌اید که رکوردهای قدیمی دیتابیس را حذف کنید؟ در مواردی نیاز داریم که همه‌چیز باقی بماند، مثل تیکت‌های پشتیبانی که سوابق ضروری سرویس‌گیرنده هستند. اما شرایطی را در نظر بگیرید (اپلیکیشنی مثل دیوار که نیازی به آرشیو آگهی‌هایش ندارد، یا شاید هم دارد؟) که واقعا نیازی به رکوردهای قدیمی نداشته باشیم و بخواهیم آنها را با شروط خاصی حذف کنیم.لاراول برای این هم راه‌حل دارد!آقای Nuno Maduro در یک Pull Request پیشنهاد کرد که چنین قابلیتی به لاراول اضافه شود تا با پیامی زمان‌بندی‌شده، رکوردها را به صورت اتوماتیک حذف کنیم و این پیشنهاد بسیار مورد استقبال قرار گرفت. در مستندات لاراول، این خاصیت را به این شیوه تعریف کرده‌اند:Sometimes you may want to periodically delete models that are no longer needed.شاید گاهی بخواهید که به صورت دوره‌ای، مدل‌هایی که دیگر نیازی به آنها نیست را حذف کنید.فعل Prune در انگلیسی به معنای هرس‌کردن است. انگار با حذف‌کردن رکوردهایی که نیاز نداریم، جدول مربوط به آن مدل‌ها را هرس می‌کنیم.چگونه از آن استفاده کنیم؟ابتدا Trait مربوط به آن یعنی Prunable را به مدلی که می‌خواهیم اضافه می‌کنیم:class Ticket extends Model { use Prunable;اما لاراول از کجا بداند که ما به چه رکوردهایی نیاز نداریم؟! در Prunable که به عنوان Trait اضافه شد، متدی به نام ()prunable وجود دارد که خروجی آن از جنس Builder است و اگر در مدل پیاده‌سازی نشود، بعدها یک Exception بر خواهد گرداند. من چنین شرطی گذاشتم:public function prunable() { return static::where('created_at', '<', now()->subMonth()); }پس هر رکوردی که تاریخ ایجاد آن از یک ماه پیش قدیمی‌تر باشد، حذف خواهد شد. می‌توانیم شروطی دیگری هم اضافه کنیم:public function prunable() { return static::where('created_at', '<', now()->subDay()) ->where('is_vip', false); }حالا می‌توانیم با دستور model:prune به آزمایش آنچه انجام داده‌ایم بپردازیم:λ php artisan model:prune 571 [App\Models\Ticket] records have been pruned.عالی شد! با این دستور، مدل‌هایی که Prunable (قابل هرس) بودند به طور خودکار شناسایی شده و رکوردهای غیر ضروریشان (بر اساس متد prunable که خودمان تعریف کردیم) حذف خواهد شد.البته برای آسان‌ترشدن کار، از متد schedule کلاس App\Console\Kernel برای زمان‌بندی استفاده می‌کنیم تا این اتفاق به صورت روزانه تکرار شود:protected function schedule(Schedule $schedule) { $schedule->command('model:prune')->daily(); }گزینه‌ی pretend هم روی میز است!گاهی قصد جدی برای حذف رکوردها نداریم و فقط می‌خواهیم بدانیم که اگر دستور model:prune را اجرا کنیم، چند رکورد حذف خواهد شد. در این صورت از یک option به نام pretend استفاده می‌کنیم:λ php artisan model:prune --pretend 58 [App\Models\Password] records will be pruned.گزینه‌ی chunkدستور model:prune یک گزینه‌ی دیگر به نام chunk دارد که توضیحش را در مستندات لاراول ندیدم. با این گزینه مشخص می‌کنیم که در هر chunk، چند مدل برای حذف‌شدن برگردانده شود و مقدار پیشفرضش 1000 است:λ php artisan model:prune --chunk=100متد ()pruningیکی از متدهای تریت Prunable، متدی به نام pruning است که مشخص می‌کند قبل از حذف یک مدل چه اتفاقی بیفتد. مثلاً بلیتی که ما تولید می‌کنیم یک فایل pdf روی سرور دارد و باید با حذف رکوردهای قدیمی، آن فایل‌ها هم حذف شوند یا دیوار را در نظر بگیرید که باید تصاویر، گزارشات و دیگر موارد مربوط به آگهی را هم حذف کند. در این صورت از متد pruning در کلاس مربوط به مدل بلیت استفاده می‌کنیم و کدهای دلخواهمان را در آن می‌نویسیم:public function pruning() { $this->file()->delete(); }حتما می‌دانید که this$ به نمونه‌ای از کلاس فعلی اشاره دارد و اگر باور نمی‌کنید، با ()dd چیزی که گفتم را آزمایش کنید!کمی عمیق‌تر!دستور model:prune چگونه کار می‌کند؟ اگر با Commandها آشنایی ندارید، توصیه می‌کنم بخش مربوط به Console از مستندات لاراول را مطالعه کنید.کلاس PruneCommand یک Command است:Illuminate\Database\Console\PruneCommandبا اجرای دستور model:prune متد handle این کلاس اجرا می‌شود كه کد تمیزی دارد:$models = $this->models();مدل‌هایی که تریت Prunable را استفاده کرده‌اند در متغیر models$ جمع می‌شوند.if ($models->isEmpty()) { $this->info('No prunable models found.'); return; }اگر هیچ مدل Prunableای در پروژه نباشد، یک پیام برگردانده می‌شود و همه‌چیز تمام می‌شود!if ($this->option('pretend')) { $models->each(function ($model) { $this->pretendToPrune($model); }); return; }اگر گزینه‌ی pretend وارد شده باشد، متد pretendToPrune را برای تک‌تک آنها اجرا می‌کند. اما اگر اینطور نبود؟$events->listen(ModelsPruned::class, function ($event) { $this->info("{$event->count} [{$event->model}] records have been pruned."); });یک Event Listener برای رویداد ModelsPruned ثبت می‌کند. این رویداد در متد ()pruneAll تریت Prunable بعد از حذف‌کردن مدل‌ها و شمارش آنها اتفاق خواهد افتاد. پیامی که در ترمینال خواهیم دید، توسط این Event Listener تولید می‌شود.$models->each(function ($model) { $instance = new $model; $chunkSize = property_exists($instance, 'prunableChunkSize') ? $instance->prunableChunkSize : $this->option('chunk'); $total = $this->isPrunable($model) ? $instance->pruneAll($chunkSize) : 0; if ($total == 0) { $this->info("No prunable [$model] records found."); } });به ازای هر مدل، این کارها انجام می‌شود: یک نمونه به نام instance ساخته می‌شود. سپس اگر روی مدل، مشخصه‌ای به نام prunableChunkSize تعریف شده باشد، آن را به عنوان سایز هر قطعه در نظر می‌گیرد (این نکته در مستندات لاراول نیست) وگرنه از گزینه‌ی chunk که در خط فرمان تعیین شده باشد استفاده می‌کند. اگر خواستید مقدار آن را در مدل تعیین کنید، کار سختی در پیش ندارید:class Ticket extends Model { public $prunableChunkSize = 200;بگذریم... بعد از آن تعداد مدل‌های حذف‌شده در total$ قرار داده می‌شود و اگر total$ برابر صفر باشد (یعنی رکوردی برای حذف نباشد)، پیام مناسبی نمایش داده خواهد شد. صدازدن متد ()pruneAll روی instance$ بخش مهم کار را انجام می‌دهد:public function pruneAll(int $chunkSize = 1000) { $total = 0; $this->prunable() ->when(in_array(SoftDeletes::class, class_uses_recursive(get_class($this))), function ($query) { $query->withTrashed(); })->chunkById($chunkSize, function ($models) use (&$total) { $models->each->prune(); $total += $models->count(); event(new ModelsPruned(static::class, $total)); }); return $total; }این متد در تریت Prunable قرار دارد و می‌توانید dispatchشدن رویداد ModelsPruned را هم در آن ببینید. ماجرا با متد prunable آغاز می‌شود که خودمان آن را در مدل تعریف کردیم و یک نمونه‌ی Builder را return کرد.امیدوارم که از مقاله استفاده کرده باشید. این مقاله شکوه لاراول را نشان می‌دهد و همچنین اهمیت مطالعه‌ی کدها و اتفاقاتی که پشت پرده رخ می‌دهند. با خواندن کدهای ابزاری که با آن کار می‌کنیم، درک عمیق‌تری از آن خواهیم داشت و این روی خروجی کارمان تاثیرات به‌سزایی خواهد گذاشت.کد تمیز بخوانید و کد تمیز بنویسید. ?

چرا نرم‌افزارها تغییر می‌کنند؟

WebPajooh — Fri, 03 Sep 2021 20:13:59 +0430

"همه‌چیز تغییر می‌کند و دیگر هیچ‌چیزی مانند سابق نخواهد بود... زندگی همین است! زندگی به پیش می‌رود و ما هم باید چنین باشیم!" (اسپنسر جانسون: چه کسی پنیر مرا جابه‌جا کرد؟)تغییر نرم‌افزار، غیر قابل اجتناب است. نه تنها مشکلی ندارد، می‌تواند عالی هم باشد! زیر نظر گرفتن تغییرات، معلّم خوبی است و به ما کمک می‌کند که حوزه‌ی تخصصی خود را بهتر و عمیق‌تر درک کنیم و بسیاری از اشتباهات را مرتکب نشویم. مادری را مثال می‌زنم که اولین فرزند خود را به دنیا می‌آورد و رشد کودکش را زیر نظر می‌گیرد و از آن تجاربی به دست می‌آورد؛ بعد از تربیت چند کودک، آشنایی بسیار خوبی با مراحل رشد و مقتضیات سنین مختلف خواهد داشت.البته ما نرم‌افزار را بی‌علت تغییر نمی‌دهیم! مايكل فزرس (Michael Feathers) چهار دلیل عمده برای تغییر نرم‌افزارها ذکر می‌کند:اضافه‌کردن یک قابلیتنیاز مشتریان تا ابد ثابت نمی‌ماند و ممکن است نیازهای جدیدی داشته باشند. از سویی دیگر، محصول شما رقیبانی در بازار دارد که نباید از آنها عقب بمانید. فرض کنید برای شرکتی کار می‌کنید که محصولی مشابه Medium را می‌سازد. قابلیت‌های جدید Medium را پیاده‌سازی می‌کند و همچنین نیازهای دیگری که کاربران ایرانی دارند را برآورده می‌کند، مانند امکان درون‌ریزی (import) از سیستم‌های وبلاگ‌دهی که در حال شکست هستند.اصلاح‌کردن یک باگباگ نرم‌افزاری، یک ارور یا نقص فنی در یک برنامه‌ی کامپیوتری است که می‌تواند منجر به یک نتیجه‌ی اشتباه یا غیر قابل پیش‌بینی شود.یکی دیگر از دلایل تغییر نرم‌افزار، اصلاح‌کردن باگ‌ها (fixing bugs) است. اصطلاح باگ به شکل وسیعی قبل از حوزه‌ی نرم‌افزار، در حوزه‌های دیگر مهندسی به کار می‌رفته و حتی ادیسون هم از آن استفاده کرده است! باگ‌ها انواع زیادی دارند؛ بعضی منجر به خطایی بحرانی می‌شوند که برنامه را متوقف می‌کند و بعضی دیگر موجب عملکرد نادرست یا مشکلات امنیتی می‌گردند. پس از اینکه نرم‌افزار منتشر شود، توسط کاربران زیادی در شرایط مختلف استفاده می‌شود و همین، اشکالات زیادی را به ما خواهد شناساند. برنامه‌نویسان برای حل اشکالات شناسایی‌شده، نرم‌افزار را تغییر می‌دهند و این تغییر می‌تواند در هر سطحی اتفاق بیفتد.بهبود طراحیاین نوع متفاوتی از تغییر نرم‌افزار است. می‌خواهیم ساختار نرم‌افزار را به نحوی تغییر دهیم که قابلیت نگهداری (maintainability) افزایش یابد، اما رفتار (behavior) آن دست‌نخورده و سالم باقی بماند! مایکل فزرس می‌گوید:The act of improving design without changing its behavior is called refactoring.یعنی عمل بهبود طراحی نرم‌افزار -بدون اینکه رفتار آن تغییر کند- را ریفکتورینگ می‌گوییم. مارتین فولر (Martin Fowler) هم دو تعریف برای ریفکتورینگ آورده که یکی بنا بر فرم اسمی (noun form: refactoring) و دیگری بنا بر فرم فعلی (verb form: refactor) آن است. بر اساس تعریف اول:Change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.تغییرات به ساختار داخلی نرم‌افزار اعمال می‌شود تا برای دیگران قابل‌فهم‌تر و دستکاری آن -بدون تغییر رفتار قابل مشاهده‌اش- ارزان‌تر باشد.امیدوارم آنچه گفته شد به شما دید مناسبی از ریفکتورینگ داده باشد. وقتی نرم‌افزار را برای تحقق اهداف کوتاه‌مدت تغییر می‌دهیم و به ساختار کلی پروژه توجه نمی‌کنیم، نرم‌افزار به سوی خرابی می‌رود و نگهداری آن مشکل می‌شود؛ در آینده‌ی نه‌چندان دور به آسانی قادر به اعمال تغییرات و افزودن قابلیت‌های جدید نخواهیم بود و کارمان شبیه یافتن سوزن در انبار کاه خواهد شد. اما ریفکتورینگ مداوم، شکل نرم‌افزار را حفظ کرده و از اینکه غیر قابل کنترل شود، جلوگیری می‌کند.فایده‌ی دیگر ریفکتورینگ این است که فهم نرم‌افزار را آسان می‌کند. شما کدهایتان را تنها برای کامپیوتر نمی‌نویسید بلکه افراد دیگری هم مجبور به خواندن آنها هستند تا نرم‌افزار را توسعه دهند، پس باید کدی بنویسید که ساختار ایده‌آلی داشته باشد و منظور خود را به وضوح بیان کند! رابرت مارتین (Robert Martin) در مقدمه‌ی Clean Code تعریف‌های مختلفی از «کد تمیز» آورده و واحد WTFs/minute را برای اندازه‌گیری کیفیت کد در بازبینی (review) معرفی می‌کند که جای تأمل دارد، خودتان باید کتاب را بخوانید!مارتین فولر فایده‌ی دیگری برای ریفکتورینگ ذکر می‌کند و آن هم کشف باگ‌هاست؛ او می‌گوید که من در شناسایی باگ‌ها از طریق خواندن کد، خیلی خوب نیستم، ولی وقتی به ریفکتورینگ می‌پردازم، با درکی که از ساختار کد پیدا کرده‌ام، باگ‌ها را شناسایی می‌کنم!آیا ریفکتورینگ باعث توسعه‌ی سریع‌تر هم می‌شود؟ جواب مثبت است زیرا از راهی که قبلاً صاف و هموار کرده‌اید عبور می‌کنید!بهینه‌سازی مصرف منابعبهینه‌سازی (optimization) مانند ریفکتورینگ است، اما هدف متفاوتی از طریق آن دنبال می‌شود. در خصوص هردویشان می‌گوییم که «ما عملکرد را دقیقاً همانطوری که هست باقی می‌گذاریم و قصدمان چیز دیگری است»، ولی در ریفکتورینگ آن «چیز دیگر» ساختار برنامه است؛ یعنی می‌خواهیم نگهداری برنامه را آسان‌تر کنیم. درباره‌ی بهینه‌سازی چطور؟ در اینجا «چیز دیگر» نحوه‌ی استفاده از منابع (معمولاً زمان و حافظه) است و می‌خواهیم مصرفشان را کاهش دهیم تا بازدهی نرم‌افزار افزایش یابد.بعد از تمام این‌ها، شما را به خواندن مقاله‌ی زیر دعوت می‌کنم:https://virgool.io/@WebPajooh/soghote-narmafzarha-ap2pkaaw4om1منابعی که این مقاله را شکل دادند:Working Effectively with Legacy Code by Michael Feathers.Refactoring by Martin Fowler.https://en.wikipedia.org/wiki/Software_bug

چگونه نرم‌افزارها سقوط می‌کنند؟

WebPajooh — Thu, 12 Aug 2021 18:44:26 +0430

یک نرم‌افزار به هزار و یک دلیل سقوط می‌کند. کاری با بازاریابی ناکارآمد یا دلایل ناشناخته‌ی دیگر ندارم و تنها چند تجربه‌ی فنی خودم را می‌نویسم. چرا یک نرم‌افزار با گذر زمان شکننده‌تر می‌شود و هرچه جلوتر بروید، کنترل و تسلط کمتری احساس می‌کنید؟نداشتن تستزمانی تست‌نوشتن را بیهوده می‌دانستم و درک نمی‌کردم که تست‌نوشتن چه فایده‌ای دارد. بعداً با پروژه‌های مختلفی سر و کار داشتم که بزرگ‌تر و بزرگ‌تر می‌شدند و تغییردادنشان ریسک داشت و ممکن بود با تغییر یک متد، قسمت‌های مختلف پروژه از کار بیفتند. تست‌ها باید به صورت استاندارد و با دقت نوشته شوند و بخش‌های مختلف نرم‌افزار را پوشش دهند. برای هر چیزی که ممکن است در آینده با مشکل مواجه شود (یعنی تقریباً همه‌چیز D:) تست بنویسید.در این باره، Michael Feathers نوشته است:The tests that we write to characterize code are very important. They are the documentation of the system’s actual behavior. Like any documentation that you write, you have to think about what will be important to the reader. Put yourself in the reader’s shoes. (Working Effectively with Legacy Code, p189)تست‌هایی که برای توصیف کد خود می‌نویسیم، بسیار مهم هستند. آنها مستندات رفتار واقعی سیستم هستند. مثل هر مستنداتی که می‌نویسید، باید به این فکر کنید که چه چیزی برای خواننده اهمیت دارد. خودتان را در کفش‌های خواننده قرار دهید و جای او باشید.رابرت مارتین هم در کتاب Clean Code مانند آن را می‌گوید:Well-written unit tests are also expressive. A primary goal of tests is to act as documentation by example. Someone reading our tests should be able to get a quick understanding of what a class is all about. (Clean Code, p175)یونیت‌تست‌هایی که خوب نوشته شده باشند، واضح و رسا هستند. یکی از اهداف اصلی تست‌ها این است که به عنوان مستندات عمل کنند و کسی که تست‌هایمان را می‌خواند، فهم مختصری از اینکه یک کلاس چه‌کاره است به دست بیاورد.نداشتن مستنداتپروژه‌ای که مستندات نداشته باشد، مانند جعبه‌ای است که راهی برای کشف محتویاتش نیست، جز اینکه آن را تکان دهیم! مستندات باید کلید فهم ساختار پروژه، موجودیت‌ها و اصطلاحات به‌کاررفته در پروژه را به برنامه‌نویسان جدید بدهد و آنها را در کمترین زمان با کارهایی که در گذشته انجام شده آشنا کند.استفاده‌نکردن از نام‌های گویانام جدول‌های دیتابیس، ماژول‌ها، کلاس‌ها، متدها و متغیرها را با دقت انتخاب کنید، حتی اگر به قیمت طولانی‌شدنشان تمام شود! این موضوع آن قدر مهم است که رابرت مارتین، فصل دوم کتاب Clean Code را به آن اختصاص داده است و می‌گوید:Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you do. (Clean Code, p18)انتخاب نام خوب، وقت‌گیر است ولی در عوض وقت بیشتری را به شما برمی‌گرداند، بنابراین مراقب نام‌هایی که انتخاب می‌کنید باشید و هر وقت جایگزین بهتری پیدا کردید، آنها را تغییر دهید. اگر چنین کنید، کسانی که کد شما را می‌خوانند (از جمله خود شما) شادتر خواهند بود!شاید کلاس CheckUser برای شما آشنا باشد، ولی نفر بعدی که به تیم می‌پیوندد و روی کد شما کار می‌کند هیچ درکی از آن نخواهد داشت و باید به اجبار تمام کد را بخواند تا بفهمد منظور از CheckUser چیست و این کلاس چه مسئولیتی دارد!همه‌چیز را به روش خودتان انجام می‌دهیدبرنامه‌نویسان می‌توانند زبان مشترکی داشته باشند و حرف همدیگر را بهتر بفهمند. فریم‌ورک لاراول Queue را پیاده‌سازی کرده است و هر برنامه‌نویسی که با آن آشنا باشد، می‌فهمد که پوشه‌ی Jobs برای چیست و Job چه کاری دارد. اما تصور کنید که Queue خودم را از صفر پیاده‌سازی کرده باشم و نامش را Servant بگذارم، چه کسی آن را کشف می‌کند؟! قابلیت‌های فریم‌ورک را بشناسید و چرخ را از نو اختراع نکنید، دیزاین‌پترن‌ها را به خوبی یاد بگیرید و در جای مناسب به کار ببرید تا زبان مشترک بین شما و سایر برنامه‌نویسان باشند. اگر چنین باشد، آنها خواهند دانست که کلاس CoffeeFactory یک Factory است!ساختار نادرستابتدا یک نیاز وجود دارد، شما هم یک کلاس با یک متد می‌نویسید. بعد از مدتی، قابلیت جدیدی خواسته می‌شود و شما هم یک متد دیگر اضافه می‌کنید. با هر درخواست، یک متد به کلاس اضافه می‌شود و پس از مدتی با کلاسی همه‌کاره سر و کار داریم که چند هزار خط کد نامرتب دارد. (The blob، یک آنتی‌پترن مشهور)در کتاب Michael Feathers آمده است:When we avoid creating new classes and methods, the existing ones grow larger and harder to understand. (Working Effectively with Legacy Code, p8)وقتی از ساختن کلاس‌ها و متدهای جدید خودداری می‌ورزیم، چیزی که در حال حاضر وجود دارد، بزرگ‌تر و بزرگ‌تر می‌شود و به دشواری درک خواهد شد!سناریوی دیگر این است که دسته‌بندی درستی وجود ندارد و همه‌چیز مثل اجرام فضایی سرگردان است. اگر مدیر از شما بخواهد که قابلیت جدیدی اضافه کنید یا چیزی را تغییر دهید، راهی جز زیر و رو کردن فایل‌های پراکنده ندارید و تازه، تکرار (Duplication) آنقدر زیاد است که اگر چیزی را تغییر دهید، استرس می‌گیرید و با خود می‌گویید: نکنه یه جای دیگه هم هست ولی من پیداش نمی‌کنم؟!تمیزکاری مداوم نداریدریفکتورینگ مداوم به حذف کدهای زائد و رفع خیلی از مشکلات دیگر کمک کرده و مانع از پراکندگی‌هایی می‌شود که فهم پروژه را مشکل می‌کنند. کدهایی که دیگر استفاده نمی‌شوند را باید حذف کرد؛ رابرت مارتین حذف آنها را به کامنت‌کردنشان ترجیح می‌دهد، توجیه‌اش این است که حتی اگر در آینده به آنها نیازی داشته باشیم، با وجود سیستم‌های کنترل سورس کد (مانند git که برایتان آشناست!) قابل بازیابی هستند. (p69)اگر درباره‌ی این مطمئن نیستید، یک کامنت TODO که در آینده به راحتی پیدا می‌شود، می‌تواند مفید باشد و ضرورت تصمیم‌گیری درباره‌ی موارد مبهم را به برنامه‌نویس‌های دیگر تیم (مخصوصاً آنهایی که در جریان کاربرد آن تکه‌کد هستند) یادآوری می‌کند.همانطور که می‌بینید، بخشی از این موارد به دانش فنی برنامه‌نویسان برمی‌گردد و بخشی دیگر (گفتن اینکه برنامه‌نویس باید/نباید به خواسته‌ی مدیریت تن بدهد را کنار بگذاریم) مربوط به تصمیم‌گیری‌های مدیریتی است. باید برای نوشتن تست و ریفکتورینگ زمان خاصی در نظر گرفت، وگرنه مدیری که اینها را تجملی غیر ضروری می‌داند، سقوط نرم‌افزار را تضمین می‌کند!شما با چه مواردی سر و کار داشته‌اید؟

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

WebPajooh — Fri, 14 May 2021 14:38:31 +0430

Extensions are made of different, but cohesive, components. Components can include background scripts, content scripts, an options page, UI elements and various logic files. Extension components are created with web development technologies: HTML, CSS, and JavaScript.اکستنشن‌‌ها از کامپوننت‌های متفاوت اما منسجم تشکیل می‌شوند. کامپوننت‌ها می‌توانند شامل اسکریپت‌های پس‌زمینه، اسکریپت‌های محتوا، برگه‌های تنظیمات، المنت‌های UI و فایل‌های مختلف مربوط به منطق اکستنشن باشند. کامپوننت‌های اکستنشن با تکنولوژی‌های توسعه‌ی وب ساخته می‌شوند: HTML و CSS و JS.دو سناریو را در نظر بگیریم: مرورگرها هر قابلیتی که به ذهن توسعه‌دهندگان یا کاربران رسیده باشد را پیاده‌سازی کنند.مرورگرها قابلیت‌های ضروری را پیاده‌سازی کنند و در کنار آن پورتی برای توسعه داشته باشند که هر کاربری بنا به نیاز خود قابلیت‌های دیگری را به آنها اضافه کند.در سناریوی اول، حجم مرورگرها سرسام‌آور می‌شود و حافظه‌ی کامپیوتر را صدها برابر آنچه در Memeها می‌بینیم، حیف و میل می‌کنند. در سناریوی دوم، حجم مرورگرها پایین می‌آید و هر کاربری تنها قابلیت‌های اضافی که نیاز دارد را نصب می‌کند و دیگر فلان اکستنشن که متن صفحات را به زبان هندی ترجمه می‌کند سربار حافظه‌ی اصلی و جانبی آنها نخواهد شد. کدام‌یک عاقلانه‌تر است؟ همه‌ی صداها می‌گویند: دو! دو! دو!در این مقاله، اکستنشن کوچکی برای مرورگرهای خانواده‌ی Chromium می‌نویسیم (من از Brave استفاده می‌کنم، گوگل‌کروم شیطان است) و از دور با ساختار یک اکستنشن آشنا می‌شویم.شروع کنیم!حتی اکستنشن‌های فایرفاکس هم یک فایل manifest.json دارند که اطلاعات اکستنشن از آنجا خوانده می‌شود. ما هم از این فایل شروع می‌کنیم:{ "manifest_version": 3, "name": "ext-tut", "description": "This is just for learning purposes", "version": "1.0.0", "icons": { "48": "icon48.png", "128": "icon128.png" } }از نسخه‌ی مانیفست چشم‌پوشی کنید. در خط بعدی نام، توضیح و نسخه‌ی اکستنشن را تعیین کرده‌ایم و بعد آیکون اکستنشن را در دو سایز اضافه کرده‌ایم. توجه داشته باشید که آیکون‌ها باید در دایرکتوری جاری قرار گرفته باشند. فایل را سیو کرده و اکستنشن را به مرورگر اضافه می‌کنیم: وارد بخش Extensions مرورگر شوید.حالت Developer mode را فعال کنید.روی گزینه‌ی Load unpacked کلیک کنید و پوشه‌ی اکستنشن را انتخاب کنید.اکستنشن به مرورگر اضافه می‌شوداین اکستنشن، بی‌مصرف‌ترین اکستنشن موجود در جهان است، زیرا هیچ قابلیتی را به مرورگر اضافه نمی‌کند و تنها آیکونی با نقاشی افتضاح من دارد! حالا مگر چه قابلیتی قرار است به مرورگر اضافه شود؟ Shareکردن در توئیتر!اکستنشن‌ها چگونه کار می‌کنند؟اکستنشن‌ها می‌توانند به شیوه‌های مختلفی کار کنند؛ می‌توانند به Eventهای مرورگر گوش کنند (Background scripts) یا اینکه در محتوای صفحاتی که باز می‌شوند، فراخوانی شوند (Content scripts) و هر کدام از اینها بسته به موقعیت و نیازمندی ما اضافه می‌شود. مثلاً ما به Content script نیاز داریم تا محتوایی را از داخل صفحه به توئیتر بفرستیم، زیرا Content scriptها قادر به خواندن و دستکاری DOM هستند.افزودن Content scriptبرای این کار، باید کد خود را به اکستنشن معرفی کنیم، پس در فایل manifest.json خواهیم داشت:"content_scripts": [ { "matches": [ "" ], "js": [ "main.js" ] } ]فیلد matches تعیین می‌کند که این Content script در چه آدرسی عمل کند. فرض کنید که می‌خواهیم اکستنشنی بنویسیم که گزینه‌ی دانلود را به انتهای پادکست‌های گوگل اضافه کند، پس نیازی نداریم که اسکریپتمان در هر صفحه‌ای لود شود و چنین چیزی خواهیم داشت:"https://podcasts.google.com/*"ما می‌خواهیم اسکریپتمان در هر صفحه‌ی فراخوانی شود، پس چاره‌ی کار است. در ادامه هم فایل main.js را معرفی کرده‌ایم، پس فایلی با همین نام در پوشه‌ی جاری بسازید. برای جلوگیری از کثیف‌کاری (ویرگول چرا Syntax highlighter ندارد؟) کدهای جاوااسکریپت را به صورت تصویر می‌گذارم (با تشکر از کربن):اگر کمی جاوااسکریپت بلد باشید، می‌بینید که کار راحتی است! در بخش A دکمه‌ای ساخته‌ایم، به آن استایل و غیره داده‌ایم و به body اضافه کرده‌ایم. در بخش B یک رویداد (Event) اضافه کرده‌ایم که هر وقت متنی در داخل صفحه انتخاب شود، عمل می‌کند (این تکه را از این جواب گرفته‌ام) و متن انتخاب‌شده را داخل document.highlighted می‌ریزد. بعد در بخش C کدی نوشته‌ام که چک می‌کند که آیا طول متن انتخاب‌شده از صفر بیشتر است یا نه (چیزی انتخاب شده یا نه؟!)، و بر اساس آن دکمه‌ی Share را نشان می‌دهد یا مخفی می‌کند. ببینیم چه شد:در پایین صفحه، دکمه‌ی Share اضافه شدنکته‌ی کنکوری: لازم نیست که بعد از هر تغییری اکستنشن را حذف و اضافه کنید. در تصویر اول (بخش اکستنشن‌ها) آیکون Refresh را می‌بینید که با کلیک روی آن، مرورگر به صورت خودجوش اکستنشن را آپدیت می‌کند.تا این قسمت از مقاله کاری کرده‌ایم که هر وقت قسمتی از متن Highlight شد، دکمه‌ی شیر در پایین صفحه نمایش داده شود. مرحله‌ی بعد این است که اگر روی دکمه کلیک کردیم، متن انتخابی در توئیتر به اشتراک گذاشته شود:document.getElementById('share-button').addEventListener('click', () => { window.open(`https://twitter.com/intent/tweet?text=${document.highlighted}`) })حالا با کلیک روی دکمه‌ی Share، پنجره‌ی اشتراک‌گذاری توئیتر باز می‌شود که نشان می‌دهد راه را درست رفته‌ایم:متن انتخاب شده در سایت توئیتر باز شد و منتظر توئیت‌شدن استافزودن Popupدر مرحله‌ی قبل موفق شدیم قسمتی از متن را انتخاب کنیم و با دکمه‌ی Share در توئیتر به اشتراک بگذاریم. این خوب است، ولی کافی نیست. می‌توانیم دکمه‌ای در بالای مرورگر داشته باشیم که با آن آدرس صفحه‌ی فعلی را هم در توئیتر به اشتراک بگذاریم. ابتدا کد زیر را به فایل manifest.json اضافه می‌کنیم:"action": { "default_popup": "popup.html" }, "permissions": [ "tabs" ]در قسمت اول، یک popup داریم که محتوای فایل popup.html را نشان می‌دهد و قسمت دوم هم permission است که مجوزهای خاصی را از مرورگر دریافت می‌کند. از آنجا که قصد داریم به URL تب‌ها دسترسی داشته باشیم، باید مجوز tabs را از مرورگر بگیریم. محتوای فایل‌های popup.html و popup.js را به ترتیب می‌بینید: