Как стать автором
Обновить
58
0
Ivan Velichko @iximiuz

Software Engineer

Отправить сообщение
Большое спасибо за перевод!
Работали и неоднократно. 6 млн строк на PHP, в которых можно было найти коммиты 5-6-летней давности — достаточно большой проект? Так вот ни одна документация не в силах была бы передать бизнес логику некоторых частей этого проекта. А правки вносились постоянно командой из 30+ человек. Боюсь представить потенциальный размер wiki по бизнес-логике такого проекта и уровень «сказочности» описанного в ней.
80-страничный мануал? Сбежал бы в первый день из такой компании)

Есть же код, он работает — запускай его и смотри. Вот и документация, самая верная и надежная.
«Объектно-ориентированное программирование для меня означает только отправку сообщений, локальное удержание и защиту, а также скрытие состояний-процессов, и экстремально позднее связывание всего. Это может быть сделано в Smalltalk и в LISP. Возможно, есть другие системы, где это возможно, но мне они неизвестны».

Локальное удержание и защиту? Мы про самбо говорим? Еще раз убеждаюсь, что CS литературу на русский лучше не переводить.
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.
Это — вероятно, пожизненная миссия, если быть честным. Идея состоит в том, чтобы дать каждому — независимо от того, на каком языке он говорит или сколько денег имеет, — возможность иметь свой голос в сети на базе лучшего в мире программного обеспечения.

Вот же тролль!
Кажется, что наше обсуждение уже немного выходит за рамки первоначальной темы.
Так тут бы предметная область была бы научной областью самой по себе. Конечно, скучно бы не было, но только потому, что это космонавтика. А если бы то же самое, но в медицине — я бы заскучал. Это же все субъективно. А любовь программиста программировать должна быть всегда. Опять же имхо)
В принципе, я согласен со всеми доводами. Хотя, по большому счету я преследовал цель понять, насколько и для кого актуальна вообще тема алгоритмов в современном мире. Особая точность тут и не требовалась. И собственно по полочкам все разложили не результаты опроса, а ваш комментарий )
Согласен полностью. Но я же не про гипотетическую ситуацию говорил, а про реальную. Это я к тому, что если выбирать, я бы предпочел работать в "идеальных" командах и в командах с перекосом в техническую сторону, даже если потом всех уволят в итоге)
Работал я как-то в двух командах. В первой все говорили, что самое важное — это value продукта. В том числе разработчики. И вместо обсуждения всяких алгоритмов и архитектур обсуждали бизнес-кейсы (а зачем тогда продакт-оунеры?). Все хотели дать людям нечто новое, собрав из готовых решений. В общем без слез на то, что было под капотом не взглянешь. А в другой команде технари были помешаны на своем деле. Обсуждали то, что и положено обсуждать технарям, фанатели от программирования самого по себе. И эту их энергию в нужное русло просто грамотно направляли продакт-оунеры. В итоге и продукт был лучше и под капотом у него было все круто. Ну и удовольствия от работы в такой команде было больше лично для меня.
Так и живем всей планетой!
Вот хотя бы ради того, чтобы вы написали этот комментарий, такие опросы нужно делать. Благодаря ему картина мира в этой области стала более четкой и вырисовалось дальнейшее направление движения, спасибо!
В опросе речь не про "знание", а про возможность самостоятельно написать. При этом я уточнил, что готовность к использованию в production написанного не важна, подойдет, например, просто сама идея, что для binary search нужен отсортированный массив, и нужно каждый раз уменьшать диапазон вдвое. Т.е. опрос именно про наличие тех самых нейронных связей алгоритмического мышления.

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

Про написание на работе — тут конечно все зависит от личного мнения отвечающего. В идеале, я бы хотел получить разделение аудитории на вот таких ребят и всех остальных. Если пару раз написал на работе binary search в своей собственной JS UI библиотеке, чтобы найти один букмарк из десятка, потому что не захотел тянуть underscore в проект — это, по-хорошему, не считается. Но так как мир не идеальный, получили среднюю температуру по больнице.

И, кстати, не факт, что нейронные связи остаются в мозге навсегда. Насколько я знаю, мозг работает по принципу "не использовать, значит потерять". Если перестаешь применять навык, со временем он разрушается. И тем быстрее он разрушается, чем позже был получен.
Ну это как 55% — Quick sort, но только 7% 3-way partition quick sort. И не важно что quick sort может иметь квадратичную сложность на некоторых наборах, если она не 3-way.
Имхо, архитектура — это про декомпозицию и взаимодействие. Не важно на каком уровне. И на уровне одного модуля/сервиса/приложения — это "хороший код" (паттерны там всякие). А когда речь идет о комплексном многоуровневом проекте — архитектура уже далека от кода, она оперирует подсистемами (их интерфейсами и порядком взаимодействия). И в случае, если последняя хороша, то чистотой кода в ее компонентах иногда можно пренебречь в угоду скорости разработки.
Так вроде статья же о том, что красивый код не имеет ничего общего с ускорением решения, если под капотом хорошая архитектура. Т.е. можно наговнокодить запилить с нуля прототип модуля X, он удобно встроится в существующем окружении и будет себе работать, пока нужен. А что внутри, пофиг. Главное — что он был встроен быстро. А еще главное — что также быстро может быть выпилен из системы. А красивый код нужен скорее в монолите — когда чем лучше код, тем меньше жди от него неприятностей, т.к. все со всем связано.

P.S. Я тоже люблю красивый код.
Рассматривайте этот вопрос, как задачу спортивного программирования. Есть входные данные, есть ожидаемые выходные. Есть ограничения по памяти и времени, т.е. если вместо сбалансированного дерева будет обычное, то так случится, что оно обязательно выродится в список для хотя бы одного из наборов входных данных и сложность вырастет с логарифмической до линейной, программа вылете по timeout. И нужно написать код, который пройдет все тесты. Если считаете, что написали — галочку ставите.
У меня есть смутное чувство, что глянув в спецификацию, любой разработчик должен быть способен реализовать алгоритм. А вот идея с постановкой вопроса "алгоритм -> задача" и "задача -> алгоритм" весьма интересна. Но это уже будет трудно упаковать в хабра-опрос, к сожалению.
В любом случае это не const, а O(n). Что-то я не вижу решения за константу, даже у PapaBubaDiop оно линейное.
1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Amsterdam, Noord-Holland, Нидерланды
Зарегистрирован
Активность