یکی از مهمترین جنبه‌های حرفه‌ای بودن، مسئولیت‌پذیر بودنه.
اگه هزینه‌هایی که از محل کار میشه از جیب خودت باشه چطور حساسیت نشون میدی را کارها و هزینه‌هایی که دارن؟ باید پول کارفرما هم واست همینطور مهم باشه.
اجتناب‌ناپذیر بودن باگ‌ها معنیش این نیست که ما به‌عنوان دولوپر، مسئولیتی در قبالشون نداریم?! هرچقدر که حرفه‌ای‌تر بشی، باید کدی که مینویسی هم باگ‌های کم و کمتری داشته باشه.
? باید به این موضوع هم دقت کرد که هر باگی چرا اتفاق افتاده و چیکار میشه کرد که دیگه اتفاق نیفته.
یکی از جنبه‌های مسئولیت پذیری تست کردنه.
باید هدف این باشه که کدی که به بخش کنترل کیفیت (QA یا بخش مشابه) می‌رسه، هیچ باگی توش نباشه. خلاف این کار باعث میشه.
هزینه‌ی اضافی تحمیل بشه به شرکت (چون حتی باگ‌های نسبتا واضحی رو که دولوپر می‌تونه پیدا کنه و دیباگ کنه هم میرن تو QA و اونجا پیدا می‌شن و کد برگشت می‌خوره به تیم توسعه و بعد دیباگ و دوباره ارسال به QA و الی آخر و این رفت و برگشت هزینه داره)
باعث میشه برنامه‌ریزی‌ها بهم بریزه
خدشه وارد شه به اعتمادی که شرکت به تیم توسعه داره
test it [your code] seven ways to Sunday! میفرماید که: کُدت رو تا جای ممکن (تا خرتلاق) تست کن. (درستش همین خرتلاقِ، نه خرتناق?)
تست کردن دستی زمان زیادی می‌بَره. درسته. بخاطر همینه که باید بریم سراغ اتوماتیک کردن تست‌هامون.
هر خط از کد باید تست داشته باشه. والسلام.
این غیر واقع بینانه نیست؟ معلومه که نه. ما این کدها رو داریم می‌نویسیم که کار کنن (دعا واسه آمینه). تنها راهی که میشه مطمئن بود از این موضوع اینه که تست بشه!
تست نوشتن واسه بعضی از کدها سخت نیست؟ چرا.
دلیلشم اینه که کد جوری نوشته شده که تست نوشتن واسش سخته! راه حلش چیه حالا؟
اینه که کدت رو جوری بنویسی که تست نوشتن واسش ساده باشه!
? بهترین راهشم اینه که اول تست بنویسی
ساختار (structure) کد خیلی مهمه
نباید ساختار فدای عملکرد (functionality) بشه.
Boy Scout rule: always check in a module cleaner than when you checked it out. قانون پسر پیشاهنگ: همیشه وقتی با یه کدی کار میکنی، سعی کن کدی که تحویل میدی تمیزتر از کدی باشه که تحویل گرفتی
? قانون پسر پیشاهنگ نشون میده که ما باید مدام کد رو تغییر بدیم و بهتر کنیم. حالا خطرناک نیست این کار؟ مدام کدی که کار میکنه رو تغییر بدیم؟ چرا خطرناکه. ولی اگه واسش تست نوشته باشی، بعد از هر تغییر میتونی تست‌ها رو اجرا کنی و مطمئن شی که آب از آب تکون نخورده!
مسئول پیشرفت شغلی تو فقط خودت هستی، نه کارفرما یا شرکتی که واسش کار میکنی
تو هفته باید ۴۰ ساعت واسه شرکت کار کنی و ۲۰ ساعت رو یادگیری و مهارت‌های خودت
⚙️ این ۲۰ ساعت که میشه حدودا ۳ ساعت در روز می‌تونه شامل پادکست گوش دادن، خوندن، یادگرفتن یه زبان برنامه‌نویسی جدید و غیره باشه. تو این مدت نباید رو پروژه‌ی کارفرما کار کنی مگه اینکه مرتبط باشه با چیزی که داری یاد می‌گیری که در این صورت اوکیه.
میشه این کار رو هم انجام نداد. مشکلی نداره. فقط دیگه نباید خودت رو «حرفه‌ای» بدونی.
شاید فک کنی این ۲۰ ساعت باعث میشه که زده شی از کار. ولی برعکسه! این کار باعث میشه اون اتفاق نیفته! ? چرا؟ چون توی این ۲۰ ساعت باید کارایی رو انجام بدی که بهت حال میدن. از جنس اون چیزایی که باعث شدن اون روز اول علاقه پیدا کنی به برنامه‌نویسی! خلاصه باید بهت (عمدتا) خوش بگذره تو این ۲۰ ساعت.
تو مهندسی نرم‌افزارها ایده‌ها، تکنیک‌ها، ابزارها و ترمینولوژی (عبارات و کلمات) گسترده‌ای وجود داره. اگه میخوای حرفه‌ای باشی، باید یه بخش قابل توجهی از این‌ها رو بلد باشی و حجم چیزهایی که بلدی هم باید مدام در حال افزایش باشه.
? که چی حالا؟ واقعیت اینه که اِنقد این چیزا زیادن و سرعت زیاد شدنشون هم زیاده که هرچیزی من الان یاد بگیرم بعد از یه مدت قدیمی و بلا استفاده میشه.
بله. سرعت رشد این حوزه خیلی خیلی زیاده. ولی از طرفی ما همون if و elsهای ۵۰ سال پیش رو داریم می‌نویسیم.
موضوعات خیلی کمی از ۵۰ سال پیش تا الان کلا بلا استفاده شدن. مثلا موضوعی مثل توسعه‌ی آبشاری تاریخ مصرفش تموم شده ولی معنیش این نیست که ما نیاز نیست بدونیم چی هست. باید خودش و نقاط قوت و ضعفش رو بدونیم (تا بتونیم مزایای سیستم‌های چابک رو مثلا بهتر درک کنیم)
⚙️ حداقل چیزهایی که هر دولوپر حرفه‌ای باید بدونه اینان:
الگوهای طراحی:
۲۴ تا الگوی طراحی کتاب Gang of Four
همینطور الگوهای معرفی شده تو کتاب‌های Pattern-Oriented Software Architecture
اصول طراحی:
اصول SOLID
اصول component
روش‌ها:
Waterfall
XP
Scrum
Lean
Kanban
Structured Design
Structured Analysis
اصول کاری (دسیپلین‌ها):
TDD
طراحی شی گرا
Structured Programming
Continuous Integration
Pair programming
Artifact ها: باید بدونی چطور از موارد پایین استفاده کنی:
UML
DFDها
Structure Charts
Petri Nets
State Transition Diagrams and tables
Flow charts
Decision tables
دولوپری که نتونه تکنیک‌ها و اصول کاری (دسیپلین‌های) جدید رو یاد بگیری، هم‌رده‌هاش به سرعت رشد میکنن و اون پس‌رفت میکنه.
چیزهایی رو یاد بگیر که از حاشیه‌ی امن(comfort zone)ت خارج هستن.
دولوپرهای حرفه‌ای مدام رو مهارتشون کار میکنن و همیشه آماده‌ی کد زدن هستن. کاری که هر روز تو شرکت انجام میدی «اجرا» است، «تمرین» نیست.
یه نوازنده رو درنظر بگیر. اگه تمرینش سر اجراهاش باشه چی میشه؟؟ هدف تمرین اصلاح و بهبود سطح مهارته و اینکه هماهنگی ذهن و انگشت‌ها باهم بالاتر بره.
حوزه‌ای که توش کار میکنی رو بشناس (مثلا سیستم بانکی یا اتوماسیون اداری).باید اطلاعاتت در حدی باشه که بتونی خطاهایی که توی جزئیاتی که بهت ارائه میشه رو بشناسی و بتونی آگاهانه تحلیلش کنی و اونو به چالش بکشی.
مشکل کارفرمای تو، مشکل توئه! باید درک کنی مشکل چیه و به سمت راه حلش حرکت کنی. سعی نکن یه خطی بین خودت و کارفرما (و کلا برنامه‌نویس‌ها و کارفرماها) بکشی.
یه آدم حرفه‌ای، کارش رو میشناسه، احساس افتخار میکنه از کاری که میکنه، به توانایی‌هاش اعتماد داره و ریسک‌های بزرگ و حساب‌شده میکنه که مبتنی بر اون اعتماد هستن. البته این رو هم می‌دونه که ممکنه بعضی وقتا شکست بخوره.
