من دارم به یک کد نگاه می کنم. این ممکن است بدترین کدی باشد که تا به حال دیده ام. برای به روز رسانی فقط یک رکورد در پایگاه داده، تمام رکوردهای موجود در مجموعه را بازیابی می کند و سپس درخواست به روز رسانی را برای هر رکورد در پایگاه داده ارسال می کند، حتی آنهایی که نیازی به به روز رسانی ندارند. یک تابع نقشه وجود دارد که به سادگی مقدار ارسال شده به آن را برمی گرداند. تست های شرطی برای متغیرهایی با مقدار ظاهراً یکسان وجود دارد که فقط در سبک های مختلف نام گذاری شده اند (firstName и first_name). برای هر به‌روزرسانی، کد پیامی را به صف متفاوتی ارسال می‌کند که توسط یک عملکرد بدون سرور متفاوت مدیریت می‌شود، اما همه کارها را برای مجموعه‌ای متفاوت در یک پایگاه داده انجام می‌دهد. آیا اشاره کردم که این عملکرد بدون سرور از یک "معماری سرویس گرا" مبتنی بر ابر است که حاوی بیش از 100 عملکرد در محیط است؟
اصلاً چطور ممکن بود این کار را انجام داد؟ صورتم را می پوشانم و به وضوح از خنده ام گریه می کنم. همکارانم می پرسند چه اتفاقی افتاده است و من آن را با رنگ ها بازگو می کنم بدترین بازدیدهای BulkDataImporter.js 2018. همه با ابراز همدردی به من سر تکان می دهند و می پذیرند: چگونه می توانند با ما این کار را انجام دهند؟
منفی بودن: یک ابزار احساسی در فرهنگ برنامه نویس
نگاتیو نقش مهمی در برنامه نویسی دارد. این در فرهنگ ما گنجانده شده است و برای به اشتراک گذاشتن آنچه آموخته ایم استفاده می شود («شما نمی دانید شما آن را باور کنید، آن رمز چگونه بود!»)، برای ابراز همدردی از طریق ناامیدی («خدایا، چرا این کار را انجام می دهم؟»)، برای نشان دادن خود («من هرگز نمی خواهم پس این کار را نکرد»)، برای سرزنش دیگران («ما به دلیل کد او شکست خوردیم، که حفظ آن غیرممکن است»)، یا، همانطور که در «سمی‌ترین» سازمان‌ها مرسوم است، کنترل دیگران از طریق یک احساس شرم ("در مورد چه چیزی فکر می کردی؟" درست است).
منفی بودن برای برنامه نویسان بسیار مهم است زیرا روشی بسیار موثر برای انتقال ارزش است. من یک بار در یک اردوی برنامه نویسی شرکت کردم و روش استاندارد القای فرهنگ صنعت در دانش آموزان این بود که سخاوتمندانه میم ها، داستان ها و ویدیوها را عرضه می کردند که محبوب ترین آنها مورد سوء استفاده قرار گرفت. . خوب است که بتوانید از ابزارهای احساسی برای شناسایی خوب، بد، زشت، این کار را نکنید، هرگز استفاده نکنید. باید افراد تازه وارد را برای این واقعیت آماده کرد که احتمالاً توسط همکارانی که از فناوری اطلاعات دور هستند سوء تفاهم خواهند شد. که دوستانشان شروع به فروش ایده های اپلیکیشن های میلیون دلاری به آنها کنند. این که آنها باید در هزارتوهای بی‌پایان کدهای منسوخ با دسته‌ای از مینوتورها در گوشه و کنار سرگردان باشند.
وقتی برای اولین بار برنامه‌نویسی را یاد می‌گیریم، درک ما از عمق «تجربه برنامه‌نویسی» بر اساس مشاهده واکنش‌های احساسی دیگران است. این را می توان به وضوح از پست های موجود مشاهده کرد ، جایی که تعداد زیادی از برنامه نویسان تازه کار در آن شرکت می کنند. بسیاری از شوخ طبع ها، تا حدی یا دیگری، با سایه های منفی متفاوتی رنگ می شوند: ناامیدی، بدبینی، خشم، اغماض و موارد دیگر. و اگر این به نظر شما کافی نیست، نظرات را بخوانید.
متوجه شدم که هر چه برنامه نویسان تجربه کسب می کنند، منفی تر می شوند. مبتدیان، غافل از مشکلاتی که در انتظارشان است، با اشتیاق و تمایل به این باور که علت این مشکلات صرفاً کمبود تجربه و دانش است، شروع می کنند. و در نهایت با واقعیت امور مواجه خواهند شد.
زمان می گذرد، آنها تجربه کسب می کنند و می توانند کد خوب را از بد تشخیص دهند. و هنگامی که آن لحظه فرا می رسد، برنامه نویسان جوان از کار با کد بدیهی بد احساس ناامیدی می کنند. و اگر آنها در یک تیم (از راه دور یا حضوری) کار می کنند، اغلب عادات عاطفی همکاران با تجربه تر را اتخاذ می کنند. این اغلب منجر به افزایش منفی می شود، زیرا جوانان اکنون می توانند با تفکر در مورد کد صحبت کنند و آن را به بد و خوب تقسیم کنند و از این طریق نشان دهند که آنها "دانستند". این موارد منفی را بیشتر تقویت می کند: از سر ناامیدی، به راحتی می توان با همکاران کنار آمد و عضوی از یک گروه شد؛ انتقاد از کد بد موقعیت و حرفه ای بودن شما را در نظر دیگران افزایش می دهد: .
افزایش منفی گرایی لزوما چیز بدی نیست. بحث برنامه نویسی، در میان چیزهای دیگر، به شدت بر کیفیت کد نوشته شده متمرکز است. آنچه که کد است به طور کامل عملکردی را که قرار است انجام دهد مشخص می کند (سخت افزار، شبکه و غیره به کنار)، بنابراین مهم است که بتوانید نظر خود را در مورد آن کد بیان کنید. تقریباً همه بحث‌ها به این موضوع می‌پردازد که آیا کد به اندازه کافی خوب است یا خیر، و به محکوم کردن مظاهر کد بد با عباراتی که مفهوم عاطفی آن کیفیت کد را مشخص می‌کند، خلاصه می‌شود:
- "تضادهای منطقی زیادی در این ماژول وجود دارد، کاندیدای خوبی برای بهینه سازی عملکرد قابل توجه است."
- "این ماژول بسیار بد است، ما باید آن را بازسازی کنیم."
- "این ماژول منطقی نیست، باید بازنویسی شود."
- "این ماژول بد است، باید وصله شود."
- «این یک تکه قوچ است، نه یک ماژول، اصلاً نیازی به نوشتن آن نبود، نویسنده آن چه فکر می‌کرد.»
به هر حال، این «انتشار احساسی» است که باعث می‌شود توسعه‌دهندگان این کد را «سکسی» بنامند، که به ندرت منصفانه است - مگر اینکه در PornHub کار کنید.
مشکل این است که مردم موجوداتی عجیب، بی قرار و عاطفی هستند و درک و ابراز هر احساسی ما را تغییر می دهد: در ابتدا به طور نامحسوس، اما در طول زمان، به طور چشمگیری.
یک شیب لغزنده مشکل دار منفی گرایی
چند سال پیش، من یک سرپرست تیم غیررسمی بودم و با یک توسعه دهنده مصاحبه کردم. ما واقعاً او را دوست داشتیم: او باهوش بود، سؤالات خوبی می‌پرسید، با فناوری آشنا بود و به خوبی با فرهنگ ما سازگار بود. من به ویژه تحت تأثیر مثبت بودن او و اینکه چقدر مبتکرانه به نظر می رسید تحت تأثیر قرار گرفتم. و من او را استخدام کردم.
در آن زمان من چند سالی بود که در شرکت کار می کردم و احساس می کردم فرهنگ ما چندان موثر نیست. قبل از رسیدن من دو بار، سه بار و چند بار دیگر سعی کردیم این محصول را عرضه کنیم، که منجر به هزینه های زیادی برای دوباره کاری شد، که در طی آن ما چیزی برای نشان دادن نداشتیم به جز شب های طولانی، ضرب الاجل های فشرده و محصولاتی که کار می کردند. و با وجود اینکه هنوز سخت کار می کردم، در مورد آخرین مهلتی که مدیریت برای ما تعیین کرده بود، شک داشتم. و او به طور معمول هنگام بحث در مورد برخی از جنبه های کد با همکارانم قسم می خورد.
بنابراین تعجب آور نبود - اگرچه من متعجب شدم - که چند هفته بعد، همان توسعه دهنده جدید همان چیزهای منفی من را گفت (از جمله فحش دادن). متوجه شدم که او در شرکتی متفاوت با فرهنگ متفاوت رفتار خواهد کرد. او فقط با فرهنگی که من ایجاد کردم سازگار شد. احساس گناه بر من غلبه کرد. به دلیل تجربه ذهنی ام، بدبینی را به یک تازه وارد القا کردم که او را کاملاً متفاوت می دانستم. حتی اگر او واقعاً اینطور نبود و فقط ظاهری به پا می کرد تا نشان دهد که می تواند با او سازگاری داشته باشد، من رفتار کثیف خود را به او تحمیل کردم. و هر آنچه گفته می شود، حتّی به شوخی یا گذرا، شیوه بدی را دارد که به آنچه باور می شود تبدیل می شود.
راه های منفی
بیایید به برنامه نویسان تازه کار سابق خود برگردیم که کمی خرد و تجربه به دست آورده اند: آنها با صنعت برنامه نویسی بیشتر آشنا شده اند و درک می کنند که کد بد همه جا وجود دارد و نمی توان از آن اجتناب کرد. حتی در پیشرفته‌ترین شرکت‌هایی که روی کیفیت تمرکز دارند نیز رخ می‌دهد (و اجازه دهید توجه کنم: ظاهراً مدرنیته از کد بد محافظت نمی‌کند).
فیلمنامه خوب با گذشت زمان، توسعه دهندگان شروع به پذیرش این نکته می کنند که کد بد یک واقعیت نرم افزار است و وظیفه آنها بهبود آن است. و اینکه اگر نمی توان از کد بد جلوگیری کرد، هیچ فایده ای برای ایجاد سر و صدا در مورد آن وجود ندارد. آنها مسیر ذن را در پیش می گیرند و بر حل مشکلات یا کارهایی که با آنها روبرو می شوند تمرکز می کنند. آنها یاد می گیرند که چگونه کیفیت نرم افزار را به طور دقیق اندازه گیری کنند و به صاحبان مشاغل ارتباط دهند، تخمین های مستدلی را بر اساس سال ها تجربه خود بنویسند و در نهایت پاداش های سخاوتمندانه ای را برای ارزش باورنکردنی و مداوم خود برای کسب و کار دریافت کنند. آنها کار خود را به قدری خوب انجام می دهند که 10 میلیون دلار پاداش دریافت می کنند و بازنشسته می شوند تا تا آخر عمر کاری را که می خواهند انجام دهند (لطفاً آن را بدیهی نگیرید).
سناریوی دیگر مسیر تاریکی است. به جای پذیرش کد بد به عنوان یک امر اجتناب‌ناپذیر، توسعه‌دهندگان این وظیفه را بر عهده می‌گیرند که همه چیز بد را در دنیای برنامه‌نویسی فراخوانی کنند تا بتوانند بر آن غلبه کنند. آنها به دلایل خوب بسیاری از بهبود کد بد موجود خودداری می کنند: «مردم باید بیشتر بدانند و اینقدر احمق نباشند». "این ناخوشایند است"؛ "این برای تجارت بد است"؛ "این ثابت می کند که من چقدر باهوش هستم"؛ "اگر من به شما نگویم این چه رمز زشتی است، کل شرکت به اقیانوس می افتد" و غیره.
مطمئناً نمی توانند تغییرات مورد نظر خود را اعمال کنند زیرا متأسفانه کسب و کار باید به توسعه خود ادامه دهد و نمی تواند وقت خود را صرف نگرانی در مورد کیفیت کد کند، این افراد به عنوان شاکی شهرت پیدا می کنند. آنها به دلیل شایستگی بالای خود حفظ می شوند، اما به حاشیه های شرکت رانده می شوند، جایی که افراد زیادی را آزار نمی دهند، اما همچنان از عملکرد سیستم های حیاتی پشتیبانی می کنند. بدون دسترسی به فرصت‌های توسعه جدید، مهارت‌های خود را از دست می‌دهند و دیگر نیازهای صنعت را برآورده نمی‌کنند. منفی‌گرایی آنها به تلخی تبدیل می‌شود و در نتیجه با مشاجره با دانش‌آموزان بیست‌ساله درباره سفری که فناوری قدیمی مورد علاقه‌شان طی کرده و چرا هنوز آنقدر داغ است، روحیه خود را تغذیه می‌کنند. آنها در نهایت بازنشسته می شوند و دوران پیری خود را با فحش دادن به پرندگان زندگی می کنند.
واقعیت احتمالاً جایی در بین این دو افراط نهفته است.
برخی از شرکت‌ها در ایجاد فرهنگ‌های بسیار منفی، جزیره‌ای و با اراده بسیار موفق بوده‌اند (مانند مایکروسافت قبل از آن). ) - اغلب اینها شرکت هایی با محصولاتی هستند که کاملاً متناسب با بازار هستند و نیاز به رشد هرچه سریعتر دارند. یا شرکت هایی با سلسله مراتب فرماندهی و کنترل (اپل در بهترین سال های جابز)، که در آن هر کس آنچه را که به او گفته می شود انجام می دهد. با این حال، تحقیقات تجاری مدرن (و عقل سلیم) نشان می‌دهد که حداکثر نبوغ، که منجر به نوآوری در شرکت‌ها و بهره‌وری بالا در افراد می‌شود، نیازمند سطوح پایین استرس برای حمایت از تفکر خلاق و روشمند مداوم است. و انجام کار خلاقانه و مبتنی بر بحث بسیار دشوار است اگر دائماً نگران این باشید که همکارانتان در مورد هر خط کدتان چه خواهند گفت.
منفی بودن، مهندسی فرهنگ پاپ است
امروزه بیش از هر زمان دیگری به نگرش مهندسان توجه می شود. در سازمان های مهندسی، قانون". حکایت ها و داستان های بیشتری در توییتر در مورد افرادی که این حرفه را ترک کرده اند به این دلیل ظاهر می شود که نمی توانند (نمی توانند) به تحمل خصومت و بدخواهی نسبت به بیگانگان ادامه دهند. حتی لینوس توروالدز سالها خصومت و انتقاد نسبت به سایر توسعه دهندگان لینوکس - این منجر به بحث در مورد اثربخشی این رویکرد شده است.
برخی هنوز از حق لینوس برای انتقاد بسیار دفاع می کنند - کسانی که باید در مورد مزایا و معایب "منفی سمی" اطلاعات زیادی داشته باشند. بله، متمدن بودن بسیار مهم است (حتی اساسی)، اما اگر دلایلی را خلاصه کنیم که چرا بسیاری از ما اجازه می دهیم بیان نظرات منفی به «سمی» تبدیل شود، این دلایل پدرانه یا نوجوانانه به نظر می رسند: «آنها سزاوار آن هستند زیرا احمق هستند. "، "او باید مطمئن باشد که دیگر این کار را انجام نخواهند داد"، "اگر آنها این کار را انجام نمی دادند، او مجبور نبود سر آنها فریاد بزند" و غیره. نمونه ای از تأثیر واکنش های احساسی یک رهبر بر یک جامعه برنامه نویسی، مخفف انجمن روبی MINASWAN است - "Matz خوب است پس ما خوب هستیم."
من متوجه شده ام که بسیاری از طرفداران سرسخت رویکرد "یک احمق را بکش" اغلب به کیفیت و صحت کد اهمیت زیادی می دهند و خود را با کارشان شناسایی می کنند. متأسفانه، آنها اغلب سختی را با صلبیت اشتباه می گیرند. مضرات این موقعیت ناشی از میل ساده، اما غیرمولد انسانی برای احساس برتری نسبت به دیگران است. افرادی که در این میل غوطه ور می شوند در مسیر تاریکی گیر می کنند.
دنیای برنامه نویسی به سرعت در حال رشد است و به مرزهای ظرف خود فشار می آورد - دنیای غیربرنامه نویسی (یا دنیای برنامه نویسی ظرفی برای دنیای غیربرنامه نویسی است؟ سوال خوبی است).
همانطور که صنعت ما با سرعت فزاینده ای گسترش می یابد و برنامه نویسی در دسترس تر می شود، فاصله بین "تکنیک ها" و "عادی ها" به سرعت در حال بسته شدن است. دنیای برنامه نویسی به طور فزاینده ای در معرض تعاملات بین فردی افرادی قرار می گیرد که در فرهنگ انزواطلبی رونق فناوری اولیه بزرگ شده اند و این آنها هستند که دنیای جدید برنامه نویسی را شکل خواهند داد. و صرف نظر از هر گونه بحث اجتماعی یا نسلی، کارایی به نام سرمایه داری در فرهنگ شرکت و شیوه های استخدام نمایان می شود: بهترین شرکت ها به سادگی کسی را که نمی تواند به طور بی طرفانه با دیگران تعامل داشته باشد، استخدام نمی کند، چه رسد به اینکه روابط خوبی داشته باشد.
آنچه در مورد منفی گرایی یاد گرفتم
اگر اجازه دهید منفی گرایی بیش از حد ذهن و تعامل با مردم را کنترل کند و به سمیت تبدیل شود، برای تیم های محصول خطرناک و برای تجارت گران است. من پروژه‌های بی‌شماری را دیده‌ام (و شنیده‌ام) که از هم پاشیدند و با هزینه‌های هنگفت به طور کامل بازسازی شدند، زیرا یک توسعه‌دهنده مورد اعتماد نسبت به این فناوری کینه‌ای داشت، توسعه‌دهنده دیگری یا حتی یک فایل منفرد انتخاب شده بود تا کیفیت کل پایگاه کد را نشان دهد.
منفی نگری روابط را تضعیف و از بین می برد. هرگز فراموش نمی کنم که چگونه یکی از همکاران من را به خاطر قرار دادن CSS در فایل اشتباه سرزنش کرد، این مرا ناراحت کرد و چندین روز به من اجازه نداد افکارم را جمع آوری کنم. و در آینده، بعید است به چنین فردی اجازه دهم نزدیک یکی از تیم های من باشد (اما چه کسی می داند، مردم تغییر می کنند).
در نهایت، منفی .
من فکر می کنم این چیزی است که یک استاد کلاس در مورد لبخند باید شبیه باشد.
البته، این دلیلی به نفع شادی، قرار دادن ده میلیارد شکلک در هر درخواست کشش یا رفتن به یک کلاس کارشناسی ارشد در مورد لبخند نیست (نه، خوب، اگر این همان چیزی است که می خواهید، پس شکی نیست). منفی بودن بخش بسیار مهمی از برنامه نویسی (و زندگی انسان) است، کیفیت سیگنال دهی، به فرد اجازه می دهد تا احساسات خود را ابراز کند و با همنوعان همدردی کند. منفی نگری بیانگر بصیرت و احتیاط، عمق مشکل است. من اغلب متوجه می شوم که وقتی یک توسعه دهنده شروع به ابراز ناباوری نسبت به آنچه قبلاً ترسو و مطمئن نبوده است به سطح جدیدی رسیده است. مردم با نظرات خود منطقی بودن و اعتماد به نفس خود را نشان می دهند. شما نمی توانید بیان منفی گرایی را رد کنید، این می تواند اورولی باشد.
با این حال، منفی گرایی باید با دیگر ویژگی های مهم انسانی: همدلی، صبر، درک و شوخ طبعی، متعادل شود. شما همیشه می توانید به یک نفر بگویید که او بدون داد و بیداد یا فحش دادن اشتباه کرده است. این رویکرد را دست کم نگیرید: اگر کسی بدون هیچ احساسی به شما بگوید که به طور جدی به هم ریخته اید، واقعاً ترسناک است.
آن زمان، چندین سال پیش، مدیرعامل با من صحبت کرد. در مورد وضعیت فعلی پروژه صحبت کردیم، سپس او از احساس من پرسید. من پاسخ دادم که همه چیز خوب است، پروژه رو به جلو است، ما به آرامی کار می کنیم، شاید چیزی را از دست دادم و نیاز به تجدید نظر داشتم. او گفت که از من شنیده است که افکار بدبینانه تری را با همکاران در دفتر به اشتراک می گذارم و دیگران نیز متوجه این موضوع شده اند. او توضیح داد که اگر شک دارم، می‌توانم آنها را به طور کامل به مدیریت بیان کنم، اما «آنها را پایین نیاورم». به عنوان یک مهندس ارشد، باید حواسم باشد که کلماتم چگونه بر دیگران تأثیر می‌گذارند، زیرا حتی اگر متوجه نباشم، تأثیر زیادی دارم. و او همه اینها را با مهربانی به من گفت و در نهایت گفت که اگر واقعاً چنین احساسی دارم، احتمالاً باید به این فکر کنم که برای خودم و شغلم چه می خواهم. این یک مکالمه فوق‌العاده ملایم بود. من از او به خاطر اطلاعاتی که در مورد اینکه چگونه نگرش تغییر یافته من در طول شش ماه بر دیگران تأثیر می گذارد تشکر کردم.
این نمونه ای از مدیریت قابل توجه و مؤثر و قدرت رویکرد نرم بود. متوجه شدم که به نظر می رسید فقط به شرکت و توانایی آن برای رسیدن به اهدافش ایمان کامل دارم، اما در واقعیت به روشی کاملاً متفاوت با دیگران صحبت کردم و ارتباط برقرار کردم. همچنین متوجه شدم که حتی اگر نسبت به پروژه‌ای که روی آن کار می‌کنم احساس تردید می‌کنم، نباید احساساتم را به همکارانم نشان دهم و بدبینی را مانند یک بیماری سرایت کنم و شانس موفقیت ما را کاهش دهم. در عوض، می‌توانستم وضعیت واقعی را به شدت به مدیریتم منتقل کنم. و اگر احساس می کردم که به حرف من گوش نمی دهند، می توانستم با ترک شرکت مخالفت خود را بیان کنم.
زمانی که سمت رئیس ارزیابی پرسنل را بر عهده گرفتم، فرصت جدیدی به دست آوردم. به عنوان یک مهندس ارشد سابق، من در بیان نظرات خود در مورد کد میراث (در حال بهبود) بسیار مراقب هستم. برای تایید یک تغییر، باید وضعیت فعلی را تصور کنید، اما اگر در ناله، حمله یا مواردی از این دست غوطه ور شوید، به جایی نخواهید رسید. در نهایت، من اینجا هستم تا یک کار را کامل کنم و نباید از کد شکایت کنم تا آن را بفهمم، ارزیابی کنم یا آن را برطرف کنم.
در واقع، هرچه بیشتر واکنش عاطفی خود را نسبت به کد کنترل کنم، بیشتر متوجه می شوم که چه چیزی می تواند باشد و سردرگمی کمتری احساس می کنم. وقتی خودم را با خویشتنداری بیان کردم («اینجا باید جای پیشرفت بیشتری وجود داشته باشد»)، داشتم خودم و دیگران را خوشحال می‌کردم و اوضاع را خیلی جدی نمی‌گرفتم. متوجه شدم که می‌توانم با منطقی بودن (به‌طور آزاردهنده؟) منفی را در دیگران تحریک کنم و کاهش دهم ("راست می‌گویید، این کد بسیار بد است، اما ما آن را بهبود خواهیم داد"). خوشحالم که می بینم چقدر می توانم در مسیر ذن پیش بروم.
اساساً من دائماً در حال یادگیری و یادگیری یک درس مهم هستم: زندگی کوتاه تر از آن است که دائماً عصبانی و دردناک باشم.
منبع: www.habr.com