یلدا ادامه داره... ❤️ ۴۰ درصد تخفیف همه دوره‌ها

استفاده از تخفیف‌ها
ثانیه
دقیقه
ساعت
روز
زبان برنامه نویسان را رمزگشایی کنید!!
ﺯﻣﺎﻥ ﻣﻄﺎﻟﻌﻪ: 8 دقیقه

زبان برنامه نویسان را رمزگشایی کنید!!

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

 زیاد به نظر می‌رسد، نه؟

حقیقت سخت برنامه نویس بودن

من سال‌هاست که یک برنامه نویس و تیم‌لیدر هستم. افراد غالباً فکر می‌کنند برنامه‌نویسی فقط نوشتن یک تکه کد است؛ چیزهایی که می‌توانند به راحتی در محل کار زشت و پیچیده شوند وقتی :

شما یک تیم بزرگ برای مدیریت دارید.

 شما چندین پروژه برای رسیدگی دارید.

 شما مشتریانی دارید که نمی‌دانند چه می‌خواهند.

 شما یک جدول زمانی احمقانه و …  دارید.

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

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

مطمئن هستم که بعضی از این موارد را در محیط کار خود شنیده‌اید یا احتمالاً خودتان بعضی از این موارد را گفته‌اید.

۱. پیشرفت پروژه چقدر بوده ؟۹۰ درصدش انجام شده

ما به عنوان برنامه نویس در برآورد زمان پروژه بسیار بد هستیم؛ و اغلب تلاش می‌کنیم تا الزامات مشتری، دستورالعمل‌های مدیریتی که هر روز تغییر می‌کنند، کمبود منابع برای انجام پروژه، جدول زمانی کوتاه برای تحویل و ...  را درک کنیم.

“آنچه یک برنامه نویس می‌تواند در یک ماه انجام دهد، دو برنامه نویس می‌توانند در دو ماه انجام دهند.“ - فرد بروکس

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

واقعیت: احتمالاً حتی شروع هم نشده.

۲. این مانع کار من نیست، بعدا درستش می‌کنم

اگر شما یک تستر یا ‌QA هستید، احتمالاً این موضوع را اغلب اوقات شنیده‌اید. برنامه نویسان معتقدند که هیچ نرم‌افزار کاملی در این دنیا وجود ندارد، تا زمانی که هنوز کار کند.

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

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

۳. هِی، من باگ‌ها را فیکس کرده‌ام، اکنون باید کار کند (در واقع این طور نیست)

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

واقعیت: این کار نمی‌کند، یا چیزی را درست می‌کند، یا چیز دیگری را خراب می‌کند.

۴.عجیب است! این در سیستم من کار می‌کند.

این یک عبارت بسیار رایج است که هر بار آن را شنیده‌ام. معمولاً هنگامی بیان می‌شود که بعد از توسعه، چیزی خراب شده یا اینکه برنامه نویسان هیچ ایده‌ای برای اینکه چرا این کار نمی‌کند ندارند. همچنین می‌تواند به خاطر بعضی دستورات یا سینتکس باشد؛ که با برخی از سیستم‌عامل‌ها مثل ویندوز یا لینوکس سازگار نیست.

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

۵.من این را نمی‌دانم!

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

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

واقعیت: ما درباره آن می‌دانیم، اما نمی‌خواهیم این کار را انجام دهیم؛ خدای من! چگونه می‌توانم این را فراموش کرده باشم؟?

۶.دیروز کار می‌کرد، چه کسی به کد من دست زده؟

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

واقعیت: شخصی کدهای جدیدی در پروژه اعمال کرده و پروژه را خراب کرده؛ یا فراموش کردید که دیروز تغییراتی ایجاد کرده اید.

۷.من این را توسعه ندادم!

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

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

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

واقعیت: یادم نمی‌آید که این را نوشتم، یا چگونه می‌توانم این اشتباه را مرتکب شوم!

۸.این فقط یک راهحل موقت است، از آن در تولید استفاده نمی‌شود.

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

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

واقعیت: راهحل موقت تبدیل به یک راهحل دائمی می‌شود؛ بعداً خواهید فهمید که ایا می‌خواهید تغییرات دیگری ایجاد کنید یا نه.

۹.داکیومنت‌ها به زودی خواهند آمد.

ما برنامه نویسان انتظار داریم دیگران مستندات را به خوبی بنویسند، اما از نوشتن همان چیزی که دوست داریم متنفریم! در واقع مستندات مانند غذا هستند، هنگامی که ما بسیار گرسنه‌ایم، اگر خوب باشد، بسیار خوب است، و اگر بد باشد، بهتر از هیچی است.

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

در مکان هایی که من کار کردم؛ اکثرا مستندات فنی منسوخ شده بودند، یا با سیستم مطابقت نداشتند. مستندات خوب به زمان و تلاش نیاز دارد. بهتر است یک نویسنده فنی را استخدام کنید و به برنامه نویسان اجازه دهید کارشان را انجام دهند.

واقعیت: تحویل مستندات عمر آدم را می‌گیرد.

کلام آخر

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

منبع

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

خیلی بد
بد
متوسط
خوب
عالی
در انتظار ثبت رای

/@Fatemeh.shirzadfar
فاطمه شیرزادفر
برنامه نویس

تجربه کلمه‌ای هست که همه برای توصیف اشتباهاتشون ازش استفاده میکنن، و من همیشه دنبال اشتباهات جدیدم! برنامه‌نویس هستم و لینوکس‌ دوست

دیدگاه و پرسش

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

در حال دریافت نظرات از سرور، لطفا منتظر بمانید

در حال دریافت نظرات از سرور، لطفا منتظر بمانید