Здравствуйте, rosencrantz, Вы писали:

R>Адекватный рефакторинг делается "заодно" — и критерием успешности выступает не чувство прекрасного, а какая-то очередная фича, которая сделана не "через жопу", а "органично".

А как в адекватных командах проводят это "заодно"? Его хоть можно отдельным коммитом провести с честным комментарием, что это именно рефакторинг? Или делаем новую фичу/затыкаем багу, а к коммиту тихой сапой кусочек рефакторинга прикрепляем?

R>Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить. А неправ — я, потому что дал первому свободу, а второго — заапрувил.

По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).

Здравствуйте, SkyDance, Вы писали:

R>>Так а в чём менеджер виноват? Задача менеджера — обеспечить приток требований — и отток релизов/демок.

SD>Традиционно считается, что это работа product manager.

Это зависит исключительно от того, кто собрал команду и из кого. На моей последней работе были и product manager ("видение продукта") и project manager ("бегать с палкой за людьми, чтобы в джире во время появились юзер сториз, чтобы спринт плэнинг состоялся, и т.д.") Когда я говорю "менеджер", я говорю о человеке, который не пишет код, а отвечает за пайплайн хотелки->релизы.

SD>О нет, как правило, "эти люди" ВЫНУЖДЕНЫ писать какие-то кривулины из-за того, что у них есть ограничения. Например, неподходящий для проекта язык. Как тебе, например, Python в качестве языка для высоконагруженного веб-приложения? Так что нужно по отдельному серваку на каждую сотню concurrent users просто для stateless операций с соединениями?

Я не вижу проблемы с Питоном и "по серваку на 100 юзеров". Ну навязали архитектуру, которая вам кажется неудачной в плане жирности инфраструктуры и денег. Ваша роль в проекте какая? Зачем вы заводитесь так, будто вам эти серверы нужно будет на своей спине таскать из подвала на 5 этаж без лифта? Или деньги на них у вас прямо из кармана вынимают? Вообще, как это оправдывает "пишем сразу легаси код"? Архитектура зависит от многих факторов, в том числе и от тех, которые программисту могут быть не видны.

SD>"Никак, придумай другой способ"

Это не "плохой код", а "код на выброс": одним коммитом добавили, а потом вторым — удалили. Он не диктует дизайн, и не повлияет на сопровождаемость кодовой базы.

SD>Конечно, бывает кривой код и по другим причинам.

Бесполезно статистику сравнивать — что у вас, что у меня слишком маленькая выборка. Из всех программистов, с которыми мне довелось работать, ощутимо большая часть была "плохие программисты". Люди с майндсетом "работает — не трогай" и "я свалю раньше, чем легаси станет проблемой". Эти люди просто брали — и с первого дня начинали вносить очевидный технический долг.

Моя точка зрения такая, что не все могут эффективно работать с существующим кодом. Майндсет "я сейчас надебажу в какое место в коде мне нужно добавить вот эти 3 строчки" — против майндсета "я сейчас попытаюсь понять на какие допущения завязан существующий код — и перепешу его таким образом, чтобы были те допущения, которые нужны для новой фичи, над которой я работаю". Мне довелось работать со многими программистами, которые предпочитают именно что — "воткнуть 3 строчки в нужное место".

Здравствуйте, Codealot, Вы писали:

C>Еще никому не удавалось избавиться от необходимости выплачивать техдолг. Ну, кроме очевидного варианта свалить. Я уже не один раз видел, как с проекта разом сваливало 3/4 старожилов, оставив подарочек тем, кто не понял, откуда ветер дует, и тем кому потом наймут.

Техдолг, он не как бомба, которая однажды взорвется и все снесет. Техдолг, он как грузы на ногах. Чем его больше, тем тяжелее идти. Но можно удвоить команду и жить с техдолгом (кому-то от этого будет очень противно, и он сметит работу).

Здравствуйте, rosencrantz, Вы писали:

R>Углы и рефакторинг — это либо такая штука, что делаешь её молча, либо, если говоришь вслух, это ругательное слово. Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий.

В итоге проект проживет 2-3 года, может чуть дольше, пока код не превратиться в unsupportable, а менеджер, который до этого довел спокойно сменит работу и начнет пилить аналогичный проект. Правда ведь?

Аё>А может переть от решения загадки, как упростить наслоения оверинжиниринга переизобретенного 5 раз велосипеда, которые все живут их все нужно поддерживать?

От решения как раз может очень даже переть.
Не прет, я так понимаю, решать "человеческие" вопросы, которые непременно возникают. С этих "велосипедов", может, кормилось 5 человек, еще 10 на нем себе карьеру сделали, включая твоего начальника. А ты сейчас этак походя покажешь их профнепригодность.

Такие вопросы вообще мало кого прет решать. Именно поэтому подобными делами и занимаются "программисты высокого уровня". Как указано в заголовке, "мастера трепотни". Они тем и отличаются от обычных программистов, что способны себя заставить пройти через эту трепотню. Преодолеть (или обрулить) сопротивление. Надбавка к их зарплате именно за вредность подобной работы. Стрессы и все такое прочее.

Здравствуйте, rosencrantz, Вы писали:

R>Если код становится всё хуже и хуже, это не менеджер плохой, а программисты.
Нет, и те и те — говно.
Непосредственный манагер, который не над другими манагерами а над девелоперами, которому посрать на то, что происходит в коде — это чистый вредитель.

R>Как правило, эти люди просто в принципе пишут плохо
Куда чаще код портится потихоньку, в результате наслоений многочисленных мержей. Часто ещё и написанных разными людьми и в условиях разной степени срочности.
Я порой даже в своём собственном коде, который кроме меня никто никогда не правил, делаю рефакторинг и разглаживаю "вековые кольца".
А то и вовсе приличный кусок переделывается потому что требования к функционалу совсем устаканились и можно с полной уверенностью вот эти заделы, оставленные чтоб потом можно было проще функционал расширять, выкинуть а логику раскатать катком на более простую и прямолинейную.

Здравствуйте, rosencrantz, Вы писали:

R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.

Угу. Плавали — знаем. Сначала все хорошо — бизнес-идея отличная, клиенты рады, с удовольствием несут бабки, контора растет, манагеры выписывают себе премии и разрабам что-то достается. Потом незаметно разработчики становятся заваленными сапорт-тикетами, времени на новые фичи нет, а рефакторинг, что бы попытаться вытащить продукт из стадии прототипа, не заапрувит менеджер . Клиенты злятся, постепенно уходят, денег поддерживать все то, что понакупили/понанимали в жирные времена нет, урезаем осетра и увольняем людей. А ведь так все хорошо начиналось. Наверняка программисты неправильные попались, завалили такой хороший продукт.

Если что это совсем свежая история из личного опыта.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, rosencrantz, Вы писали:

R>>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.

C>Главное — варить пользователей лягушек медленно, чтобы привыкли.
C>Если весь софт говно, то новый кусок гов софта и выделяться не будет. Ну чуть вонючее чем остальное, и к этому тоже привыкнут.

Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.

R>>*Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра.

C>Зачем послезавтра, если после очередного релиза они разбегутся?

Ваще вы полностью неправы. Не разбегутся если с комфортом всё ок. Просто на задачу "добавить кнопку" скажут, что займёт неделю, месяц, 3 месяца, полгода, и т.д. И проблемы тут нет. Это может звучать нелепо, но проблемы тут нет

C>и тем кому потом наймут.

Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.

Здравствуйте, rosencrantz, Вы писали:

R>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.
Не продукт, а кусок говна. Инвесторы пару лет поплатят, а после то, что они запилят умрет.

А продукты в ИТ — это то что делали в 80-90-х и начале 2000-х. Всё. Всё что позже умирает сразу после родов.

Pzz>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).

Истинно так. Знаю как по другим решениям, так и по своим. Когда с пятого переписывания вместо 2 тысяч строк и сотни патчей появляется файл из 400 строк и лишь с парой фиксов, — оказывается, что решение было слишком простым, чтобы его можно было увидеть с самого начала.

Здравствуйте, Pzz, Вы писали:

Pzz>А как в адекватных командах проводят это "заодно"? Его хоть можно отдельным коммитом провести с честным комментарием, что это именно рефакторинг? Или делаем новую фичу/затыкаем багу, а к коммиту тихой сапой кусочек рефакторинга прикрепляем?

В моих проектах для работы с кодом обычно используется процесс "git flow" — каждая фича делается в отдельном бранче (хоть 1 коммит, хоть 1000), и когда фича по мнению автора готова, делается мёрдж риквест в мастер. Т.е. на код ревью попадает один большой чейнджсет со всеми релевантными изменениями — на это уже все дружно смотрят и пишут комментарии.

Pzz>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).

Это тупой популизм. Нормальное решение не обязано быть понятно студенту-третьекурснику. Нормальное решение обязано быть более-менее понятно всем участникам команды, которые пишут код. Если 4 программиста с опытом, и 1 — третьекурсник, ориентироваться на третьекурсника не на надо, надо ориентироваться на большинство. Третьекурснику надо набираться опыта, читать книжки вне универа, задавать вопросы, и т.д. Если же вся команда (ну, особенно — 4 программиста) не понимают решение, тут нужно разобраться в ком всё-таки проблема — в решении или в программистах. У меня бывали проекты, когда проект — на Java, а команда на Java в жизни ничего не писала. Или в проекте AWS, а команда нихрена не знает про AWS. Я должен на них ориентироваться? Да срать на них. Я сделаю всё возможное, чтобы дать любому желающему возможность "въехать" и стать полезным — и буду сидеть с ними больше 8 часов в день, если это поможет им разобраться. Но если кто-то такой приходит типа "я студент-третьекурсник" — да иди ты на за дверь, без тебя разберёмся.

Здравствуйте, Артём, Вы писали:

Аё>Здравствуйте, SkyDance, Вы писали:

SD>>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).

Аё>Драйв в чём выражается?

В том, что его чувствуешь, когда он есть.

Здравствуйте, rosencrantz, Вы писали:

R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.

Главное — варить пользователей лягушек медленно, чтобы привыкли.
Если весь софт говно, то новый кусок гов софта и выделяться не будет. Ну чуть вонючее чем остальное, и к этому тоже привыкнут.

R>*Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра.

Зачем послезавтра, если после очередного релиза они разбегутся?
Еще никому не удавалось избавиться от необходимости выплачивать техдолг. Ну, кроме очевидного варианта свалить. Я уже не один раз видел, как с проекта разом сваливало 3/4 старожилов, оставив подарочек тем, кто не понял, откуда ветер дует, и тем кому потом наймут.

Здравствуйте, Abalak, Вы писали:

A>В итоге проект проживет 2-3 года, может чуть дольше, пока код не превратиться в unsupportable, а менеджер, который до этого довел спокойно сменит работу и начнет пилить аналогичный проект. Правда ведь?

Так а в чём менеджер виноват? Задача менеджера — обеспечить приток требований — и отток релизов/демок. Если код становится всё хуже и хуже, это не менеджер плохой, а программисты. Слово "рефакторинг" все знают с 5-летнего возраста, но многие думают, что это такое самостоятельное занятие. Как правило, эти люди просто в принципе пишут плохо, и думают, что однажды им дадут время привести всё в порядок — и они *тогда* приведут всё в порядок. И, как правило, если это время им дать, ничерта они в порядок не приведут, потому что в принципе не понимают по каким критериям это делается. Были бы они способны определить такие критерии, сразу бы писали нормально.

R>Я не вижу проблемы с Питоном и "по серваку на 100 юзеров".

Суслика я тоже не вижу. А он есть.

R>Вообще, как это оправдывает "пишем сразу легаси код"?

Потому что "архитектура" (ага, в кавычках) не позволяет написать иначе. Оно или не будет работать, или будет жрать как не в себя, или будет тормозить.

R>Это не "плохой код", а "код на выброс": одним коммитом добавили, а потом вторым — удалили. Он не диктует дизайн, и не повлияет на сопровождаемость кодовой базы.

Ахаха, ну конечно, "на выброс". Этот код переживет весь остальной код в проекте! Причем в неизменном виде. Под соусом "когда в следующий раз понадобится, код у нас уже есть".

R>Бесполезно статистику сравнивать — что у вас, что у меня слишком маленькая выборка. Из всех программистов, с которыми мне довелось работать, ощутимо большая часть была "плохие программисты". Люди с майндсетом "работает — не трогай" и "я свалю раньше, чем легаси станет проблемой". Эти люди просто брали — и с первого дня начинали вносить очевидный технический долг.

Я с таким встречался в сравнительно бедных компаниях, которые не в состоянии нанимать грамотных инженеров. Как правило (*), увеличение стоимости специалиста существенным образом снижает вероятность упомянутого поведения.

R>Моя точка зрения такая, что не все могут эффективно работать с существующим кодом.

Хм, а вы на собеседованиях что проверяете? Может ли программист написать сортировку? Или нечто подобное?



(*) бывают исключения из правила "дороже — лучше", но обычно с другими перекосами. Например, запредельной производительностью в плане выдаваемых строк кода. В некоторых компаниях даже определяют "архетипы" инженеров. И архетип "кодинг машин" — вполне себе встречается.

Здравствуйте, Codealot, Вы писали:

C>С тех пор прошло почти 15 лет, и все стало только хуже.
C>Это также к вопросу о том, почему софт жрет все больше и работает все хуже.

Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт. Команды бывают разные. Где-то интроверт-молчун будет ОК, а где-то просто не зайдёт. Есть команды с уебанскплохим менеджментом, где решения часто принимаются за 2 дня до ожидаемого результата — и там надо быть болтливым и соображать быстро. ГовнПлохи ли такие команды? Да конечно плохи. Но есть такие? Да конечно. И зарплату там вполне платят. Надо понимать, что любой бизнес — это баланс между зарплатой и прибылью. Если на мудастранных работниках получается поймать баланс, то бизнес — хороший. Что не всем заходит быть внутри такого — это понятно, и тут спорить не о чем.

Здравствуйте, rosencrantz, Вы писали:

R>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.

Прототип они быстро запилят, а не продукт. Потом будут долго и упорно пытаться сделать из этого говна пулю, не смогут, и хренак-хренак в продакшен что получилось. Быстро поменяют место работы. И все с начала.
Много раз уже такое видел.

Здравствуйте, rosencrantz, Вы писали:

R>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.

Ряд 1 + 1/2 + 1/4 + ... сходится, у него есть предел, равный двум.

У меня есть подозрение, что разработка продукта, который обрастает техдолгом, с которым никто не собирается бороться, а просто смиряются, что добавление кнопки занимает 2 месяца, а не два часа, тоже сходится. Т.е., такой продукт можно разрабатывать годами, будут какие-то новые версии, новые фичи. Но глядя трезвым глазом, у него есть потолок, которого ему никогда не преодолеть.

Хорошо ли от этого бизнесу? Ну в принципе, может быть хорошо. Мы видели много загнивающих и в конце концов ушедших технологий, которые, тем не менее, за время своей жизни приносили доход. Бизнес такое может пережить, если он способен прожить дольше, чем те продукты, которые его кормят, создавая новые продукты. И не способен, если он зависит от имеющегося набора продуктов, и новые создавать не способен.

Аё>Драйв в чём выражается?

В том, что тебя лично прет от решения реально интересной загадки. Это может быть что угодно, от поисков этого несчастного байта (был где-то юмористический рассказ эмбеддед-девелопера про размеры программы), до выяснения, куда течет память в .NET сервисе. И до создания по-настоящему лаконичного UI. В этом смысле мне ну очень импонирует стиль Tesla, очень лаконичный снаружи.

Но вот что у них внутри, это жжжесть. Причем понятно, почему — снаружи все тот же Маск может рявкнуть "ну-ка, немедленно спрятать лючок зарядника". А внутри, в программном коде, так сразу и не заметить все переплетения спагетти.

Здравствуйте, rosencrantz, Вы писали:

R>Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.

Зачем экзотику? Достаточно просто не срезать слишком много углов, не пытаться экономить на рефакторинге и так далее.

Да просто тошно. Как участвовать в написании, так и пользоваться. Мы ведь здесь не совещание о стратегии проводим, а просто говорим за жизнь?

R>Ваще вы полностью неправы. Не разбегутся если с комфортом всё ок. Просто на задачу "добавить кнопку" скажут, что займёт неделю, месяц, 3 месяца, полгода, и т.д. И проблемы тут нет. Это может звучать нелепо, но проблемы тут нет

Полностью прав, потому что разбегаются. Раздолбаи — в первую очередь.

R>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.

Ты явно говоришь не о том же, о чем я. Видимо, до твоих краев эта чума еще не докатилась, так что ты с этим просто не сталкивался.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, rosencrantz, Вы писали:

R>>Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.

C>Зачем экзотику? Достаточно просто не срезать слишком много углов, не пытаться экономить на рефакторинге и так далее.

Углы и рефакторинг — это либо такая штука, что делаешь её молча, либо, если говоришь вслух, это ругательное слово. Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий. "Делать лучше" можно до бесконечности. И самое печальное всегда, что это "лучше" — это обычно мнение программиста Васи ("теперь я понимаю как это работает"), а не какой-то явный критерий ("выкинули нахер все instanceof"). Адекватный рефакторинг делается "заодно" — и критерием успешности выступает не чувство прекрасного, а какая-то очередная фича, которая сделана не "через жопу", а "органично".

C>Да просто тошно. Как участвовать в написании, так и пользоваться. Мы ведь здесь не совещание о стратегии проводим, а просто говорим за жизнь?

Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить. А неправ — я, потому что дал первому свободу, а второго — заапрувил.

R>>Все проблемы от того, что технология не может договориться с менеджерами.

C>Ты явно говоришь не о том же, о чем я. Видимо, до твоих краев эта чума еще не докатилась, так что ты с этим просто не сталкивался.

Вы на флажок смотрите чтоли? Я по 8 лет отработал тимлидом в России и в Америке. Примерно один хрен. В Америке сильнее держутся за место, потому что тут работа кроме зарплаты даёт ещё плюшки. Например, страховку (это без работы *минимум* ~$500 в месяц из кармана), и proof of income (приходишь снимать квартиру, тебе говорят: не нужны нам твои поганые $36,000 наличными из кармана — ты там покажи что тебе зарплату в следующем месяце заплатят)

Здравствуйте, rosencrantz, Вы писали:

R>Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий.

Говнокодеры — независимо от уровня в иерархии — не понимают, что такое "объективно лучше".

R>Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить.

Все трое. Делать решения "чтобы было по книжке" и тащить в проект ненужные паттерны и фреймворки — признак программиста, который в развитии добрался только до уровня продвинутого ламера. Те, кто книжки не читают — еще хуже. А так же тимлиды, которые не понимают зачем нужна документация и нанимают тех, кого нанимать не надо.

R>Вы на флажок смотрите чтоли? Я по 8 лет отработал тимлидом в России и в Америке. Примерно один хрен.

Значит, недостаточно отработал. В разных компаниях тараканы разных пород. Куда-то тараканы новых пород уже добрались, куда-то нет.

Но на самом деле ты споришь вообще не с тем, о чем я написал.

R>*Комфорт* важен. *Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра. Если комфорта нет, оно неделю отработает, а дальше будет рушиться. *Охренненно* важен баланс.

Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).

Здравствуйте, Abalak, Вы писали:

A>Здравствуйте, rosencrantz, Вы писали:

R>>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.

A>Если что это совсем свежая история из личного опыта.

Бывает. Но мы же тут все взрослые люди — и не будем из этого делать далеко идущие выводы? У меня бывало что некий самостоятельный сеньорный программист что-то там программировал-программировал, и потом начал жаловаться, что оно в ночь с 31 декабря на 1 января стало легаси, и всё надо переписывать. А потом свалил в соседнюю компанию. Менеджеры плохие попались?

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, rosencrantz, Вы писали:

R>>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.

Pzz>Ряд 1 + 1/2 + 1/4 + ... сходится, у него есть предел, равный двум.

Полностью мысль напишите. 2 часа, 2 недели, ряд сходится к 2. Какой вывод? Инь и янь? Мужчина и женщина? Код и его отсутствие?

Pzz>У меня есть подозрение, что разработка продукта, который обрастает техдолгом, с которым никто не собирается бороться, а просто смиряются, что добавление кнопки занимает 2 месяца, а не два часа, тоже сходится. Т.е., такой продукт можно разрабатывать годами, будут какие-то новые версии, новые фичи. Но глядя трезвым глазом, у него есть потолок, которого ему никогда не преодолеть.

У программистов (особенно молодых) часто есть потолок: "если мне говорят делать быстро, я буду делать быстро, ведь мне говорят, а значит это важно". Тут у нас вопрос: как программисту одновременно и программировать хорошо, и не стать рабом своей работы? Не так сложно писать охухороший код без техдолга. Сложно при этом жить хоть как-то за пределами работы — и не выгореть за пару лет.

Pzz>Хорошо ли от этого бизнесу? Ну в принципе, может быть хорошо. Мы видели много загнивающих и в конце концов ушедших технологий, которые, тем не менее, за время своей жизни приносили доход. Бизнес такое может пережить, если он способен прожить дольше, чем те продукты, которые его кормят, создавая новые продукты. И не способен, если он зависит от имеющегося набора продуктов, и новые создавать не способен.

Ни разу не сталкивался, чтобы говнокод (техдолг) был большой проблемой. Либо бизнеса нет — и есть попытка запилить продукт, вокруг которого позже построить бизнес. Либо бизнес есть — и что там с продуктом происходит — не так важно. Такого чтоб "мы к сожалению не запилили фичу во время, поэтому бизнес в жопе, я рекомендую всем прямо сейчас обновить резюме и начать искать новую работу" — тоже никогда не видел. Но вообще вы пишете не про то, про что я писал. Моя мысль — в том, что если продукт менеджер с дизайнерами летает в облаках и периодически на землю сбрасывает какие-то офигенные идеи — у программистов не получится под это эффективно подстраиваться. Должен быть постоянный диалог. Программисты должны понимать степень ебанубезумия дизайнеров, и дизайнеры должны понимать какая фича сколько будет "стоить".

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, rosencrantz, Вы писали:

R>>Как правило, эти люди просто в принципе пишут плохо
CC>Куда чаще код портится потихоньку, в результате наслоений многочисленных мержей.

Какое нахрен наслоение многочисленных мёржей? Мёрж, даже если в нём нет конфликтов, требует ревью. Если всё само гладко смёржилось, это всё равно ответственность программиста — убедиться, что результат осмысленный. А уж если мёрж с конфликтами — это вообще 100% ответственность девелопера довести код до идеального состояния перед коммитом.

CC>Часто ещё и написанных разными людьми и в условиях разной степени срочности.

Срочность — это такое когнитивное искажение у программистов. Когда говорят "нужно срочно", это не означает, что надо делать плохо. Это означает, что если ты вместо 5 перекуров мог бы сходить на 4, это было бы здорово. Когда кто-то при слове "срочно" начинает нарушать вообще всё, что можно нарушить — это просто профессионал — говно. Для таких людей нужно в туалетах вешать таблички: "помойте руки", а то не дай бог они после слова "срочно" в туалет пойдут.

CC>Я порой даже в своём собственном коде, который кроме меня никто никогда не правил, делаю рефакторинг и разглаживаю "вековые кольца".
CC>А то и вовсе приличный кусок переделывается потому что требования к функционалу совсем устаканились и можно с полной уверенностью вот эти заделы, оставленные чтоб потом можно было проще функционал расширять, выкинуть а логику раскатать катком на более простую и прямолинейную.

Как определяете, что требования устаканились?

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 (делят, кому владеть каким-то выгодным проектом), или где люди попросту не могут выпрямть корявости соседних команд.

Здравствуйте, CreatorCray, Вы писали:

CC>Так что да, именно строго на глаз.

Ясно. Продолжай обобщать свой проект на всю индустрию

Здравствуйте, rosencrantz, Вы писали:

R>Продолжай обобщать свой проект на всю индустрию
Я тебе щас страшную тайну открою: ни Деда Мороза ни серебряной пули не существует! А вода — мокрая!

Здравствуйте, CreatorCray, Вы писали:

R>> Мёрж, даже если в нём нет конфликтов, требует ревью.
CC>Ревью всегда фокусируется на изменениях а не на более общей картине.

Эээ. Когда у тебя опенсорсный проект и тебе присылают PR-ы, всегда смотришь на общую картину. Потому, что это тебе потом с этим кодом жить, а не им.

Вот такое ревью имеет смысл.

А эти вот, когда вообще только на diff по диагонали смотрят, какой в таком ревью смысл вообще? Только помериться друг с другом пиписьками, тратя на это время, щедро оплаченное работодателем?

All too often a manager recruiting new designers assesses them subconsciously on the criteria for the manager’s own job—“Could he do well the job I’m doing?” This favors the articulate, the leader, the person who will be effective in meetings. It tends to overlook the introvert, the slow-spoken, and especially the unconventional. But brilliant designers come in these packages, too! (I do not assert that brilliant designers are more likely to come in such packages. I don’t know.) We managers overlook these gifted ones to our great loss, theirs, and society’s. How can we select better? First, by reminding ourselves what we seek. Second, by looking at portfolios of the design work itself, not just oral presentations about the work.

The Design of Design. Frederick Brooks

С тех пор прошло почти 15 лет, и все стало только хуже.
Это также к вопросу о том, почему софт жрет все больше и работает все хуже.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, rosencrantz, Вы писали:

R>>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.

C>Прототип они быстро запилят, а не продукт. Потом будут долго и упорно пытаться сделать из этого говна пулю, не смогут, и хренак-хренак в продакшен что получилось. Быстро поменяют место работы. И все с начала.
C>Много раз уже такое видел.

Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.

Я понимаю про что вы говорите, но ценность работника определяется не знанием и опытом, а попаданием в темперамент команды. Распиздяям будет комфортнее работать с распиздяем, чем с педантом, пытающимся разложить по полочкам. *Комфорт* важен. *Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра. Если комфорта нет, оно неделю отработает, а дальше будет рушиться. *Охренненно* важен баланс.

Здравствуйте, rosencrantz, Вы писали:

R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
Вопрос только в том, кто платит.

Здравствуйте, Codealot, Вы писали:

C>

C>Слишком часто менеджер, набирающий новых дизайнеров, подсознательно оценивает их по критериям собственной работы: «Сможет ли он хорошо выполнять ту работу, которую я выполняю?» Это благоприятствует красноречивому, лидеру, человеку, который будет эффективен на собраниях. Он имеет тенденцию упускать из виду интровертов, медлительных людей и особенно нетрадиционных людей. Но в этих упаковках есть и блестящие дизайнеры! (Я не утверждаю, что блестящие дизайнеры чаще приходят в таких пакетах. Не знаю.) Мы, менеджеры, упускаем из виду этих одаренных людей, к своей большой утрате, их и общества. Как мы можем выбрать лучше? Во-первых, напоминая себе, чего мы ищем. Во-вторых, просматривая портфолио самих дизайнерских работ, а не только устные презентации о работе.

Чтобы просмотреть работы других людей нужно самому что-то соображать. То есть дизайнер оценивает дизайнера, программист оценивает программиста и так далее. Причём люди должны иметь одинаковую специализацию.

Может ли специалист по векторной графике оценить специалиста по растровой графике и наоборот. Может ли питонист оценить сишника и наоборот. Но ситуация может быть и хуже, оценивать может менеджер потребитель.

Собствено ничего нового здесь нет. Две разные команды и даже два разных человека по одному заданию напишут две разные программы. Ещё говорят 90% стартапов проваливаются. Это уже к вопросу о том почему мегакорпорации предпочитают покупать проекты, а не пилить их самостоятельно с нуля.

А в самом начале своего пути практически все являются плохими программистами. Некоторым удаётся стать лучше с годами и десятилетиями, а некоторым нет. Но даже хорошему специалисту на создание качественного продукта понадобится много времени.

По большому счёту никого работодатели не упускают. Просто они не имеют никакого отношения к становлению специалистов и следовательно не умеют их определять.

Чтобы человек стал специалистом ему или кто-то должен платить за работу годами и десятилетиями, или он должен столько же самообучаться, но уже за свой счёт.

Работодатель же не вложив в этого специалиста ни копейки, а напротив тратя его время вдруг начинает жаловаться, что упустил "нетрадиционного слоупока". Вместо него он нанимает хитрого болтуна.

После найма нескольких болтунов до работодателя вдруг доходит, что хорошо бы посмотреть предыдущие работы людей, да и в принципе оценить их технические, а не разговорные навыки.

Но всё сводится к тому, что работодатель всё равно не сможет действовать лучше, чем самый его компетентный сотрудник. Зато он запросто может действовать как его самый некомпетентный сотрудник.

Менеджерам из таких же ничего не соображающих болтунов проще навесить на других какой-то ярлык вроде "медленный нетрадиционый интроверт". Честно признаться, что они сами нубло проникшее в компанию за счёт болтовни они естественно не могут.

Как говорится "..ть не мешки ворочить". Нет у людей элементарного понимания, что на создание качественных продуктов нужно очень много времени. И дело здесь не в интровертности и слоупочности.

Не нужно воспринимать состоявшихся специалистов с 10-20 летним опытом как данность. То что к кому-то в первый же день заглянуло несколько сотен скилбоксовых стажёров не значит, что придёт хотя бы один "слоупочный интроверт".

И если раньше говорят учили врать людей на аутсорсинге, то теперь этому учат на платных курсах. А многие работодатели как известно не ценят сотрудников. У них за забором, то есть на сайте поиска работы стоит очередь.

Здравствуйте, Pzz, Вы писали:

Pzz>Техдолг, он не как бомба, которая однажды взорвется и все снесет. Техдолг, он как грузы на ногах. Чем его больше, тем тяжелее идти. Но можно удвоить команду и жить с техдолгом (кому-то от этого будет очень противно, и он сметит работу).

Скорее не взорвется, а потянет всех ко дну. Увеличение команды тоже помогает только в определенных пределах, особенно если организовано все через жопу.

Здравствуйте, SkyDance, Вы писали:

SD>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).

Драйв в чём выражается?

Здравствуйте, SkyDance, Вы писали:

SD>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).

Какого рода драйв, типа преодолевать бардак или что?

Здравствуйте, SkyDance, Вы писали:

Pzz>>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).
SD>Истинно так. Знаю как по другим решениям, так и по своим. Когда с пятого переписывания вместо 2 тысяч строк и сотни патчей появляется файл из 400 строк и лишь с парой фиксов, — оказывается, что решение было слишком простым, чтобы его можно было увидеть с самого начала.

Целая книжка и курс про это есть -- https://web.stanford.edu/~ouster/cgi-bin/book.php
Можно автора на yt найти, с кратким содержанием. Но вроде эту книгу уже обсуждали тут когда-то.

S>Какого рода драйв, типа преодолевать бардак или что?

Не-не-не, преодолевать бардак — это почти всегда попытки построить драйв в болоте. Да, в отдельно взятом уголке болота на некоторое время драйв может и возникнуть. Но быстро угаснет, т.к. болото (и бардак) — противоположность драйву.
Драйв — это когда ты точно знаешь, что делаешь, и почему. И когда имеешь контроль над всеми компонентами уравнения, — а стало быть, можешь решать проблему, а не искать обходные пути вокруг вот той команды, и вот этой обязательной библиотеки (потому что там работает сын владельца), или вот этого "стандарта" (который двигает зять жены владельца).

Драйв — это вот: https://habr.com/ru/articles/27055/

Здравствуйте, rosencrantz, Вы писали:

R>Какое нахрен наслоение многочисленных мёржей?
А такое. Тут чуть чуть поменяли, тут чуть чут добавили. Потом смотришь на это всё и понимаешь где можно что выровнять, что то вынести и сделать более generic.
Инкрементальные изменения они такие.

R> Мёрж, даже если в нём нет конфликтов, требует ревью.
Ревью всегда фокусируется на изменениях а не на более общей картине.

R>убедиться, что результат осмысленный.
А он осмысленный.

R> А уж если мёрж с конфликтами — это вообще 100% ответственность девелопера довести код до идеального состояния перед коммитом.
Ты не понял про что я.

R>Когда говорят "нужно срочно", это не означает, что надо делать плохо.
Спасибо, кэп!

R>Как определяете, что требования устаканились?
Строго на глаз, есессна.

Здравствуйте, SkyDance, Вы писали:

SD>Или, еще интереснее, есть какая-то "инфра", которая напрочь кривая.
Тема борьбы с security идиотами это вообще отдельная песнь.
У них цель законопатить всё, включая рот и ноздри, а на вопрос "а как дышать" они пожимают плечами и не парятся, у них то всё теперь в безопасности.

SD>Конечно, бывает кривой код и по другим причинам.
Коллега из другой компании поделился историей как их местные идиоты проверяли можно ли писать на диск путём порчи нескольких мегабайт в рандомном месте на нём, с соответствующими последствиями для данных на этом диске.

Здравствуйте, CreatorCray, Вы писали:

R>>Какое нахрен наслоение многочисленных мёржей?
CC>А такое. Тут чуть чуть поменяли, тут чуть чут добавили. Потом смотришь на это всё и понимаешь где можно что выровнять, что то вынести и сделать более generic.
CC>Инкрементальные изменения они такие.

Изменения — инкрементальные, а смотреть нужно всегда на общую картину.

R>> Мёрж, даже если в нём нет конфликтов, требует ревью.
CC>Ревью всегда фокусируется на изменениях а не на более общей картине.

Нет, это абсолютно неверно. Нужно быть достаточно запущенным наркоманом, чтобы интересоваться правками в отрыве от того, к чему эти правки применяются. Правки сами по себе не работают. Любые правки должны переводить систему из одного адекватного состояния в другое — и на код ревью смотреть нужно в первую очередь на это.

R>>Как определяете, что требования устаканились?
CC>Строго на глаз, есессна.

Ясно

Здравствуйте, rosencrantz, Вы писали:

R>Изменения — инкрементальные, а смотреть нужно всегда на общую картину.
На ревью смотрят на диффы.
Ну и когда делают изменения то тоже стараются свести изменения к необходимому минимуму.
Рефакторинг банально геморно мержить когда в полёте куча других изменений, которым твой рефакторинг сломает merge.

R>Нет, это абсолютно неверно.
R>в отрыве от того, к чему эти правки применяются.
Ты опять не понял про что я.

R>>>Как определяете, что требования устаканились?
CC>>Строго на глаз, есессна.
R>Ясно

У нас банально есть стадия когда принимаются только багфиксы, и то не всё подряд, а только на одобренные баги, чтоб не было "переименуем порося в карася" т.е. фичу назовём багфиксом.
Хочешь что то в фиче поменять — свободен, вали в следующий релиз. Твой pull request просто интеграторы не примут и в мастер не смержат.

Есессна к этому моменту всё должно быть готово, так что посылать в пешее эротическое всяких ходоков с хотелками начинаем задолго до, исходя из реалистичности сроков.
Так что да, именно строго на глаз.

Здравствуйте, CreatorCray, Вы писали:

CC>Тема борьбы с security идиотами это вообще отдельная песнь.
CC>У них цель законопатить всё, включая рот и ноздри, а на вопрос "а как дышать" они пожимают плечами и не парятся, у них то всё теперь в безопасности.

О да. Совсем недавно наблюдал, как при соблюдении требований безопасности было бы невозможно работать вообще.

Здравствуйте, rosencrantz, Вы писали:

R>Менеджеры плохие попались?

Да. Менеджеры решают, кого нанимать. Взрослые люди не обвиняют других людей за свои собственные решения.

Здравствуйте, Codealot, Вы писали:

C>О да. Совсем недавно наблюдал, как при соблюдении требований безопасности было бы невозможно работать вообще.
Это у них постоянно
"Наиболее безопасный комп это обесточенный и залитый бетоном" (С)

Здравствуйте, SkyDance, Вы писали:

Аё>>Драйв в чём выражается?

SD>В том, что тебя лично прет от решения реально интересной загадки. Это может быть что угодно, от поисков этого несчастного байта (был где-то юмористический рассказ эмбеддед-девелопера про размеры программы), до выяснения, куда течет память

А может переть от решения загадки, как упростить наслоения оверинжиниринга переизобретенного 5 раз велосипеда, которые все живут их все нужно поддерживать?

Еще вопрос- тех дизайн 6 велосипед, я говорю- это ###ня, и получаю вызов на ковёр "ты не в контексте и непонимаешь, почему нельзя сделать проще". Что мне лучше- войти в контекст, написать 7 велосипед чтоб доказать- да ребятки, вы пороли ###ню.?

Здравствуйте, Артём, Вы писали:

Аё>А может переть от решения загадки, как упростить наслоения оверинжиниринга переизобретенного 5 раз велосипеда, которые все живут их все нужно поддерживать?

Может, но подавляющее большинство не будет.
Плюс к этому менеджеры очень не любят попытки взять и переделать, особенно если они оказались успешными. Так что по голове тебя не похвалят, а вполне вероятно, что это плохо скажется на твоей карьере.

Здравствуйте, SkyDance, Вы писали:

SD>Именно поэтому подобными делами и занимаются "программисты высокого уровня". Как указано в заголовке, "мастера трепотни".

А ты вообще ничего не понял.

Здравствуйте, SkyDance, Вы писали:

SD>От решения как раз может очень даже переть.
SD>Не прет, я так понимаю, решать "человеческие" вопросы, которые непременно возникают. С этих "велосипедов", может, кормилось 5 человек, еще 10 на нем себе карьеру сделали,

Исторические наслоения. Теперь с этого кормится 3 чела (условно), бизнес хочет втыкать фичи и регулярно релизить. Ну и я такой дартаньян типа- надо было диктатурой удерживать 1 велосипед на все проекты и ничего нового не добавлять без полного переписывания старого.