۱۲ اشتباه متداول برنامه نویسان

یک مجله مربوط به خودرو زمانی اعلام کرده بود, که اگر توضیح خصوصیات یک خودرو پیش از قرض دادنش به یک دوست بیش از ۱۵ دقیقه طول بکشد, آن خودرو «دارای کاراکتر » یا شخصیت است با توجه به این استاندارد, هر قطعه نرم افزاری دارای کاراکتر است

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

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

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

● اشتباه ۱: سریع و بی‌دقت بازی کردن

در نظر نگرفتن موارد اولیه کار، راحت‌ترین روش برای از کار انداختن کد است. معمولاً این نکته به معنای در نظر نگرفتن نحوه رفتار یک کاربر دلخواه است. آیا ورودی صفر در یک عملیات تقسیم مورد استفاده قرار می‌گیرد؟ آیا متن 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 به دلیل برنامه‌نویسی سریع و بی دقت از بین نمی‌رود.

● اشتباه ۲: توجه بیش از حد به جزئیات

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

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

● اشتباه ۳: ساده سازی نکردن کنترل

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

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

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

● اشتباه ۴: تکیه بیش از حد به فریم ورک‌ها

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

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

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

● اشتباه ۵: اطمینان به کلاینت

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

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

● اشتباه ۶: اطمینان نکردن کافی به کلاینت

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

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

● اشتباه ۷: وابستگی بیش از حد به بسته‌های جادویی

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

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

● اشتباه ۸: اختراع دوباره چرخ

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

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

● اشتباه ۹: شفافیت بیش از اندازه برای کاربر

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

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

● اشتباه ۱۰: بهای بیش از حد به تجربه کاربر

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

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

● اشتباه ۱۱: بستن سورس کد

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

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

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

● اشتباه ۱۲: فرض این‌که بازبودن درمان همه چیز است

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

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

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

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

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

منبع: اینفو ورلد

ترجمه: کیومرث سلطانی