Комментарии 17
Краткое изложение: "бу-бу-бу, Дональд мудёр, современные машины быстры, девушки прекрасны, бу-бу-бу".
Своевременная оптимизация - корень многих добр
Я всегда воспринимал эту фразу как "нет большого смысла в оптимизации до профилирования"
Да и если не планируется рост системы и скорость работы сейчас устраивает, то и нечего время разработчиков зря тратить.
Если смотреть с позиции заказчика, то да. Со стороны же исполнителя всё не так однозначно. Разработчик в процессе оптимизации вынужден докапываться до тонкостей. Объем его профессиональных знаний и навыков от этого только выигрывает.
С такой стороны даже ненужную оптимизацию можно рассматривать как маленькую инвестицию в образование. Окупит ли она себя? Убежден, что да. Даже в том случае, если напрямую приобретенный опыт не пригодится. Кстати, и в статье эта мысль промелькнула.
premature optimisation - помойму тут он коротко написал что преждевременное оптимизирование это корень всех зол, суть в том что все решения +- одинаковы, и правильные и нет, потомучто над ними всеми будут так или иначе найдены оптимизации и улучшения и фиксы, а писать сразу на тот 0.000001 процент, по стилю и наполнению кода это непонятно по скорости вхождения в задачу, отсюда я думаю и корень зол, это как бежать впереди телеги, кода типо пока еще нету устаканенного, но мы уже всё оптимизируем, я его так понял
грубо говоря пример, есть базовые функции *nix, в разных ОС работают одинаково, но в каких-то ОС отличаются реализацией
и вот не погрузившить в задачу, кажется что сразу так надо, а там вполне возможно был поиск или какая-то ситуация ну типо что-то хотели не совсем правильно сказать оптимизировать, но может была задумка по какой причине реализация другая
Сколько же некомпетентности, лени и "и так сойдет" прикрывались фразой об преждевременной оптимизации. И потом выясняется, чтобы работало быстро, надо половину проекта переписывать, архитектура там что макро, что микро - гавно.
Плюсую... :-)
- Давай сейчас проработаем наиболее перспективные и возможные в будущем варианты развития продукта?
-- Зачем? Согласно постановки задачи архитектура выбрана оптимальна, а проработка возможных перспектив развития сейчас это + месяц аналитики (для 1 аналитика). А сроки "горят"! Пора программировать!
<прошло 3 года>
- Тут нужно добавить небольшую и востребованную функциональность к уже существующей в продукте, какие примерно сроки разработки?
-- Ну, учитывая что это "не ложится" на базовую архитектуру приложения, не меньше чем полгода работы (для 3 аналитиков и 15 разработчиков)....
Зато теперь это востребованный продукт и бизнес понимает, что эти человеко-часы будут потрачены на пользу бизнесу, а не потому, что "программисты так видят". Могло ведь сложиться и так, что продукт "не взлетел", а время на то, чтобы он был расширяемым зачем-то потратили. С точки зрения бизнеса, лучше потратить больше потом, когда от продукта точно есть польза и эти изменения повысят отдачу от него.
Это всё на опыте приходит, по началу такой думаешь о джанго это лучшее что смогло придумать человечество, а потом бац и сайт лежит после одновременного наплыва сотни пользователей, начинаешь нагруженные ендпоинты на асинхронку переписывать, вроде как производительность улучшилась но на 1000 коннектах база отваливается, привет сырой сиквил и кеш. Кто с подобным сталкивался по дефолту оптимизированный код пишут.
Вроде заранее тратить время на оптимизацию плохо, а потом приходит клиент и говорит, что внезапно объемы у безнеса выросли, а наш софт их почету то не тянет. И короче за час надо что-то сделать или штрафы/санкции :). Так что лучше сразу делать хорошо пусть и подольше.
Так можно до паралича анализировать то, что должно решаться творчески, интуитивно. Набравшись опыта, мы в любом случае должны балансировать, в зависимости как от контекста так и от долгосрочных целей и ценностей. "Левополушарный" подход здесь плохо работает, т. к. легко впасть в неразрешимые споры и рационализации. По большому счету, мы должны стараться делать качественные прогнозы и готовить код соответствующим образом, не разбрасываясь при этом ресурсами.
Почитал комментарии. Почему-то нас всегда тащит в локальные экстремумы: либо "уууу, вот через три года пришла круглая ж и мы вам говорили, что надо было сразу делать хорошо", либо "а зачем делать хорошо под миллион пользователей в пределе, если продукт нацелен на сотню?"
И тот, и другой подход понятны.
Как тут не вспомнить историю про Петю и Васю (которая отлично ложится в канву всех комментариев):
https://pikabu.ru/story/vasya_i_petya_8618792
Про себя могу сказать, что недавно надо было поднять на работе тг-бота. Сначала мучился с асинхронщиной, слоем кэша, проблемами с БД и прочими штуками. Потом понял, что пользоваться этим ботом будут 10 человек и написал все примитивно, но зато быстро. Как итог - работает. Однако время на начальную оптимизацию "чтобы было по уму" потерял. Понимал головой, что так правильно, но, на деле, это было оверкиллом для задачи и я со своими навыками сел в лужу ((
Моя мысль в том, что часто бизнесу надо "здесь и сейчас". Плевать - насколько хорошо, главное, чтобы "тайм-ту-маркет" был сжат до минимума. Поэтому, пишется максимально быстро исходя из временных границ и так качественно, насколько это возможно, чтобы временные границы не двигать. А там уже как раз и виден скилл: если за условный день работы один человек поднимает приложение, которым может пользоваться 1 человек, а другой поднимает приложение, которое не падает на сотне - вот вам разница в скилле.
Пример Вася и Пети — это тоже в какой-то степени «локальный экстремум».
Проблема Пети — не в тщательности подхода, а в полном отрыве от рынка. Если предположить, что Петя исцелился от бизнесофобии, то в какой-то момент может выясниться, что его продукт выигрывает, а разработка обходится дешевле.
Случай Васи корректен, только если его продукт безальтернативен. Никто не любит терпеть баги. Недостаточное качество может привести к формированию отрицательного имиджа продукта.
Тема неимоверно глубокая. Как будто никак не нащупать правильную точку зрения, поэтому мы перебираем несколько утрированные примеры.
Является ли преждевременная оптимизация корнем всех зол