مدیریت تصاویر کالا
در این قسمت امکان آپلود همزمان چندین فایل به همراه پیش نمایش آنها وجود دارد. همچنین امکان کشیدن و رها کردن برای تغییر ترتیب چیدمان عکسها نیز مهیا است.( تصویر اول به عنوان کاور کالا در نظر گرفته میشود.)
قابلیتهای دیگر:
- مدیریت تصاویر اسلایدشو و تغییر ترتیب آنها از طریق کشیدن و رها کردن (drag & drop)
- تعریف برگه و تغییر ترتیب نمایش آنها از طریق کشیدن و رها کردن
- امکان ارسال پست
- تعریف دسته بندی
- مدیریت کاربران
- تعریف تنظیمات سایت
- نمایش کالا و پستهای مشابه
کارهایی که باید انجام شود:
- پیاده سازی سبد خرید و خرید آنلاین
تصویر پنل مدیریت
تصویر صفحهی اصلی:
فناوری یا کتابخانه | توضیحات | مقالات مرتبط |
Bootstrap 3.x | فریم ورک پایه ای css سایت | - Bootstrap 3 RTL Theme - Twitter Bootstrap -سازگارسازی کلاسهای اعتبارسنجی Twitter Bootstrap 3 با فرمهای ASP.NET MVC -ساخت قالبهای نمایشی و ادیتور دکمه سه وضعیتی سازگار با Twitter bootstrap در ASP.NET MVC -نمایش اخطارها و پیامهای بوت استرپ به کمک TempData در ASP.NET MVC |
AdminLTE | قالب مدیریت سایت | - نسخه راستچین شده AdminLTE 2.2.1 |
Animate.css | انیمیشنهای css3 سایت | |
Font Awesome | پک آیکونهای برداری | |
Awesome Bootstrap Checkbox | زیبا سازی چک باکس ها | |
فونت فارسی وزیر | قلم فارسی | |
سلام. یک نرم افزار رو در نظر بگیرید که هر روز، به صورت خودکار، قیمت 1000 کالا را از 100 وبسایت مختلف دریافت و در دیتابیس ذخیره می کند. پرسش من اینه که کدوم روش زیر برای طراحی دیتابیس این نرم افزار و همچنین منطق کاری اون اصولی تر و بهینه تره:
روش اول: در این روش، دیتابیس نرم افزار، شامل چهار جدول (جدول سایت ها – جدول کالاها – جدول تاریخ ها و جدول ثبت اطلاعات روزانه قیمت کالا) است که جدول ثبت تاریخ و جدول اطلاعات روزانه، ارتباط یک به چند دارند (جدول اطلاعات روزانه، شامل یک کلید خارجی از جدول کالاها، یک کلید خارجی از جدول سایت ها و یک کلید خارجی از جدول تاریخ ها است) و نرمالسازی جداول هم انجام شده.
در این روش، هر روز، به صورت خودکار، نرم افزار، ابتدا تاریخ جاری را در جدول تاریخ ها ثبت می کند و سپس، به ازای هر سایت و به ازای هر کالا، یک رکورد (شامل شناسه تاریخ جاری، شناسه سایت و شناسه کالا) را به همراه قیمت روز آن کالا که از وبسایت مربوطه دریافت کرده است، در جدول اطلاعات روزانه ثبت می کند.
بنابراین، حدود 100 هزار رکورد در هر روز باید در این جدول ثبت گردد که هم زمانبر است و هم ممکن است هنگام ثبت این داده ها در دیتابیس، خطایی رخ دهد (فرض کنیم که صحت داده ها اهمیت زیادی داشته باشد). پس لازم است پس از ثبت این رکوردها، همه آن ها مجددا چک شود که عملیات ثبت ناقص انجام نشده باشد و این هم مدتی زمان لازم دارد. ضمن آنکه حجم دیتابیس نیز روز به روز افزایش خواهد یافت.
مشکل دیگر این روش آن است که اگر در آینده، تعداد سایت ها یا تعداد کالاها افزایش یابد، اجرای این روش دشوارتر و احتمال خطای آن بیشتر می شود. مثلا اگر تعداد سایت ها 1000 و تعداد کالاها 1000 شود، هر روز باید یک میلیون رکورد در جدول اطلاعات روزانه ثبت و کنترل گردد.
روش دوم: در این روش، دیتابیس شامل همان چهار جدول قبلی است. با این تفاوت که در جدول اطلاعات روزانه، یک فیلد از نوع XML و یا یک فیلد از نوع رشته ای برای ثبت تمامی اطلاعات لازم کالا در یک روز (شامل شناسه تاریخ، شناسه کالا، شناسه سایتی که اطلاعات از آن دریافت می شود و سایر مشخصات لازم) در نظر گرفته شده است. بنابراین، در این روش، در ابتدای شروع کار نرم افزار، ابتدا به ازای هر کالا، یک رکورد در جدول اطلاعات روزانه ثبت می شود. بنابراین، کلا 1000 رکورد در این جدول وجود خواهد داشت. سپس، هر روز، عملیات دریافت اطلاعات هر کالا از سایت های مربوطه انجام شده و فایل XML یا رشته مربوط به رکورد متناظر با آن کالا ویرایش می شود. بنابراین، در این روش، همیشه کلا 1000 رکورد وجود دارد که باید به صورت روزانه، بروزرسانی شوند و این موضوع، سرعت کار را افزایش و میزان خطا و همچنین حجم دیتابیس را نیز کاهش می دهد. البته به نظرم این روش غیر اصولی است و اصول نرمال سازی و ... در مورد اون رعایت نشده و خیلی ایراد داره.
حالا پرسش من اینه که اگر محدودیت زمان برای دریافت و ثبت داده های روزانه وجود داشته باشد (مثلا کلیه اطلاعات باید در 5 دقیقه دریافت و ثبت شود) و در آینده نیز تعداد رکوردهایی که باید به صورت روزانه ثبت شود افزایش پیدا کند، کدامیک از این دو روش، از نظر طراحی و هم از نظر کاربری نرم افزار، بهینه تر و اصولی تر است؟ آیا برای رسیدن به سرعت و کارایی بالاتر، مجاز هستیم از روش دوم که غیر اصولی به نظر میرسه استفاده کنیم؟ آیا ساخت یک دیتابیس ترکیبی از SQL و فایل های XML به این شکل کار درستی است؟ در غیر اینصورت، روش اصولی برای نرم افزارهایی که باید در هر عملیات، تعداد زیادی داده را ثبت و مدیریت کنند چیست؟ با تشکر.
خیلی از ما با کابوس پروژه ای که هیچ تجربه ای در انجام آن نداریم روبرو شده ایم. نبودن تجربه موثر منجر به خطاهای تکراری و غیر قابل پیش بینی شده و تلاش و وقت ما را به هدر میدهد. مشتریان از کیفیت پایین، هزینه بالا و تحویل دیر هنگام محصول ناراضی هستند و توسعه دهندگان از اضافه کارهای بیشتر که منجر به نرم افزار ضعیتتر میگردد، ناخشنود.
همین که با شکستی مواجه میشویم از تکرار چنین پروژه هایی اجتناب میکنیم. ترس ما باعث میشود تا فرآیندی بسازیم که فعالیتهای ما را محدود نموده و ایجاد آرتیفکتها[۱] را الزامی کند. در پروژه جدید از چیزهایی که در پروژههای قبلی به خوبی کار کردهاند، استفاده میکنیم. انتظار ما این است که آنها برای پروژه جدید نیز به همان خوبی کار کند.
اما پروژهها آنقدر ساده نیستند که تعدادی محدودیت و آرتیفکت ما را از خطاها ایمن سازند. با بروز خطاهای جدید ما آنها را شناسایی و رفع میکنیم. برای اینکه در آینده با این خطاها روبرو نشویم آنها را در محدودیتها و آرتیفکتهای جدیدی قرار میدهیم. بعد از انجام پروژههای زیاد با فرآیندهای حجیم و پر زحمتی روبرو هستیم که توانایی تیم را کم کرده و باعث کاهش کیفیت تولید میشوند.
فرآیندهای بزرگ و حجیم میتواند مشکلات زیادی را ایجاد کند. متاسفانه این مشکلات باعث میشود که خیلی از افراد فکر کنند که علت مشکلات، نبود فرآیندهای کافی است. بنابراین فرآیندها را حجیمتر و پیچیدهتر میکنند. این مسئله منجر به تورم فرآیندها میگردد که در محدوده سال ۲۰۰۰ گریبان بسیاری از شرکتهای نرم افزاری را گرفت.
اتحاد چابک
در وضعیتی که تیمهای نرم افزاری در بسیاری از شرکتها خود را در مردابی از فرآیندهای زیاد شونده میدیدند، تعدادی از خبرههای این صنعت که خود را اتحاد چابک[۲] نامیدند در اویل سال ۲۰۰۱ یکدیگر را ملاقات کرده و ارزش هایی را معرفی کردند تا تیمهای نرم افزاری سریعتر نرم افزار را توسعه داده و زودتر به تغییرات پاسخ دهند. چند ماه بعد، این گروه ارزشهایی تعریف شده را تحت مانیفست اتحاد چابک در سایت http://agilemanifesto.org منتشر کردند.
ما با توسعه نرم افزار و کمک به دیگران در انجام آن، در حال کشف راههای بهتری برای توسعه نرم افزار هستیم. از این کار به ارزشهای زیر میرسیم :
۱- افراد و تعاملات بالاتر از فرآیندها و ابزارها
۲- نرم افزار کار کننده بالاتر از مستندات جامع
۳- مشارکت مشتری بالاتر از قرارداد کاری
۴- پاسخگویی به تغییرات بالاتر از پیروی از یک برنامه
با آنکه موارد سمت چپ ارزشمند هستند ولی ما برای موارد سمت راست ارزش بیشتری قائل هستیم.
افراد مهمترین نقش را در پیروزی یک پروژه دارند. یک فرآیند عالی بدون نیروی مناسب منجر به شکست میگردد و بر عکس افراد قوی تحت فرآیند ضعیت ناکارآمد خواهند بود.
یک نیروی قوی لازم نیست که برنامه نویسی عالی باشد، بلکه کافیست که یک برنامه نویسی معمولی با قابلیت همکاری مناسب با سایر اعضای تیم باشد. کار کردن با دیگران، تعامل درست و سازنده با سایر اعضای تیم خیلی مهمتر از این که یک برنامه نویس با هوش باشد. برنامه نویسان معمولی که تعامل درستی با یکدیگر دارند به مراتب موفقتر هستند از تعداد برنامه نویسی عالی که قدرت تعامل مناسب با یکدیگر را ندارند.
در انتخاب ابزارها آنقدر وقت نگذارید که کار اصلی و تیم را فراموش کنید. به عنوان مثال میتوانید در شروع به جای بانک اطلاعاتی از فایل استفاده کنید، به جای ابزار کنترل کد گرانقیمت از برنامه رایگان کد باز استفاده کنید. باید به هیچ ابزاری عادت نکنید و صرفا به آنها به عنوان امکانی جهت تسهیل فرآیندها نگاه کنید.
نرم افزار بدون مستندات، فاجعه است. کد برنامه ابزار مناسبی برای تشریح سیستم نرم افزاری نیست. تیم باید مستندات قابل فهم مشتری بسازد تا ابعاد سیستم از تجزیه تحلیل تا طراحی و پیاده سازی آن را تشریح نماید.
با این حال، مستندات زیاد از مستندات کم بدتر است. ساخت مستندات زیاد نیاز به وقت زیادی دارد و وقت بیشتری را میگیرد تا آن را با کد برنامه به روز نمایید. اگر آنها با یکدیگر به روز نباشند باعث درک اشتباه از سیستم میشوند.
بهتر است که همیشه مستندات کم حجمی از منطق و ساختار برنامه داشته باشید و آن را به روز نماید. البته آنها باید کوتاه و برجسته باشند. کوتاه به این معنی که ۱۰ تا ۲۰ صفحه بیشتر نباشد و برجسته به این معنی که طراحی کلی و ساختار سطح بالای سیستم را بیان نماید.
اگر فقط مستندات کوتاه از ساختار و منطق سیستم داشته باشیم چگونه میتوانیم اعضای جدید تیم را آموزش دهیم؟ پاسخ کار نزدیک شدن به آنها است. ما دانش خود را با نشستن در کنار آنها و کمک کردن به آنها انتقال میدهیم. ما آنها را بخشی از تیم میکنیم و با تعامل نزدیک و رو در رو به آنها آموزش میدهیم.
نرم افزار نمیتواند مثل یک جنس سفارش داده شود. شما نمیتوانید یک توصیف از نرم افزاری که میخواهید را بنویسید و آنگاه فردی آن را بسازد و در یک زمان معین با قیمت مشخص به شما تحویل دهد. بارها و بارها این شیوه با شکست مواجه شده است.
این قابل تصور است که مدیران شرکت به اعضای تیم توسعه بگویند که نیازهای آنها چیست، سپس اعضای تیم بروند و بعد از مدتی برگردند و یک سیستمی که نیازهای آنها را برآورده میکند، بسازند. اما این تعامل به کیفیت پایین نرم افزار و در نهایت شکست آن میانجامد. پروژههای موفق بر اساس دریافت بازخورد مشتری در بازههای زمانی کوتاه و مداوم است. به جای وابستگی به قرارداد یا دستور کار، مشتری به طور تنگاتنگ با تیم توسعه کار کرده و مرتبا اعمال نظر میکند.
قراردادی که مشخص کننده نیازمندیها، زمانبندی و قیمت پروژه است، اساسا نقص دارد. بهترین قرارداد این است که تیم توسعه و مشتری با یکدیگر کار کنند.
توانایی پاسخ به تغییرات اغلب تعیین کننده موفقیت یا شکست یک پروژه نرم افزاری است. وقتی که طرحی را میریزیم باید مطمئن شویم که به اندازه کافی انعطاف پذیر است و آمادگی پذیرش تغییرات در سطح بیزنس و تکنولوژی را دارد.
مسیر یک پروژه نرم افزاری نمیتواند برای بازه زمانی طولانی برنامه ریزی شود. اولا احتمالا محیط تغییر میکند و باعث تغییر در نیازمندیها میشود. ثانیا همین که سیستم شروع به کار کند مشتریان نیازمندیهای خود را تغییر میدهند. بنابراین اگر بدانیم که نیازها چیست و مطمئن شویم که تغییر نمیکنند، قادر به برآورد مناسب خواهیم بود، که این شرایط بعید است.
یک استراتژی خوب برای برنامه ریزی این است که یک برنامه ریزی دقیق برای یک هفته بعد داشته باشیم و یک برنامه ریزی کلی برای سه ماه بعد.
۱- بالاترین اولویت ما عبارت است از راضی کردن مشتری با تحویل سریع و مداوم نرم افزار با ارزش. تحویل نرم افزار با کارکردهای کم در زود هنگام بسیار مهم است چون هم مشتری چشم اندازی از محصول نهایی خواهد داشت و هم مسیر کمتر به بیراهه میرود.
۲- خوش آمدگویی به تغییرات حتی در انتهای توسعه. اعضای تیم چابک، تغییرات را چیز خوبی میبینند زیرا تغییرات به این معنی است که تیم بیشتر یاد گرفته است که چه چیزی مشتری را راضی میکند.
۳- تحویل نرم افزار قابل استفاده از چند هفته تا چند ماه با تقدم بر تحویل در دوره زمانی کوتاهتر. ما مجموعه از مستندات و طرحها را به مشتری نمیدهیم.
۴- افراد مسلط به بیزنس و توسعه دهندگان باید روزانه با یکدیگر روی پروژه کار کنند. یک پروژه نرم افزاری نیاز به هدایت مداوم دارد.
۵- ساخت پروژه را بر توان افراد با انگیزه بگذارید و به آنها محیط و ابزار را داده و اعتماد کنید. مهمترین فاکتور موفقیت افراد هستند، هر چیز دیگر مانند فرآیند، محیط و مدیریت فاکتورهای بعدی محسوب میشوند که اگر تاثیر بدی روی افراد میگذارند، باید تغییر کنند.
۶- بهترین و موثرترین روش کسب اطلاعات در تیم توسعه، ارتباط چهره به چهره است. در تیم چابک افراد با یکدیگر صحبت میکنند. نامه نگاری و مستند سازی فقط زمانی که نیاز است باید صورت گیرد.
۷- نرم افزار کار کننده معیار اصلی پیشرفت است. پروژههای چابک با نرم افزاری که در حال حاضر نیازهای مشتری را پاسخ میدهد، سنجیده میشوند. میزان مستندات، حجم کدهای زیر ساخت و هر چیز دیگری غیره از نرم افزار کار کننده معیار پیشرفت نرم افزار نیستند.
۸- فرآیندهای چابک توسعه با آهنگ ثابت را ترویج میدهد. حامیان، توسعه دهندگان و کاربران باید یک آهنگ توسعه ثابت را حفظ کنند که بیشتر شبیه به دو ماراتون است یا دوی ۱۰۰ متر. آنها با سرعتی کار میکنند که بالاترین کیفیت را ارائه دهند.
۹- توجه مداوم به برتری تکنیکی و طراحی خوب منجر به چابکی میگردد. کیفیت بالاتر کلیدی برای سرعت بالا است. راه سریعتر رفتن این است که نرم افزار تا جایی که ممکن است پاک و قوی نگهداریم. بنابراین همه اعضای تیم چابک تلاش میکنند که با کیفیتترین کار ممکن را انجام دهند. آنها هر آشفتگی را به محض ایجاد برطرف میکنند.
۱۰- سادگی هنر بیشینه کردن مقدار کاری که لازم نیست انجام شود، است. تیم چابک همیشه سادهترین مسیر که با هدف آنها سازگار است را در پیش میگیرند. آنها وقت زیادی روی مشکلاتی که ممکن است فردا رخ دهد، نمیگذارند. آنها کار امروز را با کیفیت انجام داده و مطمئن میشوند که تغییر آن در صورت بروز مشکلات در فردا، آسان خواهد بود.
۱۱- بهترین معماری و طراحی از تیمهای خود سازمان ده بیرون میآید. مدیران، مسئولیتها را به یک فردی خاصی در تیم نمیدهند بلکه بر عکس با تیم به صورت یک نیروی واحد برخورد میکنند. خود تیم تصمیم میگیرد که هر مسئولیت را چه کسی انجام دهد. تیم چابک با هم روی کل جنبههای پروژه کار میکنند. یعنی یک فرد خاص مسئول معماری، برنامه نویسی، تست و غیره نیستند. تیم، مسئولیتها را به اشتراک گذاشته و هر فرد بر کل کار تاثیر دارد.
۱۲- در بازهای زمانی مناسب تیم در مییابد که چگونه میتواند کاراتر باشد و رفتار خود را متناسب با آن تغییر دهد. تیم میداند که محیط دائما در حال تغییر است، بنابراین خود را با محیط تغییر میدهد تا چابک بماند.
امروزه صنعت نرم افزار دارای سابقه بدی در تحویل به موقع و با کیفیت نرم افزار است. گزارشات بسیاری تایید میکنند که بیش از ۸۰ درصد از پروژههای نرم افزاری با شکست مواجه میشوند؛ در سال ۲۰۰۵ موسسه IEEE برآورد زده است که بیش از ۶۰ بیلیون دلار صرف پروژههای نرم افزاری شکست خورده شده است. عجب فاجعهای؟
وقتی که از مدیران و کارکنان سوال میشود که چرا پروژههای نرم افزاری با شکست مواجه میشوند، آنها به موضوعات گسترده ای اشاره میکنند. اما شش دلیل زیر بارها و بارها تکرار شده است که به عنوان دلایل اصلی شکست نرم افزار معرفی میشوند:
۱- درگیر نشدن مشتری
۲- عدم درک درست نیازمندها
۳- زمان بندی غیر واقعی
۴- عدم پذیریش و مدیریت تغییرات
۵- کمبود تست نرم افزار
۶- فرآیندهای غیر منعطف و باد دار
با آنکه Agile برای هر مشکلی راه حل ندارد ولی برای مسائل فوق بدین صورت کمک میکند:
برای رفع مشکل عدم همکاری کاربر نهایی یا مشتری، Agile مشتری را عضوی از تیم توسعه میکند. به عنوان عضوی از تیم، مشتری با تیم توسعه کار میکند تا مطمئن شود که نیازمندها به درستی برآورده میشوند. مشتری همکاری میکند در شناسایی نیازمندیها، تایید میکند نتیجه نهایی را و حرف آخر را در اینکه کدام ویژگی به نرم افزار اضافه شود، حذف شود و یا تغییر کند، را میزند.
برای مقابله با مشکل عدم درک درست نیازمندیها، Agile تاکید دارد که نیازمندیهای کسب شده باید به صورت ویژگیهایی تعریف شوند که بر اساس معیارهای مشخصی قابل پذیرش باشند. این معیارهای پذیرش برای نوشتن تستهای پذیرش به کار میروند. به این ترتیب قبل از اینکه کدی نوشته شود، ابتدا تست پذیرش نوشته میشود. این بدین معنی است که هر کسی باید اول فکر کند که چه میخواهد، قبل از اینکه از کسی بخواهد آن را انجام دهد. این راهکار فرایند کسب نیازمندیها را از بنیاد تغییر میدهد و به صورت چشم گیری کیفیت برآورد و زمان بندی را بهبود میدهد.
برای حل مشکل زمان بندی غیر واقعی، Agile زمان بندی را به صورت یک فرآیند مشترک بین تیم توسعه و سفارش دهنده تعریف میکند. در شروع هر نسخه از نرم افزار، سفارش دهنده ویژگیهای مورد انتظار را به تیم توسعه میگوید. تیم توسعه تاریخ تحویل را بر اساس ویژگیها برآورد میزد و در اختیار سفارش دهنده قرار میدهد. این تعامل تا رسیدن به یک دیدگاه مشترک ادامه مییابد.
برای رفع مشکل ضعف در مدیریت تغییرات، Agile اصرار دارد که هر کسی باید تغییرات را بپذیرد و نسبت به آنها واقع بین باشد. یک اصل مهم Agile میگوید که هر چیزی میتواند تغییر کند مگر تاریخ تحویل! به عبارت دیگر همین که محصول به سمت تولید شدن حرکت میکند، مشتری (در تیم محصول) میتواند بر اساس اولویتها و ارزشهای خود ویژگیهای محصول را کم یا زیاد کرده و یا تغییر دهد. به هر حال او باید واقع بین باشد. اگر او یک ویژگی جدید اضافه کنید، باید تاریخ تحویل را تغییر دهد. به این ترتیب همیشه تاریخ تحویل رعایت میگردد.
برای رفع مشکل کمبود تست، Agile تاکید میکند که ابتدا باید تستها نوشته شوند و همواره ارزیابی گردند. هر برنامه نویس باید اول تست را بنویسد، سپس کد لازم برای پاس شدن آن را. همین که کد تغییر میکند باید تستها دوباره اجرا شوند. در این راهکار، هر برنامه نویس مسئول تستهای خود است تا درستی برنامه از ابتدا تضمین گردد.
برای رفع مشکل فرآیندهای غیر منعطف و باددار، Agile مدیریت پروژه را درون فرآیند توسعه میگنجاند. وظایف مدیریت پروژه بین اعضای تیم توسعه تقسیم میشود. برای مثال هر ۷ نفر در تیم توسعه نرم افزار (متدلوژی اسکرام) زمان تحویل را با مذاکره تعیین میکنند. همچنین کد برنامه به صورت خودکار اطلاعات وضعیت پروژه را تولید میکند. به عنوان مثال نمودار burndown ، تستهای انجام نشده، پاس شده و رد شده به صورت خودکار تولید میشوند.
یکی از مشکلات توسعه چابک این است که شما اول باید به خوبی آن را درک کنید تا قادر به پیاده سازی درست آن باشید. این درک هم باید کلی باشد (مانند Scrum و XP) و هم جزئی (مانند TDD و جلسات روازنه). اما چگونه باید به این درک برسیم؟ کتابها و مقالات انگلیسی زیادی برای یادگیری توسعه چابک و پیاده سازی آن در سازمان وجود دارند، ولی متاسفانه منابع فارسی کمی در این زمینه است. هدف این کتاب رفع این کمبود و آموزش عملی توسعه چابک و ابزارهای پیاده سازی آن است.
برای این یک توسعه دهنده چابک شوید، باید به مهارتهای فردی و تیمی چابک برسید. در ادامه این مهارتها معرفی میشوند.
قبل از هر چیز شما باید یک برنامه نویس باشید و مقدمات برنامه نویسی مانند الگوریتم و فلوچارت، دستورات برنامه نویسی، کار با متغیرها، توابع و آرایهها را بلد باشید. پس از تسلط به مقدمات برنامه نویسی میتوانید مهارتهای برنامه نویسی چابک را فرا بگیرید که عبارتند از:
- برنامه نویسی شیءگرا
- توسعه تست محور
- الگوهای طراحی
در ادامه نحوه کسب این مهارتها بیان میشوند.
اساس طراحی چابک بر تفکر شیءگرا استوار است. بنابراین تسلط به مفاهیم و طراحی شیءگرا ضروری است.
مهمترین و انقلابیترین سبک برنامه نویسی از دهه گذشته تا به امروز، توسعه یا برنامه نویسی تست محور است. این سبک بسیاری از ارزشهای توسعه چابک را فراهم میکند و یادگیری آن برای هر توسعه دهنده چابک ضروری است.
الگوهای طراحی راه حلهای انتزاعی سطح بالا هستند. این الگوها بهترین تکنیکهای[۴] طراحی نرم افزار هستند و بسیاری از مشکلاتی که در طراحی نرم افزار رخ میدهند با استفاده از این الگوها قابل حل هستند.
انجام پروژه نرم افزاری یک کار تیمی است. شما پس از یادگیری مهارتهای فردی باید خود را آماده حضور در تیم توسعه چابک کنید. برای این منظور باید با مهارت تیمی مانند آشنایی با گردشکار تولید نرم افزار، حضور موثر در جلسات، قبول مسئولیتها و غیره آشنا شوید.
تمامی مهارتهای تیمی توسعه چابک توسط اسکرام آموزش داده میشوند. اسکرام فریم ورکی برای توسعه چابک است که با تعریف فرآیندها، نقشها و آرتیفکتهای مشخص به تیمهای نرم افزاری کمک میکند تا چابک شوند.
[۱] Artifact : خروجی یک فرآیند است. مثلا خروجی طراحی شیءگرا، نمودارهای UML است.
[۲] Agile Alliance
[3] Acceptance Tests
void WriteFile() { using (var doc = new Document(PageSize.LETTER)) { using (var fs = new FileStream("test.pdf", FileMode.Create)) { using (var writer = PdfWriter.GetInstance(doc, fs)) { doc.Open(); var blueFont = FontFactory.GetFont("Arial", 12, Font.NORMAL, BaseColor.BLUE); doc.Add(new Chunk("Go to URL", blueFont).SetAction(new PdfAction("http://www.google.com/", false))); doc.NewPage(); doc.Add(new Chunk("Go to Test", blueFont).SetLocalGoto("entry1")); doc.NewPage(); doc.Add(new Chunk("Test").SetLocalDestination("entry1")); doc.Close(); } } } }
using System; using System.Collections.Generic; using System.IO; using System.Linq; using iTextSharp.text.pdf; namespace ReplaceLinks { public class ReplacePdfLinks { Dictionary<string, PdfObject> _namedDestinations; PdfReader _reader; public string InputPdf { set; get; } public string OutputPdf { set; get; } public Func<Uri, string> UriToNamedDestination { set; get; } public void Start() { updatePdfLinks(); saveChanges(); } private PdfArray getAnnotationsOfCurrentPage(int pageNumber) { var pageDictionary = _reader.GetPageN(pageNumber); var annotations = pageDictionary.GetAsArray(PdfName.ANNOTS); return annotations; } private static bool hasAction(PdfDictionary annotationDictionary) { return annotationDictionary.Get(PdfName.SUBTYPE).Equals(PdfName.LINK); } private static bool isUriAction(PdfDictionary annotationAction) { return annotationAction.Get(PdfName.S).Equals(PdfName.URI); } private void replaceUriWithLocalDestination(PdfDictionary annotationAction) { var uri = annotationAction.Get(PdfName.URI) as PdfString; if (uri == null) return; if (string.IsNullOrWhiteSpace(uri.ToString())) return; var namedDestination = UriToNamedDestination(new Uri(uri.ToString())); if (string.IsNullOrWhiteSpace(namedDestination)) return; PdfObject entry; if (!_namedDestinations.TryGetValue(namedDestination, out entry)) return; annotationAction.Remove(PdfName.S); annotationAction.Remove(PdfName.URI); var newLocalDestination = new PdfArray(); annotationAction.Put(PdfName.S, PdfName.GOTO); var xRef = ((PdfArray)entry).First(x => x is PdfIndirectReference); newLocalDestination.Add(xRef); newLocalDestination.Add(PdfName.FITH); annotationAction.Put(PdfName.D, newLocalDestination); } private void saveChanges() { using (var fileStream = new FileStream(OutputPdf, FileMode.Create, FileAccess.Write, FileShare.None)) using (var stamper = new PdfStamper(_reader, fileStream)) { stamper.Close(); } } private void updatePdfLinks() { _reader = new PdfReader(InputPdf); _namedDestinations = _reader.GetNamedDestinationFromStrings(); var pageCount = _reader.NumberOfPages; for (var i = 1; i <= pageCount; i++) { var annotations = getAnnotationsOfCurrentPage(i); if (annotations == null || !annotations.Any()) continue; foreach (var annotation in annotations.ArrayList) { var annotationDictionary = (PdfDictionary)PdfReader.GetPdfObject(annotation); if (!hasAction(annotationDictionary)) continue; var annotationAction = annotationDictionary.Get(PdfName.A) as PdfDictionary; if (annotationAction == null) continue; if (!isUriAction(annotationAction)) continue; replaceUriWithLocalDestination(annotationAction); } } } } }
new ReplacePdfLinks { InputPdf = @"test.pdf", OutputPdf = "mod.pdf", UriToNamedDestination = uri => { if (uri.Host.ToLowerInvariant().Contains("google.com")) { return "entry1"; } return string.Empty; } }.Start();
annotationAction.Put(PdfName.URI, new PdfString("http://www.bing.com/"));
newLocalDestination.Add((PdfObject)_reader.GetPageOrigRef(pageNum: 2));RemovePdfLinks.7z
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme);
app.UseAuthentication();