Comments 61
Всё хотят переписать только джуны, которые раньше никогда не переписывали чудо-код с поддержкой всего старого функционала и всех странных фич. После того, как им разок скажут: "Окей, делай ветку и переписывай", через месяца два оказывается, что на самом деле они ничего не хотят переписывать. Отдельный вопрос перепроектирование всей системы, но это крайне сложный для согласования процесс. Особенно когда люди живут в мире своих иллюзий и фантазий и выводить их оттуда крайне небезопасно для команды. Потому что психушка начнётся. А так она всё равно начнётся, только позже.
Правильно конечно. Однако такая штука как рефакторинг, особенно в контексте всей системы, все же полезна. И да, дается джунам чтобы заодно изучили что и как, и занимает до года, и несколько тысяч коммитов.
Вроде не джун, а временами беру и переписываю, т.к. поддержать левиафана живым гораздо сложнее, а отрефакторить из за дефектов в самом ядре невозможно.
Все зависист от конкретных обстоятельст, а не от принципа, переписывают джуны, а все кто выше читают, разбираются, поддерживают и рефакторят.
Не только джуны.
Я сравнительно недавно зашел в новый проект и почти сразу заорал о том, что всё неправильно и надо начать делать правильно.
Позже задумался о том, почему всё так ужасно и всем больно, но народ продолжает делать одно и то же. Осмотрелся и понял, что да, таки надо всё перепродумывать, но при этом не надо ломать хрупкий баланс, потому что [дальше детали реализации].
Оказывается, никто не дурак и не злой, просто другие подходы оказались неработающими, и под ковром у проекта огромная история множества попыток сделать иначе…
Не надо переписывать. Скорей всего аналитик там провёл плохой анализ, архитектор сделал плохую архитектуру, а Софью Андреевну заставили 7 раз переписать 3 тома Война и Мир под диктовку Льва Толстого. Кто не знает, это выдающаяся женщина, которая всю жизнь всё переписывала под диктовку, родила 12 детей, а в конце жизни пошла неуспешно топиться. Вот такая вот атмосфера бреда скорей всего на проекте. Весь анализ там нужно проводить в письменном виде на форумном движке. И запретить проводить митинги.
Оказывается, никто не дурак и не злой...
..., а просто всем похер.
Спасибо! Именно эту идею мне хотелось донести. Иногда у проекта бывает масса неочевидных нюансов, которые проявляются только со временем или в процессе обдумывания того самого идеального решения [о котором, скорее всего, уже думали и которое скорее всего вот так легко сразу не взлетит].
С джунами соглашусь, но по мне такое желание все же бывает не только у них. Иногда людям действительно удается переписать что-то сложное без больших последствий, что создает прецедент (на всю команду причем) того, что оно и дальше так прокатит. И оно, кстати, может и дальше прокатит и всем действительно станет лучше.
Моя идея была попытаться донести, что такие решения должны приниматься только с человеком, который знает предметную область, а в идеале и сильно участвовал в написании этого кода, человеком глубоко изнутри, а не кем-то снаружи, каким бы звездным он ни был.
А если попытаться перефразировать, то переписывать сложный код - нужно, но только в том случае, если это сознательный вариант, а альтернатива - еще хуже. А вот правильно оценить альтернативу - это уже наука, причем у каждого своя.
А нужно ли это айти вот прям здесь?
Бабушка с тетрадкой куда дешевле, а "базу" не растащат хакеры. Пенсионер-вахтёр понимает любую жизненную ситуацию, чего не скажешь про типа самые умные камеры с распознованием лиц и поведения. Продавщица за прилавком и отвесит и пробьёт, и ещё потрындеть с ней можно в процессе, а со всеми этими самообслужками стой разбирайся сам. List goes on and on где айти уже ничего не улучшает, а наоборот ухудшает.
Было уже здесь, в отличной статье от Крока про камеры на проходной. Бабушка-вахтер относительно неплохо распознает лишь лица своей национальности, а с другими нациями распознавание человеком проигрывает компьютеру фатально. Да и лицо мало просто распознать, надо еще очень быстро извлечь базу из своей памяти, и держать ее актуальной, а с этим огромные проблемы.
Еще важное отличие бабушки-вахтера в том что она не хранит идеально точную БД биометрических данных и соответствено невозможна утечка этих данных.
, а с другими нациями распознавание человеком проигрывает компьютеру фатально.
У вас негры друг за другом на проходной ходят? О том и речь, не надо пихать айти туда где от него выигрыша особого нет, а вот цена и косяки никуда не деваются. А там где productivity/cost на высоте, там всегда welcome.
Добавлю еще, что как только начинаются добавления к функциональности или усложнении системы, ну, например, не пускать определенных людей, то человеки начинают быстрее проигрывать автоматике.
Соглашусь со здравомыслием подхода! Все сильно зависит от нюансов и поставленной задачи. Если вы решаете задачу одной конкретной проходной - возможно, пенсионер-вахтер это выход, потому что люди впринципе сходу могут быстро решать целый класс задач и идеально справляться с кучей нештатных ситуаций. Люди это зачастую жирнющий плюс с точки зрения быстроты решения задачи, потому что обрабатывание внештатки в айти часто занимает астрономически много времени, денег и плюс все эти шишки набиваются только со временем.
Но у людей есть критичный недостаток, это плохая их тиражируемость. Как только проходных становится две, три, четыре, десять, сто - тиражировать человеков становится очень больно и сложно, и эта сложность сильно возрастает в зависимости от сложности решаемой функции.
Еще один недостаток - это обстоятельства, которые у человеков могут случаться чаще и менее прогнозируемо, нежели у бездушных железок. Продавщица может заболеть, быть в плохом настроении, list goes on and on, а у кремниевых список более короткий и более прогнозируемый.
Поэтому да, выбор человек или айти - это тоже выбор здравого смысла.
Мы тоже прикидывали, что можно добавить какой нить терминал простейший вместо амбарной книги и этого достаточно с головой будет. Но нет консультанты требуют каких новомодных роботов и кучу дорогой работы.
Гм, сдается мне, что на последней иллюстрации все же Дзен-кошка...
Мотильда, дайте этому человеку кружку эля и поставьте плюсов в карму, да побольше! И вызовите карету. Я хочу его видеть на Олимпе!
Я не раз говорил, что одно из определений слова сумашествие это "всё что угодно, доведённое до крайности". Любая вещь, применимая к любой ситуации, применённая без оценки ситуации будет разрушительна.
Здравый смысл - это обратное. Когда вы проводите честную и непредвзятую оценку. Когда вы анализируете текущую картину и внимательно выбирвете инструменты.
Иногда имеет смысл написать всё на чистом HTML без CSS. Иногда нужен реакт с плагинами. Иногда нужна сцепка Postgres + ElasticSearch, а иногда подойдёт дамп текстовых файлов на диск.
Иногда имеет смысл написать всё на чистом HTML без CSS. Иногда нужен реакт с плагинами. Иногда нужна сцепка Postgres + ElasticSearch, а иногда подойдёт дамп текстовых файлов на диск.
Так-то оно так, но, к сожалению, нынче без модняцких технологий в резюме, новую работу можно и не найти вовсе. Если будешь всё делать правильно, со "здравым смыслом" - есть риск что делать это будешь в последний раз.
Спасибо! Добавить нечего, все так ?
с умением задавать правильные вопросы правильным людям — и есть самый важный навык. Потому что умение остановиться, оценить обстановку и несколько раз задать себе и другим вопрос «зачем?»
Полностью согласен. Однако зачастую вопрос «зачем?» очень опасен. Обычно вызывает трения при разработке комлексных решений в многопрофильной команде. Технический продуктовый менеджмент часто присутствует даже на организационном уровне. Однако зачастую сводится к управлению портфелем продуктов.
Мне кажется, такие вопросы надо задавать максимально нейтрально, потому что это может неправильно восприниматься как атака на принятое решение. Но если человек не может защитить свою точку зрения двумя последовательными вопросами "зачем", то это не очень хорошо, конечно.
Конструктивные трения это в целом очень полезно, но только если команда умеет не выходить за рамки рабочих обсуждений, чтобы это не превратилось в ругань.
Имя ему этому навыку — здравый смысл.
Главный навык сотрудника — это лояльность, а не здравый смысл.
Если сказать руководству, что его новое решение не совсем оптимально или что оно лишено здравого смысла и его лучше отменить совсем, то это даёт минус 100 очков к лояльности и с большой вероятностью приведёт к поиску новой работы для смельчака.
К сожалению, здравый смысл не всегда помогает принимать нужные решения, так как вес и приоритет задачи зависит от высоты занимаемого поста человека, а не от пользы решения для компании или от здравого смысла.
Если не подвергать критике плохие решения руководства, а просто воплощать их в жизнь, то можно получить плюс 200 очков к лояльности, бонус за успешно выполненный проект и возможность повышения в должности и зарплате.
P.S. Да, я тот самый смельчак, который не боялся беседовать с директорами компаний и показывать, как их неоптимальные решения надо изменить, чтобы они начали приносить больше пользы компании, а не вред. После ухода из нескольких компаний я прокачал навыки: «перестать
насаждать добро», «перестать давать непрошенные советы», скрытность» и «лояльность». Теперь меня все любят, считают классным специалистом и хорошо оплачивают мой труд. А всё своё свободное время я теперь трачу на себя и свои интересы, а не на то, чтобы сделать компанию лучше.
Спасибо, лайк поставил, дополнение шикарное! Но я с ним соглашусь частично. Частично, потому что лояльность - по мне лишь одна из веток здравого смысла. Люди все очень разные, в том числе те самые принимающие решение директора: кто-то из них залетный карьерист, кто-то радеет за дело, поэтому каждый отреагирует на критику (почему именно - критику?) совершенно по разному.
И слово "критика" само по себе подразумевает начинающийся конфликт. К сожалению, многие решения кажутся неоптимальными именно с высоты своего полета, а на другом уровне выше есть много дополнительных вводных, которые могут перевернуть понимание о принятом решении. Если эти вводные не знать, в них разобраться попыток не делать, а диалог начать с открытия двери ногой (на созвоне в 100 человек, например) и фразы "тут все г%вно", то все точно пойдет по тому пути, что вы описали. Возможно, люди воспринимают предложения "насаждения добра" именно потому, что оно подается не так или есть вводные, которые не нужно знать другим сотрудникам. Мир и люди - сложные.
Но точно могу сказать, что не все директора - говнюки, не все - принимают неудачные решения, и не все из них остро реагируют на предложения, если подать их правильно. Поэтому если случай клинический (они есть, не спорю), то лояльность это выход. Но если ваш грейд позволяет общаться с принимающими решения людьми, то зачастую все не так плохо и на все можно повлиять, понять, обсудить и что-то предложить. Адекватные боссы на адекватный диалог реагируют нормально, в конце концов, это и есть то самое искусство управления людьми, никого не хочу в этом убеждать, но у меня всю жизнь было именно так.
Плюс абсолютная лояльность это все же не для всех, быть лояльным к неудачным решениям - это тоже особенный навык, который есть далеко не у всех. Поэтому если лояльность это оптимальное решение в данной ситуации, и она не вызывает отторжения, то да, это выход и надо делать работку и получать удовольствие от всего процесса.
Безусловно лояльность это вот наше все. Обычно она относится к компании, но каждый руководитель ассоциирует себя именно с компанией. Со всеми вытекающими.
Тот случай, когда комментарий дороже статьи. Я бы, правда, сузил с "сотрудника", до наемного работника.
Но не все так просто. Иногда бывает, что начальник - дурак, но в команде кроме тебя есть и другие коллеги, которые тоже не согласны с его мнением. Или твой непосредственный начальник - дурак, но выше него в иерархии есть вроде более вменяемый начальник. Или есть 2 начальника из двух смежных отделов, которые взаимодействуют друг с другом (например, в плане API), и подход смежного начальника тебе больше нравится. И вот так сидишь, и думаешь, примкнуть к злой стороне или всеже доброй.
В больших структурах такое сплошь и рядом, и когда в очередной раз будет пересмотр эффективности работы всей цепочки, то безудержная лояльность даже к неудачным решениям может закончиться не очень хорошо.
Поэтому да, все сложно, и нужно индивидуально понимать насколько договорибельно руководство в целом, и уже в конкретных обстоятельствах принимать какое-то решение.
Живой случай в соседней команде: человек пришел, сказал что надо переделывать, под его харизмой переписывать на новом языке начали, а сотрудник ушел через 4 месяца, бросив все, directed by Robert B. Weide.
Ух жиза. Даже на секунду подумал, что где-то рядом трудимся.
Давайте сразу с места в карьер: за 16 лет в индустрии я повидал изнутри несколько сотен самых разных проектов и команд
Считаем, что в шестнадцати годах 5844 дня. Несколько, ну пусть будет по минимуму — две сотни, хотя «несколько» обычно подразумевает больше. Делим дни на две сотни проектов команд, получаем 29 примерно дней на один проект. Без учёта отпусков, больничных, праздников, форс-мажоров и пр. А так меньше, конечно.
Для фрилансера, чёт подмандить по-бырому, вероятно, такой бэкграунд норм, но для более-менее сложного продукта — несерьёзно.
В общем, я сомневаюсь, что проскакав подобным образом всю карьеру по проектам вы можете давать такого рода философские советы.
То есть, советы давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
Что-то очень легко вы оценили опыт автора. Я бы не стал делать какие-либо выводы, узнав о цифре в 16 лет и сотнях проектах. Да ещё и настолько упростив это - тупо поделив. Откуда вы знаете, может, один проект был на 8 лет к примеру, а остальные сотни - оставшиеся 8. Да и всё равно это всего лишь цифры.
Т.е. на остальные проекты вообще тратились единицы дней? Нет, у меня тоже есть опыт конвейерного производства сайтов-визиток за 2-3 дня, но опыт этот специфичный.
Бывает, что работаешь и смотришь не только в свою команду, но и в 5-10 соседних, и тоже получаешь с этого опыт - кто кого нанял и как, какие решения принимались и как, какой был менеджмент, как была организована работа и так далее. Тем более если быть кем-то типа деливери менеджера, там точно придётся погружаться в разные команды и помогать чинить процессы.
Конечно, будучи в роли мидла-разработчика так широко редко получается видеть, но у людей же разные роли. Допустим можно быть в архитектурном комитете, это тоже даёт много опыта от других команд: сначала видишь проблему и их идею, потом узнаешь как прошла реализация и что получилось, какие всплыли косяки.
О сотнях автор может быть преувеличивает (а может быть и нет), но кажется мысль статьи не в этом, и можно просто принять оценочное суждение автора.
У меня претензия была к тому, что был сделан вывод об опыте автора на основании 2-х цифр (16 лет опыта и сотни проектов). А так не надо делать. Это упрощение и навешивание ярлыков чаще приводит к ошибочным выводам. Слишком мало данных для вывода. А Вы зачем-то продолжаете строить выводы на основании этих 2-х цифр.
Так мир ведь он вот какой простой, видишь две цифры - дели одну на другую и беги скорей делать выводы ?
Вот у человека -19 карма и 98 комментариев, значит он -0.19 получает за каждый комментарий. То есть, комментарии давать, конечно, можно, но авторитет их автора, прямо скажем, сомнителен.
Спасибо за провокационный комментарий. Статья - ровно об этом: математика - ок, но предпосылки к ней изначально были неверные, поэтому ее можно было не делать. Я нигде не писал, что это были МОИ проекты, или что я в них полноценно участвовал, более того, я на это никоим образом не претендую. Я имел ввиду только то, что и так было написано буквами - я повидал устройство изнутри множества команд.
Это дословно означает, что я знаю их состав, стек, инфру, подход к разработке и их проект на уровне продвинутого пользователя (где-то глубже, где-то поверхностнее). Когда ты большую часть рабочей жизни делаешь коробочный софт и встраиваемые сервисы для разработчиков, то частью работы становятся попытки разобраться кто, зачем, как и почему использует этот софт и как в итоге его потом затаскивать в контур заказчика.
Поэтому (как уже писали ниже) выдернуть две цифры и поделить одно на другое и сделать выводы - так себе история. Больших и очень сложных проектов с полноценным участием у меня было штук 10, а работку я менял всего 6 раз за все время, нигде не работая меньше года, поэтому ни о каких скаканиях речи быть не может.
"Garbage in, garbage out" - во всей его красе.
Так хорошие же советы и рассуждения правильные. Тоже подпишусь под каждым абзацем.
А десятки проектов могут идти параллельно если автор ими руководит или менторит.
Я много лет руковожу разработкой. Так вот суть статьи, это мой главный лозунг в работе. Я постоянно всем это говорю: "Не надо откладывать на завтра то что можно не делать вообще". Именно этот подход дает возможность работать на порядок более эффективно!
У меня принцип похожий, только он звучит: "Чем проще, тем лучше". Это позволяет делать минимальное количество действий, чтобы добиться нужного результата без лишних переусложнений.
Второй принцип - это "Правило 20 на 80". 20% усилий\задач приносят 80% результата, поэтому вначале выполняются именно такие задачи, а если остаётся время, то берутся другие задачи, чтобы закрыть оставшиеся 20% результата.
Спасибо. Как говорится, "если тикету уже больше года, и за ним никто не пришел, может быть он и не так нужен?" ?
Думаю, что автор описывает мышление. Качественное, системное, структурное, открытое, критическое мышление. С широкой "мыслительной рамкой"(это как я это называю), мыслительная рамка вдаль это будущее, думать на несколько шагов вперед. Мыслительная рамка вширь это на несколько людей/отделов рядом собой. Не только на себя. Обыватель мыслит 1 на 0(только на себя и прямо сейчас). При разработке сложного абстрактного продукта, всем членам команды придется мыслить пошире и вдаль хотя бы на пару шагов.
Вспоминается Эдвард де Боно с его работами по мышлению.
часто случается большой стереотип о том, что есть один проверенный способ чтобы все сделать сразу как надо.
У меня есть другой стереотип, сложившийся из личного (тоже больше 15 лет) опыта - всякий раз, когда я слышу: "сделаем сейчас как не надо (потому что нет времени/денег/людей и т.п.), а потом, вот, придет время, и переделаем нормально", то я уже сразу знаю что это "время", на самом деле, никогда не придет.
А кем вы работали, что меняли проекты каждый месяц? (несколько сотен за 16 лет.. если принять несколько сотен за 200 то каждый месяц новый проект)
Блин. На Хабре сижу всего ничего (около недельки, если не меньше) и поражаюсь - какие хорошие люди с интересными мыслями тут сидят. Спасибо вам и автору за то, что вы делаете. И создателям самого хабра тоже спасибо, что собрали всех этих людей вместе, в одном месте. P.S Извините за оффтоп
Здравый смысл основан на жизненном опыте.
Если честность, вопросы о цели, инновации и признание ошибок приводили руководителя к потере работы и репутации успешного лидера, а обратное приносило хорошую зарплату и власть годами, то его здравый смысл подсказывает делать это обратное.
Фраза-маркер "у нас стабильность" и "делай что скажут" / "все мы делаем, что нам говорят" - хороший показатель, что руководство не ориентировано на нововведения и будет их блокировать.
Как правило, за этими фразами в "инновационном активно развивающемся бизнесе" скрыты очень некрасивые истории(
Главная проблема таких утверждений, что их можно поменять на противоположные 8 штук :) в зависимости от отсутствия той или иной компетенции - как то неумение ставить задачи, координировать, мотивировать, налаживать коммуникацию, проводить технические совещания... - и сформулировать противоположные 8 принципов так, что тоже будет про здравый смысл, но с переложенной на кого-то другого ответственностью ;)
Да, реальность такая, что в основном болото и стагнация, и правила поэтому те же - как не утонуть в болоте. Но главное, может быть, другое - активно искать себе "братьев по разуму:)" и формировать окружение с близкими по духу носителями здравого смысла, не пренебрегать поддержанием таких контактов.
Спасибо за статью, а в особенности, за подкрепление основных тезисов генеративными котиками :)
От себя хотел бы добавить, что, как уже кто-то выше заметил, ваш «здравый смысл» очень похож на soft-skill «Критическое мышление». И, я в этом с вами полностью согласен, это самый ключевой навык любого профессионала.
В своей практике управления разработчиками я всегда начинаю погружение в софт-скиллы с более простой формы, которую называю «Навык сомневаться»:
– Сомневаться в своих убеждениям (Правильно ли я понимаю, что...?)
– Сомневаться в корректности поставленной задачи (Какого результата требуется достичь, оптимальным ли путем мы пытаемся до него дойти?)
– ... в оценке трудозатрат (Хватит ли времени на выполнение задания, если твой подход не сработает? Стоит ли заложить небольшой буфер на исследование вначале и на багфикс в конце?)
и т.д.
Обычно, уже этого оказывается достаточно, чтобы слегка расшевелить молодых и горячих разработчиков, немного затормозить темпераментных и прорывных визионеров от продукта и основательно приземлить клиентский отдел.
Но, в более широком смысле, этот навык – это лишь один из кусочков пазла, который плохо работает без поддержки навыков коммуникации, эмпатии, лидерства и креативного мышления.
Основной вопрос, который меня мучает уже продолжительное время – как повлиять на развитие гибких навыков в ИТ в широком смысле и как прокачать их у конкретного человека или небольшой группы людей?
Вот мне недавно дали совсем небольшой проект на React Native, который был написан пару лет назад впопыхах, человеком который даже в React не шарит. Приложение не запускалось на ios уже как полтора года, да и вообще было уйма проблем. К примеру, от typescript там только были названия файлов, index.tsx вместо index.jsx. В
Ключевой навык успешной карьеры в ИТ или 8 заблуждений на проектах