من هشت سال پیش مسیر برنامه‌نویسی خود را به عنوان یک فرد مشتاقِ خودآموز شروع کردم و حال به برنامه‌نویسی تبدیل شدم که بعضی اوقات برای استارتاپ‌هایی با بودجه‌ی کم کار می‌کند. بعد از اینکه چندین سال مشغول کار در چنین مشاغل کوچکی بودم، بالاخره در یک شرکت بزرگ استخدام شدم. همان جایی که حرفه من رشد بسزایی کرد و توانستم نسبت به مهارت‌های توسعه‌ی نرم افزار خود اعتماد به نفس کسب کنم. من در کنار آن مشغول گذراندن دوره کارشناسی ارشد خود در زمینه مهندسی نرم‌افزار بودم. مربیان به من کمک کردند تا در زمینه‌های مختلف توسعه نرم‌افزار تخصص و توانایی حل مسائل پیچیده را کسب کنم.
حالا من 25 ساله هستم. مشغول کار در اولین شغل خود هستم و به عنوان متخصصی توانا در حل بسیاری از مشکلات توسعه نرم‌افزار شناخته شده‌ام. همکاران و دوستانم به من احترام می‌گذارند. با این حال اوضاع همیشه اینطور نبوده است و لحظاتی وجود داشت که در حرفه خود سختی‌های بسیاری را تجربه کردم. همان دورانی که یک فرد خودآموز بودم و هیچ مسیری را برای خودم انتخاب نکرده بودم.
در این مقاله با شما اشتباهاتی در زمینه توسعه نرم‌افزار را به اشتراک می‌گذارم که قبل از رسیدن به اولین شغل واقعی خود آن‌ها را تجربه کرده‌ام.
نگرش «فقط کاری کن عملی بشه» را داشتم
من روی کیفیت فنی محصولات خود تمرکز نمی‌کردم. برای من فقط کارآیی داشتن آن‌ها برای مشتریان و کاربران نهایی مهم بود. من استایل کد خاص خودم را داشتم و به نوعی حس می‌کردم که موثر است. فکر می‌کردم که به غیر از خودم کسی کدهایم را نمی‌خواند یا ویرایش نمی‌کند. اما خیلی اشتباه می‌کردم.
یک روز یکی از پروژه‌های من از یک سفارش ساده به یک فروشگاه کوچک الکترونیکی تبدیل شد. قصد داشتیم همکار استخدام کنیم. همه کدها را می‌خوانند اما کسی آن‌ها را قبول نمی‌کرد. ناگهان فهمیدم که مشکل از مشتری من نیست. کدهای من مانع توسعه‌ی تجارت مشتری شده بود زیرا به کیفیت کد و استانداردهای کدنویسی پایبند نبودم. من در کدنویسی بیشتر به کمیت توجه داشتم.
امروزه خوانایی کدهایم را در بالاترین اولویت‌های خود قرار داده‌ام. حالا سعی می‌کنم کدهای خود را به ساده‌ترین حالت ممکن بنویسم و از نظرات دیگران کمک بگیرم.
آموزش‌های زیادی را مشاهده کردم اما هرگز مفاهیم عمیق‌تر را مطالعه نکردم
من آموزش‌های عملی زیادی را می‌دیدم. آموزش‌هایی که در آن شخصی مشغول ساخت برنامه‌ی وبی مشابه برنامه‌ی وب من بود. این کار به من کمک کرد تا دانش بسیار اندکی در رابطه با برنامه‌نویسی کسب کنم. وقتی سعی کردم یک مشکل دشوارتر را حل کنم، اعتماد به نفس کاذبی داشتم و تصور می‌کردم که آن آموزش‌ها برای حل این مشکلات کافی هستند. اگر امروز به این موضوع نگاه کنیم، پس از تماشای تمام آن آموزش‌ها من فقط سازه‌های پایه‌ای زبان برنامه‌نویسی خود را درک کرده‌ام. سپس از این سازه‌های پایه برای مقابله با مشکلات پیچیده استفاده کردم که به نوبه‌ی خود به کیفیت کد آسیب رساند. این آسیب تا حدی بالا بود که هیچکس نمی‌خواست آن کدها را ویرایش کند.
بعد از اینکه اولین درس مرتبط با برنامه‌نویسی خود را در دانشگاه تمام کردم، بالاخره فهمیدم که چگونه می‌توانم یک زبان برنامه‌نویسی را یاد بگیرم. من فقط در مورد کدنویسی صحبت نمی‌کنم، منظورم ترکیب آن با درک کامل مفاهیم اساسی زبان برنامه‌نویسی مثل کلاس‌ها، رابط‌ها، کلوژرها و غیره است. بنابراین درک درستی از اساسی‌ترین بخش‌های برنامه‌نویسی کسب کنید. به کسب اطلاعاتی در مورد زبان برنامه‌نویسی، API مربوط به آن و الگوی برنامه‌نویسی خود بپردازید. این کار به شما کمک می‌کند تا بتوانید طرح راه‌حل‌های خود را استدلال کنید.
هیچ اطلاعی از اکوسیستم نداشتم
من در گذشته برای خلق راه‌حل‌های بزرگ خود از یک کتابخانه ساده (مانند jQuery) استفاده می‌کردم. فکر می‌کردم که یادگرفتن و استفاده از چند کتابخانه پایه‌ای به من کمک می‌کند تا تمام مشکلات خود را در توسعه‌ی وب حل کنیم. من به راه‌حل‌های جایگزینی که شاید بهتر و موثرتر بودند علاقه نداشتم. فقط می‌خواستم نرم‌افزار را سرهم کنم و به سراغ پروژه بعدی بروم. بعداً متوجه شدم که یک مسئله‌ی ساده را با استفاده از یک راه‌حل پیچیده و غیرضروری حل کردم؛ تنها به خاطر استفاده از کتابخانه‌ای که برای حل مشکلات متفاوتی طراحی شده بود.
طبق تجربه‌های من هیچ فریمورک، زبان یا کتابخانه‌ای نمی‌تواند تنها راه‌حل کارآمد برای حل همه‌ی مشکلات شما باشد. امروزه وقتی با یک مسئله جدید روبرو می‌شوم، به دنبال راه‌حل‌های پایدار و خوبی می‌گردم که بتواند با کمترین تلاش ممکن آن مشکل را حل کند. قبل از اینکه خیلی وارد جزئیات آن راه‌حل‌ها شوم، جوانب مثبت و منفی آن راه‌حل‌ها را در نظر می‌گیرم و آن‌ها را با موارد مشابه مقایسه می‌کنم.
از آنالیزورهای کد استاتیک استفاده نکردم
تا مدت‌ها روی کدنویسی با بهترین روش‌ها تمرکز نمی‌کردم. کدهای زیادی نوشتم که به آن‌ها علاقه‌ای نداشتم. با خودم فکر می‌کردم که این کدها برای ارائه داده شدن در مصاحبه مناسب نیستند. بنابراین همیشه از ارسال کردن کدهای خود به مصاحبه‌کنندگان امتناع می‌کردم. این موضوع به نوبه‌ی خودش باعث از دست رفتن فرصت‌های جالب شد که می‌توانستم داشته باشم. بعد از اینکه اولین شغل تمام وقت خود را ترک کردم، این دو ابزار را برای جریان کار توسعه‌ی نرم افزار خود بسیار مهم می‌دانم:
- ابزارهای بررسی استایل کد: شاید موشکافانه به نظر برسند اما قوانین آن‌ها بر اساس بهترین روش‌هاست و در غلبه بر کدها و طراحی به شما کمک می‌کند.
- ابزارهای آنالیز استاتیک در سطح پروژه: این ابزارها به شناسایی مشکلات امنیتی و موارد غیرعمدی که در دیتابیس‌های بزرگ‌تر پخش شده کمک می‌کنند.
هرگز مستندات فریمورک خود را نخواندم
من خودم را یک توسعه دهنده π شکل خطاب می‌کنم. بخش‌های اصلی دانش عمیق من در دو فریمورک برای ساخت برنامه‌های وب بزرگ است؛ یک فریمورک برای ساخت بخش فرانت‌اند و دیگری برای ساخت بک‌اند. تخصص‌های دیگر من تنها اطلاعاتی است که در صورت نیاز آماده‌ی استفاده از آن‌ها هستم. اگر بخواهم مهارت‌های خود را به عنوان یک تازه‌کار خودآموخته بیان کنم، می‌گویم که آن زمان یک توسعه دهنده مبتدی بودم. اطلاعات اندکی داشتم و با همان میزان اطلاعات تمرین می‌کردم و با کمک شانس و StackOverflow توانستم محصول نرم افزاری خود را خلق کنم.
یک روز با غرور و بدون داشتن تجربه کافی سعی کردم در یک مصاحبه مخصوص برنامه‌نویسان ارشد شرکت کنم. منحنی Dunning-Kruger که در شکل پایین نشان داده شده، به چنین موقعیتی "قله‌ی کوهِ حماقت" می‌گوید. معمولاً مصاحبه‌کنندگان برای چنین مشاغلی، فریمورکِ متقاضیان را بررسی می‌کنند. همچنین از آن‌ها در مورد جزئیات ریز و سایر بخش‌های تاریک فریمورک مورد نظر نیز سوالاتی را می‌پرسند.
من می‌توانستم به طور کارآمد راه‌حل‌هایی را برای بسیاری از مشکلات خود ایجاد کنم، اما بلافاصله بعد از شنیدن اولین سوال احساس نگرانی کردم. به نظرم جواب دادن به آن سوال سخت بود و محض اطلاع باید بگویم که در آن مصاحبه موفق عمل نکردم. منحنی Dunning-Kruger به چنین وضعیتی "دره ناامیدی" می‌گوید. پس از اینکه چنین اتفاقی را تجربه کردم، فهمیدم که یکی از کلیدهای موفقیت در مصاحبه‌های برنامه‌نویسان ارشد، خواندن مستندات مربوط به زبان، فریمورک و کتابخانه‌ی من است.
وقتی مستندات هر دو فریمورک خود را مطالعه کردم، بلاخره بعد از چندین سال در مصاحبه‌ها اعتماد به نفس کسب کردم. همه‌ی این‌ها به من کمک کرد تا بتوانم بهتر در مورد دستمزد خود صحبت کنم و به نوبه خود احترام اطرافیان خود را جلب کنم.
با تست یونیت مخالف بودم
من به کد خود اعتماد کردم. کدهای خود را به طور موقت با نوشتن فراخوان کد، ورود به سیستم، بررسی دستی و نادیده گرفتن سایر روش‌های ارزشمند تست کد آزمایش کردم. سپس خطایی در همان کد ظاهر شد و من دوباره همان تست کد را نوشتم. این واقعاً اتلاف وقت بود.
بعد از سال‌ها کسب مهارت در برنامه‌نویسی و تست نویسی، این موارد جزو مزایای اصلی نوشتن تست یونیت به وسیله‌ی فریمورک تست یونیت هستند:
- به من اعتماد به نفس زیادی در مورد کدی که تست می‌شود می‌دهد چون پس از هر بار تغییر قابل تکرار است.
- به من کمک می‌کند تا به طراحی بد API غلبه کنم.
- وجود مشکل در تست کدها تقریباً همیشه نشانه‌ی یک طراحی بد شیءگراست.
- نوعی مستند است که همیشه با کدها همگام می‌باشد.
امروزه در صورت امکان توسعه‌ی تست محور را به پروژه‌های خودم معرفی می‌کنم. با این کار پس از معرفی قابلیت‌های جدید به محصولاتم، اطلاعاتی را در مورد عملکردهای ناقص و خراب بدست می‌آورم.
کدهای بسیاری را کپی کردم
من هنوز هم بعضی از پروژه‌های ترسناکی که نگهداری آن‌ها دشوار است را نگه می‌دارم. این پروژه‌ها اکثراً به خاطر اشتباهات گذشته من به این روز افتاده‌اند و جدا از کمبود یک برنامه‌ی موثر برای توسعه، عمدتاً به کپی کردن مربوط می‌شوند. این موضوع فقط در مورد کپی پیست کردن نیست، بلکه آن کدها فاقد انتزاع نیز می‌باشند. شاید این موضوع از آنجا سرچشمه می‌گیرد که اولین زبان‌های برنامه‌نویسی من HTML و CSS بوده است.
هر وقت مشتری می‌خواست نگهداری و تعمیر یکی از پروژه‌هایم را به شخص دیگری محول کند، آن‌ها پروژه‌هایم را رد می‌کردند و مرا یک توسعه‌دهنده‌ی بد خطاب می‌کردند. آن‌ها عقیده داشتند که کارهای من از نظر فنی افتضاح است. یکی از همکارانم الهام بخش من شد تا به دنبال طراحی راه‌حل‌هایی با قابلیت استفاده مجدد، انتزاعی و دیتا محور باشم. همیشه هنگام طرح راه‌حل‌های خود به یک قدم جلوتر فکر می‌کنم. به این توجه می‌کنم که کدهای من در آینده به چه روشی ممکن است مورد استفاده یا استفاده‌ی مجدد قرار گیرد.
IDE خود را نمی‌دانستم
من سفر توسعه‌ی نرم افزار خود را با استفاده از یک دفترچه یادداشت ساده شروع کردم. مربیان دانشگاه مرا از استفاده از IDE به شدت منصرف کردند. بلاخره بعد از اینکه IDE را گرفتم، از آن مثل دفترچه یادداشت استفاده کردم. من با استفاده از shell هنگام اجرای کامپایلرها، سرورها، کلاینت‌ها و تست‌ها، کدهایی را در آن نوشتم. من به تدریج انجام دادن آن کارها را به IDE خود محول کردم. به نظر من دستی انجام دادن کارها و استفاده‌ی آهسته از قابلیت‌های IDE یکی دیگر از موارد مضر برای بهره وری من بود.
قطعاً به شما توصیه می‌کنم که با گشتن در ویژگی‌های IDE خود، استفاده‌ی کارآمد از آن را یاد بگیرید. ویژگی‌هایی را یاد بگیرید که به کمک آن‌ها بتوانید بیشترین کارهای روزانه خود را به حالت اتوماتیک در بیاورید. به عنوان مثال:
- ابزارهای ریفکتورینگ سریع: بهترین تقویت‌کننده‌ی امروزی برای بهره وری که توسط IDE ارائه داده می‌شوند
- اجرای وظیفه: مواردی مثل کامپایلرها، اشکال زداها، تست‌های یونیت، مشاهده محتوای دیتابیس‌ها و غیره را اجرا می‌کند.
- ابرقدرت‌های ویرایش کد: حذف خط، مولتی کورسر و غیره.
- میانبرهای صفحه کلید برای بیشترین اقدامات انجام شده شما.
از کد خارجی استفاده‌ی مجدد نکردم
در گذشته خیلی از کدهایی که می‌نوشتم، تجاری نبودند و به همین خاطر پولی بابت آن‌ها دریافت نمی‌کردم. آن‌ها بیشتر فنی بودند و شامل کد خام دیتابیس، اجزای پایه‌ای Angular، پیاده‌سازی سفارشی و غیره می‌شدند. من از خواندن مستندات کتابخانه‌های خارجی خوشم نمی‌آمد. از گشتن در کتابخانه‌ها برای حل مشکلات خود اجتناب می‌کردم و ترجیح می‌دادم که به کدنویسی خود ادامه دهم.
قطعاً نوشتن کدهای پایه از ابتدا، درک کاملی از اصول اساسی را به شما خواهد داد. اما مهارت داشتن در استفاده‌ی مجدد از کد خارجی و مطالعه‌ی کارآمد اسناد فنی، یک تقویت کننده‌ی بهره وری بسیار با ارزش به حساب می‌آید.
ریفکتورینگ را به منظور کاهش هزینه‌های توسعه نادیده گرفتم
بارها در ابتدای حرفه‌ی توسعه‌دهندگی خود راه‌حل‌های ساده‌ای را خلق کردم که رشد قابل توجهی را بعد از انتشار پیدا کرد. مشتریان من اغلب به دنبال طراحی مجدد، اضافه کردن ویژگی‌های جدید و غیره بودند. برای اینکه مشتریان خود را با کاهش هزینه‌ی توسعه خوشحال کنم، به کدهای قدیمی در نسخه‌های قبلی محصولات خود هیچ توجهی نمی‌کردم. حتی هنوز از آن دوره یک پروژه نگهداری کرده‌ام و واقعاً از این موضوع متنفر هستم. اینگونه پروژه‌ها پر از اشکالات فنی هستند و اساساً به درد نمی‌خورند. من تنها کسی هستم که این پروژه را درک می‌کند.
امروزه از ریفکتورینگ دائمی به عنوان یک روش استاندارد در روند توسعه‌ی نرم افزار خود استقبال می‌کنم. در صورت لزوم، هزینه‌های ساخت مجدد را به هزینه‌ی توسعه‌ی کل یک ویژگی اضافه می‌کنم. پس از اینکه آن هزینه‌های اضافی را به مشتریان خود توضیح دادم، تقریباً همیشه من را درک می‌کنند.
نتیجه‌گیری
در این مقاله 10 اشتباهی را به اشتراک گذاشتم که به عنوان یک تازه‌کار خودآموخته مرتکب شده بودم. اگر می‌خواهید به یک توسعه‌دهنده‌ی خودآموز تبدیل شوید، این موارد را در ذهن خود به یاد داشته باشید و از آن‌ها اجتناب کنید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید