تجربۀ سال‌ها برنامه‌نویسی

نویسنده : سید ایوب کوکبی ۲۵ مرداد ۱۳۹۸
تجربیات سال‌ها برنامه‌نویسی

« مهم‌ترین ترفندی که پس از سال‌ها برنامه‌نویسی آموخته‌اید چه بوده است؟»

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

نیوتون جملۀ معروفی دارد:

اگر فاصلۀ دورتری را می‌بینم به خاطر این است که بر شانۀ غول‌ها ایستاده‌ام.

نیوتون

نمی‌توانم ادعا کنم که تمام این چیزها را خودم یاد گرفته‌ام. این درس‌ها را با کارِ سخت و یادگرفتن چیزهای مختلف در طیِ ۱۹ سال آموخته‌ام که ۵ سالش صرفِ دانشگاه و ۱۴ سالِ دیگر صرفِ برنامه‌نویسی شد. درس‌هایی که گرفتم بسیار برای من آموزنده بود امیدوارم برای شما هم همینطور باشد.

برای اینکه به یک برنامه‌نویسِ خوب تبدیل شوید باید سال‌ها مطالعه و تمرین کنید. کتابِ Peter Norvig یادگیری برنامه‌نویسی در ۱۰ سال را بخوانید.

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

ساده کد بنوسید. ویدیوی Simple Made Easy از ریچ هیکی را تماشا کنید. همچنین قواعد سادگی در متدِ XP از کنت بک را بخوانید. وقتی تازه شروع به برنامه‌نویسی کردم فکر می‌کردم کدهایم خیلی ساده است. سادگی کیفیتِ کد را می‌رساند. وقتی روی یک پروژۀ بزرگ کار می‌کنید ساده نویسی به یک کار سخت تبدیل می‌شود. اصلِ KISS را در اینترنت جستجو کنید. Keep it simple, Stupid یعنی به طرز احمقانه‌ای ساده کد بنویس.

کد در درجۀ اول برای انسان‌ها نوشته می‌شود نه کامپایلرها. آزمونِ نهایی برای تستِ سادگیِ کد این است که آن را به یکی از همکارانِ خود با معلومات مشابه بدهید؛ اگر زمانِ زیادی صرفِ فهمیدن کد کرد دنبالِ علت باشید.

مهارت‌های خود را به رخِ دیگران نکشید. سعی نکنید با هدفِ به رخ کشیدن مهارتهایتان، کدهای پیچیده بنویسید. ساده و خونا کد بنویسید طوری که قابلیتِ استفادۀ مجدد داشته باشد. ساده و شفاف به مسائل فکر کنید. کتابِ «تمرین برنامه‌نویسی» اثرِ برایان کرنیگان و راب پایک را مطالعه کنید. همچنین سخنرانی برایان کرنیگان و کتابِ «برنامه‌نویسی به زبان سی» اثرِ دنیس ریچی و برایان کرنیگان را مطالعه کنید؛

قوانین SRP و DRY را همیشه رعایت کنید. اصلِ Single Responsibility Principle و اصلِ Don’t repeat yourself دو قاعدۀ معروف در مهندسی نرم‌افزار هستند که در کتابِ «کدنویسی تمیز» رابرت سی مارتین به تفصیل توضیح داده شده و البته در اسکارپ هم مروری بر آن‌ها داشته‌ایم. قاعدۀ YAGNI یا You ain’t gonna need it هم وجود دارد که کاربردِ زیادی در کدنویسی دارد. YAGNI می‌گوید به اندازۀ نیاز کد بنویس؛ نه بیشتر و نه کمتر. بر اساسِ این قاعده فقط برای نیازِ امروزتان کد بنوسید تا به over engineering مبتلا نشوید. گاهی طراحی برای آینده ضروری است ولی باید تعادل را رعایت کنید. همه چیز بستگی به خودتان دارد. شما باید بتوانید در موردِ تک تکِ کدهایی که نوشته‌اید دلایلِ معقول بیاورید.

کدی که آشکارا باگی ندارد از کدی است که هیچ باگِ آشکاری ندارد بهتر است.

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

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

شما زمانی برای یک شرکت با دل و جان کار می‌کنید که آن شرکت دلیل و باوری برای انجام کارهایش داشته باشد. گاهی شرکتی به بهتر کردن اوضاعِ دنیا باور دارد. در این شرکت اصلاً مهم نیست در کجای زنجیرۀ فعالیت‌های آن باشید. شما یک رهبر هستید. رهبری یک مسئولیت واحد نیست. مسئولیتِ یک نفر هم نیست. هر کس در یک شرکت یا سازمان باید رهبر باشد. در همین رابطه اکیداً توصیه می‌کنم کتابِ Extreme Ownership: How US Navy SEALs Lead and Win را بخوانید. اگر نمی‌دانید چرایِ رهبرتان چیست خودتان باید آن چرا را پیدا کنید. چگونه می‌خواهید دیگران را ترغیب به انجام کاری کنید در حالی که هنوز پاسخی به چرایی کارتان ندارید؟

سخنرانیِ دیگری نیز تحت عنوانِ Inventing on Principle از برت ویکتور وجود دارد که دیدنش خالی از لطف نیست. این سخنرانی سه قسمتی است و قسمتِ سوم از همه مهم‌تر است. «چه چیزی شما را هدایت می‌کند؟» به نظرِ من این سوال همان سوالِ معروفِ سایمون سینک است. یعنی «چرا؟» به اعتقادِ من یکی از دلایل خلقتِ لنسان پیدا کردن پاسخِ این چرایی است. یعنی به خودمان بیاییم و بیشتر خودمان را بشناسیم.

مشتریانِ شما دقیقاً نمی‌دانند چه می‌خواهند؛ و مدیر یا کارفرمای شما نیز از این قاعده مستثنی نیست. این وظیفۀ شماست که نیازِ اصلیِ آن‌ها را کشف کنید. کتابِ Domain Driven Design اریک ایوانز را بخوانید. الگوهای طراحی آنقدری که فکر می‌کنید کاربرد ندارند. الگوهای مهم را شناسایی کنید. الگوهای طراحی مثل چکشی برای کوبیدن میخ به دیوار نیستند. کتابِ Refactoring to Patterns جوشرا کریایسکی را مطالعه کنید. در همین خصوص پاسخِ استون گریم به این سوال را هم بخوانید: «مهم‌ترین الگوهای طراحی برای استخدام شدن در گوگل، آمازون و فیسبوک چیست؟»

بخوانید  خصوصیات افرادی که مناسب کار تیمی نیستند

اصول SOLID. در رابطه با این اصول پیشتر در اسکارپ مطلبی منتشر کرده‌ایم. اهمیت این اصول از الگوهای طراحی نیز بیشتر است. عمو باب مقاله‌ای با عنوان Principles Of OOD در وبلاگش منتشر کرده که پیشنهاد می‌کنم مطالعه کنید.

متعصب نباشید. معمولاً برای انجام هر کاری چند راه وجود دارد. اصطلاحِ Best Practice بیش از حد بزرگنمایی شده است. در فرایند توسعۀ نرم‌افزار روش‌های خوب وجود دارد ولی هیچ روشی برای همیشه عالی نیست. در استفاده از تکنولوژی‌ها، زبان‌ها و ابزارها متعصبانه برخورد نکنید. روشِ خوب را به مقتضای زمان انتخاب کرده و استفاده کنید. هیچگاه وقت خود را صرفِ پیدا کردن بهترین راهکار نکنید؛ چون اصلاً چنین راهکاری وجود ندارد. هر کسی چنین حرفی زد دروغ گفته و از سرِ ناآگاهی است.

هیچکس همه چیز را بلد نیست. برخی افراد بیشتر از بقیه بلدند.

همیشه سعی کنید بدترین عضوِ یک گروه باشید.

The Passionate Programmer

این به شما کمک می‌کند فرصتی برای یادگرفتن چیزهای جدید از دیگران داشته باشید. ویدیوی باربارا لیسکو The Power of Abstraction را تماشا کنید. در بسیاری از موارد توسعه‌دهندگان بیهوده از Abstraction استفاده می‌کنند. بخش عمده‌ای از کتابِ Domain Driven Design مربوط به همین انتخابِ درستِ Abstraction ها است.

هیچ چیزی کامل نیست ولی شما همیشه می‌توانید در جهتِ کمال قدم بردارید.

کمال، دشمنِ خوبی است.

ولتر

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

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

قدرت با جمع است. محصولات عالی نتیجۀ تلاشِ گروهی هستند. کتاب «پنج اختلالِ یک تیم» از پاتریک لنسیونی یا سخنرانیِ او در مورد این کتاب را ببینید. کتابی عالی دربارۀ چگونگی عملکرد تیم‌های موفق است.

کد را از همان ابتدا به اشتراک بگذارید. با اعتماد به نفسِ بالا و بدون نگرانی کارِ نیمه تمامِ خود را با دیگران به اشتراک بگذارید. منتظر کامل شدن کد نمانید. وقتی از همان ابتدا این کار را بکنید. دیگران فرصتِ بیشتری برای بررسی و ارئۀ بازخورد دارند. اینکه منتظر بمانید تا پروژه را به مرحله‌ای از کمال برسانید و به یکباره چند هزار خط کد منتشر کنید ایدۀ خوبی نیست. در همین رابطه کتابِ Dynamics of Software Development از جیم مک کارتی را مطالعه کنید.

سعی کنید قبل از کدنویسی تست کنید. TDD و BDD را امتحان کنید. کتابِ Working Effectively with Legacy Code مایکل فیزرز را بخوانید. نوشتن تست شاید وقتِ شما را بگیرد، شاید نیازمند پیروی از یک سری اصول و قواعد باشید، شاید در کوتاه‌مدت احساس کنید که وقتِ زیادی صرفِ این کار می‌کنید. ولی قطعاً در درازمدت باعثِ صرفه‌جویی در توسعه خواهد شد. راحت‌تر می‌توانید ویژگی‌های جدید به سیستم اضافه کنید. راحت‌تر می‌توانید کدها را اشکال‌زدایی کنید. بدون تست، توسعۀ سیستم به‌خصوص سیستم‌های بزرگ دشوار است.

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

هیچگاه یادگیری را ترک نکنید. تا جایی که می‌توانید کتاب بخوانید ولی نه فقط کتاب‌های تکنیکی. کتابِ ذن و فن نگهداری موتورسیکلت از رابرت ام پیرسیگ را هم مطالعه کنید. کتاب پراگماتیک پروگرمرِ اندی هانت و دیو توماس را مطالعه کنید. کتاب‌های دیگری نیز چون Code Complete از استیو مک کونل خواندنی هستند. کتابِ SICP (ساختار و تفسیرِ برنامه‌های کامپیوتری) نوشتۀ هارولد آبلسون ، جرالد جی سوسمان و جولی ساسمان را مطالعه کنید. فقط به خواندن کتاب‌ها اکتفا نکنید. مفاهیمشان را پیاده‌سازی و تمرین هم بکنید.

برای چیزی که وظیفۀ شماست اجازه نگیرید. ریفکتور، تست و مستندسازی کدها وظیفۀ هر برنامه‌نویسی است. برای کاری که وظیفۀ شماست نیازی به اجازه گرفتن نیست.

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

هنگامِ حل مسائل از خودتان بپرسید که می‌خواهید چه چیزی را دقیقاً حل کنید. در واقع این همان سوالِ چرایی است که سیمون سینک در موردش صحبت کرده است.

هر بار فقط روی یک مسئله کار کنید. مسائلی که تاز از راه رسیده‌اند را در صف قرار دهید و بعداً به آن‌ها رسیدگی کنید. با رسیدنِ هر مسئله اولویت‌بندی کارهایتان را به هم نزنید.

بدانید که کجا هستید. این یکی از درس‌های زندگی است که در توسعۀ نرم‌افزار هم کاربرد دارد. وقتی قصدِ انجامِ کاری دارید فقط روی همان کار تمرکز کنید. وقتی ظرف می‌شورید فقط روی شستن ظرف‌ها تمرکز کنید. وقتی با خانواده وقت می‌گذرانید، تلویزیون، گوشی و هر چیز دیگری را خاموش کنید و فقط با خانوادۀ خود مشغول باشید. وقتی در یک جلسه یا مهمانی هستید تمام هوش و حواستان را صرفِ گفتگو و بحث کنید و به کارهایی که دو ساعتِ دیگر یا فردا باید انجام دهید فکر نکنید. کتاب Zen Mind, Beginner’s Mind نوشتۀ شونریو سوزوکی را بخوانید. همانطور که می‌بینید SRP یا اصلِ تک مسئولیتی، کاربردی فراتر از کدنویسی دارد.

بخوانید  افزایش بهره‌وری با 10 ابزار کاربردی اندروید

تا زمانی که دلیلی برای تغییر نیافته‌اید به چیزی دست نزنید.

بهینه‌سازی زودهنگام ریشۀ همۀ مشکلات است.

دونالد کراث

از خودتان بپرسید «ساده‌ترین پیاده‌سازی این برنامه که نیازِ مشتری را برطرف می‌کند چیست؟» این یکی از مهم‌ترین ارزش‌های برنامه‌نویسی به روش XP است. برای آشنایی بیشتر کتابِ Extream Programming کنت بک را که در فارسی «برنامه‌نویسی مفرط» ترجمه شده مطالعه کنید. ویرایشِ اولِ کتاب افراطی‌تر از ویرایش دوم است!

روراست باشید. شما هیچوقت همه چیز را نمی‌دانید. این غیر ممکن است. به یادگیری ادامه دهید و به چیزهایی که نمی‌دانید توجه نکنید. ویدیوی Ease of Work کنت بک را تماشا کنید.

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

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

یک برنامه‌نویسِ متوسط هم باشید قبول است. مقالۀ « Why the myth of the “10x” programmer is so destructive» از Matt Asay را بخوانید.

چند وظیفگی توهم است. انجام چند کار به صورت همزمان (Multi Tasking) از عهدۀ کامپیوتر که می‌تواند با سرعت زیادی بین کانتکست‌های مختلف سوئیچ کند بر می‌آید ولی برای ذهنِ انسان که در این کار به شدت ضعیف است چیزی جزء اتلافِ انرژی و هزینه نیست. در هر لحظه فقط روی یک کار تمرکز کنید. در همین خصوص کتابِ The Mythical Man Month تألیفِ فرد ایبوکز را مطالعه کنید.

۹ زن نمی‌توانند در عرضِ یک ماه یک بچه بسازند!

به جای تغییرِ دیگران خودتان را تغییر دهید. با تغییرِ خودتان دنیای اطرافتان نیز تغییر خواهد کرد.

در شروعِ کار چیزِ زیادی نمی‌دانید. کمی به خودتان وقت بدهید. فهمیدن اینکه چه کتاب‌ها و منابعی بخوانید، چه مسیری در پیش بگیرید نیازمند زمان است. صبور باشید.

مبانی را خوب یاد بگیرید. بیشتر روی مبانیِ برنامه‌نویسی تمرکز کنید. اصولِ اولیۀ مهندسی نرم‌افزار را یاد بگیرید. مهم‌ترین قسمتِ یک ساختمان پیِ آن است. پی‌ریزی را درست انجام دهید. «خشت اول گر نهد معمار کج / تا ثریا می رود دیوار کج».

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

تمرین، تمرین، تمرین! تا می‌توانید کد بنویسید و کدهای دیگران را بررسی کنید. ویدیوهای آموزشی را دنبال کنید. با انجامِ پیوسته و فشرده این کارها از چیزهایی که یاد می‌گیرید شگفت زده خواهید شد. من با زبانِ C شروع کردم. سپس سراغ ++C رفتم و الان مشغول جاوا هستم. کدنویسی را از نت پد شروع کردم. کدها را داخلِ یک صفحۀ خالی بدون سینتکس هایلایت می‌نوشتم و با دستورات CMD کامپایل و خروجی می‌گرفتم. بارها و بارها با خطاهای عجیبی روبرو شدم و زمانِ زیادی صرفِ برطرف کردنشان می‌کردم. ولی با تمرین مداوم توانستم به پیشرفتهای زیادی دست پیدا کنم.

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

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

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

قبل از انجامِ هر کاری برنامه داشته باشید. چک لیستی تهیه کنید و کارهایی مورد نیاز برای رسیدن به هدف را داخلش بنویسید. با انجام هر یک از کارها تیک بزنید و زمانی که همۀ آن‌ها تیک خورد یعنی کار به پایان رسیده است.

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

قبل از حلِ مسئله ابتدا آن را به خوبی بفهمید. بخشِ عمدۀ وقتِ خود را صرفِ فهمیدن مسئله کنید. در واقع، فهمیدن ۹۰% کار است. مسئله‌ای که خوب درک کرده باشید راحت‌تر می‌توانید راهکار برایش ارائه دهید. راحت‌تر می‌توانید راهکار را پیاده‌سازی کنید و حتی اشکالی‌زدایی برنامه هم آسان‌تر می‌شود.

بخوانید  برنامه‌نویسان حرفه‌ای چه می‌کنند

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

تا زمانی که لازم نشده دست به تغییر نزنید. از تغییرات فراری باشید مگر واقعاً ضروری باشد. تغییر یعنی هزینه، یعنی افزایشِ ریسکِ خراب شدن برنامه.

نام‌گذاری درستِ متغیرها و کامنت‌گذاری صحیح را یاد بگیرید. به اعتقادِ مهندسین نرم‌افزار این کار یکی از سخت‌ترین کارها در برنامه‌نویسی است. شاید نوشتنِ یک کامنتِ مناسب چند دقیقه وقت بگیرد. همینطور انتخابِ نامِ مناسب برای یک متد یا حتی پارامترهای آن متد. بخشِ عمدۀ سخت بودن فهمِ کدها زیر سرِ همین نام‌گذاری‌هاست.

تابعی که بیش از ۱۰ خط کد داشته باشد احتمالاً باید به دو تابعِ جدا تقسیم شود.

شما مجاز هستید کدی را کپی پیست کنید؛ ولی فقط یکبار. اگر قطعه کدی در دو جای مختلف وجود داشت یعنی قانون DRY را زیر پا گذاشته‌اید. کمی وقت بگذارید و آن کد را در یک تابعِ جدید Abstract کنید و در قسمت‌های مختلفِ به تابع ارجاع دهید.

بهینه‌سازی برای بهبودِ خوانایی کد از بهینه‌سازی برای افزایشِ پرفرمنسِ برنامه اهمیت بیشتری دارد. به عبارتی اگر قرار باشید بین بهبود خواناییِ کد و بهبود پرفرمنس یکی را فدا کنید باید بهبود پرفرمنس را فدا کنید. خوانایی بسیار مهم‌تر است.

تخمینِ زمان کار سختی است. همیشه دو برابر چیزی که در ذهن دارید تخمین بزنید. برای مدیران پایانِ زودهنگام در یک تخمینِ طولانی شیرین‌تر از پایانِ دیرهنگام در یک تخمین کوتاه‌مدت است.

تسک‌ها را به قسمت‌های کوچکتری بشکنید. هیچوقت ۱۲ ساعت را به تمام کردن یک تسکِ بزرگ اختصاص ندهید.

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

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

از ابزارها هوشمندانه استفاده کنید. قواعد، سینتکس زبان، کیووردها و هر ابزار دیگری برای ساده کردن فرایند توسعه ساخته شده‌اند. اینکه چقدر از این ابزارها بتوانید استفاده کنید به هوشِ و تلاشِ شما وابسته است.

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

هیچوقت به دیگران اعتماد نکنید. کارهایتان را با قرارداد انجام دهید به‌خصوص اگر فریلنسر هستید.

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

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

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

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

چرخ را از اول اختراع نکنید. لااقل در برنامه‌نویسی ۹۵ درصد مشکلاتی که برای شما پیش می‌آید قبلا برای یک نفرِ دیگر پیش آمده و جوابش در سایت‌هایی مثل Stackoverflow منتشر شده است. بنابراین قبل از اینکه خودتان مشغول به کدنویسی شوید جستجویی در اینترنت بکنید. و البته به این نکته هم توجه کنید که هیچوقت کدها را بدون فهمیدنشان کپی پیست نکنید.

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

سید ایوب کوکبی

نویسنده و مترجم...

1 دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *




    ابی

    دوشنبه ۱۱ شهریور ۱۳۹۸

    تشکر از نویسنده.