نظرات مطالب
معرفی Xamarin و مزیتهای استفاده از آن
با عرض سلام خدمت شما
در مورد استفاده از کتابخانههای بومی در مقاله گفته شد که به راحتی شما قادر خواهید بود که کتابخانههای Java و Objective-C را به برنامه خود Bind کنید.در مورد حجم اپلیکیشن هم در مقالات بعدی مفصل بحث خواهد شد.
در حال حاضر با افزایش حجم حافظه موبایلها حجم اپلیکیشن خیلی مد نظر نخواهد بود و بیشترین چیزی که میتواند باعث متمایز بودن یک فریم ورک شود، Performance و راحتی کار با فریم ورک در حین دسترسی کامل به آن میباشد.
حداقل حجم نرم افزارهای Android و IOS حدود 3 مگ میباشد و بیش از 2.5 مگ آن مربوط به .Net میباشد به همین خاطر اینطور قلمداد نکنید که با پیچیدهتر شدن اپلیکیشن حجم برنامه به صورت تصاعدی بالا خواهد رفت. در صورتی که چنین نخواهد بود
در قسمت قبل، مقدماتی از Pipeها را مورد برسی قرار دادیم؛ از جمله کاربرد Pipeها، نحوه استفاده از آنها، معرفی یکسری Pipe از پیش ساخته شده Angular، نحوه ارسال پارامتر به آنها و همچنین نحوه استفاده از آنها را در داخل Typescript، فراگرفتیم. در این قسمت نحوه ساخت Pipeهای سفارشی و همچنین نکات تکمیلی در مورد آنها را مورد بحث و بررسی قرار میدهیم.
نحوه ساخت Pipe سفارشی
علاوه بر استفاده از Pipeهای از پیش ساخته شده Angular، شما میتوانید Pipeهای سفارشی خود را نیز تعریف و استفاده کنید. به عنوان مثال میخواهیم Pipe ای را با نام perNumber تعریف کنیم، تا تمامی اعداد موجود در عبارت ورودی Pipe را به صورت اعداد فارسی نمایش دهد. یعنی با اعمال این Pipe به عدد 123456 خروجی ۱۲۳۴۵۶ مورد انتظار است. برای ایجاد Pipe سفارشی مراحل زیر را انجام دهید.
قدم اول - ساخت یک فایل با نام دلخواه
طبق Style Guide در Angular.io نام این فایل را per-number.pipe.ts انتخاب میکنیم.
قدم دوم – افزودن ماژولهای مورد نیاز
داخل فایل ایجاد شده ماژولهای Pipe و PipeTransform را با استفاده از دستور import از angular/core@ اضافه میکنیم.
قدم سوم – ساخت کلاس و مزین کردن آن به Pipe@
یک کلاس با نام دلخواه را مثلا به نام PerNumberPipe ایجاد میکنیم. این کلاس علاوه بر اینکه PipeTransform را پیاده سازی خواهد کرد، مزین به متادیتای Pipe@ نیز میباشد. متادیتای Pipe@ هنگام تزئین کلاس، یک نام را دریافت میکند. این نام قرار است به عنوان نام نهایی Pipe برای اعمال بر روی Template expressions مورد استفاده قرار بگیرد.
قدم چهارم – پیاده سازی متد transform
به واسطه اعمال اینترفیس PipeTransform، این کلاس باید متد transform را پیاده سازی کند. این متد در پارامتر اول خود، عبارت ورودی را که قرار است Pipe بر روی آن اعمال شود، دریافت میکند و در ادامه تعداد دلخواهی پارامتر ورودی Pipe را که میخواهد، میتواند دریافت کند.
نکته ۱: نام انتخابی برای Pipe در آذینگر Pipe@ بایستی یک شناسه معتبر در JavaScript باشد.
نکته ۲: متد transform برای Pipe اجباری است و حتما بایستی پیاده سازی شود. اینترفیس PipeTransform این متد را برای کلاس اجباری میکند؛ هرچند استفاده از این اینترفیس برای کلاس Pipe کاملا اختیاری است.
قدم آخر – نوشتن کد تبدیل اعداد
Pipe مورد نظر ما قرار است یک رشته عددی را از ورودی دریافت کند و تمامی اعداد لاتین آن را به فارسی تبدیل کند. همچنین این Pipe هیچگونه پارامتری را دریافت نمیکند. کد زیر نحوه پیاده سازی متد transform را نمایش میدهد.
نحوه معرفی Pipe سفارشی به برنامه
حالا جهت استفاده از Pipe سفارشی در کامپوننتهای خود کافی است آنرا یکبار در قسمت declarations در AppModule خود تعریف کنید.
نحوه استفاده از Pipeهای سفارشی
نحوه استفاده از Pipeهای سفارشی، دقیقا مشابه Pipeهای از قبل ساخته شده Angular میباشد.
Pipeها و تشخیص تغییرات
Angular برای اعمال Pipe بر روی Template expressions بایستی تمامی رخدادهای برنامه را تحت نظر قرار داده و با مشاهده هر تغییری بر روی عبارت ورودی Pipe، فراخوانی Pipe را آغاز کند. از جمله این رخدادها میتوان به رخداد mouse move، timer tick، server response و فشرده شدن کلیدهای ماوس و یا کیبورد اشاره کرد. واضح است که بررسی تغییرات عبارت در این همه رخداد میتواند مخرب باشد و بر روی کارآئی (Performance) تاثیر منفی خواهد گذاشت. اما Angular برای حل این مشکل و همچنین هنگام مشاهده سریع تغییرات هنگام استفاده از Pipeها، الگوریتمهای سریع و سادهای در نظر گرفته است.
در قسمت بعد با انواع Pipeها در Angular و همچنین نحوه پیاده سازی آنها، آشنا خواهیم شد.
نحوه ساخت Pipe سفارشی
علاوه بر استفاده از Pipeهای از پیش ساخته شده Angular، شما میتوانید Pipeهای سفارشی خود را نیز تعریف و استفاده کنید. به عنوان مثال میخواهیم Pipe ای را با نام perNumber تعریف کنیم، تا تمامی اعداد موجود در عبارت ورودی Pipe را به صورت اعداد فارسی نمایش دهد. یعنی با اعمال این Pipe به عدد 123456 خروجی ۱۲۳۴۵۶ مورد انتظار است. برای ایجاد Pipe سفارشی مراحل زیر را انجام دهید.
قدم اول - ساخت یک فایل با نام دلخواه
طبق Style Guide در Angular.io نام این فایل را per-number.pipe.ts انتخاب میکنیم.
قدم دوم – افزودن ماژولهای مورد نیاز
داخل فایل ایجاد شده ماژولهای Pipe و PipeTransform را با استفاده از دستور import از angular/core@ اضافه میکنیم.
import { Pipe, PipeTransform } from '@angular/core';
قدم سوم – ساخت کلاس و مزین کردن آن به Pipe@
یک کلاس با نام دلخواه را مثلا به نام PerNumberPipe ایجاد میکنیم. این کلاس علاوه بر اینکه PipeTransform را پیاده سازی خواهد کرد، مزین به متادیتای Pipe@ نیز میباشد. متادیتای Pipe@ هنگام تزئین کلاس، یک نام را دریافت میکند. این نام قرار است به عنوان نام نهایی Pipe برای اعمال بر روی Template expressions مورد استفاده قرار بگیرد.
import { Pipe, PipeTransform } from '@angular/core'; @Pipe({name: 'perNumber'}) export class PerNumberPipe implements PipeTransform { }
قدم چهارم – پیاده سازی متد transform
به واسطه اعمال اینترفیس PipeTransform، این کلاس باید متد transform را پیاده سازی کند. این متد در پارامتر اول خود، عبارت ورودی را که قرار است Pipe بر روی آن اعمال شود، دریافت میکند و در ادامه تعداد دلخواهی پارامتر ورودی Pipe را که میخواهد، میتواند دریافت کند.
import { Pipe, PipeTransform } from '@angular/core'; @Pipe({name: 'perNumber'}) export class PerNumberPipe implements PipeTransform { transform(value: any, ...args: any[]): any { } }
نکته ۱: نام انتخابی برای Pipe در آذینگر Pipe@ بایستی یک شناسه معتبر در JavaScript باشد.
نکته ۲: متد transform برای Pipe اجباری است و حتما بایستی پیاده سازی شود. اینترفیس PipeTransform این متد را برای کلاس اجباری میکند؛ هرچند استفاده از این اینترفیس برای کلاس Pipe کاملا اختیاری است.
قدم آخر – نوشتن کد تبدیل اعداد
Pipe مورد نظر ما قرار است یک رشته عددی را از ورودی دریافت کند و تمامی اعداد لاتین آن را به فارسی تبدیل کند. همچنین این Pipe هیچگونه پارامتری را دریافت نمیکند. کد زیر نحوه پیاده سازی متد transform را نمایش میدهد.
import { Pipe, PipeTransform } from '@angular/core'; @Pipe({name: 'perNumber'}) export class PerNumberPipe implements PipeTransform { transform(input: string): string{ if (input == undefined) return ''; var str = input.toString().trim(); if (str === "") return ""; str = str.replace(/0/g, '۰'); str = str.replace(/1/g, '۱'); str = str.replace(/2/g, '۲'); str = str.replace(/3/g, '۳'); str = str.replace(/4/g, '۴'); str = str.replace(/5/g, '۵'); str = str.replace(/6/g, '۶'); str = str.replace(/7/g, '۷'); str = str.replace(/8/g, '۸'); str = str.replace(/9/g, '۹'); return str; } }
نحوه معرفی Pipe سفارشی به برنامه
حالا جهت استفاده از Pipe سفارشی در کامپوننتهای خود کافی است آنرا یکبار در قسمت declarations در AppModule خود تعریف کنید.
import { PerNumberPipe } from './pipes/per-number.pipe.ts' ... declarations: [PerNumberPipe]
نحوه استفاده از Pipeهای سفارشی
نحوه استفاده از Pipeهای سفارشی، دقیقا مشابه Pipeهای از قبل ساخته شده Angular میباشد.
<h3>{{'12345679' | perNumber}}</h3>
یکسری از Pipeهای مربوط به زبان فارسی در گیتهاب بنده پیاده سازی شده است که نیازمند همکاری دوستان است. لطفا جهت همکاری برای ساخت یک ابزار جامع برای زبان فارسی در Angular به این لینک مراجعه کنید.
Pipeها و تشخیص تغییرات
Angular برای اعمال Pipe بر روی Template expressions بایستی تمامی رخدادهای برنامه را تحت نظر قرار داده و با مشاهده هر تغییری بر روی عبارت ورودی Pipe، فراخوانی Pipe را آغاز کند. از جمله این رخدادها میتوان به رخداد mouse move، timer tick، server response و فشرده شدن کلیدهای ماوس و یا کیبورد اشاره کرد. واضح است که بررسی تغییرات عبارت در این همه رخداد میتواند مخرب باشد و بر روی کارآئی (Performance) تاثیر منفی خواهد گذاشت. اما Angular برای حل این مشکل و همچنین هنگام مشاهده سریع تغییرات هنگام استفاده از Pipeها، الگوریتمهای سریع و سادهای در نظر گرفته است.
در قسمت بعد با انواع Pipeها در Angular و همچنین نحوه پیاده سازی آنها، آشنا خواهیم شد.
دلایل شانه خالی کردن از آزمایش واحد!
1- نوشتن آزمایشات زمان زیادی را به خود اختصاص خواهند داد.
مهمترین دلیلی که برنامهنویسها به سبب آن از نوشتن آزمایشات واحد امتناع میکنند، همین موضوع است. اکثر افراد به آزمایش بهعنوان مرحله آخر توسعه فکر میکنند. اگر این چنین است، بله! نوشتن آزمایشهای واحد واقعا سخت و زمانگیر خواهند بود. به همین جهت برای جلوگیری از این مساله روش pay-as-you-go مطرح شده است (ماخذ: کتاب Pragmatic Unit Testing در سی شارپ). یعنی با اضافه شدن هر واحد کوچکی به سیستم، آزمایش واحد آنرا نیز تهیه کنید. به این صورت در طول توسعه سیستم با باگهای کمتری نیز برخورد خواهید داشت چون اجزای آنرا در این حین به تفصیل مورد بررسی قرار دادهاید. اثر این روش را در شکل زیر میتوانید ملاحظه نمائید (تصویری از همان کتاب ذکر شده)
نوشتن آزمایشات واحد زمانبر هستند اما توسعه پیوسته آنها با به تاخیر انداختن آزمایشات به انتهای پروژه، همانند تصویر فوق تاثیر بسیار قابل توجهی در بهره وری شما خواهند داشت.
بنابراین اگر عنوان میکنید که وقت ندارید آزمایش واحد بنویسید، به چند سؤال زیر پاسخ دهید:
الف) چه مقدار زمان را صرف دیباگ کردن کدهای خود یا دیگران میکنید؟
ب) چه میزان زمان را صرف بازنویسی کدی کردهاید که تصور میرفت درست کار میکند اما اکنون بسیار مشکل زا ظاهر شده است؟
ج) چه مقدار زمان را صرف این کردهاید که منشاء باگ گزارش شده در برنامه را کشف کنید؟
برای افرادی که آزمایشات واحد را در حین پروسه توسعه در نظر نمیگیرند، این مقادیر بالا است و با ازدیاد تعداد خطوط سورس کدها، این ارقام سیر صعودی خواهند داشت.
تصویری از کتاب xUnit Test Patterns ، که بیانگر کاهش زمان و هزینه کد نویسی در طول زمان با رعایت اصول آزمایشات واحد است
2- اجرای آزمایشات واحد زمان زیادی را تلف میکند.
نباید اینطور باشد. عموما اجرای هزاران آزمایش واحد، باید در کسری از ثانیه صورت گیرد. (برای اطلاعات بیشتر به قسمت حد و مرز یک آزمایش واحد در قسمت قبل مراجعه نمائید)
3- امکان تهیه آزمایشات واحد برای کدهای قدیمی ( legacy code ) من وجود ندارد
برای بسیاری از برنامه نویسها، تهیه آزمایش واحد برای کدهای قدیمی بسیار مشکل است زیرا شکستن آنها به واحدهای کوچکتر قابل آزمایش بسیار خطرناک و پرهزینه است و ممکن است سبب از کار افتادن سیستم آنها گردد. اینجا مشکل از آزمایش واحد نیست. مشکل از ضعف برنامه نویسی آن سیستم است. روش refactoring ، طراحی مجدد و نوشتن آزمایشات واحد، به تدریج سبب طراحی بهتر برنامه از دیدگاههای شیءگرایی شده و نگهداری سیستم را در طولانی مدت سادهتر میسازد. آزمایشات واحد این نوع سیستمها را از حالت فلج بودن خارج میسازد.
4- کار من نیست که کدهای نوشته شده را آزمایش کنم!
باید درنظر داشته باشید که این هم کار شما نیست که انبوهی از کدهای مشکل دار را به واحد بررسی کننده آن تحویل دهید! همچنین اگر تیم آزمایشات و کنترل کیفیت به این نتیجه برسد که عموما از کدهای شما کمتر میتوان باگ گرفت، این امر سبب معروفیت و تضمین شغلی شما خواهد شد.
همچنین این کار شما است که تضمین کنید واحد تهیه شده مقصود مورد نظر را ارائه میدهد و اینکار را با ارائه یک یا چندین آزمایش واحد میتوان اثبات کرد.
5- تنها قسمتی از سیستم به من واگذار شده است و من دقیقا نمیدانم که رفتار کلی آن چیست. بنابراین آن را نمیتوانم آزمایش کنم!
اگر واقعا نمیدانید که این کد قرار است چه کاری را انجام دهید به طور قطع الان زمان مناسبی برای کد نویسی آن نیست!
6- کد من کامپایل میشود!
باید دقت داشت که کامپایلر فقط syntax کدهای شما را بررسی کرده و خطاهای آنرا گوشزد میکند و نه نحوهی عملکرد آنرا.
7- من برای نوشتن آزمایشات حقوق نمیگیرم!
باید اذعان داشت که به شما جهت صرف تمام وقت یک روز خود برای دیباگ کردن یک خطا هم حقوق نمیدهند! شما برای تهیه یک کد قابل قبول و قابل اجرا حقوق میگیرید و آزمایش واحد نیز ابزاری است جهت نیل به این مقصود (همانند یک IDE و یا یک کامپایلر).
8- احساس گناه خواهم کرد اگر تیم فنی کنترل کیفیت و آزمایشات را از کار بی کار کنم!!
نگران نباشید، این اتفاق نخواهد افتاد! بحث ما در اینجا آزمایش کوچکترین اجزا و واحدهای یک سیستم است. موارد دیگری مانند functional testing, acceptance testing, performance & environmental testing, validation & verification, formal analysis توسط تیمهای کنترل کیفیت و آزمایشات هنوز باید بررسی شوند.
9- شرکت من اجازه اجرای آزمایشات واحد را بر روی سیستمهای در حال اجرا نمیدهد.
قرار هم نیست بدهد! چون دیگر نام آن آزمایش واحد نخواهد بود. این آزمایشات باید بر روی سیستم شما و توسط ابزار و امکانات شما صورت گیرد.
پ.ن.
در هشتمین دلیل ذکر شده، از acceptance testing نامبرده شده. تفاوت آن با unit testing به صورت زیر است:
آزمایش واحد:
توسط برنامه نویسها تعریف میشود
سبب اطمینان خاطر برنامه نویسها خواهد شد
واحدهای کوچک سیستم را مورد بررسی قرار میدهد
یک آزمایش سطح پائین ( low level ) به شمار میرود
بسیار سریع اجرا میشود
به صورت خودکار (100 درصد خودکار است) و با برنامه نویسی قابل کنترل است
اما در مقابل آزمایش پذیرش به صورت زیر است:
توسط مصرف کنندگان تعریف میشود
سبب اطمینان خاطر مصرف کنندگان میشود.
کل برنامه مورد آزمایش قرار میگیرد
یک آزمایش سطح بالا ( high level ) به شمار میرود
ممکن است طولانی باشد
عموما به صورت دستی یا توسط یک سری اسکریپت اجرا میشود
مثال : گزارش ماهیانه باید جمع صحیحی از تمام صفحات را در آخرین برگه گزارش به همراه داشته باشد
ادامه دارد...
اشتراکها
#C با Mads Torgersen
اشتراکها