مرجع مقالات طراحی اپلیکیشن در مشهد حرفه ای

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

 

با آزمایش جنس آغاز فرمائید

 

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

 

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

 

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

 

از حیث مشتری نگاه نمائید

 

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

 

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

 

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

 

ریسک تغییراتی که در درحال حاضر بسط آن میباشید را دریابید

 

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

 

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

 

در حالتی که تغییر و تحول جامع و غیروابسته باشد، یه خرده شل‌خیس هستیم، ولی هنوز حس نیاز به گذر زمان دست اندرکاران خطر بالقوه وجود دارااست. در شغل، این در معنای نگاه به هر مکان ورود و خروج سیستم برای خطر بالقوه میباشد (به عنوان مثال ورودی مخاطب، سیستم I/O، هشدارهای پست الکترونیک، تماس‌های اینترنت‌خدمت و غیره) و یک میزان کلی از مقررات وجود داراست که حقیقتا می بایست به یک نظارت‌لیست برای برخی روز ها تبدیل خواهد شد.

 

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

 

روی فرآورده تمرکز نمایید، حتی هنگامی کد را نظارت می کنید

 

ما سوال های ضروریی را یافتیم که مایحتاج میباشد پیش از اینکه شما حتی درباره ی مسائلی مثل چگونگی کد تصور کنید، پرسیده خواهد شد:

 

آیا این تغییر‌و تحول یک خلل حقیقی وواقعی برای مشتری را حل می‌نماید؟

 

آیا این شیوه‌حل، رویه‌حلی حاذق و مطلوب میباشد؟

 

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

 

با انجام این تغییر تحول چه ایرادات جدیدی ممکن میباشد ساخت و ساز گردد و چه‌طور میتوانیم آن ها را کاهش دهیم؟

 

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

 

آیا هزینه‌های اصلاح در ارتباط با این تغییر تحول وجود دارااست؟ آنها چه میباشند؟

 

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

 

این مراحل به طور تقریب به شما این یقین را میدهد که به پژوهش ظریف کد بپردازید. همینطور سبب کاهش معیار فشار در روند پژوهش کد می شود و به شما یاری می‌نماید عوض این که کد را مجددا از محور بنویسید، آن را تمییز فرمائید.

 

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