Ой, извините за оффтопик, меня всегда интересовало — а можно ли назвать единоличный исполнительный орган «тёмным властелином»? Здорово бы документы смотрелись.
Ответ-то вы сами правильно в заключении написали. Нормальные игроки могут играть оффлайн, что огромный плюс. Небольшим процентом читеров при этом можно пренебречь. Проделанной работе — респект.
Без конкретных цифр решение принимать бессмысленно — это задача на оптимизацию ресурсов, и её решение зависит от конкретных данных. Если компания столкнулась с проблемами высоких нагрузок, нужно особенно внимательно относиться к алгоритмам, которые стоят за вычислениями.
Если баг добавляет какие-то фиксированные затраты (ну, например, из-за неудачной архитектуры пришлось сделать отдельный сервер очереди, который так бы не понадобился. То это мелочи. Чем больше клиентов, тем быстрее стоимость этого сервера растворится в общем объёме. Можно не перепиливать всю архитектуру, чтобы сэкономить на этом.
Если баг вводит какие-то дополнительные затраты, которые линейно растут от числа клиентов/покупателей/заработанных денег, это означает повышение цены для конечного клиента на этот процент. Компания при этом может терять конкурентное преимущество, и это можно измерить и посчитать. Тут принимается бизнес-решение — или работаем над фичами, или фиксим баг, в зависимости насколько критично для бизнеса поднять цену
Куда хуже, если система тормозит из-за неэффективного алгоритма (неэффективной структуры базы данных, неэффективных запросов к ней, неудачного проектирования масштабирования, неудачного хранения данных и т.д.), сложность которых сильно выше линейной. Тогда, чем быстрее компания растёт, тем дороже ей будет стоить инфраструктура в пересчёте на каждый заработанный рубль. И такие косяки важно и нужно уметь идентифицировать на ранних сроках. Как только такая ошибка начинает сколь-либо заметно влиять на потребление ресурсов, её надо исправлять. Они не проявляются мгновенно — типа на 100% подскочило потребление. Это всё постепенный процесс — просто постоянно растёт доля выручки, которую сжирает инфраструктура.
Если команда не может справиться с такой проблемой (а это часто случается в жизни, такие комментарии хорошо показывают непонимание ценности навыков алгоритмизации сообществом), то я бы рассмотрел третий способ потратить время программистов — провести им повышение квалификации. Пригласить олимпиадников, провести мастер-класс, порекомендовать литературу, провести может внутри компании свои соревнования. Собственно спортивное программирование — это всё как раз про сложность алгоритмов.
Неэффективные алгоритмы — это не обязательно зона ответственности архитектора. Потребление любого, даже самого маленького компонента системы может быстро разжираться. Любой отчёт, любой запрос к базе данным, неудачный формат файла обмена, чтение/запись в файл, ведение логов, неудачное разделение ответственности между модулями, неудачный API — всё это может быть бомбами замедленного действия с неэффективными алгоритмами внутри. Такие баги нужно исправлять сразу, как только они стали оказывать заметное влияние на затраты, ибо дальше будет только хуже.
К наваливанию задач это тоже относится. Вас просят сделать что-то, вы можете сказать «нет, извините, это не моя обязанность» (это на 100% верно, но не очень вежливо), а можете ответить что-то типа «я сейчас пообщаюсь с коллегами и найду того, кто сможет вам помочь». По сути — одно и то же, но с точки зрения собеседника выглядит совсем по-другому.
Замечаю, да. Это справедливо для России. Обращение «господин» к собеседнику — это что-то недостойное, признание себя слугой как бы. В общении с европейцами, американцами в этом ничего зазорного нет — сэр, мистер имеют точно такой же подтекст, как и «господин» — в прошлом это представитель высшего сословия. Собственно об этом и статья, о культурных различиях. Надо просто иметь это в виду, когда общаетесь.
Да, вы демонстрируете желание быть полезным, помочь, угодить. Когда вы на самом деле этого не хотите, но всё равно делаете, то это уже просто хороший тон, признак уважения к собеседнику и т.д. :)
Постоянные уточнения того, что только что обсуждали (п. 6) — повсеместно. To be on the same page, как они говорят.
Готовность самому что-то узнать вместо того, чтобы говорить «не знаю» в переписке тоже есть. Причём часто достаточно сказать «Я не знаю, но был аналогичный случай бла-бла-бла, и есть ещё человек Фу Бар, который это наверняка знает». Таким образом показывается, что вы не просто отмахиваетесь от вопроса, что вам лень на него отвечать и т.п., а что вы действительно не знаете и помогаете собеседнику найти ответ настолько, насколько можете.
У нас многие проблемы от такого отношения к жизни — «кто ты такой, чтобы я перед тобой расшаркивался». Во многих же остальных культурах превознести своего собеседника/партнёра — совершенно нормально. В ответ причём вы услышите то же самое.
Если в случае 2 у вас есть nginx, его же можно заставить самого и кэшировать миниатюрки. Плюсы — можно ограничить общий объём кэша и автоматически выбрасывать из него старье, которое никто не запрашивает.
На пункт 2. А как это у вас до фига свободного места, если огромный файл до сих пор на диске, пусть и анлинкнутый? du покажет 0 свободного места, как ему и положено.
Почитал я пост и комменты, и не понимаю, почему вообще красивый код ставится в противоположность простому и короткому. Короткая программа и программа в стиле «тяп-ляп», вообще говоря, — вещи ортогональные.
Во-первых, на мой взгляд, простое и изящное решение — это как раз большая красота, чем обобщённая реализация всего, что ни попадя. Умение упихнуть код из трёх файлов с десятком классов в одну небольшую функцию — это и мастерство, и искусство одновременно. Читать короткую программу — одно удовольствие.
Во-вторых, возможность повторного использования кода — это всё важно. Но при этом надо всегда помнить, что сложность — враг надёжности. Программу, которая умещается на 1 экран, можно окинуть взглядом и понять, чего от неё ждать. Как только поток исполнения размазывается по нескольким местам, понять логику по исходникам становится невероятно трудно. Это влечёт за собой ошибки при сопровождении. Дописали чуть-чуть, не учли каких-то особенностей реализации, и в результате — баг. Покрыть всё тестами можно, отловить тем самым все сложные баги — это фантастика.
Как обычно, молясь, не стоит лоб расшибать. Есть места, где сложная компонентная иерархия уместна (например, вы разрабатываете OpenSceneGraph, которым будут пользоваться тысячи людей с совершенно разными задачи). Есть места, где уместны свой язык для описания конфигурации, умная сериализация всех объектов, генерация схем баз данных, метапрограммирование (например, если вы разрабатываете 1С: Предприятие). Но если реально нет бизнес-цели обобщать код, то это не только не делает его красивее, но и ухудшает его по многим параметрам.
Я уверен, что синьор-разработчики, которые указывали новичку на необходимость упростить код, имели в виду именно это — перестать плодить ненужные строки исходников и сделать код короче, проще, надёжнее и легче в сопровождении.
А можете построить гистограммы в разрезе по профессиям? Т.е. взять, к примеру, коммуникабельность и нарисовать столбики типа у менеджеров она встречается в 90% резюме, у аналитиков в 85% и т.д. Вот это было бы интересно :)
Последовательный доступ можно сделать и на каналах, и на мьютексах. Я имел в виду, что на тех же задачах мьютексы иногда дают больше производительность, чем каналы. Чтобы не быть голословным:
for req := range ch {
...
req.resp <- C.GoString(C.crypt(req.cryptStr, req.cryptSalt))[len(salt):]
...
}
Это не значит, что везде надо применять каналы. В данном случае понятно, что решение на каналах избыточно (создание и освобождение структур явно лишнее). Тут применение мьютекса оправдано. Применять надо то, что удобно в конкретной задаче. И обычно в моих задачах это оказываются каналы. Прошу прощения за неточность формулировок.
Если баг добавляет какие-то фиксированные затраты (ну, например, из-за неудачной архитектуры пришлось сделать отдельный сервер очереди, который так бы не понадобился. То это мелочи. Чем больше клиентов, тем быстрее стоимость этого сервера растворится в общем объёме. Можно не перепиливать всю архитектуру, чтобы сэкономить на этом.
Если баг вводит какие-то дополнительные затраты, которые линейно растут от числа клиентов/покупателей/заработанных денег, это означает повышение цены для конечного клиента на этот процент. Компания при этом может терять конкурентное преимущество, и это можно измерить и посчитать. Тут принимается бизнес-решение — или работаем над фичами, или фиксим баг, в зависимости насколько критично для бизнеса поднять цену
Куда хуже, если система тормозит из-за неэффективного алгоритма (неэффективной структуры базы данных, неэффективных запросов к ней, неудачного проектирования масштабирования, неудачного хранения данных и т.д.), сложность которых сильно выше линейной. Тогда, чем быстрее компания растёт, тем дороже ей будет стоить инфраструктура в пересчёте на каждый заработанный рубль. И такие косяки важно и нужно уметь идентифицировать на ранних сроках. Как только такая ошибка начинает сколь-либо заметно влиять на потребление ресурсов, её надо исправлять. Они не проявляются мгновенно — типа на 100% подскочило потребление. Это всё постепенный процесс — просто постоянно растёт доля выручки, которую сжирает инфраструктура.
Если команда не может справиться с такой проблемой (а это часто случается в жизни, такие комментарии хорошо показывают непонимание ценности навыков алгоритмизации сообществом), то я бы рассмотрел третий способ потратить время программистов — провести им повышение квалификации. Пригласить олимпиадников, провести мастер-класс, порекомендовать литературу, провести может внутри компании свои соревнования. Собственно спортивное программирование — это всё как раз про сложность алгоритмов.
Неэффективные алгоритмы — это не обязательно зона ответственности архитектора. Потребление любого, даже самого маленького компонента системы может быстро разжираться. Любой отчёт, любой запрос к базе данным, неудачный формат файла обмена, чтение/запись в файл, ведение логов, неудачное разделение ответственности между модулями, неудачный API — всё это может быть бомбами замедленного действия с неэффективными алгоритмами внутри. Такие баги нужно исправлять сразу, как только они стали оказывать заметное влияние на затраты, ибо дальше будет только хуже.
Готовность самому что-то узнать вместо того, чтобы говорить «не знаю» в переписке тоже есть. Причём часто достаточно сказать «Я не знаю, но был аналогичный случай бла-бла-бла, и есть ещё человек Фу Бар, который это наверняка знает». Таким образом показывается, что вы не просто отмахиваетесь от вопроса, что вам лень на него отвечать и т.п., а что вы действительно не знаете и помогаете собеседнику найти ответ настолько, насколько можете.
Во-первых, на мой взгляд, простое и изящное решение — это как раз большая красота, чем обобщённая реализация всего, что ни попадя. Умение упихнуть код из трёх файлов с десятком классов в одну небольшую функцию — это и мастерство, и искусство одновременно. Читать короткую программу — одно удовольствие.
Во-вторых, возможность повторного использования кода — это всё важно. Но при этом надо всегда помнить, что сложность — враг надёжности. Программу, которая умещается на 1 экран, можно окинуть взглядом и понять, чего от неё ждать. Как только поток исполнения размазывается по нескольким местам, понять логику по исходникам становится невероятно трудно. Это влечёт за собой ошибки при сопровождении. Дописали чуть-чуть, не учли каких-то особенностей реализации, и в результате — баг. Покрыть всё тестами можно, отловить тем самым все сложные баги — это фантастика.
Как обычно, молясь, не стоит лоб расшибать. Есть места, где сложная компонентная иерархия уместна (например, вы разрабатываете OpenSceneGraph, которым будут пользоваться тысячи людей с совершенно разными задачи). Есть места, где уместны свой язык для описания конфигурации, умная сериализация всех объектов, генерация схем баз данных, метапрограммирование (например, если вы разрабатываете 1С: Предприятие). Но если реально нет бизнес-цели обобщать код, то это не только не делает его красивее, но и ухудшает его по многим параметрам.
Я уверен, что синьор-разработчики, которые указывали новичку на необходимость упростить код, имели в виду именно это — перестать плодить ненужные строки исходников и сделать код короче, проще, надёжнее и легче в сопровождении.
Это не значит, что везде надо применять каналы. В данном случае понятно, что решение на каналах избыточно (создание и освобождение структур явно лишнее). Тут применение мьютекса оправдано. Применять надо то, что удобно в конкретной задаче. И обычно в моих задачах это оказываются каналы. Прошу прощения за неточность формулировок.