برچسب: برنامه نویسی

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

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

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

1. 📕 کارهاتون رو داکیومنت کنین. دقیق بنویسین چیکار می کنین و مراحل و قدم های کارهایی که انجام می‌دین چیه. اینطوری خیلی وقت ها لازم نمی شه کار تکراری بکنین چون یکی دیگه اینکار رو می کنه و از اونطرف همه بر اساس داکیومنت های شما پیش می رن و شما رو می شناسن. این دقیقا از چیزهایی است که من در شرکت خیلی رعایت می‌کنم.
2. 🏁 اهداف بلند مدت رو هم داکیومنت کنین. بذارین همه بدونن تو تیم چه خبره، محصول داره به کدوم سمت می ره و چند ماه بعد وضع چی خواهد بود. اینطوری هیچ کس حس نمی کنه شما لازمه روز به روز مواظب محصول و کارها باشین.
3. 🤝 جلسات رو هم داکیومنت کنین. خوبه بنویسین هر بار کی چی گفته. حالا حتی در سطح کلی. اینطوری برای اینکه بدونن تو شرکت چه خبره یا تصمیم نهایی چیه، وابسته به شخص شما نیستن و شما به کارهای باحالترتون می‌رسین.
4. 🚶‍♂️ بقیه رو هم بیارین توی جلسات! اینطوری آدم های دیگه مسوولیت های شما رو یاد میگیرن و می بینن اون پشت چه خبره. هر چقدر هر چیز شفاف تر بشه بهتره. حواستون باشه این دعوت به جلسات باعث اسپم شدن وقت و زندگی مردم نشه!
5. 👩‍🔧 اطرافیان خودتون رو آموزش بدین. هدف اینه که اطرافیان شما کم کم بتونن رشد کنن و کارهای شما رو به شکل مستقل انجام بدن. اینطوری شما می‌تونین برین سراغ کارهای جالبتر بعدی یا حتی استراحت کنین. بخشی از این مطلب،بر می گرده به داشتن داکیومنت های خوب و قابل استفاده.
6. 👩‍🎓 جایگزین خودتون رو هم آموزش بدین. شما لازمه برین سراغ کارهای بهتر پس خوبه که یک نفر کم کم بتونه نقش قدیمی شما رو بازی کنه.
7. 🔑 به بقیه قدرت بدین. اگر قراره بخشی از کار شما به بقیه سپرده باشه، اونها باید آدم های قوی و با اعتماد به نفسی بشاین. اجازه بدین اونها هم تصمیم بگیرن و کارها رو پیش ببرن. همیشه کارهای مهمتر و جالبتری هست که شما به سراغش برین.
8. 📧 شما نباید مرکز ارتباط اصلی باشین. اگر کسی سوالی فنی داره یعنی داکیومنت ها خوب نیستن. اگر کسی شخصی سراغ شما میاد یعنی سیستم پرسش و پاسخ یا لیست پستی شرکت کارا نیست.
9. 👨‍💼 و کارها رو به بقیه بسپرین. حواستون باشه که آدم ها، فکرهای مستقل دارن. قرار نیست اگر کاری رو به کسی سپردین اون صد در صد اون کار رو مثل شما انجام بده. تا وقتی روش اون قابل دفاع منطقی است لازم نیست عین امتداد ذهن شما باشه (: دادن کارها به دیگران باعث رشد و توانمندی بقیه می‌شه.
10. 🏫 و یاد بگیرین! اینهمه وقتی که داره خالی می‌شه بهترین فرصت است برای یاد گرفتن و استفاده از چیزهای جدید. حواستون هست دیگه؟ قراره شما همیشه در حال استعفا باشین و مهمترین چیز برای کسی که داره استعفا می‌ده، یاد گرفتن مهارت های جدید برای مصاحبه های شغلی بعدی است. همیشه در حال یاد گیری باشین تا از بودن در شرکت لذت ببرین.

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

یک جمله هم برای مدیرها: بهترین نیروی شما، نیرویی است که باعث پیشرفت کل تیم می‌شه.

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

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

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

مرتبط

• ضریب اتوبوس

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

getpass.getpass('password:')

صداش بزنین، می‌نویسه passwrod و منتظر می‌مونه ورودی بدین. بعد بدون اینکه رو صفحه چیزی نشون بده، بعد از زدن انتر ورودی رو برمی‌گردونه. نسبتا بی‌مزه ولی کارا. برای بامزه‌تر کردنش، کتابخونه stdiomask رو داریم:

import stdiomask

stdiomask.getpass(prompt = 'Password: ')

که خب می‌پرسه پسورد و به جای چیزهایی که شما وارد می کنین، * می‌ذاره یا می‌تونین با پارامتر mask بهش بگین چی‌بذاره.

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

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

برای شروع می‌تونین سراغ باگ‌های ساده‌تر برین. مثلا توی ایشوها دنبال چیزهایی مثل good for beginners بگردین یا حتی با استفاده از سایت‌هایی مثل Up for Grab (میوه آماده چیدن) ایشوها و باگ‌ها و مشارکت‌های مناسب برای تازه کارها رو پیدا کنین. اگر هم دنبال پروژه‌های حرفه‌ای تر هستین یک ایده خوب اینه که کامیت‌ها رو نگاه کنین و ببینین مشکلات قبلی رو آدم‌های حرفه‌ای تر چطوری حل می کنن. اینطوری هم با پروژه و کدش آشناتر می‌شین و هم شیوه کار بقیه رو می‌بینین و کم کم پترن‌ها براتون آشناتر می‌شه.

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

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

رفتگر دبیان یا همون دبیان جنیتور سیستم اتوماتیکی است برای حل مشکلات ریز در بسته‌هایی که برای مدیر بسته دبیان درست می شن؛ یعنی همون dpkg. این رفتگر به شکل خودکار پیشنهادهای اصلاح رو بررسی می‌کرد و اونهایی که برای نرم افزار هم واضح بودن رو قبول می‌کرد اما حالا یه قدم جلوتر رفته: شخصا مشکلات رو پیدا می‌کنه و بعدش هم اصلاح (:

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

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

#!/usr/bin/python3

from debmutate.control import ControlEditor
from lintian_brush.fixer import report_result, fixed_lintian_tag

with ControlEditor() as updater:
    for para in updater.paragraphs:
        if para.get("Priority") == "extra":
            para["Priority"] = "optional"
            fixed_lintian_tag(
                para, 'priority-extra-is-replaced-by-priority-optional')

report_result("Change priority extra to priority optional.")

این سیستم تا حالا حدود ۶۰هزار اصلاح روی پکیج های دبیان زده که به نوبه خودش اتفاق خیلی بزرگی است که قبلا با دست و در مقیاسی بسیار کمتر و کندتر و پر خطاتر انجام می‌شد. این نمونه‌ای است از اینکه چطوری می شه کدها رو اتوماتیک کرد و کارهای دستی رو به ماشین ها سپرد. نگرانی خاصی هم برای «از دست رفتن شغل برنامه نویسی» نیست چون همیشه با اینجور پیشرفت ها، افق های جدیدی باز می شن که ما هنوز توشون لازمه کار کنیم. در واقع در اینجور موارد همون اتفاقی می‌افته که با اختراع تراکتور افتاد. آدم ها بیکار نشدن بلکه کشاورزی راحتتر شدن و بقیه رفتن سراغ چیزهای دیگه (:

البته بذارین دو نکته رو هم بگم:

۱. این توضیح در مورد همه اختراعات نیست. واقعا شاید برسیم به جایی که ماشین ها کار کنن ما بخوابیم یا صاحب هامون بخوابن و ما تو خرابه ها دنبال غذا بگردیم (:

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