Даже второй вариант не всегда пройдет. В первое случае такого принципе никогда не видел на code review. Есть вещи похуже не этичного критики кода, называется Звездная болезнь крупного проекта, когда есть крупный проект, который случайно выстрелил и стал популярным, и главный разработчик не видит проблем кода и проекта.
Мой опыт показывает, что много где не принято вообще говорить про проблемы. Даже если офис синим пламенем будет гореть, народ будет молчать, многие просто боятся осуждения со стороны руководства и колег. По мне лично надо приветствовать любые пожелания по улучшениям и в любой форме, чтобы не копить недовольство, рассматривать их на митапах, и развивать именно активную позицию — «Знаешь как улучшить работу! Скажи!». Недовольство будет всегда по началу и от него никуда не уйти! Про это есть не плохая книга «Dream Team. Как создать команду мечты»
Бывает такое, что функционал который вы добавили, разработчик может посчитать не нужным, а вам решает каждодневные задачи. Или вы сделали рефакторинг для лучшего чтения кода, а разработчику это не понравилось по каким-то личным соображениям. Бывало всякое. Бывало и такое, что написал функцию для решения одной задачи вместо подгрузки тяжелой библиотеки, как зависимость и отвязать кода от сторонних библиотек, не пропустили. В довольно крупных проектах с грамотными майнтейнерами довольно все адекватно бывает и где решения принимают несколько разработчиков. Linux Kernel code review не просто так привел, не редко его считают очень токсичным, и раньше целые форумы люди расписывали про токсичность Линуса Торвальдса и что он не пропускает полезные патчи, заставляет лучше тестировать код перед отправкой.
Даже если вежливо будете указывать людям на ошибки и даже говорить при этом про то, что они сделали хорошо(так же учат делать обратную связь высокого уровня?), то не редко они будут считать, что вы придираетесь…
Вы не поняли, был описан мой опыт, как не грамотные руководители губят процессы внутри компании. Не надо проецировать ваш опыт на мой, и додумывать непонятно что, это был лишь пример. И все описанное мной было ИМХО, что нет токсичности в поведении разработчика, что он что-то хочет улучшить. У людей всегда будут барьеры к новому, и как обычно они были пройдены, но тут не заслуга руководителя, а заслуга времени, некоторым людям нужно время, чтобы понять, осознать, что они что-то не то делают и понять в чем плюсы того или иного решения. Условный пример, вы заказали такси, а вас таксист начинает возить непонятным путем, который вы не знаете и говорит, что так лучше, быстрее, в итоге завозит вас в непонятные дворы, вы начинаете с ним ругаться куда же он вас завез, через пару минут такси выезжает из дворов и проезжает еще чуть-чуть и вы на месте, и понимаете, что таксист был прав, и что вы устроили истерику на ровном месте и не поверили более опытному таксисту. И кстати вы не считаете, что вы себя ведет досточно токсично и даже не даете при этом ответить собеседнику и начали его обвинять? Не это ли токсичное поведение? Где же обратная связь высокого уровня и где грамотный руководитель про которого вы пишете? ))
А вот еще забыл написать. Был в той компании один чудной типок, так вот он каждый день уходил с офиса под предлогом, что его ждет наш клиент для решения проблемы. И еще призрительно говорил, что он давно работает и пусть салаги решают проблемы. По должности был выше его, но он так относился не только ко мне, а так же к другим специалистам выше по должности. Не напоминает вам дедовщину? По факту, у того клиента была сотрудница, которая с утра звонила к нам, и этот типок срывался с работы к ним и ошивался у ней. В ходе корпоративного расследования, почему все так часто ломается у клиента, выяснилось, что у них роман, и никакие проблемы он решает и у клиента проблем нет! Он же был первый на увольнение…
Вы работали когда-нибудь с крупными открытыми проектами типа linux kernel?
В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
Должны. Еще как должны. При знании многих языков переход на новый практически моментален, но вот в каждом языке есть свои особенности, которые сильно влияют на производительность кода, и есть unpredictable behavior, которые полезно знать. В принципе их не всегда понимает большое количество разработчиков пишущих на этом языке, но это не значит, что не надо изучать язык.
Так как раз смотрю глобальнее. Разве может быть в ж*пе все хорошо, когда постоянно звонят клиенты на дню и сильно ругаются? Как раз решения многих проблем там были с 0 сложностью и практически нулевыми затратами. И как раз мне там удалось снизить значительно затраты на многие вещи и повысить эффективность. Тут только говорит о руководителе одно, ни что он смотрит чуть выше, а то, что он в принципе не уверен в команде и в своих силах. Руководитель должен быть всегда примером, с которым не страшно пойти в бой, и подбирать команду грамотно, создать условия для работы хороших специалистов, в итоге в офисе никаких удобств, зарплаты не высокие и понаберут незнай кого, а потом удивляются почему все так плохо))
Это вполне естественно. Пассивным людям не дают пассивничить на работе. С нормальными специалистами всегда конструктивный диалог, и они прислушиваются к коллегам. Благо до подобных пассивных компаний, у меня был опыт работы с реальными специалистами с большой буквы, и даже споры с ними всегда проходили в позитивном ключе.
Не согласен с автором, что надо прогибаться. Это не токсичность. Если вы считаете, что правы и это пойдет на пользу, идите до конца. Иначе скатитесь в итоге к пассивной серой массе. Про это есть замечательная книга «Ча́йка по и́мени Джо́натан Ли́вингстон». Выше правильно написал человек «Её снижают токсики. Они же создают настоящие конфликты, плетут заговоры и натурально выживают коллег с работы.». Вам просто не безразлично будущее проекта. Большая часть людей просто не хочет развиваться, и у них профессиональное выгорание, они приходят на работу не с икринкой глазах, развиваться, решать проблемы и получать от этого удовольствие, а просиживать попу и получить за это деньги, написали тяпляп, работает и ладно. В дали от крупных городов довольно сложно найти грамотных программистов, не говоря про знание безовых алгоритмов. Руководитель в статье относится к пассивному типу и впринципе понимает, что найти нормальных разработчиков сложно, поэтому вас просто сделали КОЗЛОМ-ОТПУЩЕНИЯ! И самое главное вам внушили, что вы были не правы. Вы согласились с этим, и все довольны… У меня была подобная ситуация, были так называемые «старички на работе» которые ничего не делали, плюс одни специалисты вечно сваливали проблемы на других, и так бесконечное перекладывание ответственности. Предлагал своему руководителю работать на опережение, добавить мониторинг оборудования и кучу всего полезного, основываясь на опыте прошлой работы, разделить нормально обязательства специалистов, установить сроки решения и ответственных, чтобы не было такого безобразия. Руководитель ничего не делал. Токсичность идет как раз от пассивных людей! В итоге мне это все настолько надоело, что все работает через одно место и на работе саботаж, что пошел непосредственно к директору, благо до этого с ним пересекались по работе, и он заметил меня как специалиста, изложил ему все проблемы и что руководитель ничего не решает, и работает по принципу сломается исправим, что не хочет развивать и улучшать ничего, и если ничего не решится мне придется уйти от них, в итоге директор согласился с моими доводами, бездельников уволили, руководитель получил выговор, коллеги по началу хряхтели и обижались, но уже через пару месяцев решилась большая груда проблем, и количество работы значительно уменьшилось, и в итоге коллеги меня зауважали и начали прислушиваться, а директор мне выписал премию, выдали в грамоту и занесли в трудовую, что получил награду за решением проблем компании. В принципе в нормальных компаниях это все должно было решаться до вас, и должно быть обучение специалистов в корпоративном университете, и должны быть описаны частые проблемы. Но у вас работает принцип какое руководство такие сотрудники… Мне известные случаи, когда такие сотрудники компании топили ко дну, в одной из таких работал, но быстро ушел, понял, что не мое и с этими людьми мне не по пути.
Так это разве мешает C++ развиваться и быстро компилировать? Это только частично упрощает разработку, что принципе нормально для оберточных языков типа Kotlin, где не хотят сильно усложнять язык и сильно вкладываться в разработку, добавить чуть синтаксического сахара, nullsafety и новый язык готов.
Язык в первую очередь должен быть удобен для программирования и не нарушать привычные паттерны, можно сделать совсем радикально и сделать набор кода справа на лево, но это кроме арабов никто не оценит…
1. Preprocessors — Compare CSS processors for parsings, nested rules, mixins, variables and math. Примерно тоже, что 3, но происходит еще разворачивание макросов, миксинов, переменныхи математики, может добавляться большое количество веток дерева, так как некоторые правила разворачиваются в ветки.
2. Просто парсер и постройка AST.
3. Prefixers — Это работа с AST на примере добавления префиксных свойств для браузеров с проверкой по базе совместимости. Т.е. полный пайплайн.
Я такое вижу от всех программистов и в большом количестве языков… Очень низкий уровень подготовки к сожалению у людей. Особенно такое часто на JS во фронтэнде, там программистами могут работать врачи и экономисты, да и программисты не всегда понимают как все это работает…
Согласен с вами на все 100%. Очень сложно объяснить людям, что все проблемы в JAVA и JavaScript и во многих языках, именно из-за безразборного создания объектов, копирования объектов(тут C++ и C, и им подобные с указателями просто выигрывают и программисты хорошо понимают этот процесс, экономят память, в других языках знают про ссылки, но не используют или не до конца понимают) вместо передачи ссылки, работа с текстом очень дорогая, все строковые операции сами по себе очень дорогие, за исключением посимвольного чтения, там от C++ даже разницы в скорости не будет практически, и трансляция практически с 0 оверхедом, но другие операции как раз могут тригерить сборку мусора особенно после циклов, да и сами работают не очень быстро, к примеру в критических участках кода я отказываюсь от regex и replace c regex, и переписываю код на посимвольное чтение и посимвольную работу с текстом, там можно получить ускорения в тысячи раз по сравнению с regex(даже с предкомпиляцией регулярных выражений). Раньше всегда учили, что конкантенация строк в цикле плохо, там создавалась новая копия стрингбуфера, и память утекала, до тех пор пока цикл не завершится, пока код не вышел из контекста, контекст ограничивается фигурными скобками {}, GC не может запустится, в итоге цикл завершается и GC вместо малого количества объектов надо почистить сотни, а то и тысячи объектов, а где-то даже миллионы, такое тоже видел, отсюда к гадалке не ходи будет дикий лаг от GC… Или еще мною любимый антипатер это ресайз масивов…
Так парсинг как раз не проблема, это довольно быстро, медленнее всего работа с AST, оптимизация дерева, к примеру упрощение выражений типа 2+3, и значительно более сложных выражений и конструкций языка, дальше сборка дерева и конвертация в объектные файлы. Те парсеры парсят, строят AST, дальше делают работу с AST, тут уже кому что надо, и потом уже выплевывают измененный css файл, и при желании создают сорсмап. Основное применение это удаление дублирующихся свойств с учетом наследования, проверка на валидность, проверка свойств на совместимость с браузерами, если нет префикса для какого браузера добавляются префиксы и т.д., замена макросов и т.д. Модулями можно написать любой функционал хоть сделать sass и less. Они дают API и строят AST, дальше извращайся как хочешь.
В подобных проектах впринципе обычно все жестко. Даже к форматированию придираются. Первый раз делают замечание, просят исправить, не исправляете в адекватный срок, отклоняют пул реквест, или если повезет кто-то перепишет правильно. Сломали коммитом что-то, по головке не погладят… Лично у меня было десятки раз, что даже отклоняли по совсем неадекватным причинам. Не конструктивность codereview решается банально за счет декларации как должен быть оформлен код, что можно делать, а чего нельзя. И в принципе должен быть опытный мейнтейнер.
Язык в первую очередь должен быть удобен для программирования и не нарушать привычные паттерны, можно сделать совсем радикально и сделать набор кода справа на лево, но это кроме арабов никто не оценит…
2. Просто парсер и постройка AST.
3. Prefixers — Это работа с AST на примере добавления префиксных свойств для браузеров с проверкой по базе совместимости. Т.е. полный пайплайн.