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

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

G>Если качество будет лучше оптимального — это плохо. Долго и дорого создаваемое решение еще будет поддерживаемо, но уже морально устареет, или потребности бизнеса изменятся. И оно будет выведено из эксплуатации. То есть, по факту, потраченное время (которое — деньги) будет выброшено.

G>Если качество будет хуже оптимального — тоже плохо по понятным причинам.

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

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

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

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

А нанять ровно тех ровно за ту цену, какую ты хочешь — ну рынок труда так не работает, ты работаешь с теми, кто там есть.

Я вот за себя могу сказать, что мне неприятно работать на проектах, где заведомо занижается качество. Я могу откладывать какие-то вещи в технический долг, но на некоторых я экономить не хочу. И если я буду вынужден это делать, наверное я подумаю про новую работу. Даже если я буду согласен с тем, что объективно тут качество не нужно. Ну такие вот у меня тараканы, извините, какой вырос, другим уже не вырасту.

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

G>Я люблю сравнивать разработку софта с конструктором из детских кубиков.

Осталось за малым и разработать норматив горизонта планирования и составить метрики "бережно- не бережно".
А из практики.
1.5 месячная поделка, легко может превратиться в 3-4 летнего плотно разрабатываемого монстра.
А "вечный проект", может заглохнуть ч/з 3 месяца после первого релиза.

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

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

Обладаю.
Но нервное это дело.
Пример из жизни: году где-то в 18 полез участвовать в Russian AI Cup. Полез за сутки до окончания отборочного этапа, который длился две недели. Фигак-фигак — и в продакшен. Попал в следующий этап. Потом какой-то код выкинул, что-то добавил, туда-сюда, попал в финал. Но дальше слился )

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

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

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

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

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

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

Ты не уточнил.
Если качественный код для себя, то разница не большая, 5-10% от времени, не более
Если код на продажу или для ревью, то:
1. Нужны стандарты оформления кода
2. х1,5, х2 ко времени или больше.

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

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

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало?

Таким навыком обладаю, но не в совершенстве.

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

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

scf>>Намного быстрее. Быстрое решение делается на питоне — загуглить IMAP библиотеку и нарисовать скрипт.

S>А почему именно на Python? Все сводится к вызову функций в популярных библиотеках — думаете слишком по-разному эти функции вызываются в Python или том же Java/C#?

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

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

В каком-то смысле обладаю...

S>Насколько быстрее, по вашим оценкам, вы сможете сделать просто рабочее решение, в сравнении с правильным решением по всем канонам?

Раз в десять быстрее, но надо понимать, что это будет программа совсем другой архитектуры.
Ну как велосипед по сравнению с автомобилем. Вроде и там и там есть колёса, но это совсем другое.

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

S>А почему именно на Python? Все сводится к вызову функций в популярных библиотеках — думаете слишком по-разному эти функции вызываются в Python или том же Java/C#?

Для джавы/шарпа нужно запускать IDE, настраивать систему сборки, компилировать в jar/exe. Плюс, нагуглить сниппет на питоне для типичной задачи намного проще, в джаве как правило найдёшь только нужную библиотеку, в то время как в питоне pip install и 3 строчки кода, всё уже в комплекте на stack overflow.

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

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

G>>Я люблю сравнивать разработку софта с конструктором из детских кубиков.

AWS>Осталось за малым и разработать норматив горизонта планирования и составить метрики "бережно- не бережно".
AWS>А из практики.
AWS>1.5 месячная поделка, легко может превратиться в 3-4 летнего плотно разрабатываемого монстра.
AWS>А "вечный проект", может заглохнуть ч/з 3 месяца после первого релиза.

Может. В этом мире все может.
Но изначально бизнес приходит с какой-то хотелкой, и ты ему задаешь всякие вопросы.
И если просят сделать поделку, ты делаешь, но заранее всех и вся предупреждаешь, что это одноразовая поделка. Это прототип.
И надо донести до бизнеса, чтобы они поняли, и заранее согласились, что в случае серьезного развития надо будет прототип выкинуть и сделать все с нуля по новым требованиям. Если надо — то с аналогиями. Типа, "ты же не сядешь в самолет, который является экспериментальным прототипом? Ты хочешь летать на серийных, проверенных самолетах".

Предвижу массу аргументов простив такого подхода. Начиная с того, что бизнес "не поймет", "не согласится" и заканчивая тем, что потом бизнес "передумает" а то и вовсе "забудет".

На это могу сказать две вещи: 1) надо качать свое умение доносить до бизнеса. 2) не надо работать с идиотами, которые не поймут, и подлецами, которые все поймут но потом тебя подставят.
Заметь, этот вопрос уже ни разу не в технической плоскости ))

AWS>И если привыкаешь работать на "отъе..сь", то так и начинаешь работать, даже когда сам понимаешь, что это супер важный продукт, а все потому что когда работал на "отъе..сь", все время тренировал этот навык.
Я на практике видел, как от отсутствия опыта люди не "фигак-фигак и в продакшен", а наоборот, стремятся сделать все "правильно" и в результате настолько переусложняют проект, что он все равно становится big ball of mud. Как говориться: "бывает, что усердие превозмогает и рассудок".
Найти грань, когда архитектура минималистична, лаконично, но продукт выполняет свою функцию и хорошо поддерживается и расширяется — это искусство ))

AWS>Поэтому если нужно умение делать архитектуру, планирование, возможности расширения, то такое нужно делать на малых задачах, так как это все тот же навык, который мы тренируем.

Нужно, никто и не спорит.
Более того, умение сделать по-правильному на малых задачах важно, чтобы в тебя поверили и к тебе прислушались на больших задачах.
Пример из жизни: мне достался микросервис от чувака, который его за 2 недели нафигачил. Потому что бизнес хотел быстрее. А так как микросервис был важен, и требовал расширения функционала — созрела идея его переписать. Я сказал, что мне надо 5 недель. По факту получилось 6. Бизнес был не очень доволен, но что же делать. За время внедрения нашлось 2 бага (один мой, один в требованиях)
А спустя год, за которые было около 10 серьезных инцидентов, и все они были из-за смежников — начальство совсем по-другому смотреть на тройные трудозатраты на разработку. И стало верить мне, когда я озвучивал затраты на более серьезный проект.

Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

Насколько быстрее, по вашим оценкам, вы сможете сделать просто рабочее решение, в сравнении с правильным решением по всем канонам?

Если вам на вашей текущей работе дают мелкое задание. Давайте, для примера, возьмем такое практическое задание:

Сделать консольную прогу, которая достанет из email-ящика по IMAP-протоколу все аттачи а на сервере их удалит. Запускаем с флагом -download — скопирует с mail все аттачи в папку на компе, запускаем с флагом -cleanup — удалит из из писем на сервере аттачи а текстовую часть писем — оставит.

Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

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

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?
Надо брать питон, готовое что-то без оглядки на лицензии и сделать. Ну пусть будет дня 3, например, хотя может уйти пол дня если всё из коробки заработает.

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

S>>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?
K>Надо брать питон, готовое что-то без оглядки на лицензии и сделать. Ну пусть будет дня 3, например, хотя может уйти пол дня если всё из коробки заработает.

А качественный код, чтобы можно было поддерживать и расширять?

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

S>>>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?
K>>Надо брать питон, готовое что-то без оглядки на лицензии и сделать. Ну пусть будет дня 3, например, хотя может уйти пол дня если всё из коробки заработает.

S>А качественный код, чтобы можно было поддерживать и расширять?

А зачем там что-то поддерживать и расширять?

Я, например, в режиме хренак-хренак как-то сделал на плюсиках DSL, который нашей команде кучу времени сэкономил, за месяц-полтора. Код был так себе, но в целом не мешало его потом пару лет дописывать и расширять. В коробочный продукт тот код, само собой, я не стал бы добавлять

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

S>А качественный код, чтобы можно было поддерживать и расширять?
Не ясно в какую сторону расширять, очень мало исходных данных. Предположим, примерно 3 дня минимум, а может и все 5. Нужно поинвестигировать как этот протокол работает чтобы понимать что требовать от библиотеки, подумать над юзкейзами, выбрать язык, библиотеки, придумать минимальную архитектуру, покрыть частично тестами, желательно проверить на тестовых аккаунтах гугла и яху. Я не знаю какие заморочки могут случится с imap, например, какая-нибудь хитрая авторизация или специфика работы с аттачами, негативные сценарии работы, н-р, разрыв соединения при clean... Вот ты говоришь, скопировать все аттачи, а завтра придёт требование чтобы все аттачи сохранялись в то же дерево папок что и на imap сервере.

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

S>Если вам на вашей текущей работе дают мелкое задание. Давайте, для примера, возьмем такое практическое задание:

S>

S>Сделать консольную прогу, которая достанет из email-ящика по IMAP-протоколу все аттачи а на сервере их удалит. Запускаем с флагом -download — скопирует с mail все аттачи в папку на компе, запускаем с флагом -cleanup — удалит из из писем на сервере аттачи а текстовую часть писем — оставит.

Хороший пример теоретически мелкого задания, которое может вылиться в тот еще гимор на практике даже для себя. В принципе на C# написал бы и отладил для рабочих нужд дня за три, может быстрее, может дольше. Это если какого факапа не вылезет, например, окажется, что с конкретным сервером нормально не работают стандартные средства .NET

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

Есть же правило (закон) Парето про 20/80. Просто рабочий на коленке для себя по нему выходит в 20% усилий от качественного (100%) результата.

P.S. Кстати в Outlook вроде есть встроенный VBA для подобных разборов с ящиками, если работа в нем происходит, то наверное самый быстрый вариант будет.

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

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

S>>>>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?
K>>>Надо брать питон, готовое что-то без оглядки на лицензии и сделать. Ну пусть будет дня 3, например, хотя может уйти пол дня если всё из коробки заработает.

S>>А качественный код, чтобы можно было поддерживать и расширять?

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

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

Gt_>этим могут mid и джуны должны заниматься, когда основная идея перед глазами и работает.

Архитектуру Мид не сможет сделать — а архитектура это основное. Причем архитектура может быть и в достаточно мелких проектах. Можно, конечно, все в одной-двух функциях написать и вроде как сделать так быстрее, но иногда оказывается что только кажется — при низком качестве кода отладка занимает больше времени.

Здравствуйте, Shmj, Вы писали:
S>Насколько быстрее, по вашим оценкам, вы сможете сделать просто рабочее решение, в сравнении с правильным решением по всем канонам?

Намного быстрее. Быстрое решение делается на питоне — загуглить IMAP библиотеку и нарисовать скрипт.

Промышленному нужно дополнительно:
— Сборка в исполняемый файл без внешних зависимостей (или документация)
— Конфигурация и валидация конфигурации (хост IMAP, креды, разные виды аутентификации, режимы работы...)
— Логгирование и/или вменяемая индикация работы
— Обработка ошибок
— Тесты
— Документация

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

scf>Намного быстрее. Быстрое решение делается на питоне — загуглить IMAP библиотеку и нарисовать скрипт.

А почему именно на Python? Все сводится к вызову функций в популярных библиотеках — думаете слишком по-разному эти функции вызываются в Python или том же Java/C#?

Gt_>>этим могут mid и джуны должны заниматься, когда основная идея перед глазами и работает.

S>Архитектуру Мид не сможет сделать — а архитектура это основное. Причем архитектура может быть и в достаточно мелких проектах. Можно, конечно, все в одной-двух функциях написать и вроде как сделать так быстрее, но иногда оказывается что только кажется — при низком качестве кода отладка занимает больше времени.

архитектура должна просматриваться уже в прототипе, что у mid перед глазами, плюс общее описание архитектуры в тикете. плюс важные моменты архитектуры будут проговорены в на grooming session. плюс code review. не вижу шансов на творчество у mid в типичном проекте.

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

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

scf>>>Намного быстрее. Быстрое решение делается на питоне — загуглить IMAP библиотеку и нарисовать скрипт.

S>>А почему именно на Python? Все сводится к вызову функций в популярных библиотеках — думаете слишком по-разному эти функции вызываются в Python или том же Java/C#?

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

У меня ваЩе Делфи и что?
В грязном варианте 1 день, ну 1,5, а реально может и пару часов хватит т.к. уже делал такое, какие нафиг 3 дня на змеюке? )))

PS:
Давайте без холивара выбора языка.

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

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

AWS>У меня ваЩе Делфи и что?
AWS>В грязном варианте 1 день, ну 1,5, а реально может и пару часов хватит т.к. уже делал такое, какие нафиг 3 дня на змеюке? )))

Я что-то про три дня говорил?


AWS>PS:
AWS>Давайте без холивара выбора языка.

Ну почему же?
Я вот пишу продакшн на плюсах, но не стал бы их использовать. Думаю, что и если бы джава/шарп были бы моими основными языками, их тоже не стал бы использовать

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

A>Раз в десять быстрее, но надо понимать, что это будет программа совсем другой архитектуры.
A>Ну как велосипед по сравнению с автомобилем. Вроде и там и там есть колёса, но это совсем другое.

А не получится ли так, что сделаете то быстрее, а вот время на отладку — уйдет намного больше?

К примеру, с заданием выше. Вылетает некая ошибка и хрен знает в чем проблема. Ну ОК, добавили логирование. Далее — опять фейл, т.к. в логах указано где возникла проблема, ясно что сторонняя либа не переваривает заголовок, который отдает сервер — но какой именно заголовок — Х.З. Добавляете еще более детальный лог — вроде ОК, но потом опять спотыкается, но уже не на заголовке а на формате тела и т.д.

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

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

A>>Раз в десять быстрее, но надо понимать, что это будет программа совсем другой архитектуры.
A>>Ну как велосипед по сравнению с автомобилем. Вроде и там и там есть колёса, но это совсем другое.

S>А не получится ли так, что сделаете то быстрее, а вот время на отладку — уйдет намного больше?

Ну ты же просил в низком качестве? Вот оно и будет в низком качестве — обрабатывать не любые данные. И плохо обрабатывать ошибки. Именно на обработке некорректных данных и идёт основная экономия.

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

S>А не получится ли так, что сделаете то быстрее, а вот время на отладку — уйдет намного больше?

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

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

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

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало?

А что там уметь? Прототипы так и делаются — применяются самые простые "наивные" алгоритмы в лоб.
В итоге работает так себе, но идею оценить можно.

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

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

У тебя то качественный код, то низкое качество. Надо бы определиться.

Почему бы не пойти другим путем — сделать минимально рабочий вариант? А дальше выяснить, какое качество в него заложить — для этого нужны конкретные причины. Допустим, мой коллега пишет полурабочий вариант с минимальным количеством фич. Мне перенимать у него работу всегда приятно — его код управляемый, хорошо поддается рефакторингу.

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

Веб-сайты так не умею делать и этого мне часто не хватает. Вроде есть куча nocode инструментов вроде django, а я по старинке колпашу.

S>Если вам на вашей текущей работе дают мелкое задание. Давайте, для примера, возьмем такое практическое задание:

S>

S>Сделать консольную прогу, которая достанет из email-ящика по IMAP-протоколу все аттачи а на сервере их удалит. Запускаем с флагом -download — скопирует с mail все аттачи в папку на компе, запускаем с флагом -cleanup — удалит из из писем на сервере аттачи а текстовую часть писем — оставит.

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

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

Вот, кстати, вчера интереса ради накидал JSON-парсер

Автор: νsb
Дата: 02.12.22

. Примерно так выглядит мой код на скорую руку.

PS кстати github copilot обалденно помогает в написании такого кода. Чуть ли не половину дописывает.

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

Не понял смысла вопроса. Всегда (когда был молодым, высоким и красивым) писал программы, которые нужны здесь и сейчас, причем качественно (как показало время)...
Одна программа используется уже 27 лет. Использую для себя несколько программ, написанных 20 лет назад (14 лет назад переведены в линукс). Без проблем работают.
ЗЫ
Я не программист.

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

S>К примеру, с заданием выше. Вылетает некая ошибка и хрен знает в чем проблема. Ну ОК, добавили логирование. Далее — опять фейл, т.к. в логах указано где возникла проблема, ясно что сторонняя либа не переваривает заголовок, который отдает сервер — но какой именно заголовок — Х.З. Добавляете еще более детальный лог — вроде ОК, но потом опять спотыкается, но уже не на заголовке а на формате тела и т.д.

Вообще без обработки ошибок писать — такое себе, ускорения не даст, наверняка будет точно как ты и сказал.
Для быстроты тут достаточно тупо логировать (не игнорировать) получаемые ошибки, без красивостей.

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

vsb>PS кстати github copilot обалденно помогает в написании такого кода. Чуть ли не половину дописывает.

Бойтесь данайцев дары приносящих
Он вместе с кодом еще и баги добавляет, я на это за него надолго обиделся

Когда просто автокомплит по слову, ситуация контроллируемая.
А когда автокомплит по 10 строчек уже сильно сложнее.

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

vsb>>PS кстати github copilot обалденно помогает в написании такого кода. Чуть ли не половину дописывает.

bnk>Бойтесь данайцев дары приносящих
bnk>Он вместе с кодом еще и баги добавляет, я на это за него надолго обиделся

bnk>Когда просто автокомплит по слову, ситуация контроллируемая.
bnk>А когда автокомплит по 10 строчек уже сильно сложнее.

Согласен, но чуть-чуть поюзав я к нему начал привыкать и уже представляю, где он точно не ошибётся, а где лучше посмотреть. В целом мой подход — либо какой-то тупой повторяющийся код чтобы он генерировал, тут он не ошибался пока. Либо сгенерировать какой-нибудь нетривиальный кусок кода, потом вглядеться и доработать. В обоих случаях время экономится. Бывает, что нормально не генерит, ну ладно. Ну ещё комменты он за меня пишет, лол (не на рсдне).

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

G>Пример из жизни: мне достался микросервис от чувака, который его за 2 недели нафигачил. Потому что бизнес хотел быстрее.

Как говорится в программирование одну и ту же задачу можно сделать минимум 3-мя способами.
В прошлом месяце нужен был срочный патч, крики-вопли. 2 часа работы в поте лица (+ не доделал еще + надо тестировать несколько модулей), потом сходил на обед, поразмышлял, добавил 3 строки в базу и усе заработало как надо.
Так же делал межпроцессорный многоопоточный модуль, с очередями, эвентами, состояниями.
Ночь переспал, выкинул все нах, оставил 5 строчек, а очередь влепил в запрашивающего данные.

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

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

A>Ну как велосипед по сравнению с автомобилем. Вроде и там и там есть колёса, но это совсем другое.

Интересная аналогия. Особенно в свете того, что в реальных условиях велосипед нередко выходит и быстрее, и эффективнее и в целом удобнее.

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


G>Если качество будет лучше оптимального — это плохо. Долго и дорого создаваемое решение еще будет поддерживаемо, но уже морально устареет, или потребности бизнеса изменятся. И оно будет выведено из эксплуатации. То есть, по факту, потраченное время (которое — деньги) будет выброшено.

Any idiot can build a bridge that stands, but it takes an engineer to build a bridge that barely stands.

К софту это тоже относится.

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

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

Конечно, я упрощаю, но в другом.
Мы предполагаем, что все участники трудовых отношений честны и добросовестны.
На практике кто-то халявит, кто-то халтурит во время работы, кто-то не настолько умен и квалифицирован, как заливал во время собеса. Ну и с другой стороны кто-то самодур, кто-то сам не знает чего хочет. А после срыва сроков все орехи падают на исполнителя. Ну и так далее.
С точки зрения владельцев бизнеса остальные факторы стоят ровно столько, насколько они влияют на прибыль. Или какие риски несут.
Вот у меня в компании сейчас стоимость замены разраба составляет около ляма рублей и 2-3 месяца по времени. Поэтому работодателю творить дичь тупо не выгодно.

vsb>На мой взгляд IT компания это содружество разных людей.
Если ты так считаешь — значит, тебя уже переиграли.
Меня, кстати, тоже. Я периодически перерабатываю. Переживаю за продукт. Не хочу "подвести" команду.
Но правда жизни в том, что все эти отношения — самообман.
Не, ну с коллегами могут быть дружеские отношения вне работы. Но только тогда они не выступают коллегами, а выступают друзьями, это разные вещи. Не стоит мешать рабочее и личное. Плохо кончится.

vsb> Пишу "содружество" потому, что обычно для программистов зарплата не является единственным, а для многих и главным фактором. Есть к примеру такое понятие как "интересные технологии", "удовлетворение от работы" и подобные. Это сильно нелинейная система. И оптимум тут далеко не факт, что будет соответствовать описанному тобой явлению.


Два момента.
Если деньги — это не главный фактор, то блин даже не знаю, что сказать. Это называется не работа, а хобби. В нашем капиталиситческом мире таких овечек бизнес съедает на завтрак пачками.
Второе: я согласен, что осваивание новых технологий полезно с точки зрения поднятия своей рыночной стоимости. ну или просто для удовольствия.
Но балом, напомню, правит капитал. И он очень даже заинтересован создать такую корпоративную среду, и такой имидж, который будет создавать у тебя иллюзию "содружества", будет из каждого утюга говорить про то, что у нас "новые технологии" и "интересные проекты".
Это будет означать ровно одно: тебе будут недоплачивать. Часть компенсации выдается в виде чести работать в этой компании. За примерами ходить далеко не надо. Все эти Яндексы и прочие Озоны с Касперским уже давно обмусолены в т.ч. и на этом формуе.

vsb>Вполне можно представить, что качество хуже оптимального получить несложно. Нанял тех, кого никто нанимать не хочет и получил.
Если нанять таких — они не только качество профукают, но и сроки. То есть в итоге еще может оказаться дороже.

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

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

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


vsb>Я вот за себя могу сказать, что мне неприятно работать на проектах, где заведомо занижается качество. Я могу откладывать какие-то вещи в технический долг, но на некоторых я экономить не хочу. И если я буду вынужден это делать, наверное я подумаю про новую работу. Даже если я буду согласен с тем, что объективно тут качество не нужно. Ну такие вот у меня тараканы, извините, какой вырос, другим уже не вырасту.

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

я с ними полностью согласен, чисто технически они правы на 146%.
Но блин, у меня от прежних хозяев стены в пятнах и дырках.
И у меня выбор, либо платить долго дорого и качественно делать ремонт, либо вообще не делать и жить в бомжатнике.
А я не хочу в бомжатнике.
Я хочу тупо закрасить грязь, это уже будет лучше, чем то что есть. Да, это будет некачественная недолговечная халтура, но это лучше чем ничего.
Придется теперь на праздниках красить самому ))

Понимаешь, к чему это я?
Мне тоже, как и тебе, как и моим знакомым строителям не нравится занижать качество.
И я тоже, как ты или строители, пожалуй откажусь от работы, где систематически надо фигак-фигак и в прод.
Но в жизни часто требуется именно это ))

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

S>Такой вопрос. Обладаете ли вы навыком сделать что-то быстро в низком качестве, но чтобы работало? Т.е. в случае, когда не нужна поддержка продукта длительная, не планируется доработка — а просто нужен результат здесь и сейчас.

S>Сколько времени вам нужно сделать качественный код и за сколько времени вы бы сделали просто рабочий?

Если нужен был бы результат, то я бы открыл бы доку по имап протоколу, зашел бы по оному из командной строки и сделал набор команд который бы позволил получить нужный результат.
Ну батник бы написал думаю. Лет 10 назад, я делал что-то подобное, по памяти разобрался за вечер.

Качественный код по сути был бы повторением этих команд.