Я смотрю на кусок кода. Возможно, это худший код, что мне когда-либо встречался. Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже тех, которые обновлять не требуется. Тут есть map-функция, которая просто возвращает переданное ей значение. Есть условные проверки переменных с очевидно одинаковым значением, просто поименованных в разных стилях (
firstName и first_name). Для каждого UPDATE’а код отправляет сообщение в другую очередь, которая обрабатывается другой serverless-функцией, но которая выполняет всю работу для другой коллекции в той же базе данных. Я не упомянул, что эта serverless-функция из облачной «сервис-ориентированной архитектуры», содержащей более 100 функций в окружении?Как вообще можно было такое сделать? Я закрываю лицо и явственно всхлипываю сквозь смех. Мои коллеги спрашивают, что случилось, и я в красках пересказываю Worst Hits Of BulkDataImporter.js 2018. Все сочувственно кивают мне и соглашаются: как они могли так с нами поступить?
Негатив: эмоциональный инструмент в программисткой культуре
Негатив играет в программировании важную роль. Он встроен в нашу культуру и используется для того, чтобы поделиться узнанным («ты не поверишь, на что был похож этот код!»), для выражения сочувствия через расстройство («господи, ЗАЧЕМ так делать?»), чтобы показать себя в выгодном свете («я бы никогда так не сделал»), чтобы взвалить вину на другого («мы зафейлились из-за его кода, который невозможно сопровождать»), или, как принято в самых «токсичных» организациях, чтобы управлять другими через чувство стыда («ты о чём вообще думал? исправляй»).
Негатив столь важен для программистов потому, что это очень эффективный способ передачи ценности. Когда-то я учился в лагере для программистов, и стандартной практикой прививки студентам цеховой культуры было щедрое снабжение мемами, историями и видео, самые популярные из которых эксплуатировали огорчение программистов, когда они сталкивались с непониманием людей. Хорошо, когда можно использовать эмоциональные инструменты для обозначения методик Хороших, Плохих, Ужасных, Никогда Так Не Делайте, Вообще Никогда. Нужно подготовить новичков к тому, что их наверняка будут понимать ошибочно коллеги, далёкие от IT. Что их друзья начнут втюхивать им идеи приложений «на миллион». Что им придётся блуждать в бесконечных лабиринтах устаревшего кода с кучей минотавров за углом.
Когда мы начинаем впервые учиться программированию, наше представление о глубине «опыта программирования» основывается на наблюдениях за эмоциональными реакциями других людей. Это хорошо видно по постам в сабе ProgrammerHumor, в котором тусуется много новичков-программистов. Многие юмористические посты в той или иной степени окрашены разными оттенками негатива: разочарование, пессимизма, негодования, снисходительности и прочих. А если вам этого покажется мало, почитайте комментарии.
Я заметил, что, по мере накопления опыта, у программистов становится всё больше негатива. Новички, не подозревающие об ожидающих их трудностях, начинают с энтузиазмом и готовностью поверить, что причина этих трудностей просто в недостатке опыта и знаний; и в конце концов они столкнутся с реальным положением вещей.
Проходит время, они набираются опыта и обретают возможность отличить Хороший код от Плохого. И когда этот момент наступает, молодые программисты испытывают огорчение от работы с очевидно плохим кодом. А если они работают в коллективе (дистанционно или очно), то часто перенимают эмоциональные привычки более опытных коллег. Нередко это приводит к увеличению негатива, ведь молодые теперь могут глубокомысленно говорить о коде и разделять его на плохой и хороший, показывая тем самым, что они «в теме». Это ещё больше усиливает негатив: на почве разочарования легко сойтись с коллегами и стать частью группы, критика Плохого кода повышает ваш статус и профессионализм в глазах других: люди, которые выражают негативное мнение, часто воспринимаются как более умные и компетентные.
Усиление негатива не обязательно плохое явление. Обсуждение программирования, помимо прочего, крайне сосредоточено на качестве написанного кода. То, чем является код, полностью определяет функцию, для которой он предназначен (отбросим оборудование, сеть и т. д.), так что важно иметь возможность выразить своё мнение об этом коде. Почти все дискуссии сводятся к тому, достаточно ли хорош этот код, и к осуждению самих манифестов плохого кода в выражениях, эмоциональная окраска которых характеризует качество кода:
- «В этом модуле много логических несоответствий, это хороший кандидат на значительную оптимизацию производительности».
- «Этот модуль довольно плохой, нам нужно его рефакторить».
- «Этот модуль не имеет смысла, его нужно переписать».
- «Этот модуль отстой, его нужно патчить».
- «Это кусок овна, а не модуль, его вообще не нужно было писать, о чём, блин, думал его автор».
Кстати, именно эта «эмоциональная разрядка» заставляет разработчиков называть код «секси», что редко бывает справедливым — если только вы не работаете в PornHub.
Проблема заключается в том, что люди — странные, неспокойные, наполненные эмоциями создания, и восприятие и выражение любых эмоций меняет нас: сначала едва заметно, но со временем — кардинально.
Неспокойная скользкая дорожка негатива
Несколько лет назад я был неформальным тимлидом и собеседовал одного разработчика. Он нам очень нравился: был умён, задавал хорошие вопросы, был технически подкован и прекрасно вписывался в нашу культуру. Мне особенно импонировала его позитивность и то, каким предприимчивым он казался. И я его нанял.
На тот момент я работал в компании пару лет и ощущал, что принятая у нас культура не слишком эффективна. Мы пытались запустить продукт дважды, трижды и ещё пару раз до моего прихода, что приводило к большим расходам на переделки, в течение которых нам нечего было показать кроме долгих ночей, сжатых сроков и типа-работающих продуктов. И хотя я ещё усердно работал, однако скептически высказывался в отношении последнего дедлайна, назначенного нам руководством. И небрежно выругался при обсуждении с моими коллегами некоторых аспектов кода.
Так что не было ничего удивительного в том — хотя я удивился, — что несколько недель спустя тот самый новый разработчик высказался в том же негативном ключе, что и я (включая ругательство). Я понял, что он повёл бы себя иначе в другой компании с другой культурой. Он лишь подстроился под ту культуру, которую создал я. Меня накрыло чувство вины. Из-за своего субъективного опыта я привил пессимизм новичку, которого я воспринимал совсем другим. Даже если он на самом деле не был таким и лишь старался казаться, чтобы показать, что может влиться в коллектив, я навязал ему своё дерьмовое отношение. А всё сказанное, пусть даже в шутку или мимоходом, имеет дурную манеру превращаться то, во что верят.
Пути негатива
Вернёмся к нашим бывшим новичкам-программистам, которые немножко набрались мудрости и опыта: они поближе познакомились с индустрией программирования и понимают, что плохой код везде, его нельзя избежать. Он встречается даже в наиболее продвинутых компаниях, сосредоточенных на качестве (и позвольте заметить: судя по всему, современность вовсе не спасает от плохого кода).
Хороший сценарий. Со временем разработчики начинают смиряться с тем, что плохой код — реальность программного обеспечения, и что их работа заключается в том, чтобы его улучшить. И что если нельзя избежать плохого кода, то и нет смысла поднимать из-за него шум. Они встают на путь дзена, сосредотачиваются на решении проблем или задач, которые встают перед ними. Узнают, как можно точно измерить и подать качество ПО владельцам бизнеса, на основе своего многолетнего опыта пишут прекрасно обоснованные сметы, и в конечном итоге получают щедрые вознаграждения за свою невероятную и неизменную ценность для бизнеса. Они так хорошо делают свою работу, что им платят премиальные бонусы в $10 млн., и они выходят на пенсию, чтобы до конца жизни заниматься тем, чем хочется (пожалуйста, не принимайте на веру).
Другой сценарий — это путь тьмы. Вместо того, чтобы принять плохой код как неизбежность, разработчики берут на себя обязанность возвещать обо всём плохом в мире программирования, чтобы они могли победить это. Они отказываются улучшать существующий плохой код по множеству благих причин: «люди должны больше знать и не быть такими тупыми»; «это неприятно»; «это плохо для бизнеса»; «это доказывает, насколько я умён»; «если я не расскажу, какой это паршивый код, вся компания низвергнется в океан», и так далее.
Наверняка не имея возможности реализовать желаемые ими изменения, поскольку бизнес, к сожалению, должен продолжать разрабатывать и не может тратить время на заботу о качестве кода, такие люди обретают репутацию жалобщиков. Их держат за высокую компетентность, однако вытесняют на задворки компании, где они не будут многим досаждать, но при этом будут поддерживать работу критически важных систем. Лишившись доступа к новым возможностям в разработке, они теряют навыки и перестают соответствовать требованиям индустрии. Их негатив превращается в ожесточённую горечь, и в результате они тешат своё эго, споря с двадцатилетними студентами о пути, пройденном их любимой старой технологией и почему она ещё бодрячком. В конце концов они выходят на пенсию и проживают старость, ругаясь на птиц.
Вероятно, реальность находится где-то посередине между этими двумя крайностями.
Некоторые компании чрезвычайно преуспели в создании крайне негативных, обособленных, волевых культур (вроде Microsoft до её потерянного десятилетия) — зачастую это компании с продуктами, прекрасно соответствующими рынку, и необходимостью расти как можно быстро; или компании с иерархией управления и контроля (Apple в лучшие годы Джобса), где каждый делает то, что прикажут. Однако современные бизнес-исследования (да и здравый смысл) говорят о том, что для максимальной изобретательности, приводящей к инновационности компании, и высокой продуктивности отдельных людей необходим низкий уровень стресса, чтобы поддерживать непрерывное творческое и методичное мышление. И крайне трудно выполнять творческую работу, в основе которой лежат обсуждения, если постоянно беспокоишься о том, что твои коллеги должны будут сказать про каждую строку твоего кода.
Негатив — это инженерная поп-культура
Сегодня отношению инженеров уделяется столько внимания, как никогда. В инженерных организациях всё популярнее становится правило "Никаких овнюков". В Твиттере появляется всё больше анекдотов и историй про людей, которые покинули эту профессию потому, что не смогли (не захотели) и дальше мириться с враждебностью и недоброжелательностью по отношению к посторонним. Даже Линус Торвальдс недавно извинился за годы своей враждебности и критики в адрес других Linux-разработчиков — это привело к дискуссии об эффективности такого подхода.
Кто-то до сих пор отстаивает право Линуса быть очень критичным — те, кто должен многое знать о преимуществах и недостатках «токсичного негатива». Да, корректность крайне важна (даже фундаментальна), но если резюмировать причины, по которым многие из нас позволяют выражению негативного мнения превратиться в «токсичность», то эти причины выглядят патерналистскими или подростковыми: «они заслуживают это, потому что идиоты», «он должен быть уверен, что они этого не повторят», «если бы они так не поступили, ему не пришлось бы на них орать», и так далее. Примером того, какое влияние эмоциональные реакции лидера оказывают на сообщество программистов, является аббревиатура MINASWAN в сообществе Ruby — «Matz is nice so we are nice» (Мац [создатель языка] хороший, значит и мы хорошие).
Я подметил, что многие пылкие сторонники подхода «убей дурака» часто очень заботятся о качестве и корректности кода, идентифицируя себя со своей работой. К сожалению, они часто путают твёрдость с жёсткостью. Недостаток такой позиции проистекает из простого человеческого, но непродуктивного желания почувствовать своё превосходство над другими. Люди, которые погружаются в это желание, застревают на пути тьмы.
Мир программирования быстро растёт и упирается в границы своего контейнера — мира непрограммирования (или это мир программирования является контейнером для мира непрограммирования? хороший вопрос).
По мере того, как наша индустрия расширяется нарастающими темпами и программирование становится всё доступнее, дистанция между «технарями» и «нормальными» быстро сокращается. Мир программирования всё больше подвергается воздействию межличностного общения людей, которые выросли в изолированной культуре «ботанов» начала технобума, и именно они сформируют новый мир программирования. И невзирая на какие-либо аргументы относительно социальной сферы или поколений, эффективность во имя капитализма проявится в культуре компаний и подходах к найму: лучшие компании просто не будут нанимать тех, кто не сможет взаимодействовать с другими нейтрально, не говоря уже о хороших отношениях.
Что я узнал о негативе
Если вы позволяете избытку негатива управлять вашим разумом и общением с людьми, превращаясь в «токсичность», то это опасно для продуктовых команд и дорого для бизнеса. Я видел несметное количество проектов (и слышал про такие), которые развалились и были полностью переделаны с большими затратами, потому что один из разработчиков, которому доверяли, точил зуб на технологию, другого разработчика или вообще единственный файл, выбранный для представления качества всей кодовой базы.
Также негатив деморализует и разрушает отношения. Я никогда не забуду, как коллега ругал меня за то, что я положил CSS не в тот файл, меня это расстроило и не давало собраться с мыслями несколько дней. И в будущем я вряд ли позволю подобному человеку оказаться поблизости от одной из моих команд (впрочем, кто знает, люди меняются).
Наконец, негатив буквально вредит вашему здоровью.
Мне кажется, так должен выглядеть мастер-класс по улыбкам.
Конечно, это не аргумент в пользу того, чтобы лучиться счастьем, вставлять десять миллиардов смайлов в каждый pull request или отправиться на мастер-класс по улыбкам (не, ну если вы именно этого хотите, то не вопрос). Негатив является крайне важной частью программирования (и человеческой жизни), сигнализируя о качестве, позволяя выразить чувства и пособолезновать людям-братьям. Негатив свидетельствует о проницательности и рассудительности, о глубине проблемы. Я часто замечаю, что разработчик достиг нового уровня, когда он начинает выражать недоверие в том, в чём раньше был робок и неуверен. Своими мнениями люди демонстрируют рассудительность и уверенность. Нельзя отбросить выражение негатива, это было бы по-оруэлловски.
Однако негатив нужно дозировать и уравновешивать другими важными человеческими качествами: сочувствием, терпением, пониманием и юмором. Всегда можно сказать человеку, что он облажался, без крика и ругани. Не надо недооценивать такой подход: если тебе совершенно без эмоций говорят, что ты серьёзно накосячил, это действительно пугает.
В тот раз, несколько лет назад, со мной поговорил СEO. Мы обсудили текущее положение проекта, затем он спросил, как я себя ощущаю. Я ответил, что всё нормально, проект движется, потихоньку работаем, пожалуй, я кое-что упустил и нужно пересмотреть. Он сказал, что слышал, как я делился более пессимистическими соображениями с коллегами в офисе, и что другие тоже это заметили. Он объяснил, что если у меня есть сомнения, я могу в полной мере высказать их руководству, но не «спускать вниз». Будучи ведущим инженером я должен помнить, как мои слова действуют на других, потому что я обладаю большим влиянием, даже если того не осознаю. И всё это он сказал мне очень по-доброму, и в завершение сказал, что если я действительно испытываю такие чувства, то мне, вероятно, нужно обдумать, чего же я желаю для себя и своей карьеры. Это была невероятно мягкая беседа в стиле «возьми себя в руки или выметайся». Я поблагодарил его за информацию о том, как моё изменившееся за полгода отношение незаметно для меня влияет на других.
Это был пример замечательного, эффективного управления и силы мягкого подхода. Я понял, что мне лишь казалось, будто я всецело верю в компанию и её способность достичь целей, а в реальности говорил и общался с другими совсем иначе. Также я понял, что даже чувствуя скептицизм в отношении проекта, над которым я работал, мне не следовало показывать своё отношение коллегам и распространять пессимизм словно заразу, уменьшая наши шансы на успех. Вместо этого я мог агрессивно транслировать реальное положение своему руководству. И если бы я почувствовал, что они меня не слушают, то мог бы выразить своё несогласие уходом из компании.
Я получил новую возможность, когда занял должность руководителя по оценке персонала. Будучи бывшим главным инженером, я очень внимательно слежу за выражением своего мнения о нашем (постоянно улучшающемся) легаси-коде. Чтобы одобрить изменение, нужно представлять текущую ситуацию, но вы ни к чему не придёте, если погрязнете в стенаниях, нападках или чём-то подобном. В конечном счёте, я здесь для того, чтобы выполнить задачу, и не должен жаловаться на код, чтобы понять его, оценить или исправить.
Фактически, чем больше я сдерживаю свою эмоциональную реакцию на код, тем лучше понимаю, каким он мог бы стать, и тем меньше смятения испытываю. Когда я выражался сдержанно («здесь должны быть возможности для дальнейших улучшений»), то тем самым радовал себя и других и не принимал ситуацию слишком близко к сердцу. Я осознал, что могу стимулировать и понижать негатив в других, будучи идеально (раздражающе?) благоразумным («вы правы, этот код довольно плохой, но мы его улучшим»). Я рад тому, насколько далеко могу пройти по пути дзена.
По сути, я постоянно учусь и переучиваю важный урок: жизнь слишком короткая, чтобы постоянно злиться и страдать.
Комментарии (105)
Godebug
22.04.2019 12:49TL;DR Объективные вещи нельзя оценивать субъективно.
kolu4iy
22.04.2019 13:38+1Это вы про код?
Godebug
22.04.2019 13:53Да. Код объективен, код должен решать какую-то задачу. Гневаться на код это совершенно непродуктивно :)
ChessShire
22.04.2019 15:11Код сам по себе объективен. Даже задача, которую надо решить, иногда бывает объективна.
Но код — это решение субъективно воспринятой задачи, которое реализовано через призму субъективных предпочтений и субъективного же опыта программиста.
В моей практике «гневаться на код» — это чаще всего сокращение от «гневаться на то, как кто-то смог так странно понять задачу» и/или «гневаться на то, как кто-то смог так интересно реализовать решение».
Вот этот мифический ктот и вызывает седину, нервный тик и интересные истории на dailywtf. А на код никто и не гневается особо.Godebug
22.04.2019 15:33+1Да, в моей практике это обозначает тоже самое. И любой разработчик может оказаться в роли этого мифического «ктота». Смысла то особо гневаться нет, видишь ошибку — исправь. И тесты этого участка кода тоже исправь. И везде где используется этот код — тоже поправь. А если этот код в пул реквесте то просто отклони и конструктивно обоснуй почему. А сначала гневаться, раздувать проблему а потом расхлебывать последствия, в том числе и со здоровьем, это совершенно непродуктивно :)
kolu4iy
22.04.2019 15:14А мне думается, что объективна проблема, которую он должен решить. А код — это полёт фантазии разработчика. И он проблему либо решает, либо нет.
Со стороны архитектора есть еще одна сущность: ресурсы, которые код задействует для решения проблемы. А также стоимость его сопровождения.
Вот проблема и ресурсы — относительно объективные метрики, а стоимость сопровождения (как и сам код) — субъективные.
Я так думаю :)
EvgeniiR
23.04.2019 09:56>«это полёт фантазии разработчика. И он проблему либо решает, либо нет.»
Ну серьёзно? В 2к19 продолжать обсуждать что первично, архитектура или функционал?
Метрик больше, и то что вы решили проблему поставленную бизнесу далеко не означает что вы сделали все хорошо. Я бы очень остерегался разработчиков которые заявляют что код написан повторно только за факт того что он работает
Hardcoin
22.04.2019 15:24Код объективен как набор байт. Ответ на вопрос "хорошо ли код решает задачу" субъективен, потому что субъективно слово "хорошо".
Вы можете объективно измерить скорость кода, покрытие тестами и даже полноту решения на множестве входных данных.
Но вы не можете объективно измерить простоту поддержки и устойчивость к человеческим ошибкам при изменениях.
Godebug
23.04.2019 12:17Но вы не можете объективно измерить простоту поддержки и устойчивость к человеческим ошибкам при изменениях.
Метрика WTFperLineOfCode?)dimm_ddr
23.04.2019 12:57+1А она точно показывает простоту поддержки и устойчивость к ошибкам? Да, понятно, что если цифра в метрике получается большая, то это скорее всего говорит о том что поддерживать и модифицировать код будет тяжко, но вот обратной зависимости скорее нет — даже чистый и очевидный код может быть тяжело поддерживать и менять. Что значит что этой метрики совершенно недостаточно. Плюс она совершенно субъективна — один программист не поймет что происходит потому что у него нет опыта, второй — потому что он думает другими паттернами, третий решит что поймет и ошибется, четвертый поймет. При этом код может быть как плохим, так и хорошим. Понятность кода вообще не может быть объективной метрикой просто по определению.
Hardcoin
24.04.2019 00:19+1Для этого нужен калиброванный прогер в палате мер и весов, что б по нему настраивать. Иначе она будет плавать от отдела к отделу, ненадёжно.
411
22.04.2019 20:41Особенно учитывая, что лет через 10 он сможет вспомнить это, обидеться, прийти к тебе домой и настучать железной клешнёй по башке.
SadOcean
23.04.2019 13:25+1Радикально не соглашусь.
Код объективен лишь в том, что он, будучи скомпилированным работает и решает задачу.
Хотя в сложных кейсах и это не очевидно — редактор со сложным интерфейсом «решает» задачу редактирования, но насколько эффективно, если пользователям тяжело его понимать?
Код пишется не только для компьютеров, но и для людей.
С точки зрения разработчика все варианты решения задачи и оформления кода для этого решения — глубоко субъективны. Разные люди по разному поймут этот код, будут испытывать проблемы с пониманием в разных местах, могут считать разные места важными или не важными, по разному будут его менять. Субъективны так же варианты расширения и изменения кода при развитии — ведь они опираются на субъективные требования (пример с интерфейсом) и субъективное понимание текущей работы кода.
Гневаться на код разумеется не продуктивно, но «ругать» странную логику, плохое форматирование, сложность чтения и т.д. для того, чтобы этого избежать — вполне продуктивно.
Усилия по улучшению кода, направленные на понимание кода в будущем и разными членами команды — оправданны.Godebug
23.04.2019 16:19Вы как-то плавно скользите от кода к системе, от системы к интерфейсам, и от этого всего к людям а потом опять к коду. Нельзя столько разных проблем притягивать за уши в трех коротеньких абзацах. SOLID наше все, как для кода так и для комментариев :)
Vladek
23.04.2019 13:46+2Он должен не только работать, он ещё должен быть готов к изменениям в дальнейшем. Рабочий код может написать практически любой, а вот рабочий код, готовый к будущим изменениям — может написать далеко не каждый.
Aquahawk
22.04.2019 14:49Ох чёрт, я пока читал хотел нарисовать эту самую path of zen. Я сейчас на стадии уменьшения гнева и это чертовски приятно.
mayorovp
22.04.2019 15:36Ключевое, о чём критики "негатива" часто забывают:
Со временем разработчики начинают смиряться с тем, что плохой код — реальность программного обеспечения, и что их работа заключается в том, чтобы его улучшить. И что если нельзя избежать плохого кода, то и нет смысла поднимать из-за него шум.
Если плохого кода избежать можно — то и шум поднимать тоже можно.
dimm_ddr
23.04.2019 12:59Можно избежать какими усилиями, стоит ли оно того? Шум в виде негатива реально поможет лучше чем что-то более нейтральное? Этот плохой код вообще нужно ли избегать?
Я допускаю что есть случаи когда ответ на все эти вопросы — да. Но мне кажется что таких случае на пару порядков меньше чем случаев где негатив используется и где его хотят использовать фанаты негатива.
SadOcean
23.04.2019 13:27Ну статья про то, что не нужно возводить это в абсолют, и шум должен быть оправдан, а не вырождаться в срач и оскорбления.
Важно и то, что код читать сложнее чем писать в принципе. Поэтому любой прочитанный код зачастую хуже, чем написанный.
Vegatron
22.04.2019 16:00+1Имхо, не должны быть «дикие» review, можно написать какие-то полиси, ввести best practices, отчетливо пропагандировать чистоту и правильность кода, устанавливая это в качестве стандарта. В таком случае при ревью можно оценку декларировать не как твое личное «негативное» мнение, а несоответствие принятым нормам и стандартам. Это во-первых позволяет исключить негатив, когда один человек, считает, что до него докапываются, а второй собственно докапывается, а во-вторых делает сам процесс несколько обезличенным. Условно ревьюер выступает в качестве веб-формы куда ты заливаешь свой код, а она тебе отвечает — переделай, с должной степенью подробностей )
Проблема чаще всего в том, что формализовать процесс подчас сложно и никто не хочет этим заниматься.
grt_pretender
22.04.2019 20:28Негатив столь важен для программистов потому, что это очень эффективный способ передачи ценности ©.
Жаль только, многие люди неспособны увидеть разницу между «эффективным способом передачи ценности» = конструктивной критикой и обычным хамством.
vassabi
22.04.2019 21:42+3начал читать. вижу
Когда мы начинаем впервые учиться программированию, наше представление о глубине «опыта программирования» основывается на наблюдениях за эмоциональными реакциями других людей.
первая мысль: «я один такой, кто вообще не обращал внимание на реакцию других людей, когда начинал учиться программированию?
Или это очередное влияние „давайте все вместе возьмемся за руки и будем вместе бороться с воображаемой токсичностью“ (вместо того, чтобы писать код) ?»
…
продолжаю читать дальше — и да, все так и есть:
В инженерных организациях всё популярнее становится правило «Никаких овнюков». В Твиттере появляется всё больше анекдотов и историй про людей, которые покинули эту профессию потому, что не смогли (не захотели) и дальше мириться с враждебностью и недоброжелательностью по отношению к посторонним.
(особенно умилило про твиттер)
dmxvlx
23.04.2019 02:58Если к каждому «плохо написанному коду», прикреплять тэг «написано джуном», то гнев может смениться если не на милость, так на снисхождение уж точно. Но кто возьмёт менторство над неумехой, и будет взращивать себе конкурента? Или же тот окажется достойным ему коллегой и другом после затраченных сил и времени?
Сложные вопросы, требующие больших вычислительных мощностей и опыта, уступают тому, чтобы просто «пометить» чувачка рукопопым…
Всегда есть Мы, и будут Они, а вот алгоритм определения этих самых Наши и Ваши у каждого свой, на основе опыта, психо-типа и ещё кучи факторов которые не так просто предопределить…vassabi
23.04.2019 04:16я наверно старомоден, однако я до сих пор не делю людей на «Наши и Ваши», а делю код на тот, который можно сделать лучше и тот, который нужно сделать лучше.
И единственное разделение людей возникает разве что в виде: люди, которые могут улучшить свой код VS люди, которые вместо улучшения своего кода начинают заниматься межличностными отношениями от «меня обидели» до «они против нас»…exception13x
23.04.2019 09:09делю код на тот, который можно сделать лучше и тот, который нужно сделать лучше.
Я правильно понял, что для Вас приемлемого кода просто не существует?
Выглядит так, будто ревью у Вас не сможет пройти без замечаний ни один человек, выложи он на ревью хоть симфонию.
А потом вы удивляетесь на реакцию коллег вида:
вместо улучшения своего кода начинают заниматься межличностными отношениями от «меня обидели» до «они против нас»
dimm_ddr
23.04.2019 13:07+2Я правильно понял, что для Вас приемлемого кода просто не существует?
Я разделяю позицию предыдущего комментатора (про можно или нужно улучшать код) и я лично вижу это так: идеального кода практически не существует, особенно если смотреть на код во времени, а не только в момент код ревью (ну то есть поддержка, модификации, вот это вот все). Но приемлимого кода более чем достаточно, нужно просто понимать что код не идеален и его можно улучшить. Прекрасно когда понятно как его можно улучшить и чего это будет стоить — это просто идеальная ситуация. Обычно это не совсем так к сожалению.
Но то, что код всегда можно улучшить не значит что все эти возможности надо писать в ревью как замечания. ЧТо-то можно написать как комментарий на будущее — на случай если мы получим от клиента бюджет на улучшение этой фичи. ЧТо-то — просто оставить при себе (например если улучшение неоднозначно или объяснение почему так лучше займет чем можно потенциально выиграть от собственно изменения). Что-то выписать и потом обсудить на очередном воркшопе или другой активности.
vassabi
23.04.2019 14:26+1Я правильно понял, что для Вас приемлемого кода просто не существует?
Приемлимый — существует конечно же. Вот идеального — нет. Причем не для меня не существует, а вообще не существует (выше комментатор вам уже в принципе ответил).
В принципе — улучшить-то можно любой код, просто это будет иметь слишком большие затраты на цену\время разработчика. Но если качество кода отрицательное (явные баги или нарушения кодстандарта) или его можно улучшить быстро (или выгода от улучшения высока — ака рефакторинг техдолга), то почему бы не сказать об этом на код ревью?
(и тут мы переходим к 2й части)
А потом вы удивляетесь на реакцию коллег
я не удивляюсь, я во-первых всегда говорю о коде, а не об авторе кода, а во-вторых, от людей с такими реакциями на кодревью лучше вежливо но твердо прощаться до конца испытательного срока (на то ведь он и испытательный).
PS: впрочем, в моей практике таких случае не было ни одного, несмотря на пол и возраст коллег.
HellWalk
23.04.2019 09:32Я видел команды, где с кодом (и, соответственно, с проектом) все было плохо, но где все были спокойны. Это напоминает поезд, который едет в пропасть, все пассажиры которого видят этого, но совершенно спокойны (а точнее им все равно — умрет один стартап — через неделю их возьмут в другой).
Для меня эмоции — это показатель того, что человек не равнодушен к тому, чем занимается.
И всё это он сказал мне очень по-доброму, и в завершение сказал, что если я действительно испытываю такие чувства, то мне, вероятно, нужно обдумать, чего же я желаю для себя и своей карьеры. Это была невероятно мягкая беседа в стиле «возьми себя в руки или выметайся»
Не переношу такие «тонкие намеки».mrigi
23.04.2019 11:03Падает любой, даже самый красивый код. Команда и нужна для того, чтобы по ходу решать задачи и проблемы. Это всего лишь обычная поточная работа. Спокойны они потому что у них есть опыт чинить на ходу и поддерживать такие проекты десятилетиями, они это умеют и в этом нет никакой пропасти. Эмоции тут неуместны, просто поддержка существующих проектов не для белок-истеричек.
peacekeeper
23.04.2019 11:48Если поезд идет в пропасть — можно или собраться с мыслями, успокоиться и найти решение. Или обвинять окружающих в плохом коде и в том, что они не умеют писать.
Для меня эмоции — это показатель того, что человек не равнодушен к тому, чем занимается.
А если человек интроверт? Такие могут переживать глубоко внутри, а снаружи быть спокойными, как скала.
Не переношу такие «тонкие намеки».
Честно — я тоже. Но после того, как эмоции откипели — я стараюсь взглянуть на это объективно. И я однозначно предпочту СЕО, который «по-доброму», но спокойно объяснит, в чем я неправ, вместо СЕО, который начнет кричать на ровном месте, и в лучшем случае услышит два слова из пяти, сказанных тобой.
Я поддерживаю автора и считаю, что негатив неконструктивен.
Но также, мы должны помнить, что:
«Нет правил без исключений»))legolegs
23.04.2019 16:22Почему вы противопоставляете «CEO «по-доброму»» и «СЕО кричать на ровном месте»? А если кричит не на ровном месте, а на развалинах, вами устроенных, то это всё равно хуже, чем начальник «по-доброму» с повадками босса мафии?
peacekeeper
25.04.2019 07:28Кричать — это не конструктивно. Это не решит проблему. Первое и главное — это решить проблему. Второе — это подумать, как сделать, чтобы подобное не повторилось. Обычно крик — это способ, которым неадекватные начальники снимают напряжение, скидывая его на подчиненных. Если вам нравится, когда на вас кричат — это ваш выбор и ваше право, вы можете работать с таким начальником.
По поводу повадок «Босса мафии»… я не помню, чтобы я упоминал что-то про: «в лес и закопать». Я говорил, что я предпочитаю адекватного человека, который спокойно объяснит в чем проблема.
Уточню: я понимаю, что есть исключения и вывести из равновесия можно даже самого спокойного человека, если это был серьезный факап, но такие случаи я сейчас не рассматриваю. Я говорю об обычном рабочем процессе.
Flammar
23.04.2019 14:17Я видел команды, где с кодом (и, соответственно, с проектом) все было плохо, но где все были спокойны. Это напоминает поезд, который едет в пропасть, все пассажиры которого видят этого, но совершенно спокойны (а точнее им все равно — умрет один стартап — через неделю их возьмут в другой).
Вспоминаю чьё-то противоположное высказывание, что лучший по качеству код он видел в мёртвых стартапах.
Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке программирования — более масштабируемом по размеру мощностей серверов, размеру кодовой базы и размеру команды разработчиков, но при этом с в разы меньшей производительностью программиста по части количества реализованных «фич» в единицу времени — типа Java.dimm_ddr
23.04.2019 14:23+1Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке программирования
Мне это утверждение кажется не менее сомнительным чем разговоры про необходимость все делать правильно с самого начала. Когда-нибудь, когда стартап станет большой компанией с хотя бы еще парой основных продуктов благодаря деньгам от которых можно позволить себе вместо развития несколько лет переписывать уже работающее, но я не уверен что есть много примеров когда это реально сработало. У меня никогда не было стартапов, так что это чистое теоретизирование конечно, но разве после того как стартап выстреливает его гонка с конкурентами заканчивается? Вон, Netscape когда его решили переписать более чем успешен был и чем это закончилось?Flammar
23.04.2019 15:27Почему «вместо»? Параллельно, денег на R&D хватит.
Вон, Netscape когда его решили переписать
Тогда MS выпустили бесплатный браузер IE и всё, модель монетизации поменялась на ходу. Когда подстроились, сделали Mozilla Firefox, но это уже была другая эпоха.dimm_ddr
23.04.2019 15:54Почему «вместо»? Параллельно, денег на R&D хватит.
И этот вариант также сомнителен. Переписать главный продукт с которого идут деньги целиком, при этом продолжать получать с него достаточно денег чтобы еще и на R&D хватило — я не знаю возможно ли такое вообще. И даже если возможно, то необходимо сравнить с альтернативой — когда первый продукт не переписывается, а все деньги идут на новые продукты или дальнейшее улучшение старого. Совершенно неочевидно что ваш вариант лучше.
EvgeniiR
23.04.2019 14:26Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке
Что-то мне подсказывает, что если стартап выстрелит, времени не будет ни на что, а бэклог будет трещать по швам от вала фич, которые нужно запилить ещё вчера, потому что их презентовали в MVP :)Flammar
23.04.2019 15:29Со временем количество фичер-реквестов в единицу времени снизится, а цена масштабирования вырастет, так что переписывание на Java станет актуальнее и выгоднее. Просто это произойдёт позже, чем вы сейчас написали.
JuniorIL
23.04.2019 18:09Для меня эмоции — это показатель того, что человек неравнодушен к тому, чем занимается.
Да, но вот вопрос, зачем? Почему надо быть «неравнодушным»?
После двух лет «неравнодушия», вытягивания проекта с первой строчки кода до ситуации, когда сами Циско интересуются моим детищем через бессонные вечера, пытаясь успеть в самом ограниченом бюджете быть и программистом и тимлидом и продактом; с дуновением ветра отношение ко мне поменялось на того самого «негативного» технаря, который мешает бизнесу. А вот равнодушных фрилансеров, которые просто просили большую цену и делали работу уважают так как прежде. Так может нам (как минимум мне) пора начинать учиться? Просто плюнуть на всё, брать соответсвующие деньги за свою работу и не давать ей влезать в эмоциональную сферу, ведь в конечном итоге этими эмоциями мы вредим всем, и компании и менеджменту и себе. И если менеджеры хотят чтобы жизнь людей полагалась лишь на один датчик, то надо сообщить о проблеме, а если вас не послушали и совесть дороже проблемы — просто уволиться.
olegiv2019
23.04.2019 09:54На мой взгляд (дилетанта в разработке ПО — каковым я себя считаю) -«плохой/хороший» — формулировки ни о чем. Есть задача — если она выполняется согласно ТЗ — значит все замечательно. Все вопросы к составителям ТЗ на разработку ПО.
EvgeniiR
23.04.2019 10:00+1Есть задача — если она выполняется согласно ТЗ — значит все замечательно. Все вопросы к составителям ТЗ на разработку ПО.
А после нас хоть потоп, да, главное что в карман денежка упала, а когда у бизнеса проблемы будут можно и другую работу найти.
Как вы в требованиях опишите поддерживаемый код?SwingoPingo
23.04.2019 10:15-1А за поддерживаемый код никто платить не собирался, извините
EvgeniiR
23.04.2019 12:31Да, это очень печальный момент, желания и требования заказчика, по крайней мере в том виде, в котором они понимаются исполнителями, далеко не всегда совпадают с тем что ему действительно нужно. С похожими мыслями я, кстати, писал вторую свою статью на хабр, хотя вряд ли я донес их хорошо.
Мне как разработчику хочется нести ответственость за свой код и стараться сделать его лучше. И мои интересы, как разработчика, не всегда совпадают с тем что хочет диктовать заказчик, и тут нужно искать компромиссы.
olegiv2019
23.04.2019 10:32«а когда у бизнеса проблемы» — об этом должен думать не рядовой программист, а тот кто руководит командой программистов и соответственно согласовывает ТЗ с тем кто ставит задачу
«Как вы в требованиях опишите поддерживаемый код?» — это все хорошо формализуется
Хотя грех спорить с тем, что код дожен быть «читабельным» и т.д. При этом хочу отметить — что любой человек пытается решить задачу с наименьшими энергозатратамиEvgeniiR
23.04.2019 10:45«а когда у бизнеса проблемы» — об этом должен думать не рядовой программист, а тот кто руководит командой программистов
Об этом должны думать все, но код пишет программист, и если программист не думает как сделать хорошо он и не сделает хорошо.
«Как вы в требованиях опишите поддерживаемый код?» — это все хорошо формализуется
Вот это интересно. Допустим задал я программисту интегрироваться с новым почтовым сервисом, как формализовать требования к качественному коду?
Не говоря уже о том что не бывает однозначно хорошего и однозначно плохого кода, т.к. в разных ситуациях один и тот же код может быть как хорошим так и не очень, как проверить что программист задумывался об архитектуре, советовался с бизнесом о возможных дальнейших изменениях, даже банальные штуки как направление зависимостей, сложность методов, предлагаете заказчику во все это вникать?olegiv2019
23.04.2019 10:50-1Если Вы — руководитель проекта ставите программисту задачу — и если Вы компетентный менеджер — Вы всегда предварительно обсудите все вопросы с персоналом, занятым разработкой ПО — по-моему это очевидно
SwingoPingo
23.04.2019 11:10Все это действительно хорошо формализуется и часто хватает даже беглого взгляда по диагонали что бы примерно понять качество кода, но! Представителям заказчика не нужно качество кода. Им нужно решение задачи за меньшие деньги и меньшее время. За это они получат премии, медальки и печеньки. А на остатки ФОТ от премий, медалек и печенек джуны на пол ставки будут запиливать код как бог на душу положит лишь бы только заработал к часу Х и всех занятых в процессе такая ситуация устраивает. Потому что печенки и медальки они вот, а на то что проект выстрелит никто вообще то и не рассчитывал.
Уже после появится Программист который скажет — «что за лажа!? кто так пишет?». Но он появится на временной шкале жизни проекта много позже, поэтому высказывания и желание его вернуть печенки и медальки эффективных менеджеров в замен на хороший код (потому что денег ему лично выделили за работу как будто код хороший, а не куча гумуса) смысла не имеют. А имеет смысл только повышение его, Программиста, зарплаты на переписание всего этого. Говнокод рождается по объективным причинам и в первую очередь сам заказчик и является этой причиной.EvgeniiR
23.04.2019 12:19Все это действительно хорошо формализуется и часто хватает даже беглого взгляда по диагонали что бы примерно понять качество кода,
Не совсем так… Формализуются лишь совсем простые условия, типа проверить не лепятся ли SQL-запросы в контроллерах/шаблонах представления, да читаемые ли имена даются переменным.
Невозможно, например, проверить соблюдение принципа стабильных зависимостей без анализа потока изменений.
Практически не возможно рассуждать о том хорошо/плохо выбрано архитектурное ограничение, не зная как оно было принято
«A good architecture
comes from understanding it more as a journey than as a destination, more as an
ongoing process of enquiry than as a frozen artifact» © Uncle Bob
Есть запахи, почуять которые бывает сложно даже программисту работающему на проекте — тот же temporal coupling.
Ну и ещё интересный и очень печальный момент — люди могут делать плохо, иметь от этого проблемы, и действительно не замечать их, точнее, принимать асболютно как должное, т.к. ни у кого ещё не было опыта реализации даного функционала, а процесс обмена знаниями, как минимум в нашей сфере, на мой взгляд, построен, весьма не очень.SwingoPingo
23.04.2019 12:32Абсолютно согласен. Заказчиков, закладывающих эти нюансы в бюджет на этапе проектирования мне хватит двух пальцев пересчитать. Заказчиков, закладывающих в процесс жизни кода его хотя бы периодический ревью на оптимальность — одного. При этом же очевидно что существуют силы которые из приличного кода/архитектуры будут стремиться сделать код неприличным.
DrunkBear
23.04.2019 11:08Ну да, а потом открываешь profiler и понимаешь, что замечательный код ( он выполняет все требования ТЗ) при обновлении 1 поля обновляет всю таблицу теми же значениями, что и были. И одним новым, да.
И в этом случае для конкретной команды нормально подойти и сказать — «взгляните, у вас тут какое-то говно творится, можете пофиксить?»
Flammar
23.04.2019 16:52В таком случае получается, что ТЗ призвано быть «серебряной пулей», решающей все проблемы раз и навсегда, иначе — «все вопросы к составителям ТЗ на разработку ПО».
olegiv2019
23.04.2019 17:15Да нет конечно «раз и навсегда» — не бывает. Я всего лишь хотел сказать, что как поставлена задача — так и будет она решаться. Если нужно быстрее и сейчас — это одно, если перспектива — это другое. И программисту вовсе нет дела до перспективных планов компании — заказчика — это задача компетентного менеджера.
aivazovski
23.04.2019 10:32У меня был хрестоматийный пример. Продуктовая компания, отдел разработки поделён на 3и команды, 2е самодостаточные команды которые пилят фичи и команда поддержки, которая латает всплывающие баги и смотрит легаси.
В первой команде разработки тимлид был «токсичным нытиком» из статьи, во второй спокойно реагировал на проблемы или косяки. Угадайте, какая команда была продуктивней?..
А никакая. Обе команды запиливали фичи схожей сложности, тратя при этом схожее время.
А в чём мораль? А в том, что во второй команде рабочий климат был гораздо лучше. И если нет разницы продуктивности, зачем мотать нервы?ixamilion
23.04.2019 13:59Даже если бы команда во главе с «токсичным нытиком» была бы продуктивнее второй, многие 10 раз бы подумали с кем работать лично им выгоднее. И тогда факт токсичного окружения становиться конкурентным преимуществом при выборе места работы.
dim2r
23.04.2019 11:28Есть разница между идеями «сделать так, чтобы работало» и «сделать правильно». Мне мои заказчики через 7 лет звонили, говорили что работает. Правильно ли было сделано? — не задумывался. Если работает, — значит правильно.
Flammar
23.04.2019 14:55Интересно, какая доля написанного кода сможет прожить семь лет?..
vassabi
23.04.2019 16:16+1глядя в бездну кровавого энтерпрайза, могу сказать что от 5% (активная разработка) и до 99% (никакой активности, 1 человек в саппорте максимум).
dim2r
24.04.2019 10:15Я когда-то работал в небольших конторах, когда ты на проекте царь и бог. Тогда это было возможно.
Сейчас с трудом это можно представить — настолько все куда-то едет и плывет. Программист превратился в гребца на галере, которым погоняют какие-то гуманитарии.vassabi
24.04.2019 11:21+1… странно, я последние три года ушел от стартаперов и работаю на корпорации в адовом лигаси (код 1994 года рождения, первый автор — не программист по профессии). Но, никто не против, чтобы я взял и переписал хоть слева-направо хоть справа-налево — так что, если не бог, то уж царь на проекте. Денег и времени конечно нет, но в стартапах их тоже нет (денег там если и есть — то на найм людей, которые пишут не в вашем проекте). Зато с дедлайнами никто не дышит в спину.
Вот так потихоньку пишешь код — и будешь уверен, что он там до следующего десятилетия будет работать.dim2r
24.04.2019 12:05Да, я тоже заметил, что на стартапах дедлайны и адреналин, а на энтерпрайзе их нет, хотя порой возникает ощущение бессмысленности работы.
mrigi
23.04.2019 11:29Возможно, это худший код, что мне когда-либо встречался.
Тут проблема не в коде, а в таких глобальных оценках. Они совершенно ни к чему.
Чтобы обновить всего одну запись в базе данных, он извлекает все записи в коллекции, а затем отправляет запрос на обновление каждой записи в базе, даже тех, которые обновлять не требуется
Результат её работы корректен? Если да, не трогай. Если нет, исправь.
Производительности хватает? Если да, не трогай. Если нет, улучши.
Всё просто. Никакие лишние слова и эмоции не нужны.
Да прибудет с вами дзен.x8core
23.04.2019 11:48Это так не работает. Я буду трогать даже если работает, так как мне интересно разобраться и исправить. Иногда мои мысли идут в сторону производительности и я буду трогать. Вам как раз таки нужно смириться с этим, что будут трогать то, что работает. Ломать будут это, уничтожать, если появиться соответствующее желание. Жизнь ежедневно ломает все ваши смыслы и устои, а вы продолжаете сопротивляться негативу, разрушению и с этим всё нормально.
Дзен для вас всех лишь очередная идея, так как вы направляете внимание на идеи, а не на то, кем вы являетесь. Вы только и подшучиваете над дзеном, и вставляете его как крылатые выражения вроде «мир во всём мире», приплетаете его когда надо и не надо.dimm_ddr
23.04.2019 13:17Это так не работает. Я буду трогать даже если работает, так как мне интересно разобраться и исправить.
Это ваше личное качество. И на мой взгляд это качество скорее отрицательное, а не положительное. Если конечно вы тратите на это рабочее время (я сейчас не говорю про случай когда рефакторинг делается для разгрузки мозга и своеобразного отдыха, такое тоже бывает). Именно из этого качества и появляются идеи «а давайте все перепишем с нуля», преждевременная оптимизация и ловля блох. Нужно решать реальные проблемы, а не просто интересные. Это практически как искать потерянную вещь под фонарем, а не там где потерял — гораздо приятнее, но результат так себе.x8core
23.04.2019 13:29Реальные проблемы сложно решить, если ты их не видишь.) Спросите у любого программиста, и он скажет что это нормально писать код в виде текста в тестовом файле. И это при той технологической мощи, которая у нас есть на Земле сейчас. Так уже десятками лет код пишут. Журналист и программист используют один и тот же метод ввода информации. Ту же клавиатуру и мышь или тачпад. Вы не находите в этом реальной проблемы или противоречия?)
dimm_ddr
23.04.2019 14:04Вы не находите в этом реальной проблемы или противоречия?)
Я не нахожу в вашем комментарии никакой связи ни с вашим предыдущим комментарием, но с моим на него ответом.
mrigi
23.04.2019 16:40Во первых, если у вас есть время и энтузиазм лезть туда куда не просили и помимо постоянных поточных задач, то боюсь что менеджеры у вас никакие и уровень вашей прокастинации на рабочем месте просто зашкаливает.
Во вторых, представьте что через ваше приложение проходят сотни миллионов долларов ежедневно. Я посмотрю как долго вы продержитесь в компании, если будете лезть в критически важный код ради ускорения, которое никто не просил. Один эпик фэйл и пойдете на кислород. Хотя думаю нормальный тимлид вас до этого и не допустит.
И третье, спасибо что рассказали что для меня дзен. Вам полюбому виднее. Могу лишь сказать, что по отношению к чужому коду я эмоций не испытываю вообще. Даже мыслей винить кого-то в криворукости или ещё чем-то не возникает. Это факт.x8core
23.04.2019 16:52Сколько же стереотипов можно вскрыть простым комментарием… Вы только почитайте свой коммент. Как различно люди видят то, что я написал.
bvbr
23.04.2019 22:02а потом вдруг ВНЕЗАПНО оказывается что такая перезапись не изменившихся данных попадает в очередь на репликацию и кладет ее полностью при вроде бы не сильно увеличившейся нагрузке.
пример из жизни если что, не сотни миллионов конечно, но достаточно серьезный продакшн
vassabi
23.04.2019 17:48трогайте, только тестами обложите сначала и метриками. Чтобы было видно — улучшилось ли что-то и насколько.
Я только «ЗА» за такое трогание кода — может, потенциально оптимизирующая идея и не прокатит, зато тесты и испытательный конфиг — вот они.
SwingoPingo
23.04.2019 12:20Вопрос зачастую стоит не так: работает/не работает, быстро/медленно. Вопрос стоит так: нужно добавить один параметр к двум сотням существующих, не затронув их работы, а в коде черт ногу сломит. И цена минимального изменения — ревью всей функциональности, создание нового ТЗ, согласование со всеми смежными отделами, переписание на поддерживаемый код, тестирование переписанного.
Все это рождает массу вопросов взаимодействия с коллегами, с заказчиком, с партнерами. Заказчика надо убедить выделить ресурсы на это. Выделить тестировщиков, время. На пустом месте. Ваше положение становится шатко, рисуются работы в выходные, дэдлайны, сданные билеты в турцию, ссора с женой, испорченные каникулы детей и т.д. Это непосредственная причина негатива, а не «худший в мире код».mrigi
23.04.2019 16:18Огромное приложение на миллионы строк, смежные отделы и у них нет собственных разработчиков, тестировщиков, сопровождающих код на всём жизненном цикле приложения? Что за притянутый за уши сферический конь в вакууме? Ещё и возникающий «зачастую»?
SwingoPingo
23.04.2019 17:53По моему опыту эта картина описывает 90% всего рынка программизма РФ.
Для того что бы все это получить достаточно тысячи талантливых строк. Немного измененный реальный пример: Драйвер считывания показателей счетчика. Код на пару тысяч строк написанных джуном. Все работает. Все завязано на производственные процессы трех отделов снимающих оперативную инфо по десятку параметров. Поступает задача увеличить дискретность съема данных в 2 раза. Начали разбор. Код написан с ошибками. Случайным образом они не фатальные, а на уровене погрешности. Увеличить дискретность нельзя. Переписание его — не повторишь ошибок округления и все такое. ТЗ процесса нет, есть куча денежной отчетности сути которой никто в деталях не понимает, но «изменять нельзя» т.к. санкции за изменение показателей. Опять же ретроспектива, отчеты должны выдавать те же данные при обращении к прошлым снятым показателям. Программист настаивает на создании ТЗ и полноценном тестировании с обнулением всего этого гумуса. Отделы на: «работало не трожь! вас же всего только просили снимать в 2 раза чаще!». Задача в итоге (внимание!) не решилась. Ибо не имела решения в котором все бы были довольны. А вы миллионы строк.
А как так получилось? Да элементарно, когда драйвер писали никто не думал что на его данных будут завязаны какие то серьезные процессы. Отдали джуну.mrigi
23.04.2019 21:03Так а в чём проблема, если у вас есть архив данных? Делаете изменения, прогоняете старые данные через новый код и убеждаетесь, что всё совпадает. В чём сложность-то? Не знаю подробностей, но с очень большой вероятностью проблема в программисте. Так как это абсолютно типичная постановка задачи для энтерпрайза.
Flammar
23.04.2019 15:03Результат её работы корректен? Если да, не трогай. Если нет, исправь.
К сожалению, этот принцип сегодня не работает: трогать код придётся в любом случае, и довольно рано: требования заказчика меняются на лету. Поэтому приходится создавать код, устойчивый к «троганиям». Можно, конечно, попытаться принудить заказчика написать более внятное ТЗ, такое, чтоб «один раз и на всю жизнь», чтоб программу никогда не пришлось изменять, и отказывать от работы с заказчиками, не желающими писать такое, но это обычно менее реально, чем писать код, приемлемо устойчивый к изменениям.mrigi
23.04.2019 16:11Этот принцип переживёт нас с вами. Открою вам великую тайну: и 15 лет назад требования заказчика точно так же менялись на лету. Куда надежнее иметь разработчиков, устойчивых к любому коду.
Namynnuz
23.04.2019 12:40Я никогда не забуду, как коллега ругал меня за то, что я положил CSS не в тот файл, меня это расстроило и не давало собраться с мыслями несколько дней
Ути пусенька. А чо тогда не «у меня начался ПТСР, я начал пить, потерял дом, жену, работу, после чего оказался на улице, меня подобрал добрый дядя психиатр, выписал таблетки, которые я должен был распространять на районе, после чего я понял, что дальше так продолжаться не может и самоутопился в тазу, пяшу с таво свету»?
На мой вкус, любому, кто вообще использует слово «токсичный» (в любом контексте), следует прописывать 50 ударов розгами. Мне интересно, как эти девочки-снежинки вообще выдерживают ментальные нагрузки, необходимые для переламывания собственного разума супротив логики, когда приходится поддерживать какую-то дикую застарело-засохше-зацвётшую вермишель.
И ладно бы тебе просто дали задачу по поиску бага в каком-то страшном и странном. Обычно ведь всё это происходит в самый неподходящий момент, бизнес терпит убытки и тебе в этой нервной обстановке, когда как раз-таки белки-истерички суетятся и мешают работать, нужно перелопачивать и прогонять через себя огромные объёмы маразматичного бреда, чтобы найти баг и починить его. Сколько ещё багов кроется в этой вермишели — неизвестно, но в следующий раз или ты, или кто-то после тебя, точно так же занырнёт в эту зловонную жижу, вместо того, чтобы раз и навсегда отрефакторить это всё и вычистить большое количество потенциальных проблем, повышая и стабильность в целом, и скорость поиска новых багов, понижая входной порог для поддержки. Но на потенциальное у них времени и денег нет. Авось пронесёт. А кем вы себя видите через пять лет в таких условиях?
Зато эффективные менеджеришки конечно же получат премии за быстрофикс, читай, овертаймовое насилие над тобой и потерянные деньги для бизнеса, при том, что этого можно было изначально избежать, корректно формулируя требования и учитывая свои возможности. И вот именно это бесит. Проблема (в управлении) не решается. Даже следствие этой проблемы — плохой код, который перерастает в плохой легаси код. И в один прекрасный момент это всё с грохотом рушится, погребая под собой всех. А виноват, конечно же, последний притрагивавшийся к этому программист.
После пары нервных забегов, у тебя образуется резко негативное отношение к плохому коду. Потому что не он является причиной, но именно он является триггером плохих воспоминаний. И его наличие является потенциальным (высоко вероятным) признаком возможности повторения всего этого непотребства. Почему никто не предлагает радостно смотреть в глаза и гладить по головке маньяка-насильника? Другие бы жертвы посмотрели на тебя, и тоже перестали сильно горевать по порванной заднице, да и в процессе меньше нервничали. И всё, проблема решена?Flammar
23.04.2019 15:18Вы обозначили ту же проблему, которой касается комментируемая переводная публикация, только другими словами. Перманентная психотерапия для лечения системной проблемы негативности мышления и мировоззрения при разработке ПО — вещь нужная.
olegiv2019
23.04.2019 13:41Кстати, кто может сказать про code.jquery.com/jquery-3.4.0.min.js
«хороший» или «плохой» это код? ))) (обычная практика написания кода в js)mayorovp
23.04.2019 15:02+1Не «написания», а распространения. Исходные коды этой библиотеки выглядят совсем по-другому.
olegiv2019
23.04.2019 15:17-1Так код-то «хороший» или «плохой»?
это и есть исходный код — только без пробелов и переносов строк (в отладке смотрится без особых неудобств).Zenitchik
23.04.2019 16:12Вообще-то нет. Они его из кучи файлов-исходников собирают. Загляните в их репозиторий.
olegiv2019
23.04.2019 16:26Это понятно — что собирают. Только одни так собирают — другие собирают в более читабельном виде. Для конечного пользователя это все-равно исходный код на js — в который можно вносить любые изменения и без сборки.
Zenitchik
23.04.2019 17:42Для конечного пользователя это все-равно исходный код
Для конечного пользователя — это библиотечный код, который править категорически нельзя, если только ты не решил библиотеку форкнуть.
Если же решил — так возьми исходники, а не сборку, и собери по своему.
А теперь ответьте, нахрена собирать «в более читаемом виде», если никто его читать не будет?olegiv2019
23.04.2019 17:46Понятие «категорически нельзя» само по себе звучит не очень корректно.
Ну, я программистом себя не считаю, поэтому читаю и меняю библиотеки если мне нужно. Желания тянуть содержимое node_modules (несколько сот MБ) ради мелкой правки у меня нет. Если вы посмотрите содержание модулей из которых построена библиотека — увидите, что в собранном файле тот-же код.Zenitchik
23.04.2019 17:59Понятие «категорически нельзя» само по себе звучит не очень корректно.
Именно корректно. Потому что копаться в собранном файле — это извращение.
Для этого можно скачать исходники, которые совсем чуть чуть больше. И копаться в них гораздо удобнее.
Желания тянуть содержимое node_modules (несколько сот MБ)
Так не тяните. Кто Вас просит её со всеми зависимостями тянуть?
Да и потом, даже мегабайт-полтора — это ОЧЕНЬ большой проект. На счёт сотен — вы что-то преувеличиваете.
ради мелкой правки
«Мелкая правка» — это как правило кейс, который лучше делать своей функцией. Просто не используйте библиотечную, если она Вам не нужна.
Если вы посмотрите содержание модулей из которых построена библиотека — увидите, что в собранном файле тот-же код.
Ну, знаете… Тот же… Это как считать два геометрических тела равными, если можно описать аффинное преобразование одного в другое. Никто не запрещает так считать, и если для дела надо — так считают. Но в большинстве случаев…olegiv2019
23.04.2019 18:06Возможно Вы и правы. Но я не знаю как построить проект без зависимостей указанных в package.json.
Про несколько сот MБ немного загнул я конечно — для этой библиотеки всего 72 МБ
Vladek
23.04.2019 13:53Плохой код неизбежен. Если с кодом всё хорошо, то я его не увижу — меня бы не наняли, ведь с кодом всё хорошо и ещё один разработчик не нужен.
dimm_ddr
23.04.2019 14:05Ну необязательно. Если нужно просто добавить новую фичу, значит ли это что код без этой фичи — плохой?
Vladek
23.04.2019 14:38+1В хорошем коде цена добавления новой фичи низкая — не нужно ничего переписывать и переделывать, разбираться или исследовать долго, код сам подсказывает своей организацией где чего добавить, всякая инфраструктура, не относящая напрямую к новой фиче, уже есть и работает — бери и пользуйся.
EvgeniiR
23.04.2019 14:45Хороший код то тоже нужно кому-то писать, да и фич может быть много, они сами по себе могут быть объёмные. Не бывает такого что архитектура, бац, и хорошая, и можно не парится о ней, и рефакторинг никогда не понадобится. Хорошим тоном нынче считается инкрементальная разработка )
Ndochp
23.04.2019 15:45Фичи они разные. И закон Мерфи никто не отменял.
В рабочей жизни я ярко с таким не сталкивался, но в институте влетел в идеальное попадание:
Лаба по хешированию. У разных вариантов — разные функции перебора при коллизии. Я получение задачи проболел, поэтому написал все что нужно с вынесенной в сторону функцией вычисления адреса при коллизии.
Прихожу на зачет в готовность быстренько подправить функцию и сдаться и узнаю свой вариант — «метод цепочек». Упс :(
dimm_ddr
23.04.2019 15:57В хорошем коде цена добавления новой фичи низкая
Какой бы она не была вы вполне можете увидеть код не потому что он плох, а потому что продукт нужно развивать и разработчиков стало не хватать. Я пытался намекнуть именно на это. Но в случае когда нужна новая фича вполне можно сказать что код плохой так как в данный момент не делает того что нужно. И вот чтобы понять так ли вы определяете плохой код или нет я и задал свой вопрос.
Flammar
23.04.2019 15:12Если нужно просто добавить новую фичу
А оно оказывается вдруг раз — и непросто. Причём настолько непросто, что оказывается проще привыкнуть жить без этой фичи.
Arohas
23.04.2019 19:08Статья хорошая в своих, так сказать, посылах, но с одним моментом я не согласен: негатив в оценках как таковой свойственен как раз незрелому уму, и чем опытней и мудрее человек, тем больше он склонен к осторожности в суждениях.
У меня был случай: будучи в командировке, фактически на коленке в условиях цейтнота надо было написать утилиту, её функционал — не суть, там было много алгебры и графики… справился и забыл.
Примерно через год я решил сдуть с нее пыль, отрефакторить и применить, так сказать, для внутренних нужд фирмы. Мои впечатления были на уровне: «господи, что за инопланетянин это сделал?! Как вообще можно было додуматься до такого?». Я реально не мог понять как это работает, и ПОЧЕМУ это работает. В результате просто переписал все с нуля.
Это был какой-то переломный момент в моем мировосприятии. С тех пор, я ни разу не сказал плохого о чужом коде который вижу, даже если он казался мне очень дурным. Хотя, порой думал гневно, да…
dendron
24.04.2019 02:45Вот если бы ещё кто-нибудь рассказал как можно «продать» идею улучшения кодовой базы руководству — цены бы ему не было. С точки зрения бизнеса это выбрасывание денег на ветер.
И вообще, «ты же профессионал, значит должен не ныть о плохом коде, а уметь делать крутые вещи из говна и палок». А если не умеешь — значит ты не профессионал. А если подумаешь сменить работу — то ты просто неудачник, убегающий от вызовов. И вообще, «работать в нашем банке — очень почётно». Кстати, мы вчера уж заключили контракт на поставку термоядерного реактора на нашей суперкрутой технологии Копростикус (tm), так что засучи рукава — и вперёд.vassabi
24.04.2019 11:25+1как можно «продать» идею улучшения кодовой базы руководству — цены бы ему не было. С точки зрения бизнеса это выбрасывание денег на ветер.
надо SJW на это подписать. Типа: «классный код улучшает условия труда угнетенных негров и подавленных женщин, а плохой код — это токсичный маскулинизм и патриархальная культура изнасилования (или оставить rape culture ?) мозга».
И бизнесу продать защиту от угрозы бойкота, остракизма и общественного порицания за их плохой код — улучшение кодовой базы даст благожелательные публикации в лгбтк тусовке, позитивный пиар в фейсбучике и твиттере, и их может даже покажут в cnn и по bbc (но это если они смогут убедить, что их код может понять любой, пардон мой френч, mentally challenged индивидуум или представитель расовых и гендерных общин on medication).
UPD: Вот, как раз отличная цитата в тему:
Ключевой момент здесь, что наши программисты не исследователи. Они, как правило, весьма молоды, идут к нам после учебы, возможно изучали Java, или C/C++, или Python. Они не в состоянии понять выдающийся язык, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен прост для понимания и изучения.
(с) отсюда
Вот, тоже самое, что у меня, но у меня слишком много горечи, а тут так приятно написано.
dimaaan
Поймал себя на том, что читаю это (внутренним) голосом Николя Дроздова :)