usernameak
Джифорсович
фраза "умеет разбираться в чужом коде" обычно говорит о чём-то плохом, обычно о том что этот чужой код ужасен
в остальных случаях оно само собой разумеется
потом читаешь комментарии в коде, а там разработчик оставил сюрпризы
Джифорсович
100~ чатов, это норма
Oleg
фраза "умеет разбираться в чужом коде" обычно говорит о чём-то плохом, обычно о том что этот чужой код ужасен
в остальных случаях оно само собой разумеется
Далеко не всякий работодатель честно признается, что код написан нечитабельно. Иногда он даже не знает об этом.
Так что умение еще в теме. Не сомневайся.
Особенно когда имеешь дело с долгоиграющими проектами.
Про однодневки для веба не говорю конечно.
usernameak
Далеко не всякий работодатель честно признается, что код написан нечитабельно. Иногда он даже не знает об этом.
Так что умение еще в теме. Не сомневайся.
Особенно когда имеешь дело с долгоиграющими проектами.
Про однодневки для веба не говорю конечно.
не, умение полезное, но это немного red flag, что придется иметь дело с легаси. как по мне)
Oleg
не, умение полезное, но это немного red flag, что придется иметь дело с легаси. как по мне)
Напрасно. Под этим умением я ещё понимаю отсутствие истерики при виде плохо структурированного кода. И стойкость в процессе приведения кода в приличный вид.
Для меня плохим сигналом будет утверждение что "тут проще все заново написать чем разобраться".
А такие варианты я встречал неоднократно.
Snusmumriken
Ребятки, все всё понимают что хотят, не надо заниматься ерундой )
usernameak
Напрасно. Под этим умением я ещё понимаю отсутствие истерики при виде плохо структурированного кода. И стойкость в процессе приведения кода в приличный вид.
Для меня плохим сигналом будет утверждение что "тут проще все заново написать чем разобраться".
А такие варианты я встречал неоднократно.
мне доводилось иметь дело с жутковатой вещью, где в коде можно было в целом разобраться, но мельчайшее изменение в нём ломало кучу слабо связанных вещей, и меня хотели заставить рефакторить его, будто там доступен какой-то ещё рефактор кроме как переписать
usernameak
ну и я свалил быстро, потому что платили мало за такой геморрой
Snusmumriken
Ребятки, пока проект не увидите, его состояние не оцените. И в некоторых случаях, требование "умение читать чужой код" связано с нетерпимостью и требованию всё переписать под лекала свежего сотрудника, и с таким я тоже встречался.
В третьих, степень ужасности — величина ненормированная. Приходишь и оцениваешь состояние проекта, если слишком ужасно для тебя — убегаешь. Вот и всё, собственно.
Highly Likely
Программисты, у которых плохо читаемый код вызывает только желание «все выкинуть и написать с нуля» либо плохие программисты, либо стажеры/джуны :-)
Snusmumriken
Ну пока я был стажёром, было жуткое желание всё переделать на своей текущей работе. А потом я всё понял. Вообще всё. И сам стал писать ещё хуже, тупее и в лоб. И это нормально.
Highly Likely
Ну вот типа. Очень редко бывает настолько плохой код, что его надо переписать
Highly Likely
Чаще бывает паршивый код, с которым можно смириться и по чуть-чуть переделывать. И это вполне норм
Highly Likely
Стандарты индустрии за 10 лет поменялись очень сильно. Но это не значит, что есть хоть какой-то смысл каждый год всё переписывать
Artem
Snusmumriken
Это потому что ты стажёр ))
Artem
я вот сейчас страдаю из-за того что у меня один программер пишет в лоб
Highly Likely
что-то нормальным мне это не кажется
Бизнес хочет деняк, а не чистый код. И не всегда есть возможность писать / переписывать идеально :)
Artem
в хайлоад проект так не прокатывает
usernameak
Ну вот типа. Очень редко бывает настолько плохой код, что его надо переписать
даже если его писали китайцы за миску риса? или это уже edge case
Oleg
Программисты, у которых плохо читаемый код вызывает только желание «все выкинуть и написать с нуля» либо плохие программисты, либо стажеры/джуны :-)
Некоторые могут тебя на дуэль вызвать за такое.
Они себя такими не считают.
Highly Likely
в хайлоад проект так не прокатывает
Прокатывает. Если место такое, что в ближайшие полгода переписываться не будет — да и хрен с ним, хоть на гоуту напиши, если это будет необходимо
Highly Likely
Придет время — переделаешь
Snusmumriken
я вот сейчас страдаю из-за того что у меня один программер пишет в лоб
Переписывание — такая штука которая стоит времени и денег. И производится в те моменты, когда уже накопилось настолько большой техдолг (который копится всегда, кто бы что ни говорил, как бы тестами ни покрывали), что внедрение фич или поддержка становится слишком проблематичным. Вот собственно и всё.
Highly Likely
Некоторые могут тебя на дуэль вызвать за такое.
Они себя такими не считают.
Ну так это нормально. Опыт и понимание приходит с возрастом и… опытом :-)
usernameak
Прокатывает. Если место такое, что в ближайшие полгода переписываться не будет — да и хрен с ним, хоть на гоуту напиши, если это будет необходимо
а я было дело на гоуту писал, когда фичу надо было запилить за пару часов до дедлайна
Artem
Прокатывает. Если место такое, что в ближайшие полгода переписываться не будет — да и хрен с ним, хоть на гоуту напиши, если это будет необходимо
вот мне так очередь вебхуков стопорнули на днях, смотрю, а там запрос каждый по 5-10 секунд обрабатыватся, потому что вот так вот в лоб был написан
Snusmumriken
вот мне так очередь вебхуков стопорнули на днях, смотрю, а там запрос каждый по 5-10 секунд обрабатыватся, потому что вот так вот в лоб был написан
Это уже не просто костыль а кривой костыль. И проблема не в том что "в лоб", а в том что криво )
Highly Likely
Я вот прямщас пишу фичу «в лоб», потому что писать «красиво» нет ни времени, ни необходимости. Потому что хрен знает когда этот кусок кода будет переделываться и упарываться по «красивому» дизайну смысла нет никакого
usernameak
Переписывание — такая штука которая стоит времени и денег. И производится в те моменты, когда уже накопилось настолько большой техдолг (который копится всегда, кто бы что ни говорил, как бы тестами ни покрывали), что внедрение фич или поддержка становится слишком проблематичным. Вот собственно и всё.
кстати, а как покрывать тестами, если это настолько старая херня, что неизвестно, какое поведение у него вообще должно быть?
Snusmumriken
кстати, а как покрывать тестами, если это настолько старая херня, что неизвестно, какое поведение у него вообще должно быть?
Это очень интересный вопрос.
Ответ: никак. Или частично, в пределах известного поведения.
Artem
в хайлоаде в лоб можно писать только при условии что у тебя неограниченные возможности по горизонтальному масштабированию есть
Snusmumriken
Да можно там писать в лоб в подавляющем числе случаев, изгаляясь только на ботлнеках.
Highly Likely
вот мне так очередь вебхуков стопорнули на днях, смотрю, а там запрос каждый по 5-10 секунд обрабатыватся, потому что вот так вот в лоб был написан
Это плохо написанный код, а не решение «в лоб»
Snusmumriken
Да )))
Daniil
Я тут как раз подбираю стиль, в каком эффективно писать...
Проект плотный, из разных времён, в разном стиле...
И должен сказать, что основным фактором является умение писать на одной волне с товарищами по команде.
То есть даже если писать так как было в проекте, не факт, что это подойдёт. Как договорились писать - тоже может не сработать, потому что можно попасть на период рефакторинга, где стиль только-только вырабатывается.
А когда общаешься с коллегами, уточняет вектора решения тех или иных вопросов, там-то нужный стиль и вырабатывается.
Artem
Это плохо написанный код, а не решение «в лоб»
код написанный в лоб - чаще всего плохо написанный код, потому что разработчик себя не утруждает немного подумать
Snusmumriken
По моим наблюдениям, код написанный в лоб прост и туп как молоток, чем хорош: как бы много строчек ни было в какой-нибудь функции, они все предельно тупые и последовательные, кто угодно может увидеть что там происходит, хоть и многословно.
Highly Likely
код написанный в лоб - чаще всего плохо написанный код, потому что разработчик себя не утруждает немного подумать
Повторюсь: если у тебя бесконечное количество времени и ресурсов — вперед писать только хороший код и «чуть-чуть» думать.
Если разница между «в лоб» и «красиво» занимает тыщу строк — я выберу в лоб в рамках реалий/времени
Artem
Я тут как раз подбираю стиль, в каком эффективно писать...
Проект плотный, из разных времён, в разном стиле...
И должен сказать, что основным фактором является умение писать на одной волне с товарищами по команде.
То есть даже если писать так как было в проекте, не факт, что это подойдёт. Как договорились писать - тоже может не сработать, потому что можно попасть на период рефакторинга, где стиль только-только вырабатывается.
А когда общаешься с коллегами, уточняет вектора решения тех или иных вопросов, там-то нужный стиль и вырабатывается.
мы делали проще, собирались командой и обговарили свои стандарты по каждому пункту как и что писать, договаривались и приходили к компромису, который все удобен и приятен в чтении/понимании + не несет за собой скрытых проблем в будущем
Highly Likely
Если на задачу у меня есть неделя — решение одно. Если полгода — другое. Умение принимать решения исходя из этих переменных и есть уровень профессионализма
Artem
Повторюсь: если у тебя бесконечное количество времени и ресурсов — вперед писать только хороший код и «чуть-чуть» думать.
Если разница между «в лоб» и «красиво» занимает тыщу строк — я выберу в лоб в рамках реалий/времени
в лоб - это как раз обычно 1000 строк, а красиво и подумав в 50 строк умещается и работает в 5 -10 раз лучше
Snusmumriken
Задачи хайлоада, кстати, обычно не в бизнес-логике а в ядре — как правило куча асинхронщины, всяких остановок корутин по таймауту, ин-рам-базах/кешах и прочей фигне. Тому кто пишет бизнес-логику остаётся накатать всё тупо и в лоб чтобы всё работало как положено.
Да, да, испортить можно что угодно, и переписывать всякую ерунду.
Artem
я тут как-то пришел на один проект, переписал архитектуру, после чего сняли две стойки серверов за ненадобностью и выставили на продажу
Artem
Задачи хайлоада, кстати, обычно не в бизнес-логике а в ядре — как правило куча асинхронщины, всяких остановок корутин по таймауту, ин-рам-базах/кешах и прочей фигне. Тому кто пишет бизнес-логику остаётся накатать всё тупо и в лоб чтобы всё работало как положено.
Да, да, испортить можно что угодно, и переписывать всякую ерунду.
вот корутины я так еще нигде и не прикрутил
Artem
даже вебсокеты на libev взял
usernameak
Задачи хайлоада, кстати, обычно не в бизнес-логике а в ядре — как правило куча асинхронщины, всяких остановок корутин по таймауту, ин-рам-базах/кешах и прочей фигне. Тому кто пишет бизнес-логику остаётся накатать всё тупо и в лоб чтобы всё работало как положено.
Да, да, испортить можно что угодно, и переписывать всякую ерунду.
а ещё боль в том что многопоточный код невозможно тестировать
Artem
а ещё боль в том что многопоточный код невозможно тестировать
все возможно, если логи правильно писать
usernameak
и всякие пограничные случаи, связанные с синхронизацией запросто можно упустить
Artem
я о том, что он непредсказуем
я так только первые разы думал, а потом оказалось что все предсказуемо, если есть опыт
usernameak
я имею ввиду, что автоматические тесты на нем могут иметь false positive
Snusmumriken
вот корутины я так еще нигде и не прикрутил
Они крайне удобны для оборачивания пользовательских функций при переделке местных функций под асинхронные. Например
function readfile(filename, mode)
local block, done = {}, false
local function pipe(async_chunk)
if not async_chunk or #async_chunk == 0 then
done = true
end
block[#block + 1] = async_chunk
end
asyncioread(filename, mode, pipe)
while not done do coroutine.yield() end
return table.concat(block)
end
local userfunction = function(...)
something = readfile("myfile.txt")
anotherthing = readfile("myfile2.txt")
...
end
local routines = {}
table.insert(routines, coroutine.new(userfunction))
while 1 do
for i, co in ipairs(routines) do
if not coroutine.resume(co) then
table.remove(routines, i)
end
end
process_events_like_asyncioread()
end
Snusmumriken
Функция асинхронного чтения и последний цикл приложули может быть написан на сишке и являться частью ядра ивент-драйвен-фигни, а ля сервера приложений.
Snusmumriken
Соответственно, если все потенциально лочащие функции асинхронны (сетевые запросы всякие, чтение с диска преимущественно) — оно параллельно в одном потоке обрабатывает тысячи пользовательских функций, и они как бы не мешают друг другу, а пользователь пишет самый тупой и прямой в мире код без единого колбека, который просто выполняется асинхронно.
Snusmumriken
Snusmumriken
Они крайне удобны для оборачивания пользовательских функций при переделке местных функций под асинхронные. Например
function readfile(filename, mode)
local block, done = {}, false
local function pipe(async_chunk)
if not async_chunk or #async_chunk == 0 then
done = true
end
block[#block + 1] = async_chunk
end
asyncioread(filename, mode, pipe)
while not done do coroutine.yield() end
return table.concat(block)
end
local userfunction = function(...)
something = readfile("myfile.txt")
anotherthing = readfile("myfile2.txt")
...
end
local routines = {}
table.insert(routines, coroutine.new(userfunction))
while 1 do
for i, co in ipairs(routines) do
if not coroutine.resume(co) then
table.remove(routines, i)
end
end
process_events_like_asyncioread()
end
Кстати, сюда же можно пихнуть sleep в таком виде:
function co_sleep(delay)
local timeout = os.clock() + delay
while os.clock() < timeout do
coroutine.yield()
end
end
Ну и вот, эта функция теперь может параллельно слипать с другими. И на этом принципе вся синхронщина переделывается под асинхронщину, не затрагивая пользовательский код вообще — он всё ещё как бы написан для синхронного взаимодействия, но благодаря этому выполняется асинхронно.
Snusmumriken
Ооо, телега продолжается. Я ещё вспомнил что чинил этим же способом проблемы многопоточности и остановки потоков у lanes — оно требует, чтобы "код двигался" для проверок, может ли тред самоубиться по внешнему сигналу или нет. Про него конечно можно "забыть", мол "закроется когда-нибудь потом, а результат мы выдадим уже сейчас" но оно может привести к переполнению тредов в ОС и падению всей приложули на всяком хайлоаде. Соответственно всё io можно сделать асинхронным/на корутинах, чтобы корректно убивать поток в любой момент, и я это уже делал, для отрубания тасок.
И даже без lanes — всякие sleep'ы и прочие хттп-запросы могут возвращать специальную ошибку, мол "данная задача истекла по времени, завершайся", и пользователь быстро свернёт свой код, остановив корутину по внешнему таймауту. Тут уже, правда, нужна минимальная дисциплина, и при внедрении этой фигни в уже существующую платформу может потребовать кучи переписываний.
Luсky
Нужно ли юзать это при внедрении в программу возможности редактирования файла, являющегося частью этой программы?
Luсky
Ну, типа бд в луёвой табличке, которая через dofile прицеплена к скрипту, который может перезаписывать файл с этой табличкой.
Snusmumriken
Ммм, а в чём проблема обычного конфига? )
Snusmumriken
Цапни serpent и сохраняй таблички.
Snusmumriken
Ну типа, знаешь, в программах есть кнопка "сохранить настройки" — вот это типа сериализация текущего состояния настроек кнопок и запись в файлик. При запуске программы типа ты считываешь файлик один раз, а при изменении настроек — записываешь.
Snusmumriken
Но, в твоей проге должна быть возможность ручного сохранения этой фигни, плюс желательно автоматические бекапы раз в N минут при наличии изменений, в противном случае можно профукать данные или обкекаться с переизбытком использования жд.
Luсky
Мерси!
mva
Джифорсович
Я такой мем сегодня от эйчара услышал
"Мы используем виндовс на проде, потому что так хочет клиент"
Highly Likely
Я такой мем сегодня от эйчара услышал
"Мы используем виндовс на проде, потому что так хочет клиент"
А что не так? Клиент не может хотеть виндовз на проде? :-)
Джифорсович
Если это не обязательно - то зачем заставлять разрабов страдать?
Highly Likely
Если это не обязательно - то зачем заставлять разрабов страдать?
Так клиент хочет или необязательно? :)
Джифорсович
А я щас даже и не скажу, где же венда так необходима на проде
Джифорсович
Так клиент хочет или необязательно? :)
Клиент где то там себе захотел, а зачем - сам не знает
В этом и мем
Highly Likely
Клиент где то там себе захотел, а зачем - сам не знает
В этом и мем
Точно ли не знает?
Джифорсович
Ну представь себе прод, где нужно бек в контейнерах крутить, и балансить запросы ингрессом, + постгрес
Зачем тут венда?
Snusmumriken