LINUX.ORG.RU

Нужность эффективных алгоритмов

 


2

4

У меня на работе большинство разработчиков негативно относятся к усложнениям алгоритмов. Например вместо глупого перебора среди нескольких ГБ данных использование специализированых структур данных вызывает бурю негодования. Аргументы следующие: алгоритм запускается раз в неделю и ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание. Зато кто из среднестатистических сениоров в нашем ущербном перегретом рынке знает дальше ArrayList и HashMap? Суффиксные деревья, триграммы, 100 строчечные geospatial индексы пугают людей, ибо написаны вручную, а максимум что дозволено - интегрировать какой-то фреймворк. Доки умеют читать все. Я велосипедист и не нужен.

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

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

★★★★★

Последнее исправление: vertexua (всего исправлений: 1)

Ответ на: комментарий от i-rinat

После выигрыша в разы может быть выигрыш в 5%

?

Просто для протокола: улучшения в 5% скорее всего не стоят уродования кода; улучшения в 5 раз скорее всего стоят другого алгоритма.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

улучшения в 5% скорее всего не стоят уродования кода

И я тоже самое хочу сказать. Но возможна ситуация, когда тебе говорят: «делай так», потому что задача требует. И возможно, это даже хуже, чем ситуация, описанная ТС. Он хотя бы может утешать себя мыслями о том какой он умный и как он всё может сделать по-правильному.

Можно даже формализовать :) Поддерживаемость — m, скорость работы — s. Требуется максимизировать f₁(m,s) = m + 2s в исходном случае и f₂(m,s) = m + 100s во втором.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Но возможна ситуация, когда тебе говорят: «делай так», потому что задача требует. И возможно, это даже хуже, чем ситуация, описанная ТС

И, если ты считаешь, что задача этого не требует, то ты ровно в той же ситуации.

tailgunner ★★★★★
()

что код нужно писать правильно и эффективно

Вопрос интересный и в нем есть множество аспектов.

Во первых понимание слов «правильно и эффективно». Нету абстрактной «правильно и эффективно» - есть поставленная задача с ограничениями и ее решение. Реализация должна решать поставленную задачу, а не быть «абстрактно правильной». Тот кто пишет абстрактно правильно - обычно пишет херню полную, потому что в результате оказывается что задача нихера не решается или решается не полностью - например появляются крайние случаи где это не работает - зато 'правильно' - но это уже якобы не проблемы инженера, а проблемы тех «недоразвитых идиотов которые не осилили матан а теперь формулируют херню». А на самом деле это проблемы именно инженера, просто вместо того чтобы решать задачу он техномастурбировал.

Второе - противоречивость позиции вида «зато любой дебил» возникать может в том случае если ты беспокоишься о проблемах о которых беспокоится не твоя работа. Наблюдается часто когда какой нить девелопер коих в компании тыщи начинает размышлять с точки зрения владельца компании на тему «легкости поиска рабочей силы» и т.д. Это не его проблема и задача раз, и ему платят за инженерную работу, а не за просирание времени в мечтах «а если бы это была его компания». Это не его компания - и те чья это компания свою работу делают и так. Помечтать можно, но когда в работе люди начинают руководствоваться этой высосанной из пальца мотивацией, и строить свою собственную компанию на местах - начинается херня полная.

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

То есть сформулировать можно так - технический эффект от твоей реализации должен быть или a) действительно нужен или b) ничего не стоить.

А спорить о «хорошо правильно и эффективно» без привязки этого к ограничениям задачи - это херня полная рождающая никому не нужных уродцев.

r ★★★★★
()

Из-за таких сволочей мир скатывается в чОрную дыру.

Anon
()

Аргументы следующие: алгоритм запускается раз в неделю и ускорение с 1 часа, до 3 мин ничего не меняет, но усложняет поддержку и понимание.

Как доказать или опровергнуть, что ты не прав? Берешь и пишешь свою версию. Если ты на нее потратишь неделю, вместо двух часов, то ты не прав. Потому что тот кто решил задачу за 2 часа сделал все правильно: расчет времени выполнения vs частота запуска программы в твоем случае идеально решен. Все остальное: нужно больше документации! нужно больше рефакторинга! Это все твои домыслы. За текущую реализацию клиент/компания ничего не доплатили тому парню, а тут приходишь ты и рассказываешь, что ты крутой, раз видишь «полную картинку». На деле ты не видишь ничего, кроме как еще одного места для проявления своего перфекционизма :)

Садись и пиши код, докажи, что ты прав (или не прав).

gh0stwizard ★★★★★
()

максимум что дозволено - интегрировать какой-то фреймворк

Напиши фреймворк с алгоритмом и структурами и интегрируй его.

anonymous
()

«А еще у них в код понапиханы sleep'ы, и с каждой версией под предлогом оптимизации задержки чуть уменьшают»

devl547 ★★★★★
()

Насколько у вас развито ощущение того, что код нужно писать правильно и эффективно просто потому что код нужно писать правильно и эффективно?

Код пишется для людей, многие программисты забывают это, стремясь сделать «круто», что рождает однострочники, которые проще выкинуть, алгоритмы, которые проще переделать, нежели понять и ПО, поддерживать которое настолько трудоёмко, что проще его переделать.

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

Alve ★★★★★
()

Действительно, задача не критична по скорости и нормально будет приносить деньги даже в простейшей реализации.

Ааа, задача всетаки за бабло. Сам был в подобной ситуации. Простая и старая реализация была очень-очень простой. Тем не менее, некоторые люди до меня и со мной были настолько некомпетенты и ленивы, что умудрялись делать такие фееричные извращения, о которых я лучше промолчу. Они не правили баги, не стремились отрефакторить, нет. Потому что понимали, что за это никто не приплатит. Клиент просил увеличить перформанс программы и на каждую его просьбу делались костыли. В один прекрасный момент решить эту задачу поручили мне и я понял, что неважно насколько простая реализация, если она не способна решать задачи в рамках текущего ТЗ (а не той, что была ранее), то надо переводить текущую реализацию в состояние legacy и писать новую на следующие два-три года.

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

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

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 1)

"Нужность эффективных алгоритмов"

определяется тимлидом. Не нравится этот — найдите себе другого.

anonymous
()
Ответ на: "Нужность эффективных алгоритмов" от anonymous

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

Есть решение - использовать готовые фреймворки. Но обычно мне нужна только 1 фича оттуда. И иногда мне нужен «параметр Х», который там просто не настраивается.

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

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 2)
Ответ на: комментарий от vertexua

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

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

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

anonymous
()

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

vertexua ★★★★★
() автор топика
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от alienclaster

Серьезные алгоритмисты обычно не сильно полагаются на распаралеливание

Это ты байки какик-то задвигаешь.

чтобы ускорить алгоритм в 3-4 раза.

лол. Кому нужны эті 3-4 раза.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

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

Anon
()
Ответ на: комментарий от vertexua

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

cdshines ★★★★★
()
Ответ на: комментарий от Anon

а что представлять - я этім занимался. Паралелизм делает алгоритмы мутными. Это не то, что нужно делать в первую очередь.

dzidzitop ★★
()
Ответ на: комментарий от dzidzitop

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

Anon
()
Ответ на: комментарий от Anon

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

dzidzitop ★★
()
Ответ на: комментарий от Anon

ну головой думать нужно сначала, конечно. Хотя проблемы часто возникают в конце :)

dzidzitop ★★
()
Ответ на: комментарий от AIv

пни меня в jabber плз, или скажи какой твой контакст, есть пара общих вопросов по LnLR или как там ваши алгоритмы звались :)

qnikst ★★★★★
()
Ответ на: комментарий от dzidzitop

это при программировании за деньги

Так бы сразу и сказал! Ясен пень, для чужого дяди ты сделаешь абы как. Лишь бы баксы получить быстрей! А для себя, любимого, будешь стараться.

Anon
()
Ответ на: комментарий от Anon

«достаточной» - это когда все более-менее довольны, но можно сделать в несколько раз быстрей. Нужно уметь остановиться и ставить приоритеты.

dzidzitop ★★
()
Ответ на: комментарий от AIv

или хотя бы название основной статьи на зарубежном.

qnikst ★★★★★
()

Вот только что, geohash уменьшил время работы одного метода до «полтора-часа-хрен-знает-сколько» до 5 сек

vertexua ★★★★★
() автор топика

Если «экономия на спичках» - пишу самый простой вариант. Если час/3мин в неделю - таки нужно сделать 3мин. Это тоже время, это тоже нагрузка. Естественно, нужно комментировать. Возражения от коллег минимальны, разве что манагеры грустны - им бы по-быстрее, да по-дешевле...

То, что ты описал - эффективный менеджмент(tm) головного мозга.

bug
()
Ответ на: комментарий от AIv

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

Anon
()
Ответ на: комментарий от bug

Мне иногда становится жалко программистов: я даже не могу придумать более скучной работы. Сидишь и пишешь какую-то фигню. Причем эта фигня и есть цель. Жутко. Как у каких-то (да простят мне маты) блоггеров. Бррр.

Anon
()
Ответ на: комментарий от Anon

Да ладно тебе! Там несколько миллисекунд!

То то у ТС-а эти миллисекунды в часы превращаются...

AIv ★★★★★
()

Правило 80/20 знаешь? Оптимизировать надо те 20% кода, выполнение которого занимает 80% времени. Остальное - не трожь!

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.