alt.net
چند سال پیش این بخت را داشتم تا کمی در حرفه برنامه‌نویسی پیشرفت کنم. فرصتی برای رهبری، خودش را به من نشان داد و من از آن نهایت استفاده را بردم. طی چند ماه مهارت‌های برنامه‌نویسی من به طور نمایی رشد کردند و من طی چند سال گذشته به تکمیل ان‌ها ادامه داده‌ام. بدون شک هنوز چیزهای زیادی هست که باید یاد بگیرم و ۵ سال دیگر اگر به کدهایی که الان نوشته‌ام نگاهی بیندازم مطمئنا از آن‌ها خجالت خواهم کشید. پیش از این عادت داشتم به مهارت‌های برنامه‌نویسی خودم اطمینان داشته باشم، اما تنها هنگامی که پذیرفتم چیزهای بسیار کمی می‌دانم و احتمالاً همیشه این طور خواهد بود، واقعاً شروع به فهمیدن کردم.
سری «اصول برنامه‌نویسی» مجموعه‌ای است از نوشته‌های وبلاگ من که به برنامه‌نویسان با اشتیاق کمک می‌کند تا بتوانند به خودشان کمک کنند. طی این مجموعه نگاهی خواهیم انداخت به موضوعاتی که فهم آن‌ها به جز برای کسانی که قبلا با ان‌ها کار کرده‌اند چندان آسان نیست. من همیشه دو جبهه را در دنیای دات‌نت دیده‌ام، یکی که به شدت از طرف مایکروسافت به عنوان ادامه طبیعی VB6 و ASP کلاسیک پشتیبانی می‌شود (معمولاً به آن روش MSDN[1] گفته می‌شود) و دیگری که به شدت نشأت گرفته از تجارب شی‌گرایی بوده و تحت تأثیر بهترین پروژه‌ها و مفاهیم جاوا قرار دارد (معروف به ALT.NET).
در دنیای واقعیت چندان نمی‌توان این دو را با هم مقایسه کرد. روش MSDN راهی را تعریف می‌کند که در آن یک برنامه درحد فراخوانی تک تک APIها تعریف می‌شود (مگر نه اینکه همه فقط به خاطر مستندات مرجع APIهاست که به سراغ MSDN می‌رویم؟). در حالی که ALT.NET روی موضوعات مجردتر و ارائه پیاده‌سازی آن‌ها متمرکز است. همان‌طور که Jeremy Miller می‌گوید: جامعه دات‌نت زیادی بر یادگیری APIها و جزییات frameworkها تمرکز کرده در حالی که طراحی و اصول کدنویسی را فراموش کرده‌است. به عنوان یک مثال خوب، روش MSDN برای ارتباط با پایگاه داده‌ها به شدت بر DataSet و DataTable تاکید می‌کند. در حالی که ALT.NET به الگوهای ذخیره‌سازی[2]، مشکل ناهمگونی شی-رابطه‌ای[3] و همه پیاده‌سازی‌های رایج آن مثل NHibernate (O/R Mapping) و MonoRail (ActiveRecord) و حتی DataSet و DataTable توجه می‌کند. به عبارت دیگر بر خلاف تصور خیلی از مردم، ALT.NET جایگزین روش MSDN نیست بلکه به این معنی است که برنامه‌نویسان باید به راه حل‌های متنوع دیگری که خود روش MSDN هم بخشی از آن است دقت بیشتری کنند.
البته از آنچه که گفته شد مشخص است که کار کردن به روش ALT.NET نیاز به تعهد خیلی بیشتر و دایره اطلاعات خیلی بیشتری دارد. یادگیری آن سخت‌تر است و منابع آن کم‌تر (که همین امر دلیل اغاز این مجموعه است). البته این روش ارزش سختی آن را دارد. برای من، موفقیت حرفه‌ای منجر به رضایت شخصی بسیار بیشتری شده‌است.
اهداف
اگرچه ساده‌اندیشانه است اما هر تصمیمی که در مورد برنامه‌نویسی می‌گیرم بر اساس قابلیت نگهداری[4] آن است. قابلیت نگهداری موضوعی کلیدی در توسعه نرم‌افزار است. خوانندگان ثابت CodeBetter آنقدر درباره قابلیت نگهداری شنیده‌اند که دیگر حالشان به هم می‌خورد. اما دلیلی وجود دارد که ما این‌قدر درباره قابلیت نگهداری صحبت می‌کنیم: این موضوع رمز موفقیت شما به عنوان یک برنامه‌نویس درجه یک است. من می‌توانم چند دلیل برای اثبات این موضوع بیاورم. نخست تجارب شخصی و مطالعات مختلف نشان می‌دهند که بخش قابل توجهی از عمر سیستم‌ها (بیش از ۵۰ درصد) در مرحله نگهداری[5] می‌گذرد. منظور از نگهداری، انجام تغییرات، اصلاح خطا[6]ها و پشتیبانی است. ثانیاً رواج هر روزه روش‌های برنامه‌نویسی چرخه‌ای[7] به معنی تقاضاهای هر روزه تغییرات و امکانات جدید در برنامه‌هاست (و حتی اگر شما از روش‌های چرخه‌ای مثل روش‌های چابک[8] استفاده نکنید باز هم مشتریانتان به همان سبک انتظار انجام تغییرات هر روزه را دارند). به طور خلاصه، راه حل‌های با قابلیت نگهداری بالا به طور خلاصه نه فقط هزینه‌های شما را کاهش می‌دهند بلکه کمیت و کیفیت امکانات برنامه را هم افزایش می‌دهند.
حتی اگر در دنیای برنامه‌نویسی تازه کار باشید، باز هم ممکن است بر اساس تجربیاتی که دارید عقایدی راجع به قابل نگهداری بودن یا نبودن نرم‌افزار پیدا کرده باشید. این عقاید ممکن است از کار کردن با دیگران، بر عهده گرفتن برنامه کسی دیگر یا اصلاح برنامه‌ای که خودتان چند ماه قبل نوشته باشید به دست آمده باشد. یکی از مهم‌ترین کارهایی که می‌توانید انجام دهید یادداشت‌کردن مشکل و جستجو در گوگل است. برای مثال آن‌هایی که سال‌ها با ASP Classic کار کرده‌اند می‌دانستند که یکپارچگی بیش از حد کد آن با HTML اصلا چیز خوبی نبود.
تولید کد قابل نگهداری کار چندان راحتی نیست. در ابتدای راه باید تلاش بسیار زیادی به خرج بدهید تا زمانی که این کار طبیعی‌تر شود. همان‌طور که حدس می‌زنید ما اولین کسانی نیستیم که به قابلیت نگهداری در نرم‌افزار فکر کرده‌ایم. برای رسیدن به این هدف باید کمی خودتان را با ایده‌های مرتبط با قابلیت نگهداری آشنا کنید. همین‌طور که در مرور این ایده‌ها جلو می‌رویم شما هم باید سعی کنید در ان‌ها عمیق‌تر شده، در گوگل به دنبال ان‌ها و پیش‌زمینه آن‌ها بگردید و مهم‌تر از همه سعی کنید آن‌ها را در یکی از پروژه‌های در دست انجامتان به کار گیرید.
[1] The MSDN Way
[2] Persistence
[3] Object-Relational Impedence Mismatch
[4] Maintainability
[5] Maintenance
[6] Bug
[7] Iterative Development
[8] Agile
