Здравствуйте, Артём, Вы писали:
Аё>Здравствуйте, SkyDance, Вы писали:
SD>>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).
Аё>Драйв в чём выражается?
Здравствуйте, rosencrantz, Вы писали:
R>Углы и рефакторинг — это либо такая штука, что делаешь её молча, либо, если говоришь вслух, это ругательное слово. Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий.
В итоге проект проживет 2-3 года, может чуть дольше, пока код не превратиться в unsupportable, а менеджер, который до этого довел спокойно сменит работу и начнет пилить аналогичный проект. Правда ведь?
Здравствуйте, rosencrantz, Вы писали:
R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
Угу. Плавали — знаем. Сначала все хорошо — бизнес-идея отличная, клиенты рады, с удовольствием несут бабки, контора растет, манагеры выписывают себе премии и разрабам что-то достается. Потом незаметно разработчики становятся заваленными сапорт-тикетами, времени на новые фичи нет, а рефакторинг, что бы попытаться вытащить продукт из стадии прототипа, не заапрувит менеджер . Клиенты злятся, постепенно уходят, денег поддерживать все то, что понакупили/понанимали в жирные времена нет, урезаем осетра и увольняем людей. А ведь так все хорошо начиналось. Наверняка программисты неправильные попались, завалили такой хороший продукт.
Если что это совсем свежая история из личного опыта.
Здравствуйте, Abalak, Вы писали:
A>Здравствуйте, rosencrantz, Вы писали:
R>>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
A>Если что это совсем свежая история из личного опыта.
Бывает. Но мы же тут все взрослые люди — и не будем из этого делать далеко идущие выводы? У меня бывало что некий самостоятельный сеньорный программист что-то там программировал-программировал, и потом начал жаловаться, что оно в ночь с 31 декабря на 1 января стало легаси, и всё надо переписывать. А потом свалил в соседнюю компанию. Менеджеры плохие попались?
Здравствуйте, Abalak, Вы писали:
A>В итоге проект проживет 2-3 года, может чуть дольше, пока код не превратиться в unsupportable, а менеджер, который до этого довел спокойно сменит работу и начнет пилить аналогичный проект. Правда ведь?
Так а в чём менеджер виноват? Задача менеджера — обеспечить приток требований — и отток релизов/демок. Если код становится всё хуже и хуже, это не менеджер плохой, а программисты. Слово "рефакторинг" все знают с 5-летнего возраста, но многие думают, что это такое самостоятельное занятие. Как правило, эти люди просто в принципе пишут плохо, и думают, что однажды им дадут время привести всё в порядок — и они *тогда* приведут всё в порядок. И, как правило, если это время им дать, ничерта они в порядок не приведут, потому что в принципе не понимают по каким критериям это делается. Были бы они способны определить такие критерии, сразу бы писали нормально.
Здравствуйте, Pzz, Вы писали:
Pzz>А как в адекватных командах проводят это "заодно"? Его хоть можно отдельным коммитом провести с честным комментарием, что это именно рефакторинг? Или делаем новую фичу/затыкаем багу, а к коммиту тихой сапой кусочек рефакторинга прикрепляем?
В моих проектах для работы с кодом обычно используется процесс "git flow" — каждая фича делается в отдельном бранче (хоть 1 коммит, хоть 1000), и когда фича по мнению автора готова, делается мёрдж риквест в мастер. Т.е. на код ревью попадает один большой чейнджсет со всеми релевантными изменениями — на это уже все дружно смотрят и пишут комментарии.
Pzz>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).
Это тупой популизм. Нормальное решение не обязано быть понятно студенту-третьекурснику. Нормальное решение обязано быть более-менее понятно всем участникам команды, которые пишут код. Если 4 программиста с опытом, и 1 — третьекурсник, ориентироваться на третьекурсника не на надо, надо ориентироваться на большинство. Третьекурснику надо набираться опыта, читать книжки вне универа, задавать вопросы, и т.д. Если же вся команда (ну, особенно — 4 программиста) не понимают решение, тут нужно разобраться в ком всё-таки проблема — в решении или в программистах. У меня бывали проекты, когда проект — на Java, а команда на Java в жизни ничего не писала. Или в проекте AWS, а команда нихрена не знает про AWS. Я должен на них ориентироваться? Да срать на них. Я сделаю всё возможное, чтобы дать любому желающему возможность "въехать" и стать полезным — и буду сидеть с ними больше 8 часов в день, если это поможет им разобраться. Но если кто-то такой приходит типа "я студент-третьекурсник" — да иди ты на за дверь, без тебя разберёмся.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, rosencrantz, Вы писали:
R>>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.
Pzz>Ряд 1 + 1/2 + 1/4 + ... сходится, у него есть предел, равный двум.
Полностью мысль напишите. 2 часа, 2 недели, ряд сходится к 2. Какой вывод? Инь и янь? Мужчина и женщина? Код и его отсутствие?
Pzz>У меня есть подозрение, что разработка продукта, который обрастает техдолгом, с которым никто не собирается бороться, а просто смиряются, что добавление кнопки занимает 2 месяца, а не два часа, тоже сходится. Т.е., такой продукт можно разрабатывать годами, будут какие-то новые версии, новые фичи. Но глядя трезвым глазом, у него есть потолок, которого ему никогда не преодолеть.
У программистов (особенно молодых) часто есть потолок: "если мне говорят делать быстро, я буду делать быстро, ведь мне говорят, а значит это важно". Тут у нас вопрос: как программисту одновременно и программировать хорошо, и не стать рабом своей работы? Не так сложно писать охухороший код без техдолга. Сложно при этом жить хоть как-то за пределами работы — и не выгореть за пару лет.
Pzz>Хорошо ли от этого бизнесу? Ну в принципе, может быть хорошо. Мы видели много загнивающих и в конце концов ушедших технологий, которые, тем не менее, за время своей жизни приносили доход. Бизнес такое может пережить, если он способен прожить дольше, чем те продукты, которые его кормят, создавая новые продукты. И не способен, если он зависит от имеющегося набора продуктов, и новые создавать не способен.
Ни разу не сталкивался, чтобы говнокод (техдолг) был большой проблемой. Либо бизнеса нет — и есть попытка запилить продукт, вокруг которого позже построить бизнес. Либо бизнес есть — и что там с продуктом происходит — не так важно. Такого чтоб "мы к сожалению не запилили фичу во время, поэтому бизнес в жопе, я рекомендую всем прямо сейчас обновить резюме и начать искать новую работу" — тоже никогда не видел. Но вообще вы пишете не про то, про что я писал. Моя мысль — в том, что если продукт менеджер с дизайнерами летает в облаках и периодически на землю сбрасывает какие-то офигенные идеи — у программистов не получится под это эффективно подстраиваться. Должен быть постоянный диалог. Программисты должны понимать степень ебанубезумия дизайнеров, и дизайнеры должны понимать какая фича сколько будет "стоить".
Здравствуйте, rosencrantz, Вы писали:
R>Если код становится всё хуже и хуже, это не менеджер плохой, а программисты.
Нет, и те и те — говно.
Непосредственный манагер, который не над другими манагерами а над девелоперами, которому посрать на то, что происходит в коде — это чистый вредитель.
R>Как правило, эти люди просто в принципе пишут плохо
Куда чаще код портится потихоньку, в результате наслоений многочисленных мержей. Часто ещё и написанных разными людьми и в условиях разной степени срочности.
Я порой даже в своём собственном коде, который кроме меня никто никогда не правил, делаю рефакторинг и разглаживаю "вековые кольца".
А то и вовсе приличный кусок переделывается потому что требования к функционалу совсем устаканились и можно с полной уверенностью вот эти заделы, оставленные чтоб потом можно было проще функционал расширять, выкинуть а логику раскатать катком на более простую и прямолинейную.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, rosencrantz, Вы писали:
R>>Как правило, эти люди просто в принципе пишут плохо CC>Куда чаще код портится потихоньку, в результате наслоений многочисленных мержей.
Какое нахрен наслоение многочисленных мёржей? Мёрж, даже если в нём нет конфликтов, требует ревью. Если всё само гладко смёржилось, это всё равно ответственность программиста — убедиться, что результат осмысленный. А уж если мёрж с конфликтами — это вообще 100% ответственность девелопера довести код до идеального состояния перед коммитом.
CC>Часто ещё и написанных разными людьми и в условиях разной степени срочности.
Срочность — это такое когнитивное искажение у программистов. Когда говорят "нужно срочно", это не означает, что надо делать плохо. Это означает, что если ты вместо 5 перекуров мог бы сходить на 4, это было бы здорово. Когда кто-то при слове "срочно" начинает нарушать вообще всё, что можно нарушить — это просто профессионал — говно. Для таких людей нужно в туалетах вешать таблички: "помойте руки", а то не дай бог они после слова "срочно" в туалет пойдут.
CC>Я порой даже в своём собственном коде, который кроме меня никто никогда не правил, делаю рефакторинг и разглаживаю "вековые кольца". CC>А то и вовсе приличный кусок переделывается потому что требования к функционалу совсем устаканились и можно с полной уверенностью вот эти заделы, оставленные чтоб потом можно было проще функционал расширять, выкинуть а логику раскатать катком на более простую и прямолинейную.
Здравствуйте, SkyDance, Вы писали:
SD>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).
Какого рода драйв, типа преодолевать бардак или что?
Здравствуйте, SkyDance, Вы писали:
Pzz>>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику). SD>Истинно так. Знаю как по другим решениям, так и по своим. Когда с пятого переписывания вместо 2 тысяч строк и сотни патчей появляется файл из 400 строк и лишь с парой фиксов, — оказывается, что решение было слишком простым, чтобы его можно было увидеть с самого начала.
S>Какого рода драйв, типа преодолевать бардак или что?
Не-не-не, преодолевать бардак — это почти всегда попытки построить драйв в болоте. Да, в отдельно взятом уголке болота на некоторое время драйв может и возникнуть. Но быстро угаснет, т.к. болото (и бардак) — противоположность драйву.
Драйв — это когда ты точно знаешь, что делаешь, и почему. И когда имеешь контроль над всеми компонентами уравнения, — а стало быть, можешь решать проблему, а не искать обходные пути вокруг вот той команды, и вот этой обязательной библиотеки (потому что там работает сын владельца), или вот этого "стандарта" (который двигает зять жены владельца).
R>Так а в чём менеджер виноват? Задача менеджера — обеспечить приток требований — и отток релизов/демок.
Традиционно считается, что это работа product manager. Однако на примере высокоэффективных компаний, устранение product manager'ов и замена их на грамотных инженеров резко ускоряют разработку, да еще и качество повышается. Неплохо об этом написано в биографии Маска (и Джобса тоже, хотя там шибко вычурно). В слегка "облагороженном" виде это звучит как "product people must sit and work next to engineering". Менеджер (продакт) должен не "обеспечивать приток", а отвечать на вопросы "мы можем сделать вот так, или во этак — как наши юзеры хотят?"
R> Как правило, эти люди просто в принципе пишут плохо, и думают, что однажды им дадут время привести всё в порядок — и они *тогда* приведут всё в порядок.
О нет, как правило, "эти люди" ВЫНУЖДЕНЫ писать какие-то кривулины из-за того, что у них есть ограничения. Например, неподходящий для проекта язык. Как тебе, например, Python в качестве языка для высоконагруженного веб-приложения? Так что нужно по отдельному серваку на каждую сотню concurrent users просто для stateless операций с соединениями?
Или, еще интереснее, есть какая-то "инфра", которая напрочь кривая. Тебе сообщают "у тебя память течет в твоем сервисе". Ты им в ответ — ну окей, дайте мне ssh, сниму дамп, посмотрю, что в памяти. В ответ "ну знаешь, наша инфра сейчас проходит апгрейд, так что теперь такие не-secure штуки как ssh больше нельзя". "Ну и как мне взять дамп?" — "Никак, придумай другой способ". И в коде приложения внезапно появляется тонна временного кода, который fork/exec'ает еще один процесс внутри контейнера, снимает дамп основного процесса, и шлет этот дамп хрен знает куда (но туда, про куда "безопасность" еще не узнала, например, прямо на адрес твоего рабочего компьютера).
Конечно, бывает кривой код и по другим причинам. Лени, нежеланию посмотреть, как это на самом деле должно быть сделано. Или просто от желания "сделать мир лучше" — запилить мега-фреймворк для переворачивания строк. Тоже частый случай, да. Но таки куда чаще я вижу системы грузиков и противовесов там, где есть или turf wars (делят, кому владеть каким-то выгодным проектом), или где люди попросту не могут выпрямть корявости соседних команд.
Здравствуйте, SkyDance, Вы писали:
R>>Так а в чём менеджер виноват? Задача менеджера — обеспечить приток требований — и отток релизов/демок.
SD>Традиционно считается, что это работа product manager.
Это зависит исключительно от того, кто собрал команду и из кого. На моей последней работе были и product manager ("видение продукта") и project manager ("бегать с палкой за людьми, чтобы в джире во время появились юзер сториз, чтобы спринт плэнинг состоялся, и т.д.") Когда я говорю "менеджер", я говорю о человеке, который не пишет код, а отвечает за пайплайн хотелки->релизы.
SD>О нет, как правило, "эти люди" ВЫНУЖДЕНЫ писать какие-то кривулины из-за того, что у них есть ограничения. Например, неподходящий для проекта язык. Как тебе, например, Python в качестве языка для высоконагруженного веб-приложения? Так что нужно по отдельному серваку на каждую сотню concurrent users просто для stateless операций с соединениями?
Я не вижу проблемы с Питоном и "по серваку на 100 юзеров". Ну навязали архитектуру, которая вам кажется неудачной в плане жирности инфраструктуры и денег. Ваша роль в проекте какая? Зачем вы заводитесь так, будто вам эти серверы нужно будет на своей спине таскать из подвала на 5 этаж без лифта? Или деньги на них у вас прямо из кармана вынимают? Вообще, как это оправдывает "пишем сразу легаси код"? Архитектура зависит от многих факторов, в том числе и от тех, которые программисту могут быть не видны.
SD>"Никак, придумай другой способ"
Это не "плохой код", а "код на выброс": одним коммитом добавили, а потом вторым — удалили. Он не диктует дизайн, и не повлияет на сопровождаемость кодовой базы.
SD>Конечно, бывает кривой код и по другим причинам.
Бесполезно статистику сравнивать — что у вас, что у меня слишком маленькая выборка. Из всех программистов, с которыми мне довелось работать, ощутимо большая часть была "плохие программисты". Люди с майндсетом "работает — не трогай" и "я свалю раньше, чем легаси станет проблемой". Эти люди просто брали — и с первого дня начинали вносить очевидный технический долг.
Моя точка зрения такая, что не все могут эффективно работать с существующим кодом. Майндсет "я сейчас надебажу в какое место в коде мне нужно добавить вот эти 3 строчки" — против майндсета "я сейчас попытаюсь понять на какие допущения завязан существующий код — и перепешу его таким образом, чтобы были те допущения, которые нужны для новой фичи, над которой я работаю". Мне довелось работать со многими программистами, которые предпочитают именно что — "воткнуть 3 строчки в нужное место".
Здравствуйте, rosencrantz, Вы писали:
R>Какое нахрен наслоение многочисленных мёржей?
А такое. Тут чуть чуть поменяли, тут чуть чут добавили. Потом смотришь на это всё и понимаешь где можно что выровнять, что то вынести и сделать более generic.
Инкрементальные изменения они такие.
R> Мёрж, даже если в нём нет конфликтов, требует ревью.
Ревью всегда фокусируется на изменениях а не на более общей картине.
R>убедиться, что результат осмысленный.
А он осмысленный.
R> А уж если мёрж с конфликтами — это вообще 100% ответственность девелопера довести код до идеального состояния перед коммитом.
Ты не понял про что я.
R>Когда говорят "нужно срочно", это не означает, что надо делать плохо.
Спасибо, кэп!
R>Как определяете, что требования устаканились?
Строго на глаз, есессна.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, SkyDance, Вы писали:
SD>Или, еще интереснее, есть какая-то "инфра", которая напрочь кривая.
Тема борьбы с security идиотами это вообще отдельная песнь.
У них цель законопатить всё, включая рот и ноздри, а на вопрос "а как дышать" они пожимают плечами и не парятся, у них то всё теперь в безопасности.
SD>Конечно, бывает кривой код и по другим причинам.
Коллега из другой компании поделился историей как их местные идиоты проверяли можно ли писать на диск путём порчи нескольких мегабайт в рандомном месте на нём, с соответствующими последствиями для данных на этом диске.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
R>Я не вижу проблемы с Питоном и "по серваку на 100 юзеров".
Суслика я тоже не вижу. А он есть.
R>Вообще, как это оправдывает "пишем сразу легаси код"?
Потому что "архитектура" (ага, в кавычках) не позволяет написать иначе. Оно или не будет работать, или будет жрать как не в себя, или будет тормозить.
R>Это не "плохой код", а "код на выброс": одним коммитом добавили, а потом вторым — удалили. Он не диктует дизайн, и не повлияет на сопровождаемость кодовой базы.
Ахаха, ну конечно, "на выброс". Этот код переживет весь остальной код в проекте! Причем в неизменном виде. Под соусом "когда в следующий раз понадобится, код у нас уже есть".
R>Бесполезно статистику сравнивать — что у вас, что у меня слишком маленькая выборка. Из всех программистов, с которыми мне довелось работать, ощутимо большая часть была "плохие программисты". Люди с майндсетом "работает — не трогай" и "я свалю раньше, чем легаси станет проблемой". Эти люди просто брали — и с первого дня начинали вносить очевидный технический долг.
Я с таким встречался в сравнительно бедных компаниях, которые не в состоянии нанимать грамотных инженеров. Как правило (*), увеличение стоимости специалиста существенным образом снижает вероятность упомянутого поведения.
R>Моя точка зрения такая, что не все могут эффективно работать с существующим кодом.
Хм, а вы на собеседованиях что проверяете? Может ли программист написать сортировку? Или нечто подобное?
(*) бывают исключения из правила "дороже — лучше", но обычно с другими перекосами. Например, запредельной производительностью в плане выдаваемых строк кода. В некоторых компаниях даже определяют "архетипы" инженеров. И архетип "кодинг машин" — вполне себе встречается.
Здравствуйте, CreatorCray, Вы писали:
R>>Какое нахрен наслоение многочисленных мёржей? CC>А такое. Тут чуть чуть поменяли, тут чуть чут добавили. Потом смотришь на это всё и понимаешь где можно что выровнять, что то вынести и сделать более generic. CC>Инкрементальные изменения они такие.
Изменения — инкрементальные, а смотреть нужно всегда на общую картину.
R>> Мёрж, даже если в нём нет конфликтов, требует ревью. CC>Ревью всегда фокусируется на изменениях а не на более общей картине.
Нет, это абсолютно неверно. Нужно быть достаточно запущенным наркоманом, чтобы интересоваться правками в отрыве от того, к чему эти правки применяются. Правки сами по себе не работают. Любые правки должны переводить систему из одного адекватного состояния в другое — и на код ревью смотреть нужно в первую очередь на это.
R>>Как определяете, что требования устаканились? CC>Строго на глаз, есессна.
Здравствуйте, rosencrantz, Вы писали:
R>Изменения — инкрементальные, а смотреть нужно всегда на общую картину.
На ревью смотрят на диффы.
Ну и когда делают изменения то тоже стараются свести изменения к необходимому минимуму.
Рефакторинг банально геморно мержить когда в полёте куча других изменений, которым твой рефакторинг сломает merge.
R>Нет, это абсолютно неверно. R>в отрыве от того, к чему эти правки применяются.
Ты опять не понял про что я.
R>>>Как определяете, что требования устаканились? CC>>Строго на глаз, есессна. R>Ясно
У нас банально есть стадия когда принимаются только багфиксы, и то не всё подряд, а только на одобренные баги, чтоб не было "переименуем порося в карася" т.е. фичу назовём багфиксом.
Хочешь что то в фиче поменять — свободен, вали в следующий релиз. Твой pull request просто интеграторы не примут и в мастер не смержат.
Есессна к этому моменту всё должно быть готово, так что посылать в пешее эротическое всяких ходоков с хотелками начинаем задолго до, исходя из реалистичности сроков.
Так что да, именно строго на глаз.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
