Comments 109
Первым делом разработали API для фотографий.
Мы отказались от КЛАДРА в пользу ФИАСА
Наконец добрались до робота импорта XML-фидов.
Ребята, на самом деле, не умаляя важности хорошей архитектуры с точки зрения легкости сопровождения, но для коммерческого успеха сайта она находится далеко не на первом месте. Я не знаю, каким был руководителем тот босс, но в одном он прав. На первом месте — SEO. Совсем недалеко за ним идут быстродействие и стабильность сайта, поддержка мобильных устройств, простота и понятность поиска, фильтрации. Всё остальное, различные API для интеграции, документация для разработчиков и тем более для пользователей, это не важно для сайта, продающего товары/услуги. Если сайт продает ИТ-сервисы, то да, ему нужна документация для разработчиков. Документация пользователям обычно не нужна от слова «вообще». Потому что если какие-то действия на сайте портала не интуитивно понятны, а требуют прочтения документации, 99% пользователей его закроют и пойдут на другой портал, а не будут разбираться.
В 2000-х годах например крупный сайт BN.ru размещал строчки с предложениями (без фото, без описаний, просто дублировал журнал Бюллетень Недвижимости) и кучу баннеров. Тогда вообще все сайты по недвижимости пестрели баннерами, и монетизация шла в основном через них. Фоток квартир было мало потому что на смартфонах ещё не было камер со сносным качеством.
Затем появились новые сайты с фотками, описаниями, удобными поиском и картой, а BN попал в западню: даже после ввода более подробных страниц объекта, большинство агентств всё равно слали им данные в привычном виде (только строчки).
Плюс само пользовательское поведение стало меняться. Если раньше для решения проблемы в основном шли в Яндекс, то теперь недвижимость ищется через сайты, которые на слуху (тот же Авито). Зоопарк порталов стал сжиматься, и такое идёт не только в сфере недвижимости, а вообще во всех сферах. На каждом направлении появляется 2-3 крупных портала-агрегатора, они тянут на себя значительный трафик, а остальным приходится выживать.
Другое дело, что часть порталов из прошлого и сейчас хорошо себя чувствует, и если бы владельцы этого портала вместо сео занимались бы удобством работы с ним в новых реалиях, а разработчики вместо тайного переписывания движка занимались бы обеспечением этого удобства — глядишь не было бы схлопывания посещаемости в 1000 раз.
Я бы на вашем месте сделал бы другой главный вывод: надо смотреть не только на то, как ты делаешь, но и на то, что ты делаешь, для кого и какие перспективы.
Я наверное выскажу очевидные вещи — всем пользователям все равно на чем написан проект, как он работает внутри, используется ли там perl образца 2001 года или новомодный фреймворк. Главное что бы сервис быстро, интуитивно и удобно выполнял задачи пользователей.
Тут встает такой вопрос — а пробовали ли Вы донести до руководства, что перенос картинок из БД ускорит загрузку сайта, тем самым повысив удобство пользователей? И например можно потратить неделю и переписать только эту часть, не трогая другие костыли.
Другое дело, что дефицитный ресурс (рабочее время разработчиков) возможно использовалось не для того, что действительно приоритетно. Какой смысл в удобном личном кабинете например, если твои объекты по недвижимости с каждым годом смотрит всё меньше посетителей? Вероятен сценарий, что разработчики вместо оптимизации того, что есть, поигрались с интересными им технологиями и приложили руку к падению проекта на дно.
Но возможно это просто естественный процесс. С появлением и ростом Авито, ЦИАНа (вот они кстати молодцы, из чего-то абсолютно неюзабельного они сделали удобный и популярный портал) и Яндекс Недвижимости многие очень популярные порталы из прошлого стали неактуальны. Некоторые ещё держатся на старых технологиях (EMLS например), но это скорее исключение. Так что возможно с такими ресурсами просто объективно было нельзя ничего сделать, и жизненный цикл портала закончился сам по себе.
Ошибка босса в том что он вас не контролировал, и вы с ним разговаривали на разных языках.
Кто-то в компании должен объединять все отделы в единый организм. Если не босс, то какой то менеджер, который разбирается и в том что вы творите и в сео и текстах и тд.
Иначе получается лебедь, рак и щука.
Если кто-то не дирижирует этим оркестром, то провал — вопрос только времени. Если каждый в оркестре будет думать что он сам отдельно от дирижера сейчас сыграет супер развязочку, пусть не по нотам, но зато от души, от всего сердца, то в результате получится какофония. Вы же сами признаете что было много сео задач, но время вы тратили на переписывание как в вашем понимании должно быть лучше.
Успех компании это слаженная работа всего организма, каждый орган должен быть здоров и работать поддерживая всех остальных. Тогда на выходе получается лучший продукт, а не продукт где лучший дизайн, но плохое сео, или идеальный движок, но опять же низкое сео и тд.
Так файлы можно и на HDD хранить, MS SQL Server так умеет же.
И сами крайне редко используют эту фишку в своих продуктах.
Причем казалось бы в продукте как шарепоинт или проджект, это решение напрашивается, однако нет. Сменилось уже 3 поколения платформ, а использование filestream до сих пор не включили в рекомендуемый набор по развертыванию.
Хотя шарепоинт это и есть файлопомойка++ (утрирую конечно, но у многих именно так)
А во-вторых, надо плясать не от крутости фишек, а от задачи. И если есть задача хранить файлы на HDD, а основную часть данных — на SSD, то в SQL Server есть простое решение. Которое куда проще чем альтернативы с раздельным хранением файлов и их описаний.
Вот если файлов становится так много что их надо начинать хранить распределенно — это уже другая задача, и SQL Server ее не решает. Но тут-то обсуждается совсем не такая ситуация.
И задачи собственно те-же. Положить файл в хранилище, обеспечить его индексацию, совместную работу с ним, права доступа и относительно компактное хранение.
Что же до команд, то это 2 команды которые работают над флагманскими продуктами для бизнеса.
И в этом разрезе видно что команда шарепоинта просто забила, а команда сиквела согласилась.
И общепринятая практика на сегодняшний момент хранить всякий «стафф» в файловой системе, обеспечивая индексацию средствами шарепоинта, а права доступа средствами файловой системы. Серьезные же документы хранятся в базе данных, где обеспечена версионность, ролевая модель IRM и всякие другие плюшки.
1. Сервер получает запрос.
2. Передает его на бэк.
3. Бэк лезет в базу и делает там выборку.
4. Бэк передает извлеченную картинку серверу.
5. Сервер отдает её посетителю.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
На сайтах с небольшой нагрузкой разница не очень заметна. Но вот когда база разрастается на гигабайты и сайт начинают посещать уже не полтора пользователя в день, все становится очень грустно.
Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5.
Это если у вас картинки лежат прямо на сервере, выставленном во внешний мир по HTTP.
Могут лежать и на другом сервере, но и в этом случае хранение картинок в базе добавляет заметный оверхед без получения особого профита от этого. И, по моему мнению, этого лучше избегать и использовать специализированные решения, заточенные на работу с файлами/объектами.
CDN. S3/GCP/ABS. Просто другой сервер из соображений безопасности.
Про S3/GCP и прочее —
proxy_pass http://my_bucket.s3.amazonaws.com/...
не?
С другого сервера аналогично, s3-compatible например (minio etc), или даже монтировать через nfs.
В случае с CDN делать вообще ничего не надо.
Если у вас CDN как услуга, то да.
Про S3/GCP и прочее
Если у вас открыт доступ к хранилищу по HTTP.
даже монтировать через nfs.
Это если между ними есть такая сеть.
И согласитесь, да, что кроме случая с CDN, это уже далеко не "Сервер получает запрос — Сервер отдает её посетителю."
Ну например — github.com/bsc-s2/lua-resty-s3-client
Lua в nginx очень быстрое.
А еще можно наколхозить горячий in memory кэш на сервере.
> Это если между ними есть такая сеть.
И что же мешает поднять приватную подсеть?
> И согласитесь, да, что кроме случая с CDN, это уже далеко не «Сервер получает запрос — Сервер отдает её посетителю.»
Ну да, кое-какие телодвижения для настройки нужно сделать.
Но это таки не тот адок, когда для выдергивания картинки, скажем, 1х1 или 5000х5000 нужно отдавать запрос бэку, ждать пока он там прожует и пошуршит по базе и отдаст результат, и только уже потом его можно отдавать посетителю.
Ну например — github.com/bsc-s2/lua-resty-s3-client
Это все равно больше не сингл-хоп.
И что же мешает поднять приватную подсеть?
Разные ситуации бывают.
Ну да, кое-какие телодвижения для настройки нужно сделать.
Здесь вопрос не в том, какие телодвижения надо сделать для настройки, а в том, где случается ботлнек в производительности.
Но это таки не тот адок
В обмен на адок вида "как бы нам обеспечить консистентность хранилища в БД и на файловой системе". А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш...
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
> В обмен на адок вида «как бы нам обеспечить консистентность хранилища в БД и на файловой системе». А еще ведь перед бэком, который лазит за картинкой в БД, можно поставить кэш…
И в чем проблема с консистентностью?
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
Вот по нашему опыту, ботлнек как раз именно в «бэк лезет в базу за картинками».
У каждого своя ситуация.
И в чем проблема с консистентностью?
Каждая операция записи, связанная с картиной — распределенная транзакция.
С базой, кроме всего прочего, я еще вижу некоторую проблему в кластеризации и процессе бэкапа базы таких объемов.
… а проблем с бэкапом файлового хранилища такого объема вы не видите?
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
> … а проблем с бэкапом файлового хранилища такого объема вы не видите?
Эти проблемы решается сильно проще. Инкрементальные бэкапы, дедупликация, распределенные файловые системы — вот это вот все.
Я говорил, есть же специальные решения, придуманные и отточенные для работы с файлами. База данных к этому относится очень с натяжкой.
Это решаемая и не запредельной сложности проблема. К тому же никак не влияющая на посетителей.
… пока она не ломается.
Впрочем, мой пойнт был не в этом. Мой пойнт был в том, что ваше "Если же хранить на файловой системе, то все ограничивается пунктами 1 и 5" верно только в примитивном случае.
Беда в том, что CDN, и все остальное, что отдает картинки сразу по HTTP — это не просто "выкати свой сервер с файловой системой", это интеграционная задача.
А мне не ясно, почему у вас что-то тормозило из-за картинок в базе. Сколько я не измерял — всегда разница была незначительной между хранением в БД и в файловой системе. Поэтому предпочитал и предпочитаю хранить в БД, ибо целостность.
Целостность в БД в конечном итоге образуется через целостность файловой системы. И если используете картинки как обычно это делают — раз загрузили и только читаете — преимуществ у СУБД нет. При конкурентной записи, постоянном изменении одних и тех же картинок — еще какой-то смысл есть.
А вот кэши СУБД/быстрые диски SSD, которые были бы полезны для запросов без картинок — забиваются тем, с чем легко справляется файловая система напрямую без БД с обычных дисков HDD
Конечно обидно, что труд нескольких лет остался не востребованным, но с другой стороны лично вы прокачали скилы и этот ваш опыт сам по себе ценность. Теперь можете рассчитывать на трудоустройство в более интересном и ИТ -ориентированном месте, где успешно будете применять эти навыки.
Я пришел на эту работу в 2014 году, простым junior .net.
На втором году работы, мой руководитель ушел с проекта. И я остался один на один с этой древней махиной, в которой было от силы 3% моего кода.
Если руководитель не стал ни чего предпринимать и просто слился — тут или он сам по себе такого склада (инфантильный с позиции тех. эксперта), или попросту понимал что уже ни чего нельзя было исправить (руководство не принимало информацию к сведению). В любом случае весь рассказ больше о всё об одном — ошибке управления и адаптации на рынке, технические аспекты могли иметь место быть, но как уже упомянули ранее — их роль была далеко не основополагающей.
Если та нить между сотрудниками, которая удерживает бизнес на плаву, порвана, то ваш продукт непременно пойдет ко дну.
Вероятен сценарий, что каждый со своей колокольни думает что знает рынок и свой продукт, но на самом деле не видит целостной картины.
Я старался никогда не обвинять. Мы тоже где-то действовали в своих интересах, но на это у нас были причины.
Про избегание начинающих разрабов… Попахивает дискриминацией по признаку отработанных лет. Каждый джуниор должен иметь возможность получить опыт, чтобы стать кем то большим.
Эта компания оказалась одной из таких, за что ей надо отдать должное.
что стоит избегать разработчиков с парой лет опыта
Избегайте, ваше право. Вот только опытных, как показывает практика, с каждым годом всё меньше, а запросы у них всё выше… :)
Мир меняется. Глобализируется. Некоторые услуги просто пропадают (уменьшаются на порядки), другие появляются. Остаются только крупные игроки, которым принадлежит большая часть глобального рынка. Остальные делят крохи.
Но сайт умер, вероятно, по другим причинам — его вытеснили в естественном отборе другие сайты, предлагающие подобную информацию в более удобном виде.
Не увидел в обзоре сравнения вашего сайта с конкурентами на рынке, набора ключевых показателей этого сравнения, и попыток их улучшить.
копание внутри сайта без оглядки на рынок — позиция страуса, который копает червячка в песке, оставив жопу беззащитной
«Так никто не ищет, это низкочастотный запрос, я уверен»
до боли знакомо)) три мульона доводов, сценариев рассказываешь, а он — не, у нас же специфика)) а ты ему опять — да никто не ищет товар по коду в официальном каталоге производителя, потому что никто его не знает, ищут по модели и тому, что увидели на бумажке, перебирая все варианты. А он тебе — нифига, это все неправильные коды))
Не факт. Я например когда ищу запчасть к машине вбиваю в гугл её partnumber найденный под картинкой, скажем, hondapartsnow и гугл выкидывает мне список конкретных продавцов (в моем регионе). На порядки удобнее и быстрее, чем попытка сформировать запрос «вон ту хреновину от коробки передач на такой то пепелац».
В одном из своих интервью он дал дельный совет как найти себя в бизнесе. Этот совет просто до идиотизма простой.
Точную цитату сейчас лень искать. Но все что он тогда наговорил можно вынести тезисом в одно слово: улучшайте.
Хамят продавцы в магазине у дома? Откройте по соседству такой же, только с вежливым и внимательным персоналом.
Роскосмос дорого запускает спутники? Придумайте технологию возврата ступеней и снижайте стоимость пуска с каждым запуском (уже).
В общем щупайте слабые места конкурентов и аккуратно туда давите.
В связи с этим я не понимаю автора статьи. Если вы, автор, со своим техническим напарником были настолько подкованы во всем бизнес-процессе фирмы и постоянно фейс-палмили от нелогичных решений руководителя, что вам мешало запустить свой сервис с домами и риелторами?
Запустили бы и показали как надо. А дядю бывшего начальника на вертушку охранником посадить.
> Запустили бы и показали как надо
«Станьте ёжиками». Это же так просто и не требует вложений.
Улучшая, можно во-первых провалиться
Можно. Но как показала практика вперед вырываются только те кто постоянно находятся в развитии и поиске нового. Стагнация это один шаг до смерти любого дела (что мы и видим на примере данной статьи).
как тот же Тиньков со страховой, который не смог предложить сервис даже на уровне конкурентов
Подробности не знаю. Возможно это была его ошибка. Но как говорится не ошибается тот кто ничего не делает. И не стоит забывать, что Тиньков начинал как фарцовщик одежды, а на данный момент является долларовым миллиардером и владельцем банка. Прошел бы он этот путь, если бы являлся любителем стабильности и стагнации? Общий знаменатель его успешности более чем впечатляет.
«Станьте ёжиками». Это же так просто и не требует вложений.
Любое дело требует вложений.
Даже для того чтобы выиграть в лотерее нужно купить билет.
Адекватному человеку это изначально понятно и не требует никакого скудоумного обстебывания с неуместным сарказмом.
В действительности, я начал полностью переписывать систему практически с 0. Пришлось это делать тайно от руководства.
Не надо так делать.
Я искренне уважаю стремление автора вытянуть проект, его полную погруженность в работу и неиссякаемый энтузиазм. Но в тайне переписывать систему — это, я считаю, ошибка.
Разработчик не должен думать за бизнес и принимать решение за бизнес. Да, он может высказать свое мнение, предоставить свою экспертизу, выразить сомнение, проявить инициативу. Но без одобрения менеджмента делать крупный кусок работы — за это никто спасибо не скажет. Более того, это не очень-то и этично. Это как сказать прямым текстом: «Товарищ менеджер, ты сам не понимаешь, что ты делаешь. Поэтому я буду принимать решения за тебя, с тобой не посоветовавшись». Не надо решать за менеджмент, что делать.
К тому же, из текста для меня совсем не очевидно, почему проект провалился. Может, при текущем маркетинге, дизайне и фичах, даже если бы все летало, проект бы это не спасло.
Все-таки мы переписывали скорее для себя и будущих разработчиков, чтобы нам же было легче модернизировать и поддерживать продукт дальше, другими сотрудниками. Простые задачи больше не занимали много времени.
И эту задачу мы выполнили. Это был фундамент на будущее, которое мб когда-нибудь там и наступит.
Мне это немного напомнило известную притчу про Васю, который наговнокодил и выпустил свой продукт на рынок быстро, и Петю, который долго вылизывал свой код, но закончил уже тогда, когда его продукт перестал быть актуальным.
Рефакторинг — это конечно хорошо, но если проект умирает, то может вместо закладывания фундамента на будущее лучше делать что-то другое?
Почему не надо?
Потому что это не нормальные деловые отношения. Не надо брать на себя чужие зоны ответственности. Если руководство забраковало идею, нужно принять это решение. Не надо решать за других людей. Да, возможно, это неправильное решение. Но делать «благую работу» вопреки ему — это неправильно.
В командах приходится работать с большим количеством людей. Многие из которых не всегда принимают корректные решения. Везде всегда кажется, что кто-то что-то решил не так. Но нужно с этим жить, а не делать по своему. Максимум, что можно сделать — это выразить свое мнение. Или сменить работу. Но игнорировать чужие решения в их зоне ответственности — это не тру.
Далее, это просто неблагодарная работа. Премию за это вряд ли выпишут. Более того, если это всплывет, руководство вообще может отреагировать весьма негативно. Потому что в их глазах вы делаете не то, что должны.
Ну, и конечно, такая деятельность — она вызывает большое чувство обиды и неудовлетворенности. Если пытаться сделать все что возможно, но в рамках рабочих нормальных отношений, — то чувства обиды не будет.
Нужно кооперироваться и уважать чужие решения. Даже если кажется, что они неверны.
Кооперироваться банально невыгодно. Да, люди не хотят быть плохими, но шаг за шагом, сами того не замечая, начинают. В данном конкретном случае «уважать чужие решения» == «искать баги в чужом коде целыми днями» && «изучать устаревшие технологии». Зачем? За это не будут больше платить, и не дадут долю в бизнесе.
Есть совсем упоротые, которые подвызываются на фриланс либо удаленку параллельно с основной работой, и две, а то и три ЗП одновременно получают (и при этом ловят намного больший кайф от того, как поимели систему и дебилов менеджеров, чем от процесса траты трех ЗП), но большинство просто начинает подменять нужные задачи интересными, поучивать технологии в рабочее время, продавать ненужные усложнения бизнесу. Это повсеместная проблема, и лично для себя я сделал вывод, что системно она не решаема. Или нужен маг, который зажгет глаза (но на поток ты хантинг магов не поставишь, а чаще появляются зажигатели глаз, но в невыгодном для бизнеса направлении — приходит главный архитектор, и говорит «сейчас есть мегатренд — новая технология. Давайте разбираться, и перепишем все на ней»), или просто бизнес должен признать, что производство кода имеет запредельный % брака, и вбрасывать больше ресурсов.
Любой бизнес это стратегия — как при ограниченных ресурсах достигать максимальных результатов. Переписывание проекта — это ставка на долгосрочный результат, может быть лучше было бы решать коротко срочные задачи?
Иными словами, вместо SEO и оптимизации сайта надо было заниматься привлечением клиентов. Одна точка подачи объявлений на город? Вы не понимаете, насколько это неудобно. Нет преимуществ подавшим объявление в поиске на сайте? Опять неудобно. Нет оплаты через инет? Опять неудобно.
Вот потихоньку ваших клиентов и переманили те, где было удобно.
Мы — разработчики и могли только отпимизировать сайт. У нас были и плюшки для ручного размещения, и оплата через интернет, и бонусы для клиентов. А вот привлечением занимались периодически и малоуспешно.
Я это все к тому, что увы, при всем уважении к автору, ну не сделать даже имея полную поддержку бизнеса и дрим тим из 5 фулл-стек синиор разрабов, захват рынка. Пользователи привыкают к массе мелких плюшек. Пользователи хотят актуальную базу данных с мгновенным парсингом даже тех агенств, которые активно защищаются от ботов-парсеров. Пользователи хотят того, на что надо масса человекочасов, даже если все писать с первого раза и без багов.
А потом оказалось, что нужные задачи не решены, зато есть сверкающая отполированная платформа, которая не способна вытащзить компанию, потому что владельцу нужен не переписанный проект, а проект соответствующий его требованиям, которого нет, потому что вместо решения поставленных задач перепиливалась платформа тайком. Да, да, виноват конечно руководитель.
Это генально…
Бабло в рекламу = 45% успеха
Архитектура и код = 10% успеха
Как то так
Я видел, как в одной крупной корпорации не приветствовали собственные разработки. Все централизовано закупалось. Так вот, разработчиков с треском уволили, с трудовыми комиссиями, с фабрикованием ложных трудовых характеристик, с подставами с опозданиями, и т.д., потому что вдруг выяснилось, что разработанное условно бесплатное ПО по функционалу и качеству на голову превышало возможности дорогостоящего закупаемого ПО, с которого начальники имели профит в виде отката.
В 2014 году посетителей стало меньше в 3 раза, но старая платформа все равно перестала справляться с нагрузкой. Сервер устал? ;)
Программистов понять легко, они старались сделать как лучше. Но если бы они и не ударились в тайное причинение добра, а смирно выполняли все хотелки руководства — результат был бы тот же.
То есть если предположить, что исход был бы такой же — самореализация автора как клевого программиста переписавшего всё в идеальный не кому не нужный код обошлась фирме которая и так загибается в 2400000 рублей.
Следующая статья автора будет ещё большим пиаром "новой супер платформы".
Так, ладно, работа нужна?
Я заметил такую вещь, что у программистов своеобразный склад ума и взглядов, и им в команду всегда требуются специалисты другого уровня, как стратегический менеджмент, маркетинг и т.п.
Читал твою статью чуть ли не со слезами на глазах. Очень печально что такой труд умер. К сожалению, а может и к радости — множество проектов умирает по этой причине.
Создавая портал — нужно понимать такую вещь в первую очередь — сайт (любой «полезный» кстати) — это не кусочек кода с «техником» — это такая же функциональная фирма как и любая другая офисная, так же требует «техничку», директора, менеджера, маркетолога, и «водителя» — вот многие об этом забывают.
В твоей статье меня порадовал твой профессионализм и усидчивость — это высокая ценность в твоей среде, береги ее и развивай. И ради бога не трать себя на «пустые» компании.
Желаю тебе найти перспективный проект с перспективной командой.
Первое правило
Как мы создали технологичный продукт и провалились на дно