یکی از احمقانه ترین مشاغل، مدیرانی هستند که برنامه نویسان را مدیریت می کنند. نه همه، بلکه آنهایی که خود برنامه نویس نبودند. کسانی که فکر می‌کنند با استفاده از روش‌های کتاب می‌توان کارایی را «افزایش» کرد (یا افزایش «کارایی»؟). حتی بدون زحمت خواندن همین کتاب ها، ویدیو یک فیلم کولی است.
کسانی که هرگز کد ننوشته اند. کسانی که فیلم های هالیوودی درباره برنامه نویسان برای آنها ساخته می شود - خوب، آنهایی که با استفاده از خط فرمان ایمیل تماشا می کنند. کسانی که به غیر از شاخص ها، سررسیدها و دستمزد خودشان علاقه ای ندارند.
کسانی که اکثریت هستند.
اما آنها به دلیل دیگری احمق هستند. آنها کارایی یا حداقل اثربخشی را می خواهند (بیا مدیر، گوگل چه تفاوتی دارد) بدون اینکه یکی یا دیگری را بفهمند. بدون درک کلی از ماهیت، فرآیند به دست آوردن نتیجه، زیان هایی که در این فرآیند رخ می دهد، هزینه های توسعه. به طور خلاصه، کار با یک برنامه نویس به گونه ای است که انگار یک جعبه سیاه است.
آنها دقیقاً به یک دلیل وارد مدیریت برنامه نویسان شدند: هیاهو، پول، بازار و یکسری از همان احمق ها وجود دارد. جایی برای گم شدن وجود دارد.
اگر در تولید مونتاژ مکانیکی تبلیغاتی وجود داشت، ما آنجا اجرا می کردیم. استیشن واگن ها مکش می کنند. من تعجب نمی کنم که مردی که در ماه دسامبر در محله ما درخت کریسمس می فروشد، یک مدیر فناوری اطلاعات در تعطیلات است.
خلاصه اگر ممکن است به گردن این بچه ها شلیک کنید. نگران نباش کار پیدا می کنند. هیچ یک از آنها تا زمانی که خودشان یک برنامه نویس نشوند هرگز کار شایسته ای انجام نمی دهند. زیرا او ماهیت، مکانیسم، منطق فرآیندی که کنترل می کند را درک نمی کند.
خوب، در مورد مدیران کافی است. حالا سر اصل مطلب، برای برنامه نویسان. چگونه با یادگیری نوشتن کد با کیفیت بالا راندمان توسعه را افزایش دهیم.
برای افزایش کارایی، باید مشکلات را سریعتر بدون از دست دادن کیفیت حل کنید. برای حل سریعتر مشکلات، باید بتوانید بلافاصله کد با کیفیت بالا بنویسید. و "با کیفیت بالا" و "نوشتن" و "فورا". بگذارید با یک استعاره توضیح دهم.
نوشتن کد با کیفیت بالا مانند صحبت کردن به یک زبان خارجی است. وقتی زبانی را نمی دانید، زمان زیادی را صرف تلاش می کنید تا افکار خود را در آن فرموله کنید.
اگر نیاز دارید فوراً چیزی بگویید، فقط روی برخی از کلمات می چسبید، اغلب آنهایی که درست نیستند، مقالات، ترتیب صحیح کلمات را فراموش می کنید، نه به ذکر زمان فعل و تلفظ ضعیف.
اگر برای فرمول‌بندی پاسخ وقت دارید، باید یک فرهنگ لغت یا یک مترجم آنلاین باز کنید و زمان زیادی را صرف فرمول‌بندی افکار خود کنید. با این حال، این احساس همچنان ناخوشایند خواهد بود: شما پاسخ را می‌گویید و نمی‌دانید که درست است یا نه. در مورد کد هم همینطور است - به نظر می رسد نوشته شده است، به نظر می رسد کار می کند، اما اینکه آیا با کیفیت خوب است یا نه یک راز است.
معلوم می شود اتلاف وقت مضاعف است. رسیدن به پاسخ زمان می برد. همچنین تدوین این پاسخ به زمان نیاز دارد - و نه چندان کم.
اگر مهارت نوشتن کد با کیفیت بالا وجود داشته باشد، می توان پاسخ را بلافاصله به محض اینکه در ذهن بلوغ کرد، بدون صرف وقت اضافی برای ترجمه، فرموله کرد.
مهارت نوشتن کد با کیفیت بالا به هنگام طراحی معماری کمک می کند. شما به سادگی گزینه های نادرست، غیرقابل تحقق یا دستپاچه را در ذهن خود در نظر نخواهید گرفت.
به طور خلاصه: مهارت نوشتن کد با کیفیت بالا به طور قابل توجهی سرعت حل مسئله را افزایش می دهد.
اما این همه ماجرا نیست. با تشکر از مدیران چکمه های نمدی، یک نکته وجود دارد - ما دلیلی برای نوشتن کد با کیفیت بالا نداریم. مدیر به کد نگاه نمی کند، مشتری به کد نگاه نمی کند. ما به ندرت کد را به یکدیگر نشان می‌دهیم، فقط گاهی اوقات، در برخی از پروژه‌ها که در آن یک کد تعیین شده "بررسی" یا بازسازی دوره ای وجود دارد.
به نظر می رسد که در بیشتر موارد کدهای نامطلوب به تولید یا مشتری می رود. شخصی که کدهای شیطون نوشته است، یک اتصال عصبی پایدار ایجاد می کند - نوشتن کدهای نامطلوب نه تنها ممکن است، بلکه ضروری است - پذیرفته شده است، و حتی برای آن هزینه می پردازند.
در نتیجه، مهارت نوشتن کدهای باکیفیت اصلاً شانسی برای توسعه ندارد. کد نوشته شده توسط یک کارمند مشروط هرگز توسط کسی بررسی نمی شود. تنها دلیلی که او برنامه‌نویسی عادی را یاد می‌گیرد، انگیزه درونی است.
اما این انگیزه درونی با برنامه ها و الزامات کارایی و بهره وری در تعارض است. این تناقض به وضوح به نفع کدهای با کیفیت بالا حل نمی شود، زیرا مردم حتی از مردم به دلیل کدهای بد انتقاد نمی کنند. و برای شکست در تحقق برنامه - حتی در این صورت.
باید چکار کنم؟ من دو مسیر را می بینم و پیشنهاد می کنم که می توان آنها را با هم ترکیب کرد.
اولین مورد این است که کد خود را به شخصی در داخل شرکت نشان دهید. نه به صورت واکنشی (هنگامی که از شما خواسته می شود/اجباری)، بلکه فعالانه (اوه، رفیق، لطفاً به کد من نگاه کنید). نکته اصلی در اینجا این است که نگذارید پوزخندی ارسال کنید، سعی نکنید انتقاد از کد را به شکلی مودبانه بیان کنید. اگر کد مزخرف است، می گوییم: کد مزخرف است. البته با توضیحات و توصیه هایی برای بهتر شدن.
اما این مسیر هم چنین است. کاربرد آن بستگی به نقطه ای دارد که در آن تماس رخ داده است. اگر کار قبلاً وارد مرحله تولید شده باشد و معلوم شود که کد مزخرف است، انجام مجدد آن فایده ای ندارد. به طور دقیق تر، دلایل - معیارها نیز کاهش می یابد. مدیران عجله خواهند کرد و شما را با الزامات کارآیی زیر پا می گذارند. و حتی سعی نکنید به آنها توضیح دهید که کدهای مزخرف قطعاً به شکل باگ برمی گردند - برای شما نتیجه معکوس خواهد داشت. فقط می توانید متعهد شوید که دیگر این کار را نکنید.
اگر کار هنوز تحویل داده نشده است، یا تازه شروع شده است، پس ریختن چیزهایی روی کد (یا پروژه، ایده آن) می تواند معنای کاملاً عملی داشته باشد - شخص این کار را به طور معمول انجام می دهد.
راه دوم، جالبترین راه، انجام توسعه متن باز در ساعات غیر کاری است. هدف چیست: برای دسته ای از برنامه نویسان، یعنی برنامه نویسان، کد شما را ببینند و در مورد آن صحبت کنند. همه افراد داخل شرکت وقت ندارند. اما برنامه نویسان در سرتاسر دنیا هنوز کاری برای انجام دادن ندارند و اگر از نظر کاربردی چیز مفیدی بنویسید، قطعا به داخل آن نگاه خواهند کرد.
ترفند اصلی به نظر من کدنویسی در ساعات غیر کاری است چون تضاد کیفیت کد و سرعت تحویل نتیجه کارساز نخواهد بود. توسعه خود را برای حداقل یک سال بنویسید. نه ضرب الاجل، نه مشخصات فنی، نه پول و نه رئیس به شما فشار نمی آورد. آزادی کامل و خلاقیت.
فقط در خلاقیت آزاد می توانید درک کنید و احساس کنید کد عالی چیست، زیبایی زبان و فناوری را مشاهده خواهید کرد و جذابیت وظایف تجاری را احساس خواهید کرد. خوب، شما یاد خواهید گرفت که کدهای با کیفیت بالا بنویسید.
درست است، این نیاز به صرف وقت شخصی دارد. درست مثل هر پیشرفت دیگری. به آن نه به عنوان هزینه، بلکه به عنوان یک سرمایه گذاری - در خودتان نگاه کنید.
منبع: www.habr.com