یکی از مَثَل‌های رایج در فرهنگمان این است که «تجربه را تجربه کردن خطا است» و شاید به نوعی بتوان گفت که این مَثِل در حوزهٔ توسعهٔ نرم‌افزار هم شاید بتواند مفید واقع گردد که در همین راستا در ادامه قصد داریم تا تجارب ۳۰ سالهٔ یک برنامه‌نویس را در اختیار شما قرار دهیم که حاوی اطلاعات مفیدی برای دولوپرها، خصوصاً برای تازه‌کارها، است.

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

پیش از پرداختن به این تجربیات، بد نیست یک آشنایی نسبی با نویسندهٔ اصلی این مقاله، Andrew Wulf، داشته باشیم. وی دولوپر ارشد iOS است که در حال حاضر در کمپانی Walt Disney مشغول به کار است که تجربهٔ کار با زبان‌های جاوا، جاوااسکریپت و سی‌پلاس‌پلاس را نیز دارا است و وبلاگی دارد به آدرس The Codist که در آن تجربیات خود را با فالوورهایش به اشتراک می‌گذارد. حال بپردازیم به بررسی این تجربیات که برخی از مهم‌ترین آن‌ها عبارتند از:

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

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

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

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

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

تنها چیزی که هرگز تغییر نمی‌کند خودِ «تغییر» است
برنامه‌ریزی برای آینده بر این اساس که فردا هم مثل امروز است کاری است بس بیهوده بلکه باید توجه داشته باشید که در دنیا، و به‌ ویژه دنیای برنامه‌نویسی، هیچ چیز همیشگی نیست و اگر برخلاف این مسئله فکر می‌کنید، باید بدانید که تصور مخربی دارید.

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

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

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

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

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

برای ترشی انداختن، صدها راه مختلف وجود دارد
برای مشتری‌ها اهمیتی ندارد که شما برای نوشتن یک برنامه با چه مشکلاتی مواجه می‌شوید بلکه آنچه برایشان مهم است اینکه نرم‌افزار شما کارهای مورد نظرشان را انجام دهد (همان‌طور که وقتی برای مهمان‌تان سر سفره ترشی سرو می‌کنید، او کاری ندارد که ترشی را به چه روشی درست کرده‌اید بلکه چیزی که برایش مهم است، مزهٔ ترشی است.)

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

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

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

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

دو مورد آخری که برایتان شرح می‌دهیم، شاید نَه اخلاقی باشند و نَه حرفه‌ای اما به‌ هر حال مد نظر قرار دادن مواردی از این دست هم توسط دولوپرهای تازه‌کار خالی از لطف نیست!

همیشه دنبال مشتریان پول‌دار بگردید
از دید برخی دولوپرها یا شرکت‌های نرم‌افزاری، پیدا کردن مشتریان ثروتمندی که با تکنولوژی آشنایی ندارند نهایت شانس است (مشتریان باهوش زیاد سؤال می‌پرسند و افرادی هم با توان مالی ضعیف از پس هزینه‌ها برنمی‌آیند!)

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

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

نگاهی به تجربیات دولوپری که ۳۰ سال کد زده است!