چگونه یک برنامه‌نویس باقی بمانیم؟

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

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

الگوریتم

تعریف الگوریتم در ویکی‌پدیا این طوره:

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

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

دونستن الگوریتم‌ها به ما کمک می‌کنه تا در زمان برخورد به مسئله راه حل از پیش آماده داشته باشیم. به بهینه‌ترین حالت ممکن عمل می‌کنه و لازم نیست تا دوباره چرخ رو اختراع کنیم. از سمت دیگه برای هر مسئله راه حل‌های مختلفی وجود داره که توی موقعیت‌های مخصوص به خود بهترین بازدهی رو دارند. مثلاً برای مسیریابی چندین الگوریتم مختلف وجود داره. اگر برای حل پازل هزارتو (Maze) سیستم مسیریابی می‌نویسید شاید بتونید فقط با Breadth-first search مسیر رو پیدا کنید یا اگر برنامه مسیریابی می‌نویسید شاید می‌بایست سری به A* بزنید.
از طرفی دیگه مطالعه الگوریتم‌های موجود تمرینی برای ذهن ماست تا بتونیم نحوه فکر کردن برای حل مساله رو یاد بگیریم.

شی‌گرایی (Object oriented programming)

شی‌گرایی یک پارادایم، روش، نحوه فکر کردن به اجزای یک سیستم ست. در این روش همه چیز شی (Object) در نظر گرفته می‌شود که حاوی اطلاعات است. قصد ندارم اینجا مسئله رو توضیح بدم اما مهارت پیدا کردن در استفاده "صحیح" از شی‌گرایی مهارتی ست که به سال‌ها تجربه و مطالعه احتیاج داره! پاس کردن چند واحد در دانشگاه یا خوندن C# در چند روز یا نوشتن کد جاوا کافی نیست. برنامه‌نویس‌هایی رو می‌شناسم که تا به حال عبارت SOLID رو نشنیدند یا هنگام نوشتن برنامه بهش پایبند نیستند. SOLID مختصر عبارات زیره:

• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

این اصول توسط Michael Feathers بیان شدند. تو کتاب Clean code از Robert C. Martin (یا سری ویدیوهایی که داره) درباره این اصول مفصل توضیح می‌ده. اما قبل از یادگیری این اصول باید بدونید تا حد ممکن باید از شی‌گرایی پرهیز کرد. صحبت درباره این موضوع خودش یه مقاله دیگه ست.
یک نکته آزاردهنده‌ای که اغلب اوقات از اساتید دانشگاه! یا تازه فارق التحصیلان می‌شنوم اینه که C/C++ شی‌گرا نیستند! نمی‌تونم واژه مناسبی که عصبانیتم رو نشون بده پیدا کنم و فقط می‌گم: "دوست عزیز، اشتباه می‌کنی" (لبخند هیستریک) شما حتی توی C می‌تونید شی‌گرایی رو پیاده سازی کنید. این کار پیشنهاد نمی‌شه ولی Axel Schreiner در کتاب Object-oriented Programming in ANSI-C به این امر پرداخته.

الگوهای طراحی (Design patterns)

الگوی طراحی در ابتدا جنبشی بود که توسط Christopher Wolfgang Alexander شکل گرفت. او یک معمار بود! کتابی در زمینه معماری ساختمان ارایه کرد به نام A Pattern Language: Towns, Buildings, Construction که در اون به الگوهای ریاضی یا متدی برای طراحی اجزای خونه از در و چارچوب و پله و غیره اشاره شده بود. هر زمانی که شما به عنوان یک معمار با مسئله‌ای مثل طراحی پلکان، چارچوب یا هر جزیی از خونه رو به رو می‌شدید الگویی معرفی شده بود که با پیروی از اون محصول بدون مشکل و استاندارد طراحی می‌کردید. کتاب و طرز فکر او روی برنامه‌نویسان هم تاثیرگذار بود.

در اوایل دهه نود چهار برنامه‌نویس به نام‌های Erich Gamma, Richard Helm, Ralph Johnson و John Vlissides که به Gang of Four معروف شدند کتابی رو نوشتند که بزرگترین تاثیر رو در تاریخ برنامه‌نویسی رو داشت، Design Patterns: Elements of Reusable Object-Oriented Software توی این کتاب به الگوهایی برای مشکلاتی که در برنامه‌ها به صورت تکراری به وجود می‌آمد پرداختند. علاوه بر اون هر راه حل اسم مشخصی داشت. این کتاب علاوه بر حل مشکلات یا جلوگیری از مشکلات به دایره لغات بین برنامه‌نویس‌ها تبدیل شد. توی این کتاب 23 ؟ الگو معرفی شده بود که تا به امروز قابل استفاده هستند. بعدها سایر برنامه‌نویس‌ها مثل Martin Fowler هم به معرفی الگوهای طراحی پرداختند.

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

چند رشته‌ای (Multi threading)

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

اکثر زبان‌های برنامه‌نویسی هم دسترسی به Thread رو میسر می‌کنند و می‌تونید از قابلیت‌هایی که بهتون می‌ده استفاده کنید.

شبکه

می‌تونید دنیای امروز بدون اینترنت رو تصور کنید؟ بزرگترین شبکه ساخته بشر. تقریباً تمام برنامه‌های کاربردی و شبکه‌های اجتماعی و غیره که استفاده می‌کنیم به نحوی با اینترنت در ارتباط هستند. داشتن دانش از لایه‌های زیرین شبکه به درک بهتر و بازدهی بهتر شما در برنامه‌نویسی سطوح بالاتر کمک می‌کنه. اگر خیلی به برنامه‌نویسی شبکه علاقه ندارید حداقل اطلاعات از مفاهیم شبکه مثل پروتکل‌های شبکه HTTP, SMTP, SNMP, ICMP و خیلی مثال دیگه می‌تونه به شما در رفع نیازهاتون کمک کنه یا در رفع مشکل راحتتر و بهتر عمل کنید.

آشنایی با SQL

عبارت SQL مخفف Structured Query Language ست به معنی زبان پرسش ساختاریافته! زبان استانداری هست که برای پایگاه‌های داده Relational استفاده می‌شه. اگر کار با یکی از این پایگاه‌های داده مثل MS SQL یا MySQL یا حتی SQLite رو یاد بگیرید می‌تونید با کمی تغییر با بقیه پایگاه‌های داده هم کار کنید. هیچ شکی نیست هر برنامه‌نویسی گذرش به پایگاه داده خواهد افتاد.

برنامه‌نویسی مبتنی بر تست (Test driven programming)

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

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

مستندسازی

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

تسلط به IDE

مهم نیست با Emacs یا Vim کد می‌نویسید. Visual Studio یا Eclipse رو انتخاب می‌کنید. اما هر کدوم رو که انتخاب کردید سعی کنید تمام جزییات اون رو یاد بگیرید و به کار ببرید. هر پلاگینی که فکر می‌کنید براتون می‌تونه مفید باشه یا برنامه‌نویس‌های دیگه پیشنهاد میدن رو تست کنید. IDE شما، ابزار شماست که هر روز برای سال‌ها باهاش کار دارید. پس توی انتخاب و یادگیریش وسواس به خرج بدید.

کنترل ورژن

برنامه‌هایی که نسخه‌های قبلی پروژه رو برای ما نگه می‌دارند رو برنامه‌های کنترل ورژن می‌گیم. مثل Git, SVN, Perforce یا غیره. و با اینا لازم نیست دیگه روی فلش فایل منتقل کنید! یا قبل از تغییر بزرگ در نرم افزار یه نسخه زیپ شده از پروژه نگه دارید! نمی‌دونم چه قدر از اهمیت این برنامه‌ها باید بگم اما می‌تونن ناجی کل پروژه و تیم شما باشند! حتی قبل از یادگیری زبان برنامه‌نویسی شروع به یادگیری یکی از مثال‌هایی که گفتم بشید، ضرر نمی‌کنید!

ریاضی

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

آمار

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

چه چیزهایی یاد نگیریم؟ یا با تامل بیشتر یاد بگیریم؟

فریمورک‌ها

اگر تمام مواردی که صحبت کردیم موارد جامع بود و مستقل از زبان بود فریم‌ورک‌ها وابسته به زبان هستند و طول عمر دارند. با گذر از تاریخ مصرفشون دانش و تجربه شما در اون بخش هم دیگه به درد نمی‌خوره. همین چند سال پیش وقتی بخش نیازمندی‌های روزنامه رو باز می‌کردی برای استخدام برنامه‌نویس با انبوه آگهی استخدام برنامه‌نویس C# با تسلط بر JQuery, Entity Framework، WPF و امثالهم رو به رو بودیم. چند سال بعد با موج Angular.JS و الان با React و خیلی چیزهای دیگه که من زیاد ازشون اطلاع ندارم. اما همه اینا تاریخ مصرف دارند و معلوم نیست که شش ماه آینده وجود داشته باشند یا خیر. پس به جای یاد گرفتن فریم ورک‌های مختلف بهتره مهارتمون تو بخش‌های دیگه برنامه‌نویسی رو ارتقا ببخشیم و تا می‌تونیم فریم‌ورک یاد نگیریم!

حباب‌ها

یه زمان RFID خیلی تکنولوژی باحالی بود. هر کسی داشت یه RFID به همه چیز می‌چسبوند. کتاب‌ها نوشته و چاپ می‌شد. یه زمان دیگه اینترنت اشیا یک زمان دیگه VR/AR یه زمان دیگه کینکت...یا الان که این مقاله رو می‌نویسم Block Chain... بانکداری نوین بر اساس بلاکچِین، شهر الکترونیکی بلاک چینی، مسنجر بلاک چینی... همه چیز بلاک چینی می‌شه و به مدینه فاضله می‌رسیم. همه ماینر هستند. همه اینترنت آزاده و دولت‌ها برچیده می‌شن. مسخره ست؟
کسانی که تو تکنولوژی‌های جدید کار می‌کنند دو دسته هستند. یکی توسعه دهنده‌هایی که دارند واقعاً اون محصولات رو توسعه می‌دن یا دارن تکنولوژی جدید خلق می‌کنند. اینا خیلی کاردرست و با دانش هستند و تکنولوژی با وجود همچین افرادی پیش می‌ره. یک سری دیگه هم نونشون توی اینه که برن سراغ تکنولوژی که همه گیر نشده و با اطلاعات گاهاً ناقص و اشتباه خودشون رو طوری نشون بدن که دانشی دارند که بقیه از اونا آگاه نیستند. تو این شرایط این تکنولوژی‌ها حباب هستند و حتی اگر دانش بالای اون رشته رو داشته باشید باز هم ریسک عدم موفقیت اون رو دارید.
اما وقتی یک تکنولوژی ته نشین می‌شه! گل آلودگی اون کمتر می‌شه و کاربرد حقیقی و اکوسیستمش شکل می‌گیره زمان مناسبتری برای عموم برای یادگیری و حرکت به سمت اونه. پس گول حباب‌ها رو نخورید.

در آخر

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