ضرورت تکنولوژی

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

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

شکست نظامی ناشی از عدم استفاده از تکنولوژی روز فقط مختص به ما نیست:

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

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

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

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

می‌دانستید روزهایی در بورس تهران وجود داشته که انجام معاملات متوقف شده آن هم به این علت که نرم‌افزار هدایت معاملات، توانایی پردازش ارقامی بزرگتر از یک حد معین را نداشته؟ می‌دانستید سال‌هاست سازمان امور مالیاتی کشور به دنبال شرکتی می‌گردد که بتواند یک نرم‌افزار جامع مالیاتی تهیه کند ولی موفق نمی‌شود؟ می‌دانستید که یکی از نهادهای مهم کشور هرگز موفق نشده برای رفع نیازهای داخلی خودش به یک نرم‌افزار با قابلیت image processing از یک شرکت داخلی نرم‌افزار تهیه کند؟ آیا می‌دانستید که در زمان شروع پروژه کارت ملی شایع بود که به علت ناتوانی ایرانی‌ها، یک شرکت هندی نرم‌افزارهای مورد نیاز برای پروژه کارت ملی را تهیه کرده؟ آیا می‌دانستید…

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

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

فردا پرداز

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

به همین دلیل یک سایت جدید به آدرس FardaPardaz.com (فردا پرداز) ثبت کرده و فعالیت‌های جدیدی را در آنجا شروع کرده‌ام. برای کسب اطلاعات بیشتر راجع به «فردا پرداز» یا به وب‌سایت آن مراجعه کنید یا به وبلاگ آن. آدرس وبلاگ فردا پرداز http://blog.FardaPardaz.com و آدرس فید آن http://blog.fardapardaz.com/syndication.axd است. لطفاً بنده را از نظرات ارزشمندتان محروم نفرمایید.

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

‫‫C#‎ برای توسعه برنامه‌های dynamic

به غیر از ما، خیلی‌های دیگر هم به فکر توسعه برنامه‌های dynamic با C#‎ و ‎.Net هستند. به عنوان نمونه به تلاش مایکروسافت در نسخه‌های ۳ و بعد از ۳ دات‌نت دقت کنید (LINQ و بقیه) یا به کتاب‌هایی مثل Pro Dynamic .NET 4.0 Applications: Data-Driven Programming for the .NET Framework نگاهی بیندازید.

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

آیا نرم‌افزار تجارت کثیفی است؟

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

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

این طور مسائل هم باعث می‌شود سازمان‌ها و افراد دید چندان مثبتی نسبت به کار نرم‌افزار نداشته باشند و هم باعث می‌شود رقابت در بین شرکت‌های نرم‌افزاری کمی کثیف شود.

بی‌اطمینانی به مایکروسافت

سال‌های سال است که با محصولات مایکروسافت کار می‌کنم. دقیقاً از داس ۵ به این طرف. البته هیچ وقت هم با این موضوع مشکل خاصی نداشتم. هر وقت مایکروسافت داس را کنار می‌گذاشت و ویندوز را رو می‌کرد ما هم سراغ ویندوز می‌رفتیم، هر وقت ASP Classic را دور می‌انداخت ما هم همین کار را می‌کردیم و سراغ ASP.NET می‌رفتیم. خلاصه این که هر وقت مایکروسافت یکی از فناوری‌هایش را با فناوری جدیدتری جایگزین می‌کرد ما هم بدون هیچ اعتراضی همین کار را می‌کردیم. این تند تند عوض شدن فناوری را هم می‌گذاشتیم به حساب این که در دنیای کامپیوتر همه چیز تند تند عوض می‌شود و این ماییم که باید خودمان را با این موضوع تطبیق دهیم.

اما از وقتی که با NHibernate آشنا شدم و روال کار آن را با LINQ-to-SQL و Entity Framework مقایسه کردم دیدم که یک جای کار می‌لنگد. NHibernate با احستاب سوابق جاوایی‌اش چندین سال است که به خوبی کار کرده و خیلی کم دچار تغییرات شدید شده است. کلیاتی که از NHibernate یاد گرفته‌ام هنوز همان است و مجبور نشده‌ام به جز LINQ-to-NHibernate که یک افزونه جدید حساب می‌شود نه یک تغییر، چیز اساسی یاد بگیرم. اما کسانی که ORM را با مایکروسافت شروع کرده‌اند مثل من راحت نبوده‌اند. چون اول وقت زیادی روی LINQ-to-SQL گذاشتند ولی بعد از مدت کوتاهی به آنها اعلام شد که LINQ-to-SQL دیگر توسعه داده نخواهد شد و به جای آن باید از Entity Framework استفاده کنند. این یعنی چیزی را که یاد گرفته و به آن عادت کرده‌اید را باید به طور کامل دور ریخته و فناوری جدیدتری را با صرف کلی وقت یاد بگیرید.

مشابه این مسئله را در SourceSafe و جایگزینی آن با TFS هم دیده‌ام. کسانی که با SourceSafe کار می‌کردند مجبور شدند آن را با TFS عوض کنند. اما کسانی که از همان اول با SVN کار می‌کردند هیچ وقت دچار همچین اجباری نشدند. حدس می‌زنم همین مسئله را در مورد Web Serviceها از یک سو و ‎.Net Remoting و WCF از دیگر سو داشته باشیم.

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

انواع طراحی در نرم‌افزار

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

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

طراحی کارکرد (نوع اول)

طراحی کارکرد برنامه از دید کاربرد. این نوع طراحی مواردی مثل زیر را مشخص می‌کند:
۱- روال انجام یک کار معین چطور است و شامل چرا مراحلی می‌شود.
۲- روش ارتباط کاربر با برنامه از چه طریق بیشتر باشد، صفحه کلید، ماوس یا چیز دیگر؟
۳- اگر برنامه در جایی دچار خطا شد این خطا را چطور به کاربر اعلام کند و بعد از اعلام خطا چه چیزی باید اتفاق بیفتد؟
۴- برنامه چطور باید جلوی اشتباهات احتمالی کاربر را بگیرد.
۵- کار کردن با برنامه چقدر برای کاربر راحت است؟
۶- رنگ، اندازه قلم و کوچک بزرگی دکمه‌ها و فرم‌ها چطور باید باشد؟
۷- اگر کاربر اطلاعاتی را در صفحه‌ای وارد کرد و سهواً خارج شد، آیا برنامه تمهیدات لازم را برای جلوگیری از دست رفتن اطلاعات کابر دارد؟
۸- اگر یک چیز کوچک از نیازمندی‌های برنامه دچار مشکل شد، مثلاً اینترنت قطع شد یا کاغذ پرینتر تمام شد، آیا کل برنامه از کار می‌افتد؟
۹- آیا امکان تست برنامه یا قسمتی از آن بدون تاثیر بد روی اطلاعات عملیاتی وجود دارد؟
۱۰- امکانات backup/restore چقدر آسان و مطمئن است؟
۱۱- آیا سابقه‌ای از خطاهای سیستم وجود دارد؟
۱۲- آیا ساختار برنامه با منطق و صنعت مشتری (حسابداری، انبارداری و…) منطبق است؟
۱۳- آیا می‌توان در سیستم مشخص کرد که هر کسی چه کاری کرده؟
۱۴- آیا واقعاً برنامه توانسته سرعت عمل کاربرانش را بالا ببرد؟
۱۵- آیا برنامه می‌تواند علت خطاهای به وجود آمده را خوب بفهمد و علت واقعی خطا را نمایش دهد؟
۱۶- آیا برنامه طوری نوشته شده که نیاز به حضور مستمر افراد تیم پشتیبانی نداشته باشد؟
۱۷- چقدر طول می‌کشد تا کاربر بتواند به اطلاعات مورد نظرش دست پیدا کند؟ به عبارت دیگر جستجوی اطلاعات چقدر آسان یا سخت است.
۱۸- آیا برنامه یادش می‌ماند که کاربر در مراحل قبلی در حال انجام چه کاری بوده؟ این موضوع به کاربر کمک می‌کند تا مجبور نشود یک سری عملیات را مجدداً تکرار کند. مثلاً وقتی روی یکی از اقلام Grid کلیک شد و وارد صفحات اطلاعات جزیی شد، بعد از اتمام کار در صفحه جزیی بتواند به همان صفحه و آیتم از Grid قبلی بازگردد. یا اگر مثلاً کاربر در سه روز پیش در حال وارد کردن اطلاعات حضور و غیاب بود، بعد از سه روز باز هم بتواند از همانجا کارش را ادامه دهد.
۱۹- آیا امکان کار به صورت تعداد بالا یا فله‌ای (Bulk) موجود است؟ مثلاً اگر قرار شد ۱۲۰ تا نامه در پوشه «اداره مالیات» بایگانی شود باید این کار را تک تک انجام داد یا امکان انجام دفعتی آن موجود است؟
۲۰- آیا چیزی به نام امکان «ذخیره موقت» موجود است؟ مثلاً اگر انجام کاری ۳۰ دقیقه طول بکشد، آیا کاربر می‌تواند وسط کار بلند شده و با ذخیره موقت کار خیالش راحت باشد که اگر حتی کامپیوترش خاموش هم که شد باز کار نصفه نیمه‌اش از دست نخواهد رفت؟
۲۱- آیا برنامه امکان یادگیری از کاربر را دارد؟ مثلاً برنامه می‌تواند از کاربر یاد بگیرد روش اسکن و ذخیره مدارک چطور است و خودش این کار را با کمک چیزی مثل macro به طور خودکار و با کمترین دخالت کاربر انجام دهد؟
۲۲- آیا با یک نگاه کلی به برنامه می‌توان وضعیت فعلی برنامه مثل ارتباط با شبکه، عدم hang یا کاربر login کرده را فهمید؟
۲۳- …

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

طراحی فنی (نوع دوم)

این نوع طراحی را خیلی راحت‌تر می‌توان درک کرد. منظور از این طراحی، طراحی مورد نیاز برای پیاده‌سازی نرم‌افزار از جمله موارد زیر است:
۱- معماری لایه‌های نرم‌افزار چطور باشد؟
۲- از کدام رابط برای ارتباط با دیتابیس استفاده شود؟ از ADO.NET یا NHibernate؟
۳- تعریف عملیات در یک کلاس واحد باشد یا در طول چند کلاس پراکنده؟
۴- آیا لازم است از interfaceها استفاده شود؟
۵- تبادل اطلاعات بین صفحات از طریق query string انجام شود یا session؟
۶- دریافت اطلاعات از متودها به صورت ref و out باشد یا از کلاس‌های کمکی موسوم به DTO استفاده شود؟
۷- خوانایی مهم‌تر است یا performance؟
۸- منطق تجاری برنامه در اسکریپت‌ها و stored procedureهای دیتابیسی نگهداری شود یا در کلاس‌های سرویسی دات‌نت؟
۹- استفاده از تریگرها در دیتابیس مجاز است یا خیر؟
۱۰- از کدام فناوری برای Ajax استفاده شود؟
۱۱- …

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

مقایسه با صنعت ساختمان

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

خواندن کتاب‌های کامپیوتری

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

دسته اول: ابزارها
شامل کتاب‌هایی که برای آشنایی و یادگیری ابزار خاصی نوشته شده‌اند. مثل:

دسته دوم: فناوری‌ها
شامل کتاب‌هایی که استفاده از فناوری خاصی را آموزش می‌دهند. مثل:

دسته سوم: زبان/مفهوم
کتاب‌هایی که زبان‌های برنامه‌نویسی را آموزش می‌دهند، راجع به یک استاندارد صحبت می‌کنند یا مباحث آکادمیک مثل طراحی الگوریتم، لایه‌های شبکه، سیستم عامل و… را مورد بحث قرار می‌دهند. مثل:

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

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

کتاب‌های دسته دوم (فناوری‌ها) نسبت به کتاب‌های دسته‌ی قبل نیاز به مطالعه و دقت بیشتری دارند. اگر چه همیشه لازم نیست آدم همه‌ی سوراخ سنبه‌های یک فناوری را بلد باشد اما اقلاً باید بداند آن فناوری چه طور امکاناتی دارد و اقلاً به طور سر سری هم که شده یک بار مطالبی راجع را به آن خوانده باشد. کتاب‌های این دسته و دسته قبل همیشه نیاز به کمی تمرین دارند.

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

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

مشکل ارتقای اجزای نرم‌افزار

یکی از مشکلات بزرگی که نرم‌افزار نویس‌ها مدام با آن دسته و پنجه نرم می‌کنند مشکل ارتقا اجزا و بخش‌های مختلف یک نرم‌افزار است. برای این مشکل مثال‌های زیادی وجود دارند:
۱- برنامه را با VB6 نوشته‌اید ولی حالا که به VB.NET ارتقا داده‌اید متوجه شده‌اید که پیش‌فرض VB.NET برای اعضای کلاس private است نه public.
۲- برنامه را با NHibernate 1.2 نوشته‌اید ولی بعد از ارتقا به NHibernate 2.0 فهمیده‌اید که برنامه با آن configuration قدیمی کار نمی‌کند و باید web.config/app.config را هم عوض کنید.
۳- برنامه را با فلان library نوشته‌اید و بعد از ارتقا به نسخه جدید فهمیده‌اید که نسخه جدید به خیلی از مسائلی که قبلاً گیر نمی‌داد حالا گیر می‌دهد و نمی‌گذارد برنامه اجرا شود.
۴- در برنامه‌های ASP.NET از کنترل‌های Telerik استفاده کرده‌اید و بعد از ارتقا فهمیدید که tagهای استفاده شده در markup اسمشان عوض شده و حالا دچار parser error شده‌اید.
۵- در برنامه‌ای که برای ویندوز ۹۵ نوشته شده از یک API خاص استفاده شده که دیگر در ویندوزهای جدیدتر وجود ندارد.
۶- در بخشی از برنامه از نسخه x یک library استفاده کرده‌اید و بعداً لازم می‌شود بخشی از یک نرم‌افزار دیگر را به نرم‌افزار فعلی‌تان الحاق کنید اما این بخش جدید از نسخه y استفاده می‌کند نه x.
۷-…

این مسئله که برای برنامه‌نویسان عذاب‌آور و برای مدیران ترس‌آور است را می‌توان به دو بخش خارجی و داخلی تقسیم کرد. بخش خارجی مربوط است به dllها، libraryها، APIها و platformهایی که از خارج شرکت/تیم می‌آیند و معمولاً حق انتخاب زیادی در مورد آنها وجود ندارد. بخش داخلی مربوط است به اجزا و dllهایی که در داخل شرکت ساخته می‌شود و version زدن آنها یک مصیبت بزرگ است. در مورد dllهای داخلی مسئله backward comaptiblity و وابستگی به dllهای دیگر هم باید چک شود. چیزی که معمولاً در مورد dllهای خارجی بهتر رعایت می‌شود.

برای کاهش مشکلات ارتقا به نظر بنده موارد زیر را می‌توان در نظر گرفت:
۱- مثبت‌نگر باشید. ارتقا dllها خصوصاً در مورد dllهای خارجی معمولاً نوید دهنده امکانات بهتر و کامل‌تر است. معمولاً هدف از ارائه نسخه جدیدتر رفع اشکالات نسخ قبلی، بهبود عملکرد و… است. پس بنابراین خوشحال باشید که رفع مشکلات مربوط به نسخه جدید به معنی ارتقا کیفیت نرم‌افزار شما خواهد بود.
۲- پیروی از اصل KISS (Keep It Simple Stupid)‎: یعنی تا آنجا که می‌توانید برنامه را ساده نگه داشته و بیخودی از هر کتابخانه، class و dll دیگری استفاده نکنید.
۳- Dependency Injection: برنامه‌ها با حداقل وابستگی به هم نوشته شوند.
۴- موتوا قبل ان تموتوا (بمیرید قبل از آن که بمیرید): قبل از آن که مجبور شوید ارتقا دهید، ارتقا دهید. تولید کنندگان نرم‌افزار معمولاً قبل از ارائه نهایی نسخ جدید آنها را به صورت نسخه‌های آزمایشی ارائه می‌دهند و حتی قبل از آن کلی بحث راه می‌اندازند، نظر سنجی و اطلاع‌رسانی می‌کنند که ما قرار است فلان چیز را به نرم‌افزارمان اضافه کنیم یا تغییر بدهیم. بنابراین فرصت خیلی زیادی دارید که خود را به موقع ارتقا دهید.
۵- پیروی از تجارب TDD مثل Unit Test و Continuous integration: این راه‌حل خصوصاً در مورد dllهای داخلی خیلی خوب جواب می‌دهد. اگر برای همه بخش‌هایی ممکن unit test نوشته باشید آن وقت نگرانی کمتری برای ارتقا دارید چون خیلی سریع می‌فهیمد که آیا چیزی خراب شده یا نه. Continuous integration هم به همین شکل کمک می‌کند که در حداقل زمان ممکن خطا را کشف کنید.
۶- به هیچ وجه Warningهای هنگام کامپایل را دستکم نگیرید. خیلی از warningهای نسخه امروز به compile errorهای نسخه فردا تبدیل خواهند شد.
۷- استفاده از الگوهای جدیدی مثل MVC چون کار تست را راحت‌تر کرده و decoupling که با استفاده از dependency injection محقق می‌شود را بهتر اجرا می‌کنند.

شما چه راه‌هایی برای کاهش این طور مشکلات سراغ دارید؟

استفاده از مفاهیم جدید تولید نرم‌افزار

روند طراحی و توسعه نرم‌افزار طی ده سال گذشته حتی در همین ایران خودمان هم تغییرات زیادی داشته. آن زمان یعنی حدود سال ۷۹ شمسی مردم تازه از شر FoxPro خلاص شده و به دیتابیس‌های مدرن‌تری مثل Access، MS SQL Server و Oracle رو آورده بودند. برنامه‌نویسی در عصر ویندوز راحت‌تر و منظم‌تر شده بود. تا قبل از آن عموماً کسی لذت Foreign Key و Delete/Update Cascade را کشف نکرده بود. طی این ده سال استفاده از Database Driver و ADO رواج زیادی پیدا کرد. در این دوره آنها که منظم‌تر بودند از نمودارهای ERD برای بیان ساختار دیتابیس، نرمال‌سازی، کلاس‌های مجزا برای دسترسی به دیتابیس (معماری سه لایه) و… استفاده می‌کردند.

اما اکنون آن دوران به سر آمده و ما خیلی وقت است که وارده دوران Domain Driven Design یا همان DDD شده‌ایم. در عصر DDD هیچکس مستقیماً به دیتابیس وصل نمی‌شود بلکه از ORM‌ استفاده می‌کند. روابط بین entityها به جای ERD با UML Class Diagram تعریف می‌شود و معماری‌های چندلایه‌ای با استفاده از DDD خیلی راحت‌تر شده و…

حال سوال این است که آیا لازم است ما هم صرفاً به خاطر همراهی با زمان یه سمت Domain Driven Design و Object Oriented برویم یا این که واقعاً نفعی برای ما و شرکت‌مان در آن وجود دارد؟ جواب این سوال هر دو است. چون اولاً وقتی که همه دنیا به این سبک جدید رو آورده‌اند خیلی سخت است که ما همان روش‌ها و ابزارهای قدیمی را نگه داریم و خلاف جریان آب شنا کنیم. ثانیاً عصر جدید امکانات بسیار خوبی را با خود به همراه آورده است و نباید آن را به این سادگی از دست بدهیم.

عصر جدید یعنی دنیای Domain Driven Design و Object Oriented که با استفاده از ORMها و UML محقق می‌شود به شما کمک می‌کند که:
‫۱- کد شما قابلیت نگهداری بالایی داشته باشد.
‫۲- پیدا کردن و برطرف کردن باگ‌ها راحت‌تر باشد.
‫۳- اگر طراحی درست انجام شده باشد، برنامه‌نویسی راحت‌تر خواهد بود.
‫۴- مزایای معرفی شده در Object Oriented به طور ملموسی در دسترس قرار خواهد گرفت. مفاهیمی مثل Inheritance باعث می‌شود حجم کد کاهش یابد.
‫۵- کدهای DDD خیلی منظم‌تر از کدهای تولید شده در دوران قبل هستند.
‫۶- تولید نرم‌افزارهای DDD هم‌خوانی بسیار بیشتری با متودولوژی‌های جدید اسکرام، XP و… دارد.
‫۷- …

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