ورود کاربران VIP شماره پشتیبانی سایت : 0345 907 909

منوی سایت


با 12 اشتباه رایج در بین برنامه نویسان آشنا شوید

 


یک مجله مربوط به خودرو زمانی اعلام کرده بود، که اگر توضیح خصوصیات یک خودرو پیش از قرض دادنش به یک دوست بیش از 15 دقیقه طول بکشد، آن خودرو «دارای کاراکتر» یا شخصیت است. با توجه به این استاندارد، هر قطعه نرم افزاری نیز  دارای کاراکتر است. بیشتر ویژگی های خاص برنامه نویسی وابستگی شدیدی به Context خاصی که در آن مطرح می شوند داشته و به همین دلیل توصیف آن ها می تواند با ابهام همراه باشد. به عنوان مثال، سایت هایی که داده های XML را عرضه می کنند ممکن است به شیوه ای نوشته نشده باشند که به مرورگر اعلام کنند انتظار داده های XML را داشته باشد. این باعث می شود تا زمانی که مقدار درستی در فیلد مخصوص نوشته نشود، کل کارایی نرم افزار زیر سؤال برود.

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

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

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

بدترین بخش ماجرا این است که پیشرفت های انجام شده با هدف برطرف کردن این قبیل مشکلات معمولا درست عمل نمی کنند. به عنوان مثال آخرین نسخه جاوا را در نظر بگیرید. این نسخه تلاش می کند تا با اضافه کردن یک سینتکس ساده کار بررسی کردن Null Pointer را به صورت همیشگی انجام دهد. فقط کافی است تا یک علامت سؤال به هر فراخوانی متد اضافه کنید تا به صورت خودکار Null Pointer ها بررسی شوند. به این ترتیب، دیگر به نوشتن قطعه کدی مانند زیر نیازی نیست.


code>

public String getPostcode(Person person) {

String ans= null;

if (person != null) {

Name nm= person.getName();

if (nm!= null) {

ans= nm.getPostcode();

}

}

return ans

}

</code>


در عوض کافی است تا تنها بنویسید:


<code>

public String getFirstName(Person person) {

return person?.getName()?.getGivenName();

}

</code>


به هر ترتیب، در پایان چنین پیشرفت هایی در سینتکس تنها می توانند سیستم را از Crash کردن نجات دهند و کارکرد درست آن را تضمین نمی کنند. در واقع ریشه مسئله، یعنی ازدیاد مقادیر Null به دلیل برنامه نویسی سریع و بی دقت از بین نمی رود.

● اشتباه 2: توجه بیش از حد به جزئیات:
از یک طرف نرم افزارهایی با جزئیات بسیار زیاد می توانند به شدت کند عمل کنند. بررسی کردن چندین Null Pointer در کارایی تفاوت چندانی ایجاد نمی کند، اما بعضی از نرم افزارها به گونه ای نوشته می شوند که مانند افراد وسواسی هستند که باید چندین بار بسته بودن در را بررسی کنند تا خوابشان ببرد. توجه بیش از اندازه نسبت به جزئیات می تواند نرم افزار را دچار مشکل سازد، به خصوص زمانی که این بررسی کردن ها نیازمند ارتباط با یک سایت دیگر از طریق شبکه است. من پکیج هایی دارم که در صورت اجرا روی لپ تاپی بدون اتصال وای فای به طرز قابل توجهی کند می شوند.

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

● اشتباه 3: ساده سازی نکردن کنترل:
در بسیاری از مواقع توسعه دهندگان با ساده سازی نکردن کنترل وظایف در نظر گرفته شده در کد، در واقع آغاز یک فاجعه را رقم می زنند. مایک سوبلسکی، یکی از مؤسسان OtherInBox.com از مدافعان سرسخت این ایده است که برای هر کاری باید فقط یک محل در کد وجود داشته باشد. اگر این مکان ها به دو برسد، احتمال دارد که کسی یکی از آن ها را تغییر داده، اما دیگری را تغییر ندهد.

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

همان طور که ممکن است حدس زده باشید، سوبلسکی یک برنامه نویس Ruby on Rails است. این فریم ورک سادگی و کوتاهی کد را ترویج می کند و در این راستا فرض می کند که ساختار نرم افزار با یکی از الگوهای شناخته شده هماهنگ می شود. فلسفه ای که برنامه نویسان Rails بعضی اوقات از آن با اصطلاح «قرارداد، نه تنظیم» یاد می کنند. نرم افزار فرض می کند، اگر کسی یک شیء از نوع Name با دو خاصیت first و last بسازد، نرم افزار باید بلافاصله یک جدول Name در پایگاه داده با دو ستون first و last نیز ایجاد کند. با تعریف نام ها در یک مکان، می توان از مشکلات احتمالی که در اثر رعایت نکردن توالی تنظیمات در لایه ها ایجاد می شود، جلوگیری کرد.

● اشتباه 4: تکیه بیش از حد به فریم ورک ها:
بعضی مواقع ابزارهای جادویی به گمراهی منجر می شوند. با مجردسازی کارکردها، فریم ورک ها در بسیاری از مواقع برنامه نویس را از درک این که چه چیزی در کد درست کار نمی کند، ناکام می گذارند.جی بلیک میک، یک برنامه نویس ساکن سیاتل، یک نمونه از توسعه دهندگانی است که تکیه بیش از حد به ابزارهای خودکاری مانند Ruby on Rails را دور شدن از تولید کدهای تمیز معنی می کند.

میک می گوید : «قرارداد بنا به تعریف، چیزی است که در خارج از کد قرار دارد. به عنوان مثال، تا زمانی که مکانیزم Ruby on Rails را برای تبدیل یک URL به فراخوانی های متد ندانید، هیچ راهی وجود ندارد که متوجه شوید در پاسخ به یک پرس و جو(query) چه اتفاقی می افتد.»میک معتقد است: «در این حالت خواندن کد باید با در اختیار داشتن یک راهنما همراه شود که به شما بگوید در پشت این دستورات دقیقا چه اتفاقی در حال وقوع است.»

میک ادامه می دهد : «قوانین با وجود این که تقریبا منطقی هستند، چندان بدیهی نیستند. برای کار روی برنامه های Ruby on Rails باید این فریم ورک را دقیقا بشناسید. با رشد برنامه، پروژه تان بیش از پیش به این دانش خارجی تقریبا بدیهی وابسته می شود. در نهایت، مجموع این بخش های کمی تا قسمتی بدیهی به مجموعی نابدیهی تبدیل می شود. بنابراین، چیزهای زیادی است که برای کار روی برنامه های این چنینی باید یاد بگیرید و البته هنگام اشکال زدایی برنامه آن ها را به یاد آورید.»مایک مورتون، یک برنامه نویس دیگر می گوید: «فریم ورک ها در نود درصد راه بالا رفتن از کوه، با یک اتاق از امکانات کامل شما را همراهی می کنند، اما این پایان کار آن ها است. اگر می خواهید ده درصد آخر را انجام دهید، باید بتوانید پیش بینی کرده و اکسیژن و امکانات دیگر را از ابتدا با خود بیاورید.»

● اشتباه 5: اطمینان به کلاینت:
بسیاری از باگ های امنیتی هنگامی اتفاق می افتند که توسعه دهندگان فرض می کنند دستگاه کلاینت کار درست را انجام خواهد داد. به عنوان مثال، کدی که برای اجرا در مرورگر نوشته شده می تواند توسط مرورگر بازنویسی شده تا کار مشخصی را انجام دهد. اگر برنامه نویس برگشتن مجدد تمام داده ها را دوباره بررسی نکند، همه چیز می تواند دچار مشکل شود. یکی از ساده ترین حمله ها بر پایه این حقیقت ایجاد شده است که بعضی از برنامه نویسان داده های کلاینت را مستقیم به پایگاه داده می فرستند. فرآیندی که به خوبی کار می کند، البته تا زمانی که کلاینت تصمیم بگیرد به جای فرستادن جواب های سالم، SQL به پایگاه داده بفرستد. اگر سایتی از کاربر نام وی را درخواست کرده و وی نام را به یک پرس وجو اضافه کند، مثلا به جای نام x; DROP TABLE users.. را تایپ کند، پایگاه داده به شکلی کاملا وظیفه شناسانه فرض می کند که نام x است، سپس به دستور بعدی رفته و جدول مربوط به کاربران را پاک می کند. راه های فراوانی برای سوء استفاده از اطمینان یک سرور وجود دارد که افراد خرابکار از آن سود می برند. نظرسنجی های وبی می توانند دعوت نامه ای برای تزریق Bias باشند. سرریزکردن بافر هنوز هم یکی از ساده ترین راه های خراب کردن یک نرم افزار است.

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

● اشتباه 6: اطمینان نکردن کافی به کلاینت:
بعضی اوقات امنیت فراوان به صورت پارادکس گونه ای به ایجاد حفره های امنیتی منجر می شود. چند روز بیش، به من گفته شد که راه حل مشکل بخشی از یک نرم افزار خاص، chmod 777کردن دایرکتوری و تمام فایل های درون آن است. امنیت فراوان می تواند به هدر رفتن تلاش ها منجر شود و برنامه نویس را مجبور سازد که محدودیت ها را کمتر کند تا تنها بتواند فرآیند را اجرا کند.

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

● اشتباه 7: وابستگی بیش از حد به بسته های جادویی:
آیا نگران امنیت هستید؟ فقط کمی رمزنگاری چاشنی آن کنید. می خواهید پایگاه داده شما پشتیبان داشته باشد؟ فقط دکمه Automated Replication را فشار دهید. نگران نباشید، فروشنده گفته است : «این روش به خوبی جواب می دهد.» برنامه نویسان کامپیوتر افراد خوشبختی هستند. دانشمندان علوم کامپیوتر به طور مرتب کتابخانه های فوق العاده ای ایجاد می کنند که با گزینه های فراوانی برای کمک به کدهای ما پر شده اند. تنها مشکل این است که سادگی همراه با استفاده از کد شخصی یا گروهی دیگر در پروژه خود، می تواند مسائل پیچیده ای را به وجود آورد یا حتی بدتر دام های جدیدی را وارد کد شما کند.

جان ویگا، یکی از مؤلفان «24 گناه نابخشودنی امنیت نرم افزار : رخنه های برنامه نویسی و شیوه اصلاح آن ها» اعتقاد دارد، رمزشناسی یک از مهم ترین منابع ضعف در این مسئله است. تعداد بسیاری زیادی از برنامه نویسان تصور می کنند که می توان یک کتابخانه Encryption را به برنامه لینک کرد، دکمه ای را فشار داده و از امنیتی غیرقابل نفوذ برخوردار شد. اما واقعیت این است که بسیاری از این الگوریتم های جادویی ضعف هایی پنهان دارند و یافتن این ضعف ها به یادگیری ای بیشتر از آن چیزی که در بخش Quick Start راهنمای آن ها گفته شده است نیاز دارد. حال برای یادگیری بیشتر در باره این الگوریتم ها به کسب دانش بیشتری درباره موضوع نیاز دارید و این نیازمند صرف وقت و زمان است. به همین دلیل، بسیاری از برنامه نویسان ترجیح می دهند تا به این کدها اطمینان کرده و بدون مطالعه بیشتر، از آن ها در پروژه هایشان استفاده کنند.

● اشتباه 8: اختراع دوباره چرخ:
درست کردن ماست خود، قصابی کردن دام های خود و نوشتن کتابخانه های خود فقط به این دلیل که فکر می کنید راه بهتری برای کد زنی آن دارید، می تواند دردسرهای زیادی برای شما به همراه داشته باشد.ویگا می گوید : «پرورش دادن رمزنگاری مخصوص به خودتان یک خوشامد گویی برای حمله کنندگان است.» توجه کنید که حتی خبره ها هم وقتی سعی می کنند دیگران را از یافتن و استفاده از ضعف های سیستم شان بازدارند، ممکن است اشتباه کنند.

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

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

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

● اشتباه 10: بهای بیش از حد به تجربه کاربر:
بعضی از توسعه دهندگان با ارائه کردن فقط یک راه حل برای هر نیاز، مشکلات گنجاندن تعداد زیادی ویژگی را از میان می برند. جی میل، به ارائه کردن انتخاب های محدودی که توسعه دهندگان عاشق آن هستند، معروف است. شما پوشه ندارید، اما می توانید ایمیل های خود را با توجه به کلمات tag کرده یا روی آن ها label قرار دهید. ویژگی هایی که توسعه دهندگان عقیده دارند از داشتن پوشه بسیار قدرتمندتر هستند.

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

● اشتباه 11: بستن سورس کد:
یکی از دشوارترین چالش های هر شرکت مشخص کردن میزانی از نرم افزار است که قرار است با دیگر افراد تقسیم شود. جان گیلمور، از مؤسسان Cygnus Solutions یکی از نخستین شرکت های اپن سورس، اعتقاد دارد تصمیم به توزیع نکردن سورس کد علیه یکپارچگی نرم افزار عمل کرده و یکی از راحت ترین راه های جلوگیری از خلاقیت و از آن مهم تر جلوگیری از پوشاندن و اصلاح باگ ها است.

گیلمور می گوید : «از نتایج عملی باز کردن کد، کمک افرادی که شما تا به حال اسمشان را هم نشنیده اید به توسعه و بهبود پروژه نرم افزاری تان است. آن ها باگ ها را خواهند یافت ( و برای اصلاح آن ها تلاش می کنند)، ویژگی های جدید اضافه کرده و مستند سازی را بهبود می بخشند. حتی اگر بهبود انجام شده توسط آن ها، به شیوه آماتوری صورت گرفته باشد، یک بررسی چند دقیقه ای از طرف تیم توسعه می تواند به یافتن راه حل هماهنگ تری برای حل همان مشکل منجر شود.»

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

● اشتباه 12: فرض این که بازبودن درمان همه چیز است:
تا به حال میلیون ها پروژه اپن سورس عرضه شده و تنها نسبت اندکی از آن ها توانسته است توجه کاربرانی بیش از انگشتان یک دست را برای کمک به نگه داری، بازبینی و گسترش خود جلب کنند. به معنای دیگر، جمله معروف «اگر آن را بسازید، افراد به سراغش خواهند آمد،» همیشه نتایج خوبی را در عمل تولید نمی کنند.

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

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

بارها پیش آمده، کدهایی که تنها بعضی وقت ها کار می کنند، به داخل SourceForge انداخته شده تا شاید کسی پیدا شده و با سپری کردن زمان قابل توجهی آن ها را کامل کند. این تصمیمی است که می تواند یک پروژه را قبل از آن که واقعا شروع شده باشد، از مسیر خارج کند.

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




( بدون کامنت - اولین کامنت را شما بنویسید )



 



سوالات و نظرات کاربران در مورد این مطلب

هنوز نظری در مورد این مطلب ارسال نشده است. شما اولین نفر باشید!

نکات مهم :

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

* نام 
آدرس ايميل (برای دریافت پاسخ از طریق ایمیل)
* شماره موبایل (برای دریافت پاسخ از طریق SMS)
توجه: ایمیل و موبایل شما فقط برای دریافت پاسخ سایت بوده و نمایش داده نمیشود.
* متن

* کد امنیتی
کد امنیتی


(اگر کد امنیتی واضح نیست، روی آن کلیک کنید تا عوض شود)
 


توجه : نظر شما بعد از تایید از طرف سایت، نمایش داده خواهد شد.



سرزمین دانلود، مرجع دانلود و آموزش نرم افزار

سرزمین دانلود را دنبال کنید !

عضویت در خبرنامه سرزمین دانلود

با وارد کردن ایمیل خود و سپس تایید آن، جدیدترین مطالب و نرم افزار ها برای شما ارسال می شود:



------------------------------------------