Комментарии 110
Проходит время, они набираются опыта и обретают возможность отличить Хороший код от Плохого. И когда этот момент наступает, молодые программисты испытывают огорчение от работы с очевидно плохим кодом. А если они работают в коллективе (дистанционно или очно), то часто перенимают эмоциональные привычки более опытных коллег. Нередко это приводит к увеличению негатива, ведь молодые теперь могут глубокомысленно говорить о коде и разделять его на плохой и хороший, показывая тем самым, что они «в теме». Это ещё больше усиливает негатив: на почве разочарования легко сойтись с коллегами и стать частью группы, критика Плохого кода повышает ваш статус и профессионализм в глазах других: люди, которые выражают негативное мнение, часто воспринимаются как более умные и компетентные.
Поймал себя на том, что читаю это (внутренним) голосом Николя Дроздова :)
TL;DR Объективные вещи нельзя оценивать субъективно.
Это вы про код?
Да. Код объективен, код должен решать какую-то задачу. Гневаться на код это совершенно непродуктивно :)
Код сам по себе объективен. Даже задача, которую надо решить, иногда бывает объективна.
Но код — это решение субъективно воспринятой задачи, которое реализовано через призму субъективных предпочтений и субъективного же опыта программиста.
В моей практике «гневаться на код» — это чаще всего сокращение от «гневаться на то, как кто-то смог так странно понять задачу» и/или «гневаться на то, как кто-то смог так интересно реализовать решение».
Вот этот мифический ктот и вызывает седину, нервный тик и интересные истории на dailywtf. А на код никто и не гневается особо.
Но код — это решение субъективно воспринятой задачи, которое реализовано через призму субъективных предпочтений и субъективного же опыта программиста.
В моей практике «гневаться на код» — это чаще всего сокращение от «гневаться на то, как кто-то смог так странно понять задачу» и/или «гневаться на то, как кто-то смог так интересно реализовать решение».
Вот этот мифический ктот и вызывает седину, нервный тик и интересные истории на dailywtf. А на код никто и не гневается особо.
Да, в моей практике это обозначает тоже самое. И любой разработчик может оказаться в роли этого мифического «ктота». Смысла то особо гневаться нет, видишь ошибку — исправь. И тесты этого участка кода тоже исправь. И везде где используется этот код — тоже поправь. А если этот код в пул реквесте то просто отклони и конструктивно обоснуй почему. А сначала гневаться, раздувать проблему а потом расхлебывать последствия, в том числе и со здоровьем, это совершенно непродуктивно :)
А мне думается, что объективна проблема, которую он должен решить. А код — это полёт фантазии разработчика. И он проблему либо решает, либо нет.
Со стороны архитектора есть еще одна сущность: ресурсы, которые код задействует для решения проблемы. А также стоимость его сопровождения.
Вот проблема и ресурсы — относительно объективные метрики, а стоимость сопровождения (как и сам код) — субъективные.
Я так думаю :)
Со стороны архитектора есть еще одна сущность: ресурсы, которые код задействует для решения проблемы. А также стоимость его сопровождения.
Вот проблема и ресурсы — относительно объективные метрики, а стоимость сопровождения (как и сам код) — субъективные.
Я так думаю :)
>«это полёт фантазии разработчика. И он проблему либо решает, либо нет.»
Ну серьёзно? В 2к19 продолжать обсуждать что первично, архитектура или функционал?
Метрик больше, и то что вы решили проблему поставленную бизнесу далеко не означает что вы сделали все хорошо. Я бы очень остерегался разработчиков которые заявляют что код написан повторно только за факт того что он работает
Ну серьёзно? В 2к19 продолжать обсуждать что первично, архитектура или функционал?
Метрик больше, и то что вы решили проблему поставленную бизнесу далеко не означает что вы сделали все хорошо. Я бы очень остерегался разработчиков которые заявляют что код написан повторно только за факт того что он работает
Код объективен как набор байт. Ответ на вопрос "хорошо ли код решает задачу" субъективен, потому что субъективно слово "хорошо".
Вы можете объективно измерить скорость кода, покрытие тестами и даже полноту решения на множестве входных данных.
Но вы не можете объективно измерить простоту поддержки и устойчивость к человеческим ошибкам при изменениях.
Но вы не можете объективно измерить простоту поддержки и устойчивость к человеческим ошибкам при изменениях.
Метрика WTFperLineOfCode?)
А она точно показывает простоту поддержки и устойчивость к ошибкам? Да, понятно, что если цифра в метрике получается большая, то это скорее всего говорит о том что поддерживать и модифицировать код будет тяжко, но вот обратной зависимости скорее нет — даже чистый и очевидный код может быть тяжело поддерживать и менять. Что значит что этой метрики совершенно недостаточно. Плюс она совершенно субъективна — один программист не поймет что происходит потому что у него нет опыта, второй — потому что он думает другими паттернами, третий решит что поймет и ошибется, четвертый поймет. При этом код может быть как плохим, так и хорошим. Понятность кода вообще не может быть объективной метрикой просто по определению.
Для этого нужен калиброванный прогер в палате мер и весов, что б по нему настраивать. Иначе она будет плавать от отдела к отделу, ненадёжно.
Особенно учитывая, что лет через 10 он сможет вспомнить это, обидеться, прийти к тебе домой и настучать железной клешнёй по башке.
Радикально не соглашусь.
Код объективен лишь в том, что он, будучи скомпилированным работает и решает задачу.
Хотя в сложных кейсах и это не очевидно — редактор со сложным интерфейсом «решает» задачу редактирования, но насколько эффективно, если пользователям тяжело его понимать?
Код пишется не только для компьютеров, но и для людей.
С точки зрения разработчика все варианты решения задачи и оформления кода для этого решения — глубоко субъективны. Разные люди по разному поймут этот код, будут испытывать проблемы с пониманием в разных местах, могут считать разные места важными или не важными, по разному будут его менять. Субъективны так же варианты расширения и изменения кода при развитии — ведь они опираются на субъективные требования (пример с интерфейсом) и субъективное понимание текущей работы кода.
Гневаться на код разумеется не продуктивно, но «ругать» странную логику, плохое форматирование, сложность чтения и т.д. для того, чтобы этого избежать — вполне продуктивно.
Усилия по улучшению кода, направленные на понимание кода в будущем и разными членами команды — оправданны.
Код объективен лишь в том, что он, будучи скомпилированным работает и решает задачу.
Хотя в сложных кейсах и это не очевидно — редактор со сложным интерфейсом «решает» задачу редактирования, но насколько эффективно, если пользователям тяжело его понимать?
Код пишется не только для компьютеров, но и для людей.
С точки зрения разработчика все варианты решения задачи и оформления кода для этого решения — глубоко субъективны. Разные люди по разному поймут этот код, будут испытывать проблемы с пониманием в разных местах, могут считать разные места важными или не важными, по разному будут его менять. Субъективны так же варианты расширения и изменения кода при развитии — ведь они опираются на субъективные требования (пример с интерфейсом) и субъективное понимание текущей работы кода.
Гневаться на код разумеется не продуктивно, но «ругать» странную логику, плохое форматирование, сложность чтения и т.д. для того, чтобы этого избежать — вполне продуктивно.
Усилия по улучшению кода, направленные на понимание кода в будущем и разными членами команды — оправданны.
Он должен не только работать, он ещё должен быть готов к изменениям в дальнейшем. Рабочий код может написать практически любой, а вот рабочий код, готовый к будущим изменениям — может написать далеко не каждый.
del
Крик души удалил… Ибо нельзя их (ПО по которому крик души) критиковать
Плохое это плохо, а хорошее — хорошо. С вас 1000 рублей.
Ох чёрт, я пока читал хотел нарисовать эту самую path of zen. Я сейчас на стадии уменьшения гнева и это чертовски приятно.
Ключевое, о чём критики "негатива" часто забывают:
Со временем разработчики начинают смиряться с тем, что плохой код — реальность программного обеспечения, и что их работа заключается в том, чтобы его улучшить. И что если нельзя избежать плохого кода, то и нет смысла поднимать из-за него шум.
Если плохого кода избежать можно — то и шум поднимать тоже можно.
Можно избежать какими усилиями, стоит ли оно того? Шум в виде негатива реально поможет лучше чем что-то более нейтральное? Этот плохой код вообще нужно ли избегать?
Я допускаю что есть случаи когда ответ на все эти вопросы — да. Но мне кажется что таких случае на пару порядков меньше чем случаев где негатив используется и где его хотят использовать фанаты негатива.
Я допускаю что есть случаи когда ответ на все эти вопросы — да. Но мне кажется что таких случае на пару порядков меньше чем случаев где негатив используется и где его хотят использовать фанаты негатива.
Ну статья про то, что не нужно возводить это в абсолют, и шум должен быть оправдан, а не вырождаться в срач и оскорбления.
Важно и то, что код читать сложнее чем писать в принципе. Поэтому любой прочитанный код зачастую хуже, чем написанный.
Важно и то, что код читать сложнее чем писать в принципе. Поэтому любой прочитанный код зачастую хуже, чем написанный.
Имхо, не должны быть «дикие» review, можно написать какие-то полиси, ввести best practices, отчетливо пропагандировать чистоту и правильность кода, устанавливая это в качестве стандарта. В таком случае при ревью можно оценку декларировать не как твое личное «негативное» мнение, а несоответствие принятым нормам и стандартам. Это во-первых позволяет исключить негатив, когда один человек, считает, что до него докапываются, а второй собственно докапывается, а во-вторых делает сам процесс несколько обезличенным. Условно ревьюер выступает в качестве веб-формы куда ты заливаешь свой код, а она тебе отвечает — переделай, с должной степенью подробностей )
Проблема чаще всего в том, что формализовать процесс подчас сложно и никто не хочет этим заниматься.
Проблема чаще всего в том, что формализовать процесс подчас сложно и никто не хочет этим заниматься.
Негатив столь важен для программистов потому, что это очень эффективный способ передачи ценности ©.
Жаль только, многие люди неспособны увидеть разницу между «эффективным способом передачи ценности» = конструктивной критикой и обычным хамством.
Жаль только, многие люди неспособны увидеть разницу между «эффективным способом передачи ценности» = конструктивной критикой и обычным хамством.
начал читать. вижу
первая мысль: «я один такой, кто вообще не обращал внимание на реакцию других людей, когда начинал учиться программированию?
Или это очередное влияние „давайте все вместе возьмемся за руки и будем вместе бороться с воображаемой токсичностью“ (вместо того, чтобы писать код) ?»
…
продолжаю читать дальше — и да, все так и есть:
(особенно умилило про твиттер)
Когда мы начинаем впервые учиться программированию, наше представление о глубине «опыта программирования» основывается на наблюдениях за эмоциональными реакциями других людей.
первая мысль: «я один такой, кто вообще не обращал внимание на реакцию других людей, когда начинал учиться программированию?
Или это очередное влияние „давайте все вместе возьмемся за руки и будем вместе бороться с воображаемой токсичностью“ (вместо того, чтобы писать код) ?»
…
продолжаю читать дальше — и да, все так и есть:
В инженерных организациях всё популярнее становится правило «Никаких овнюков». В Твиттере появляется всё больше анекдотов и историй про людей, которые покинули эту профессию потому, что не смогли (не захотели) и дальше мириться с враждебностью и недоброжелательностью по отношению к посторонним.
(особенно умилило про твиттер)
Большое спасибо за статью.
Если к каждому «плохо написанному коду», прикреплять тэг «написано джуном», то гнев может смениться если не на милость, так на снисхождение уж точно. Но кто возьмёт менторство над неумехой, и будет взращивать себе конкурента? Или же тот окажется достойным ему коллегой и другом после затраченных сил и времени?
Сложные вопросы, требующие больших вычислительных мощностей и опыта, уступают тому, чтобы просто «пометить» чувачка рукопопым…
Всегда есть Мы, и будут Они, а вот алгоритм определения этих самых Наши и Ваши у каждого свой, на основе опыта, психо-типа и ещё кучи факторов которые не так просто предопределить…
Сложные вопросы, требующие больших вычислительных мощностей и опыта, уступают тому, чтобы просто «пометить» чувачка рукопопым…
Всегда есть Мы, и будут Они, а вот алгоритм определения этих самых Наши и Ваши у каждого свой, на основе опыта, психо-типа и ещё кучи факторов которые не так просто предопределить…
я наверно старомоден, однако я до сих пор не делю людей на «Наши и Ваши», а делю код на тот, который можно сделать лучше и тот, который нужно сделать лучше.
И единственное разделение людей возникает разве что в виде: люди, которые могут улучшить свой код VS люди, которые вместо улучшения своего кода начинают заниматься межличностными отношениями от «меня обидели» до «они против нас»…
И единственное разделение людей возникает разве что в виде: люди, которые могут улучшить свой код VS люди, которые вместо улучшения своего кода начинают заниматься межличностными отношениями от «меня обидели» до «они против нас»…
делю код на тот, который можно сделать лучше и тот, который нужно сделать лучше.
Я правильно понял, что для Вас приемлемого кода просто не существует?
Выглядит так, будто ревью у Вас не сможет пройти без замечаний ни один человек, выложи он на ревью хоть симфонию.
А потом вы удивляетесь на реакцию коллег вида:
вместо улучшения своего кода начинают заниматься межличностными отношениями от «меня обидели» до «они против нас»
Я правильно понял, что для Вас приемлемого кода просто не существует?Я разделяю позицию предыдущего комментатора (про можно или нужно улучшать код) и я лично вижу это так: идеального кода практически не существует, особенно если смотреть на код во времени, а не только в момент код ревью (ну то есть поддержка, модификации, вот это вот все). Но приемлимого кода более чем достаточно, нужно просто понимать что код не идеален и его можно улучшить. Прекрасно когда понятно как его можно улучшить и чего это будет стоить — это просто идеальная ситуация. Обычно это не совсем так к сожалению.
Но то, что код всегда можно улучшить не значит что все эти возможности надо писать в ревью как замечания. ЧТо-то можно написать как комментарий на будущее — на случай если мы получим от клиента бюджет на улучшение этой фичи. ЧТо-то — просто оставить при себе (например если улучшение неоднозначно или объяснение почему так лучше займет чем можно потенциально выиграть от собственно изменения). Что-то выписать и потом обсудить на очередном воркшопе или другой активности.
Я правильно понял, что для Вас приемлемого кода просто не существует?
Приемлимый — существует конечно же. Вот идеального — нет. Причем не для меня не существует, а вообще не существует (выше комментатор вам уже в принципе ответил).
В принципе — улучшить-то можно любой код, просто это будет иметь слишком большие затраты на цену\время разработчика. Но если качество кода отрицательное (явные баги или нарушения кодстандарта) или его можно улучшить быстро (или выгода от улучшения высока — ака рефакторинг техдолга), то почему бы не сказать об этом на код ревью?
(и тут мы переходим к 2й части)
А потом вы удивляетесь на реакцию коллегя не удивляюсь, я во-первых всегда говорю о коде, а не об авторе кода, а во-вторых, от людей с такими реакциями на кодревью лучше вежливо но твердо прощаться до конца испытательного срока (на то ведь он и испытательный).
PS: впрочем, в моей практике таких случае не было ни одного, несмотря на пол и возраст коллег.
Я видел команды, где с кодом (и, соответственно, с проектом) все было плохо, но где все были спокойны. Это напоминает поезд, который едет в пропасть, все пассажиры которого видят этого, но совершенно спокойны (а точнее им все равно — умрет один стартап — через неделю их возьмут в другой).
Для меня эмоции — это показатель того, что человек не равнодушен к тому, чем занимается.
Не переношу такие «тонкие намеки».
Для меня эмоции — это показатель того, что человек не равнодушен к тому, чем занимается.
И всё это он сказал мне очень по-доброму, и в завершение сказал, что если я действительно испытываю такие чувства, то мне, вероятно, нужно обдумать, чего же я желаю для себя и своей карьеры. Это была невероятно мягкая беседа в стиле «возьми себя в руки или выметайся»
Не переношу такие «тонкие намеки».
НЛО прилетело и опубликовало эту надпись здесь
Если поезд идет в пропасть — можно или собраться с мыслями, успокоиться и найти решение. Или обвинять окружающих в плохом коде и в том, что они не умеют писать.
А если человек интроверт? Такие могут переживать глубоко внутри, а снаружи быть спокойными, как скала.
Честно — я тоже. Но после того, как эмоции откипели — я стараюсь взглянуть на это объективно. И я однозначно предпочту СЕО, который «по-доброму», но спокойно объяснит, в чем я неправ, вместо СЕО, который начнет кричать на ровном месте, и в лучшем случае услышит два слова из пяти, сказанных тобой.
Я поддерживаю автора и считаю, что негатив неконструктивен.
Но также, мы должны помнить, что:
«Нет правил без исключений»))
Для меня эмоции — это показатель того, что человек не равнодушен к тому, чем занимается.
А если человек интроверт? Такие могут переживать глубоко внутри, а снаружи быть спокойными, как скала.
Не переношу такие «тонкие намеки».
Честно — я тоже. Но после того, как эмоции откипели — я стараюсь взглянуть на это объективно. И я однозначно предпочту СЕО, который «по-доброму», но спокойно объяснит, в чем я неправ, вместо СЕО, который начнет кричать на ровном месте, и в лучшем случае услышит два слова из пяти, сказанных тобой.
Я поддерживаю автора и считаю, что негатив неконструктивен.
Но также, мы должны помнить, что:
«Нет правил без исключений»))
Почему вы противопоставляете «CEO «по-доброму»» и «СЕО кричать на ровном месте»? А если кричит не на ровном месте, а на развалинах, вами устроенных, то это всё равно хуже, чем начальник «по-доброму» с повадками босса мафии?
Кричать — это не конструктивно. Это не решит проблему. Первое и главное — это решить проблему. Второе — это подумать, как сделать, чтобы подобное не повторилось. Обычно крик — это способ, которым неадекватные начальники снимают напряжение, скидывая его на подчиненных. Если вам нравится, когда на вас кричат — это ваш выбор и ваше право, вы можете работать с таким начальником.
По поводу повадок «Босса мафии»… я не помню, чтобы я упоминал что-то про: «в лес и закопать». Я говорил, что я предпочитаю адекватного человека, который спокойно объяснит в чем проблема.
Уточню: я понимаю, что есть исключения и вывести из равновесия можно даже самого спокойного человека, если это был серьезный факап, но такие случаи я сейчас не рассматриваю. Я говорю об обычном рабочем процессе.
По поводу повадок «Босса мафии»… я не помню, чтобы я упоминал что-то про: «в лес и закопать». Я говорил, что я предпочитаю адекватного человека, который спокойно объяснит в чем проблема.
Уточню: я понимаю, что есть исключения и вывести из равновесия можно даже самого спокойного человека, если это был серьезный факап, но такие случаи я сейчас не рассматриваю. Я говорю об обычном рабочем процессе.
Я видел команды, где с кодом (и, соответственно, с проектом) все было плохо, но где все были спокойны. Это напоминает поезд, который едет в пропасть, все пассажиры которого видят этого, но совершенно спокойны (а точнее им все равно — умрет один стартап — через неделю их возьмут в другой).Вспоминаю чьё-то противоположное высказывание, что лучший по качеству код он видел в мёртвых стартапах.
Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке программирования — более масштабируемом по размеру мощностей серверов, размеру кодовой базы и размеру команды разработчиков, но при этом с в разы меньшей производительностью программиста по части количества реализованных «фич» в единицу времени — типа Java.
Вообще, наибольший акцент на качестве кода я встречал в оффшорном программировании — «мы должны писать более качественный код, чем сам заказчик». Что само по себе понятно. Но это отдельная сфера.
Стартапы умирают не от плохого качества кода. Они вообще в 90+% случаев умирают, и это нормально. От плохого качества кода умирают проекты, которые давно пережили фазу стартапа, но которые в период очередного кризиса оказались недостаточно привлекательными для программистов в качестве предмета приложения своих сил. Как известно, «бабло побеждает зло», но в такие периоды количество бабла оказывается ограниченным, а унаследованного зла может оказаться слишком много.
Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке программированияМне это утверждение кажется не менее сомнительным чем разговоры про необходимость все делать правильно с самого начала. Когда-нибудь, когда стартап станет большой компанией с хотя бы еще парой основных продуктов благодаря деньгам от которых можно позволить себе вместо развития несколько лет переписывать уже работающее, но я не уверен что есть много примеров когда это реально сработало. У меня никогда не было стартапов, так что это чистое теоретизирование конечно, но разве после того как стартап выстреливает его гонка с конкурентами заканчивается? Вон, Netscape когда его решили переписать более чем успешен был и чем это закончилось?
Почему «вместо»? Параллельно, денег на R&D хватит.
Вон, Netscape когда его решили переписатьТогда MS выпустили бесплатный браузер IE и всё, модель монетизации поменялась на ходу. Когда подстроились, сделали Mozilla Firefox, но это уже была другая эпоха.
Почему «вместо»? Параллельно, денег на R&D хватит.И этот вариант также сомнителен. Переписать главный продукт с которого идут деньги целиком, при этом продолжать получать с него достаточно денег чтобы еще и на R&D хватило — я не знаю возможно ли такое вообще. И даже если возможно, то необходимо сравнить с альтернативой — когда первый продукт не переписывается, а все деньги идут на новые продукты или дальнейшее улучшение старого. Совершенно неочевидно что ваш вариант лучше.
Если стартап «выстрелит», то найдутся деньги, чтоб его код просто переписать на другом языке
Что-то мне подсказывает, что если стартап выстрелит, времени не будет ни на что, а бэклог будет трещать по швам от вала фич, которые нужно запилить ещё вчера, потому что их презентовали в MVP :)
Для меня эмоции — это показатель того, что человек неравнодушен к тому, чем занимается.
Да, но вот вопрос, зачем? Почему надо быть «неравнодушным»?
После двух лет «неравнодушия», вытягивания проекта с первой строчки кода до ситуации, когда сами Циско интересуются моим детищем через бессонные вечера, пытаясь успеть в самом ограниченом бюджете быть и программистом и тимлидом и продактом; с дуновением ветра отношение ко мне поменялось на того самого «негативного» технаря, который мешает бизнесу. А вот равнодушных фрилансеров, которые просто просили большую цену и делали работу уважают так как прежде. Так может нам (как минимум мне) пора начинать учиться? Просто плюнуть на всё, брать соответсвующие деньги за свою работу и не давать ей влезать в эмоциональную сферу, ведь в конечном итоге этими эмоциями мы вредим всем, и компании и менеджменту и себе. И если менеджеры хотят чтобы жизнь людей полагалась лишь на один датчик, то надо сообщить о проблеме, а если вас не послушали и совесть дороже проблемы — просто уволиться.
Да, но вот вопрос, зачем? Почему надо быть «неравнодушным»?
Тоже постоянно задаю себе этот вопрос. Что может быть проще — делать только то, что нужно, чтобы закрыть очередной таск в жире, и ни капли больше — не рефакторить, не находить и исправлять ошибки в чужом коде, не поднимать в команде темы «давайте работать качественней» и т.д.
Но в тоже время, как только я начну так работать — я перестану уважать свой труд.
На мой взгляд (дилетанта в разработке ПО — каковым я себя считаю) -«плохой/хороший» — формулировки ни о чем. Есть задача — если она выполняется согласно ТЗ — значит все замечательно. Все вопросы к составителям ТЗ на разработку ПО.
Есть задача — если она выполняется согласно ТЗ — значит все замечательно. Все вопросы к составителям ТЗ на разработку ПО.
А после нас хоть потоп, да, главное что в карман денежка упала, а когда у бизнеса проблемы будут можно и другую работу найти.
Как вы в требованиях опишите поддерживаемый код?
А за поддерживаемый код никто платить не собирался, извините
Да, это очень печальный момент, желания и требования заказчика, по крайней мере в том виде, в котором они понимаются исполнителями, далеко не всегда совпадают с тем что ему действительно нужно. С похожими мыслями я, кстати, писал вторую свою статью на хабр, хотя вряд ли я донес их хорошо.
Мне как разработчику хочется нести ответственость за свой код и стараться сделать его лучше. И мои интересы, как разработчика, не всегда совпадают с тем что хочет диктовать заказчик, и тут нужно искать компромиссы.
Мне как разработчику хочется нести ответственость за свой код и стараться сделать его лучше. И мои интересы, как разработчика, не всегда совпадают с тем что хочет диктовать заказчик, и тут нужно искать компромиссы.
«а когда у бизнеса проблемы» — об этом должен думать не рядовой программист, а тот кто руководит командой программистов и соответственно согласовывает ТЗ с тем кто ставит задачу
«Как вы в требованиях опишите поддерживаемый код?» — это все хорошо формализуется
Хотя грех спорить с тем, что код дожен быть «читабельным» и т.д. При этом хочу отметить — что любой человек пытается решить задачу с наименьшими энергозатратами
«Как вы в требованиях опишите поддерживаемый код?» — это все хорошо формализуется
Хотя грех спорить с тем, что код дожен быть «читабельным» и т.д. При этом хочу отметить — что любой человек пытается решить задачу с наименьшими энергозатратами
«а когда у бизнеса проблемы» — об этом должен думать не рядовой программист, а тот кто руководит командой программистов
Об этом должны думать все, но код пишет программист, и если программист не думает как сделать хорошо он и не сделает хорошо.
«Как вы в требованиях опишите поддерживаемый код?» — это все хорошо формализуется
Вот это интересно. Допустим задал я программисту интегрироваться с новым почтовым сервисом, как формализовать требования к качественному коду?
Не говоря уже о том что не бывает однозначно хорошего и однозначно плохого кода, т.к. в разных ситуациях один и тот же код может быть как хорошим так и не очень, как проверить что программист задумывался об архитектуре, советовался с бизнесом о возможных дальнейших изменениях, даже банальные штуки как направление зависимостей, сложность методов, предлагаете заказчику во все это вникать?
Все это действительно хорошо формализуется и часто хватает даже беглого взгляда по диагонали что бы примерно понять качество кода, но! Представителям заказчика не нужно качество кода. Им нужно решение задачи за меньшие деньги и меньшее время. За это они получат премии, медальки и печеньки. А на остатки ФОТ от премий, медалек и печенек джуны на пол ставки будут запиливать код как бог на душу положит лишь бы только заработал к часу Х и всех занятых в процессе такая ситуация устраивает. Потому что печенки и медальки они вот, а на то что проект выстрелит никто вообще то и не рассчитывал.
Уже после появится Программист который скажет — «что за лажа!? кто так пишет?». Но он появится на временной шкале жизни проекта много позже, поэтому высказывания и желание его вернуть печенки и медальки эффективных менеджеров в замен на хороший код (потому что денег ему лично выделили за работу как будто код хороший, а не куча гумуса) смысла не имеют. А имеет смысл только повышение его, Программиста, зарплаты на переписание всего этого. Говнокод рождается по объективным причинам и в первую очередь сам заказчик и является этой причиной.
Уже после появится Программист который скажет — «что за лажа!? кто так пишет?». Но он появится на временной шкале жизни проекта много позже, поэтому высказывания и желание его вернуть печенки и медальки эффективных менеджеров в замен на хороший код (потому что денег ему лично выделили за работу как будто код хороший, а не куча гумуса) смысла не имеют. А имеет смысл только повышение его, Программиста, зарплаты на переписание всего этого. Говнокод рождается по объективным причинам и в первую очередь сам заказчик и является этой причиной.
Все это действительно хорошо формализуется и часто хватает даже беглого взгляда по диагонали что бы примерно понять качество кода,
Не совсем так… Формализуются лишь совсем простые условия, типа проверить не лепятся ли 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.
Ну и ещё интересный и очень печальный момент — люди могут делать плохо, иметь от этого проблемы, и действительно не замечать их, точнее, принимать асболютно как должное, т.к. ни у кого ещё не было опыта реализации даного функционала, а процесс обмена знаниями, как минимум в нашей сфере, на мой взгляд, построен, весьма не очень.
Абсолютно согласен. Заказчиков, закладывающих эти нюансы в бюджет на этапе проектирования мне хватит двух пальцев пересчитать. Заказчиков, закладывающих в процесс жизни кода его хотя бы периодический ревью на оптимальность — одного. При этом же очевидно что существуют силы которые из приличного кода/архитектуры будут стремиться сделать код неприличным.
Ну да, а потом открываешь profiler и понимаешь, что замечательный код ( он выполняет все требования ТЗ) при обновлении 1 поля обновляет всю таблицу теми же значениями, что и были. И одним новым, да.
И в этом случае для конкретной команды нормально подойти и сказать — «взгляните, у вас тут какое-то говно творится, можете пофиксить?»
И в этом случае для конкретной команды нормально подойти и сказать — «взгляните, у вас тут какое-то говно творится, можете пофиксить?»
В таком случае получается, что ТЗ призвано быть «серебряной пулей», решающей все проблемы раз и навсегда, иначе — «все вопросы к составителям ТЗ на разработку ПО».
Да нет конечно «раз и навсегда» — не бывает. Я всего лишь хотел сказать, что как поставлена задача — так и будет она решаться. Если нужно быстрее и сейчас — это одно, если перспектива — это другое. И программисту вовсе нет дела до перспективных планов компании — заказчика — это задача компетентного менеджера.
Есть задача — если она выполняется согласно ТЗ — значит все замечательно. Все вопросы к составителям ТЗ на разработку ПО.
В теории — да, на практике жизнь выдает такое, что волосы встают дыбом:
Сделал задачу в жире. Под конец оказывается, что задача была написана некорректно — значительную часть работы можно было не делать. Начальник, узнав это, попытался вину скинуть на меня — мол это я, получив задачу, должен уточнять, действительно ли она такая, как написано.
На что начальник был послан лесом, а я отправился искать новую работу)
Большая часть управляющих менеджеров недостаточно компетентны (назначенные по всем известным причинам на свои должности) — как следствие — неэффективная деятельность таких компаний (а таких компаний, особенно в госсекторе — большинство) — это печально.
«Посылать лесом» конечно не эффективно с любой точки зрения, но иногда конечно, трудно бывает сдержаться. Мои знакомые программисты (и не только) обычно в таких случаях уходят молча (без внешних эмоций) с текущего места работы.
«Посылать лесом» конечно не эффективно с любой точки зрения, но иногда конечно, трудно бывает сдержаться. Мои знакомые программисты (и не только) обычно в таких случаях уходят молча (без внешних эмоций) с текущего места работы.
У меня был хрестоматийный пример. Продуктовая компания, отдел разработки поделён на 3и команды, 2е самодостаточные команды которые пилят фичи и команда поддержки, которая латает всплывающие баги и смотрит легаси.
В первой команде разработки тимлид был «токсичным нытиком» из статьи, во второй спокойно реагировал на проблемы или косяки. Угадайте, какая команда была продуктивней?..
А никакая. Обе команды запиливали фичи схожей сложности, тратя при этом схожее время.
А в чём мораль? А в том, что во второй команде рабочий климат был гораздо лучше. И если нет разницы продуктивности, зачем мотать нервы?
В первой команде разработки тимлид был «токсичным нытиком» из статьи, во второй спокойно реагировал на проблемы или косяки. Угадайте, какая команда была продуктивней?..
А никакая. Обе команды запиливали фичи схожей сложности, тратя при этом схожее время.
А в чём мораль? А в том, что во второй команде рабочий климат был гораздо лучше. И если нет разницы продуктивности, зачем мотать нервы?
Есть разница между идеями «сделать так, чтобы работало» и «сделать правильно». Мне мои заказчики через 7 лет звонили, говорили что работает. Правильно ли было сделано? — не задумывался. Если работает, — значит правильно.
Интересно, какая доля написанного кода сможет прожить семь лет?..
глядя в бездну кровавого энтерпрайза, могу сказать что от 5% (активная разработка) и до 99% (никакой активности, 1 человек в саппорте максимум).
Я когда-то работал в небольших конторах, когда ты на проекте царь и бог. Тогда это было возможно.
Сейчас с трудом это можно представить — настолько все куда-то едет и плывет. Программист превратился в гребца на галере, которым погоняют какие-то гуманитарии.
Сейчас с трудом это можно представить — настолько все куда-то едет и плывет. Программист превратился в гребца на галере, которым погоняют какие-то гуманитарии.
… странно, я последние три года ушел от стартаперов и работаю на корпорации в адовом лигаси (код 1994 года рождения, первый автор — не программист по профессии). Но, никто не против, чтобы я взял и переписал хоть слева-направо хоть справа-налево — так что, если не бог, то уж царь на проекте. Денег и времени конечно нет, но в стартапах их тоже нет (денег там если и есть — то на найм людей, которые пишут не в вашем проекте). Зато с дедлайнами никто не дышит в спину.
Вот так потихоньку пишешь код — и будешь уверен, что он там до следующего десятилетия будет работать.
Вот так потихоньку пишешь код — и будешь уверен, что он там до следующего десятилетия будет работать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Это так не работает. Я буду трогать даже если работает, так как мне интересно разобраться и исправить. Иногда мои мысли идут в сторону производительности и я буду трогать. Вам как раз таки нужно смириться с этим, что будут трогать то, что работает. Ломать будут это, уничтожать, если появиться соответствующее желание. Жизнь ежедневно ломает все ваши смыслы и устои, а вы продолжаете сопротивляться негативу, разрушению и с этим всё нормально.
Дзен для вас всех лишь очередная идея, так как вы направляете внимание на идеи, а не на то, кем вы являетесь. Вы только и подшучиваете над дзеном, и вставляете его как крылатые выражения вроде «мир во всём мире», приплетаете его когда надо и не надо.
Дзен для вас всех лишь очередная идея, так как вы направляете внимание на идеи, а не на то, кем вы являетесь. Вы только и подшучиваете над дзеном, и вставляете его как крылатые выражения вроде «мир во всём мире», приплетаете его когда надо и не надо.
Это так не работает. Я буду трогать даже если работает, так как мне интересно разобраться и исправить.Это ваше личное качество. И на мой взгляд это качество скорее отрицательное, а не положительное. Если конечно вы тратите на это рабочее время (я сейчас не говорю про случай когда рефакторинг делается для разгрузки мозга и своеобразного отдыха, такое тоже бывает). Именно из этого качества и появляются идеи «а давайте все перепишем с нуля», преждевременная оптимизация и ловля блох. Нужно решать реальные проблемы, а не просто интересные. Это практически как искать потерянную вещь под фонарем, а не там где потерял — гораздо приятнее, но результат так себе.
Реальные проблемы сложно решить, если ты их не видишь.) Спросите у любого программиста, и он скажет что это нормально писать код в виде текста в тестовом файле. И это при той технологической мощи, которая у нас есть на Земле сейчас. Так уже десятками лет код пишут. Журналист и программист используют один и тот же метод ввода информации. Ту же клавиатуру и мышь или тачпад. Вы не находите в этом реальной проблемы или противоречия?)
НЛО прилетело и опубликовало эту надпись здесь
Сколько же стереотипов можно вскрыть простым комментарием… Вы только почитайте свой коммент. Как различно люди видят то, что я написал.
а потом вдруг ВНЕЗАПНО оказывается что такая перезапись не изменившихся данных попадает в очередь на репликацию и кладет ее полностью при вроде бы не сильно увеличившейся нагрузке.
пример из жизни если что, не сотни миллионов конечно, но достаточно серьезный продакшн
пример из жизни если что, не сотни миллионов конечно, но достаточно серьезный продакшн
трогайте, только тестами обложите сначала и метриками. Чтобы было видно — улучшилось ли что-то и насколько.
Я только «ЗА» за такое трогание кода — может, потенциально оптимизирующая идея и не прокатит, зато тесты и испытательный конфиг — вот они.
Я только «ЗА» за такое трогание кода — может, потенциально оптимизирующая идея и не прокатит, зато тесты и испытательный конфиг — вот они.
Интересная мысль. Не смотрел под таким углом.
Вопрос зачастую стоит не так: работает/не работает, быстро/медленно. Вопрос стоит так: нужно добавить один параметр к двум сотням существующих, не затронув их работы, а в коде черт ногу сломит. И цена минимального изменения — ревью всей функциональности, создание нового ТЗ, согласование со всеми смежными отделами, переписание на поддерживаемый код, тестирование переписанного.
Все это рождает массу вопросов взаимодействия с коллегами, с заказчиком, с партнерами. Заказчика надо убедить выделить ресурсы на это. Выделить тестировщиков, время. На пустом месте. Ваше положение становится шатко, рисуются работы в выходные, дэдлайны, сданные билеты в турцию, ссора с женой, испорченные каникулы детей и т.д. Это непосредственная причина негатива, а не «худший в мире код».
Все это рождает массу вопросов взаимодействия с коллегами, с заказчиком, с партнерами. Заказчика надо убедить выделить ресурсы на это. Выделить тестировщиков, время. На пустом месте. Ваше положение становится шатко, рисуются работы в выходные, дэдлайны, сданные билеты в турцию, ссора с женой, испорченные каникулы детей и т.д. Это непосредственная причина негатива, а не «худший в мире код».
НЛО прилетело и опубликовало эту надпись здесь
По моему опыту эта картина описывает 90% всего рынка программизма РФ.
Для того что бы все это получить достаточно тысячи талантливых строк. Немного измененный реальный пример: Драйвер считывания показателей счетчика. Код на пару тысяч строк написанных джуном. Все работает. Все завязано на производственные процессы трех отделов снимающих оперативную инфо по десятку параметров. Поступает задача увеличить дискретность съема данных в 2 раза. Начали разбор. Код написан с ошибками. Случайным образом они не фатальные, а на уровене погрешности. Увеличить дискретность нельзя. Переписание его — не повторишь ошибок округления и все такое. ТЗ процесса нет, есть куча денежной отчетности сути которой никто в деталях не понимает, но «изменять нельзя» т.к. санкции за изменение показателей. Опять же ретроспектива, отчеты должны выдавать те же данные при обращении к прошлым снятым показателям. Программист настаивает на создании ТЗ и полноценном тестировании с обнулением всего этого гумуса. Отделы на: «работало не трожь! вас же всего только просили снимать в 2 раза чаще!». Задача в итоге (внимание!) не решилась. Ибо не имела решения в котором все бы были довольны. А вы миллионы строк.
А как так получилось? Да элементарно, когда драйвер писали никто не думал что на его данных будут завязаны какие то серьезные процессы. Отдали джуну.
Для того что бы все это получить достаточно тысячи талантливых строк. Немного измененный реальный пример: Драйвер считывания показателей счетчика. Код на пару тысяч строк написанных джуном. Все работает. Все завязано на производственные процессы трех отделов снимающих оперативную инфо по десятку параметров. Поступает задача увеличить дискретность съема данных в 2 раза. Начали разбор. Код написан с ошибками. Случайным образом они не фатальные, а на уровене погрешности. Увеличить дискретность нельзя. Переписание его — не повторишь ошибок округления и все такое. ТЗ процесса нет, есть куча денежной отчетности сути которой никто в деталях не понимает, но «изменять нельзя» т.к. санкции за изменение показателей. Опять же ретроспектива, отчеты должны выдавать те же данные при обращении к прошлым снятым показателям. Программист настаивает на создании ТЗ и полноценном тестировании с обнулением всего этого гумуса. Отделы на: «работало не трожь! вас же всего только просили снимать в 2 раза чаще!». Задача в итоге (внимание!) не решилась. Ибо не имела решения в котором все бы были довольны. А вы миллионы строк.
А как так получилось? Да элементарно, когда драйвер писали никто не думал что на его данных будут завязаны какие то серьезные процессы. Отдали джуну.
Результат её работы корректен? Если да, не трогай. Если нет, исправь.К сожалению, этот принцип сегодня не работает: трогать код придётся в любом случае, и довольно рано: требования заказчика меняются на лету. Поэтому приходится создавать код, устойчивый к «троганиям». Можно, конечно, попытаться принудить заказчика написать более внятное ТЗ, такое, чтоб «один раз и на всю жизнь», чтоб программу никогда не пришлось изменять, и отказывать от работы с заказчиками, не желающими писать такое, но это обычно менее реально, чем писать код, приемлемо устойчивый к изменениям.
Я никогда не забуду, как коллега ругал меня за то, что я положил CSS не в тот файл, меня это расстроило и не давало собраться с мыслями несколько днейУти пусенька. А чо тогда не «у меня начался ПТСР, я начал пить, потерял дом, жену, работу, после чего оказался на улице, меня подобрал добрый дядя психиатр, выписал таблетки, которые я должен был распространять на районе, после чего я понял, что дальше так продолжаться не может и самоутопился в тазу, пяшу с таво свету»?
На мой вкус, любому, кто вообще использует слово «токсичный» (в любом контексте), следует прописывать 50 ударов розгами. Мне интересно, как эти девочки-снежинки вообще выдерживают ментальные нагрузки, необходимые для переламывания собственного разума супротив логики, когда приходится поддерживать какую-то дикую застарело-засохше-зацвётшую вермишель.
И ладно бы тебе просто дали задачу по поиску бага в каком-то страшном и странном. Обычно ведь всё это происходит в самый неподходящий момент, бизнес терпит убытки и тебе в этой нервной обстановке, когда как раз-таки белки-истерички суетятся и мешают работать, нужно перелопачивать и прогонять через себя огромные объёмы маразматичного бреда, чтобы найти баг и починить его. Сколько ещё багов кроется в этой вермишели — неизвестно, но в следующий раз или ты, или кто-то после тебя, точно так же занырнёт в эту зловонную жижу, вместо того, чтобы раз и навсегда отрефакторить это всё и вычистить большое количество потенциальных проблем, повышая и стабильность в целом, и скорость поиска новых багов, понижая входной порог для поддержки. Но на потенциальное у них времени и денег нет. Авось пронесёт. А кем вы себя видите через пять лет в таких условиях?
Зато эффективные менеджеришки конечно же получат премии за быстрофикс, читай, овертаймовое насилие над тобой и потерянные деньги для бизнеса, при том, что этого можно было изначально избежать, корректно формулируя требования и учитывая свои возможности. И вот именно это бесит. Проблема (в управлении) не решается. Даже следствие этой проблемы — плохой код, который перерастает в плохой легаси код. И в один прекрасный момент это всё с грохотом рушится, погребая под собой всех. А виноват, конечно же, последний притрагивавшийся к этому программист.
После пары нервных забегов, у тебя образуется резко негативное отношение к плохому коду. Потому что не он является причиной, но именно он является триггером плохих воспоминаний. И его наличие является потенциальным (высоко вероятным) признаком возможности повторения всего этого непотребства. Почему никто не предлагает радостно смотреть в глаза и гладить по головке маньяка-насильника? Другие бы жертвы посмотрели на тебя, и тоже перестали сильно горевать по порванной заднице, да и в процессе меньше нервничали. И всё, проблема решена?
Кстати, кто может сказать про code.jquery.com/jquery-3.4.0.min.js
«хороший» или «плохой» это код? ))) (обычная практика написания кода в js)
«хороший» или «плохой» это код? ))) (обычная практика написания кода в js)
Не «написания», а распространения. Исходные коды этой библиотеки выглядят совсем по-другому.
Так код-то «хороший» или «плохой»?
это и есть исходный код — только без пробелов и переносов строк (в отладке смотрится без особых неудобств).
это и есть исходный код — только без пробелов и переносов строк (в отладке смотрится без особых неудобств).
Вообще-то нет. Они его из кучи файлов-исходников собирают. Загляните в их репозиторий.
Это понятно — что собирают. Только одни так собирают — другие собирают в более читабельном виде. Для конечного пользователя это все-равно исходный код на js — в который можно вносить любые изменения и без сборки.
Для конечного пользователя это все-равно исходный код
Для конечного пользователя — это библиотечный код, который править категорически нельзя, если только ты не решил библиотеку форкнуть.
Если же решил — так возьми исходники, а не сборку, и собери по своему.
А теперь ответьте, нахрена собирать «в более читаемом виде», если никто его читать не будет?
Понятие «категорически нельзя» само по себе звучит не очень корректно.
Ну, я программистом себя не считаю, поэтому читаю и меняю библиотеки если мне нужно. Желания тянуть содержимое node_modules (несколько сот MБ) ради мелкой правки у меня нет. Если вы посмотрите содержание модулей из которых построена библиотека — увидите, что в собранном файле тот-же код.
Ну, я программистом себя не считаю, поэтому читаю и меняю библиотеки если мне нужно. Желания тянуть содержимое node_modules (несколько сот MБ) ради мелкой правки у меня нет. Если вы посмотрите содержание модулей из которых построена библиотека — увидите, что в собранном файле тот-же код.
Понятие «категорически нельзя» само по себе звучит не очень корректно.
Именно корректно. Потому что копаться в собранном файле — это извращение.
Для этого можно скачать исходники, которые совсем чуть чуть больше. И копаться в них гораздо удобнее.
Желания тянуть содержимое node_modules (несколько сот MБ)
Так не тяните. Кто Вас просит её со всеми зависимостями тянуть?
Да и потом, даже мегабайт-полтора — это ОЧЕНЬ большой проект. На счёт сотен — вы что-то преувеличиваете.
ради мелкой правки
«Мелкая правка» — это как правило кейс, который лучше делать своей функцией. Просто не используйте библиотечную, если она Вам не нужна.
Если вы посмотрите содержание модулей из которых построена библиотека — увидите, что в собранном файле тот-же код.
Ну, знаете… Тот же… Это как считать два геометрических тела равными, если можно описать аффинное преобразование одного в другое. Никто не запрещает так считать, и если для дела надо — так считают. Но в большинстве случаев…
Плохой код неизбежен. Если с кодом всё хорошо, то я его не увижу — меня бы не наняли, ведь с кодом всё хорошо и ещё один разработчик не нужен.
Ну необязательно. Если нужно просто добавить новую фичу, значит ли это что код без этой фичи — плохой?
В хорошем коде цена добавления новой фичи низкая — не нужно ничего переписывать и переделывать, разбираться или исследовать долго, код сам подсказывает своей организацией где чего добавить, всякая инфраструктура, не относящая напрямую к новой фиче, уже есть и работает — бери и пользуйся.
Хороший код то тоже нужно кому-то писать, да и фич может быть много, они сами по себе могут быть объёмные. Не бывает такого что архитектура, бац, и хорошая, и можно не парится о ней, и рефакторинг никогда не понадобится. Хорошим тоном нынче считается инкрементальная разработка )
Фичи они разные. И закон Мерфи никто не отменял.
В рабочей жизни я ярко с таким не сталкивался, но в институте влетел в идеальное попадание:
Лаба по хешированию. У разных вариантов — разные функции перебора при коллизии. Я получение задачи проболел, поэтому написал все что нужно с вынесенной в сторону функцией вычисления адреса при коллизии.
Прихожу на зачет в готовность быстренько подправить функцию и сдаться и узнаю свой вариант — «метод цепочек». Упс :(
В рабочей жизни я ярко с таким не сталкивался, но в институте влетел в идеальное попадание:
Лаба по хешированию. У разных вариантов — разные функции перебора при коллизии. Я получение задачи проболел, поэтому написал все что нужно с вынесенной в сторону функцией вычисления адреса при коллизии.
Прихожу на зачет в готовность быстренько подправить функцию и сдаться и узнаю свой вариант — «метод цепочек». Упс :(
В хорошем коде цена добавления новой фичи низкаяКакой бы она не была вы вполне можете увидеть код не потому что он плох, а потому что продукт нужно развивать и разработчиков стало не хватать. Я пытался намекнуть именно на это. Но в случае когда нужна новая фича вполне можно сказать что код плохой так как в данный момент не делает того что нужно. И вот чтобы понять так ли вы определяете плохой код или нет я и задал свой вопрос.
Если нужно просто добавить новую фичуА оно оказывается вдруг раз — и непросто. Причём настолько непросто, что оказывается проще привыкнуть жить без этой фичи.
Статья хорошая в своих, так сказать, посылах, но с одним моментом я не согласен: негатив в оценках как таковой свойственен как раз незрелому уму, и чем опытней и мудрее человек, тем больше он склонен к осторожности в суждениях.
У меня был случай: будучи в командировке, фактически на коленке в условиях цейтнота надо было написать утилиту, её функционал — не суть, там было много алгебры и графики… справился и забыл.
Примерно через год я решил сдуть с нее пыль, отрефакторить и применить, так сказать, для внутренних нужд фирмы. Мои впечатления были на уровне: «господи, что за инопланетянин это сделал?! Как вообще можно было додуматься до такого?». Я реально не мог понять как это работает, и ПОЧЕМУ это работает. В результате просто переписал все с нуля.
Это был какой-то переломный момент в моем мировосприятии. С тех пор, я ни разу не сказал плохого о чужом коде который вижу, даже если он казался мне очень дурным. Хотя, порой думал гневно, да…
У меня был случай: будучи в командировке, фактически на коленке в условиях цейтнота надо было написать утилиту, её функционал — не суть, там было много алгебры и графики… справился и забыл.
Примерно через год я решил сдуть с нее пыль, отрефакторить и применить, так сказать, для внутренних нужд фирмы. Мои впечатления были на уровне: «господи, что за инопланетянин это сделал?! Как вообще можно было додуматься до такого?». Я реально не мог понять как это работает, и ПОЧЕМУ это работает. В результате просто переписал все с нуля.
Это был какой-то переломный момент в моем мировосприятии. С тех пор, я ни разу не сказал плохого о чужом коде который вижу, даже если он казался мне очень дурным. Хотя, порой думал гневно, да…
-How to stop a long rollback?
-Go to the pub.
-Go to the pub.
Спасибо за статью
Вот если бы ещё кто-нибудь рассказал как можно «продать» идею улучшения кодовой базы руководству — цены бы ему не было. С точки зрения бизнеса это выбрасывание денег на ветер.
И вообще, «ты же профессионал, значит должен не ныть о плохом коде, а уметь делать крутые вещи из говна и палок». А если не умеешь — значит ты не профессионал. А если подумаешь сменить работу — то ты просто неудачник, убегающий от вызовов. И вообще, «работать в нашем банке — очень почётно». Кстати, мы вчера уж заключили контракт на поставку термоядерного реактора на нашей суперкрутой технологии Копростикус (tm), так что засучи рукава — и вперёд.
И вообще, «ты же профессионал, значит должен не ныть о плохом коде, а уметь делать крутые вещи из говна и палок». А если не умеешь — значит ты не профессионал. А если подумаешь сменить работу — то ты просто неудачник, убегающий от вызовов. И вообще, «работать в нашем банке — очень почётно». Кстати, мы вчера уж заключили контракт на поставку термоядерного реактора на нашей суперкрутой технологии Копростикус (tm), так что засучи рукава — и вперёд.
как можно «продать» идею улучшения кодовой базы руководству — цены бы ему не было. С точки зрения бизнеса это выбрасывание денег на ветер.надо SJW на это подписать. Типа: «классный код улучшает условия труда угнетенных негров и подавленных женщин, а плохой код — это токсичный маскулинизм и патриархальная культура изнасилования (или оставить rape culture ?) мозга».
И бизнесу продать защиту от угрозы бойкота, остракизма и общественного порицания за их плохой код — улучшение кодовой базы даст благожелательные публикации в лгбтк тусовке, позитивный пиар в фейсбучике и твиттере, и их может даже покажут в cnn и по bbc (но это если они смогут убедить, что их код может понять любой, пардон мой френч, mentally challenged индивидуум или представитель расовых и гендерных общин on medication).
UPD: Вот, как раз отличная цитата в тему:
Ключевой момент здесь, что наши программисты не исследователи. Они, как правило, весьма молоды, идут к нам после учебы, возможно изучали Java, или C/C++, или Python. Они не в состоянии понять выдающийся язык, но в то же время мы хотим, чтобы они создавали хорошее ПО. Именно поэтому язык должен прост для понимания и изучения.(с) отсюда
Вот, тоже самое, что у меня, но у меня слишком много горечи, а тут так приятно написано.
… по мере накопления опыта, у программистов становится всё больше негатива…
Между прочим… нормально это, для умов юных…
Повзрослеют, поймут. Так всегда бывает.
Уйдет негатив.
Между прочим… нормально это, для умов юных…
Повзрослеют, поймут. Так всегда бывает.
Уйдет негатив.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гнев на код: программисты и негатив