Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Работа в Google глазами украинского разработчика

[Об авторе: Александр — разработчик prom.ua, с 2008 по 2010 работал на проектах Google как подрядчик-контрактор]

На предыдущей работе я ездил в продолжительные on-site командировки в Google. Работа была интересной и неплохо оплачиваемой. Ушел с нее, так как она стала мешать заниматься собственным проектом. К сожалению, за два года не хватило опыта и смелости вывести проект в прибыль. Когда накопленных на предыдущей работе сбережений осталось менее чем на полгода, приступил к поиску новой работы и устроился в Prom.ua.

Хочу поделиться своим опытом работы на проектах в Google и сравнить процессы разработки в «кремниевой» и украинской продуктовых компаниях.

Что нравилось в Google

В Google все сделано для того, чтобы разработчики дольше оставались на работе, и им было удобно в офисе. Просторные помещения, бесплатное трехразовое питание, mini-kitchen’ы, спортивные секции, бассейн, волейбол, тренажеры, массаж и т.д. непосредственно на территории кампусов.

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

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

Удобно организована работа с любого компьютера в офисе или удаленно: введя свой логин/пароль, попадаешь в свое рабочее пространство. На ноутбуках запрещено хранить рабочий код — весь код должен лежать в «рабочем пространстве» — с ноутбука нужно логиниться в это «пространство» и только потом вести разработку. Можно спокойно терять рабочий ноут, не опасаясь утерять конфиденциальную информацию, а также не опасаться, что на рабочем компе «накроется» жесткий диск и вместе с ним — все твои наработки :)

Классная «облачная» инфраструктура для сборки, тестирования и деплоя в dev-окружение и продакшн. Сборка проходит не на твоем компе, а где-то в «облаке». Это ускоряет процесс сборки, так как независимые модули могут собираться параллельно, а уже собранные кем-то другим другим модули для заданной версии кода — могут использоваться без пересборки. То же самое касается тестирования.

Компания придерживается правила eat your own dog food, используя собственные разработки внутри компании. Это помогает быстро выявлять и исправлять баги и вносить полезные для пользователей изменения в разрабатываемые продукты.

Повсеместное используют protobuffers для хранения и передачи данных и rpc на основе protobuffers для общения сервисов между собой. Это избавляет от изобретения «зоопарка» форматов хранения и передачи данных с последующим изобретением всевозможных конвертеров между этими форматами.

Код большинства проектов хранится в общем репозитории, который организован в виде библиотек функций. По этому репозиторию сделан удобный поиск. Это позволяет не изобретать велосипед каждому из проектов, а использовать уже существующие наработки других проектов. Также, улучшения в core-библиотеках сразу же становятся видны во всех проектах, использующих эти библиотеки. В отличие от Google, в Prom.ua сейчас идет тенденция к разделению кода на кучу независимых репозиториев для слабо связанных проектов. Это, с одной стороны, хорошо, т.к. разные команды не зависят друг от друга и работают каждый в своем ритме, но с другой стороны — не видны оперативные изменения в разных проектах, нужно выстраивать и поддерживать в актуальном состоянии API для взаимодействия между проектами, а также затруднено использование общего кода между проектами.

Что не нравилось в Google

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

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

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

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

Много нового кода в Google пишут на Java. Это хорошо с точки зрения hr’ов: программистов на Java сейчас очень много, и есть из кого выбирать. Но плохо с точки зрения качества кода. Из моей практики заметил, что программисты на Java зачастую любят злоупотреблять ненужными паттернами проектирования, нагромождать кучу бесполезных абстракций, интерфейсов, фреймворков и xml-файлов, ошибочно предполагая, что это «круто». В итоге простейший код из 100 строчек превращается в монстра на 100500 строчек, который сложно понимать, расширять, рефакторить и дебажить. Это существенно затягивает время разработки. Например, разработка новой версии веб-интерфейса для одного из проектов Google растянулась на несколько лет не в последнюю очередь из-за слишком «умного» кода на Java.

Постепенное вытеснение кода на Python кодом на Java под флагом того, что «код на Java быстрее». Из моей практики, среднестатистический код на Python получается проще и понятнее аналогичного кода на Java. В результате разработка и расширение кода на Python занимает в несколько раз меньше времени и усилий по сравнению с аналогичным кодом на Java. Насчет утверждения «код на Java быстрее» — да, обычно первоначальный код на Python получается медленнее кода на Java. Но код на Python можно легко оптимизировать в случае необходимости до скорости, равной или превышающей скорость аналогичного кода на Java. Для этого нужно лишь грамотно использовать средства, предоставляемые Python, только в крайних случаях прибегая к переписыванию «узких мест» на C с использованием ctypes или Swig. Занимательные факты — автор Python, долгое время работавший в Google, перешел в Dropbox, а автор Java — перешел из Oracle в Google :)

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

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

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

Сравнение процессов в Google и Prom.ua

К сожалению, с увеличением размера продуктовых компаний в них теряется дух стартапа. Выстраивается иерархия из «эффективных» менеджеров, порождая бесполезную бюрократию, рвется свободное общение между директорами и обычными работниками, замедляется решение оперативных вопросов. Между написанием новых фич и их внедрением в продакшн проходит всё больше и больше времени, что не дает сразу увидеть отклик реальных пользователей на новые изменения в коде. Также с возрастом проекты начинают терять былое качество кода — он обрастает кучей малополезных bells&whistles (обычно оставляющих за собой устаревший код, костыли и баги), которые постоянно требуют отделы продакт-менеджмента и маркетинга.

В отличие от Google, в Prom.ua еще не потерян дух стартапа. Руководители с менеджерами не прячутся от сотрудников, поэтому быстрее решаются оперативные вопросы. Качество кода здесь пока еще лучше, чем на большинстве моих предыдущих проектов похожей сложности. Разработка и деплой идет быстрее — у нас код попадает в продакшн в течение нескольких дней (а иногда и часов), поэтому сразу виден отклик реальных пользователей на новые изменения в коде. Мы можем намного быстрее реализовывать необходимые функции и «оттачивать» их на основе обратной связи. Среди потока задач находится большой процент интересных (например, оптимизация по производительности и потреблению памяти, рефакторинг кода, улучшения UX). Более того, некоторые не совсем интересные задачи становятся интересными, т.к. тут сразу видна реакция посетителей на результаты твоей работы. У нас не приходится писать код «на склад», который в лучшем случае выйдет в продакшн через пару месяцев.

На данном этапе развития компании здесь я вижу для себя больше возможностей для самореализации и карьерного роста, по сравнению с Google. Что будет дальше, покажет время.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Иногда складывается впечатление что в книгах по Python между строк написано «НЕНАВИДЬ ДЖАВУ, С%№А!».

Из моей практики, среднестатистический код на Python получается проще и понятнее аналогичного кода на Java.
Мне интересно:
Комплексы по поводу размера Питон против Джава — это у всех питонистов или только у сотрудников прома?
Читабельность, понятность, часто сокрость и другие метрики кода куда больше зависят от программиста (его опыта и навыков), а не от языка. Первые 2 так же зависят и от того кто читает код.
.
Но код на Python можно легко оптимизировать в случае необходимости до скорости, равной или превышающей скорость аналогичного кода на Java. Для этого нужно лишь грамотно использовать средства, предоставляемые Python, только в крайних случаях прибегая к переписыванию “узких мест” на C с использованием ctypes или Swig.
Як діти, їй-Богу © А на джаве нельзя переписать “узкие места” на Ц? Или переписать “понятный код” на мутотень но быструю"? Меня всегда забавляли такие аргументы.
.
В отличие от Google, в Prom.ua еще не потерян дух стартапа.
Я что-то пропустил или у прома уже:
As of 2013, Google had 47,756 employees (in the fourth quarter, including the Motorola subsidiary),[6] among them more than 10,000 software developers based in more than 40 offices
А если нет то зачем сравнивать палец с ...?

91 коментар

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

отличная статья, жаль что видосов нет

а кстати, интересно, а почему на Dart не переходят?

а кстати, интересно, а почему на Dart не переходят?
По слухам таки переходят.

думаю слухи верные.
ЯП — неплох.
опыта разработки ВМ — у гугловцев хватает.
плюс курс на использование только своего инструментария.

по идее, для серверной ВМ Dart можно прикрутить и подключение jar’ников.
хотя, если есть угроза судебных тяжб с Oracle, то конечно не будут.

Серёжа, а что означает ВМ?

ффух, встиг прочитати, поки не прибігли юристи Google

Мне кажется, что компания посредник оговаривает тот момент, что не стоит публично рассказывать, где и что вы делали будучи в длительной "

on-site командировки
"

к сожалению, нет. не оговаривает явно.
обычно ограничивается перечислением с пространной формулировкой «и другая информация, раскрытие которой можетпривести к финансовым и другим нематериальным потерям, вклячая репутационные». ну, дословно не процитирую. в любом случае, даже отзывы о том, как в компании плохо и почему — попадает под всеобъемлющее определение «коммерческой тайны»

Как минимум — это (неразглашение) является частью «джентельменского соглашения» :)

А почему в protobuf каждому полю в сущности надо ручками назначить идентификатор? Разве «компилятор» protoc с этим сам разобраться не может?

Это нужно для того, чтобы новый код мог читать старые версии protobuf-ов, записанных 100 лет назад где-нибудь в BigTable — поля в сериализованных protobuf’ах определяются по их идентификаторам, а вовсе не именам (это сделано в целях уменьшения размеров сериализованных protobuf-ов). Например, если 100 лет назад у protobuf’а User было только два поля: Name и Email, а затем в него добавили еще два необязательных поля Age и Gender, то новый код сможет спокойно прочитать старые версии User’а, вытянув оттуда Name и Email. Поля Age и Gender при этом будут пустыми. Аналогично, старый код, знающий только про Age и Gender, может спокойно читать новые protobuf-ы, пропуская поля с незнакомыми ему идентификаторами.

Если бы идентификаторы полям назначал компилятор, то как бы он узнал, что полям Name и Email нужно оставить прежние идентификаторы после добавления полей Age и Gender? Если бы он назнчачил им другие идентификаторы, то новый код не смог бы прочитать старые protobuf’ы, а старый код — новые probotbuf’ы.

Вы слишком буквально поняли мой вопрос. Решение проблемы версионирования сериализованных данных на этапе компиляции — атавизм, добавляющий головной боли в момент написания кода.

Решение проблемы версионирования сериализованных данных на этапе компиляции — атавизм, добавляющий головной боли в момент написания кода.
  1. В чем заключается сложность проставления вручную идентификаторов для полей структуры?
  2. Предложите решение, в котором не нужно проставлять вручную эти идентификаторы, чтобы оно удовлетворяло требованиям:
    • подержка forward- и backward compatiblity при добавлении/удалении/переименовании полей структуры
    • минимальный объем сериализованных данных (чтобы было на уровне protobuf’а или Cap’n Proto)
    • минимальное использование CPU и памяти во время сериализации/десериализации данных

1. Я же привел пример. Большая сущность, скажем, сотня полей. Вставьте или удалите поле из середины.

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

Хэш по полю структуры не подойдет по следующим причинам:

  1. Возможны коллизии для разных имен полей
  2. При переименовании поля значение хэша становится другим
  3. Сериализованный хэш занимает больше места, чем идентификатор, присвоенный вручную (много байт вместо одного байта для структур, содержащих до 256 полей)

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

Позиция в поле сущности в качестве идентификатора плоха тем, что в итоге нельзя будет менять местами поля, а новые поля должны всегда добавляться в конец списка полей. Например, если в User { name, email } решили добавить gender c age, то их нужно будет добавлять в конец сущности — { name, email, gender, age }, но никак не { gender, email, name, age } .

Мы уже с вами, кажется, определились, что не все поддерживают обратную совместимость этим путем. С моим подходом мне не страшно вставить поле в середину, или поменять их местами.
Вот на вашем же примере сущности User, представляем на секундочку, что там 100 полей, и работа над проектом ведется уже пару лет. Варианта два — либо у нас все поля пронумерованы по порядку (что мог сделать и компилятор), и если нам надо вставить поле в середину, то нас ждет тот еще геморой с переназначением индексов, либо у нас ничего не пронумеровано, и нас ждет квестик под названием «найди максимальный индекс поля в этой каше». Ах да, есть третий вариант, если все поля добавляются всегда в конец сущности, но это делает ее совершенно не читабельной. Кстати вопрос, если есть поле 1 и 5, а 2-3-4 нету, под них же не выделяется место?

Кстати вопрос, если есть поле 1 и 5, а 2-3-4 нету, под них же не выделяется место?
Нет. Струтура преобразуется в последовательность байт в TLV виде:
{id поля1}{длина_поля1}{значение_поля}{id поля2}{длина_поля2}{значение_поля2}...{id_последнего_поля}{длина_последнего_поля}{значение_последнего_поля}

Тип полей определяются по их id. Размеры для коротких полей и полей фиксированной длины можно не хранить. Размеры полей полезны при сканировании определенного набора полей в сериализованном списке струтур — с помощью них можно пропускать длинные поля, не входящие в искомый набор, не тратя время на их чтение.

Если какие-либо поля отсутствуют в структуре или имеют значение по умолчанию, то они вообще не занимают место в сериализованном виде.

А чем принципиально отличается работа контрактором в гугл или работа постоянным сотрудником?

Есть вариант, после контрактора перейти в постоянный штат?

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

Контракторы могут перейти в постоянный штат. Некоторые мои коллеги так и сделали. Но большинство из них перешло работать в другие компании Silicon Valley после окончания контракта.

Постепенное вытеснение кода на Python кодом на Java под флагом того, что «код на Java быстрее».
Не совсем так. Во внутренней сети гугла без проблем можно найти документ, озаглавленный «Python considered harmful». Не совсем понятно, почему его не выпускают наружу, ничего NDA-шного или раскрывающего архитектуру приложений в нем нет.
Основная идея документа — при росте codebase проект на Python становится неуправляемым. В качестве примера приведен Mondrian (прежняя система Code Review), написанный самим Гвидо. Думаю, это было последней каплей, после которой тот свалил из гугла.

Да, старая беда, при использовании ЯП с динамической типизацией.
В Фейсбуке тоже, Hack сотворили — на вид пхп, но со статической типизацией.
В итоге компилятор ВМ может эффективный код генерировать, и сам код может при росте кгоколичества остаётся управляемым.

Я чувствую себя комфортно как со статической, так и с динамической типизацией. Статическая типизация — не панацея от всех бед. Она позволяет отлавливать определенный тип багов. Но, как показывает практика проектов, написанных на ЯП с динамической типизацией (например, prom.ua), эти баги не существены как в количественном, так и в качественном выражении. Подавляющее большинство критичных багов связано с логическими ошибками, которые никак не выявляются с помощью статической типизации.

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

Я чувствую себя комфортно как со статической, так и с динамической типизацией.
дело не в индивидуальном комфорте.

а в статистическом факте — чем больше проект и больше в нем людей, тем реже встретится реализация на ЯП с динамической типизацией

— Можно намного быстрее рефакторить и расширять существующий код.
в большой толпе на ЯП с динамической типизацией?
Но, как показывает практика проектов, написанных на ЯП с динамической типизацией (например, prom.ua),
да и без prom.ua — что на серверсайде большинства веба крутится? PHP.

какое количество разработчиков обычно справляется, т.к. сказать «с обычным веб сайтом»?
2-3, или 200-300?
подсказка, недавно встретил исследование — четверть сайтов мира крутятся на WordPress.
инсталяций WooCommerce и подобных, тьмы. чтобы не думали что речь только о «статике».

Преимущества динамической типизации над статической:
для малых команд.

мегабаталии на эту тему, где пожалуй все остальное сказано:
Как избавиться от динамической типизации

а в статистическом факте — чем больше проект и больше в нем людей, тем реже встретится реализация на ЯП с динамической типизацией
Думаю тут дело не в том, что динамическая типизация вводит больше порядка, а в том, что по мере роста проекта уже точней понимают как и что он должен делать и скорость работы приложения становится более критичной, а вот тут уже языки со статической типизацией как правило быстрее.
какое количество разработчиков обычно справляется, т.к. сказать «с обычным веб сайтом»?
2-3, или 200-300?
Опять же что что считать обычным есть довольно много проектов где разработчиков под сотню. При этом используются языки с динамической типизацией.
Опять же что что считать обычным есть довольно много проектов где разработчиков под сотню.
что значит - довольно много? сколько - процентов от числа проектов - вообще?
При этом используются языки с динамической типизацией.
я не рассматриваю аргументы двух видов:
нефальсифицируемые
"а вот я знаю случай!"
нефальсифицируемые
это как? может, не верифицируемые, то есть, не поддающиеся проверке?

супер. не знаю значения слова, а использую.
то есть «сфальсифицированный» — на самом деле это «методологически опровергнутый».
прикольно.

супер. не знаю значения слова, а использую
а оно часто так :)

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

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

со временем, критики указали что все равно часть научного знания оказывается нефальсифицируемым, так что философам еще работа в этом направлении осталась. в поиске — еще более общего критерия.

«сфальсифицированный» — на самом деле это «методологически опровергнутый».
я бы сказал —
"сфальсифицированнЫЙ«(т.е. состоявшееся действие) — это доказана методологическая возможность опровержения.

а нефальсифицируемость — это когда невозможно придумать опровержения.

например — теории заговора — нефальсифицируемы «по определению».

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

да.
ладно бы там история и психология, они нефальсифицируемы.

математика — нефальсифицируема! то есть — ненаучна, как по отсутствию эмпирической верификации, так и по методологии.

удивительная она штука, математика, да.

по мере роста проекта уже точней понимают как и что он должен делать
да, вполне причина.

известно что для прототипирования более эффективно применять ЯП с динамической типизацией.
или, когда нет проработки ТЗ, да и самого ТЗ, а есть разрозненный набор несвязанных хотелок и фич. т.е. когда фактически отсутствует этап проектирования.

а вот тут уже языки со статической типизацией как правило быстрее.
автовывод типов да, пока в массовых ЯП не прижился. Haskell да Scala. Да в лямбдах, где они есть.

Не знаю, что там не так с Mondiran, но его opensource-клон — code.google.com/p/rietveld — вроде нормально развивается. Наш проект (prom.ua) пока тоже остается управляемым спустя шесть лет разработки. Качество кода постепенно ухудшается (как и в большинстве развивающихся крупных проектов), но пока нет ничего критичного — систематический рефакторинг и code cleanup позволяют держать код на уровне.
Качество кода падает не из-за Python’а, а по следующим причинам, свойственным большинству коммерческих проектов:
* Постоянное внедрение большого количества новых «фич» (в основном bells&whistles).
* Код от старых «фич» почему-то склонен оставаться в проекте навечно — «авось пригодится».
* Т.к. количество реализованных «фич» слишком велико и нет ответственного по каждой «фиче», то качество их реализации постепенно падает, а количество багов в них постепенно растет.

Python же, наоборот, позволяет внедрять новые «фичи» с поразительной скоростью, а также быстро рефакторить код, несмотря на возраст, объем и сложность проекта.

при росте codebase проект на Python становится неуправляемым
За час чтения ДОУ — вторая информационная вишенка!!! (первая была про «ошибку выжившего»)
А вы говорите — ДОУ не торт!
Из моей практики заметил, что программисты на Java зачастую любят злоупотреблять ненужными паттернами проектирования, нагромождать кучу бесполезных абстракций, интерфейсов, фреймворков и xml-файлов, ошибочно предполагая, что это «круто». В итоге простейший код из 100 строчек превращается в монстра на 100500 строчек, который сложно понимать, расширять, рефакторить и дебажить.
К сожалению, с увеличением размера продуктовых компаний в них теряется дух стартапа. Выстраивается иерархия из «эффективных» менеджеров, порождая бесполезную бюрократию, рвется свободное общение между директорами и обычными работниками, замедляется решение оперативных вопросов. Между написанием новых фич и их внедрением в продакшн проходит всё больше и больше времени, что не дает сразу увидеть отклик реальных пользователей на новые изменения в коде.

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
(M. Conway, 1967)

...Complex programming projects cannot be perfectly partitioned into discrete tasks that can be worked on without communication between the workers and without establishing a set of complex interrelationships between tasks and the workers performing them.
(F. Brooks, 1975)

Ви в назві помилились. Вірно так: «Работа в Prom.ua глазами украинского разработчика»

Иногда складывается впечатление что в книгах по Python между строк написано «НЕНАВИДЬ ДЖАВУ, С%№А!».

какашку можно написать на любом языке.

Иногда складывается впечатление что в книгах по Python между строк написано «НЕНАВИДЬ ДЖАВУ, С%№А!».

К сожалению, не читал ни одной книги по Python, поэтому не могу оценить корректность данного утверждения.

неужели Вам передалось с молоком матери?0.о

Более того, преподы в американских университетах теперь активно зомбируют студентов Python’ом — news.ycombinator.com/...item?id=8001337 . Так что конец Java близок как никогда!

Более того, преподы в американских университетах теперь активно зомбируют студентов Python’ом — news.ycombinator.com/...item?id=8001337 . Так что конец Java близок как никогда!
«Python is Now the Most Popular Introductory Teaching Language at Top U.S. Universities»
Если Паскаль с Делфи не убили Джаву, то куда уж Питону. Кстати, эффект таки противоположный с Паскалем получилсо, стоит задуматсо. :)
Так что конец Java близок как никогда!
100500-й раз такие заявочки звучат в сторону java и что-то как-то не фонтан)

Тем более преподы могут использовать python как первый язык (например у меня в школе первым был паскаль) и это сантиметров к пипиське python’а не добавляет, java возьмет свое :Р

100500-й раз такие заявочки звучат в сторону java и что-то как-то не фонтан)
Это все та же история, которую рассказывал Джоел bit.ly/1ndL9tI
Самое забавное или печально, что Питон вместо Джавы, только усугубляет проблему.

Согласен, что обучить программировать на Python’е легче, чем на Java и тем более на C. Поэтому обучение студентов на Python приведет к повышенному количеству «прогромистов», которые не задумываясь разбрасывают по коду O(n^2) алгоритмы (по CPU и по потребляемой памяти), где можно обойтись O(n) или даже O(1) алгоритмами.

Прикол в том, что спрос на таких «прогромистов» выше, чем спрос на программистов, разбирающихся в Computer Science. Почему так происходит? Вспомните, когда в последний раз вы занимались core CS-задачами, а когда — программированием очередной «фичи» с «тупой» бизнес-логикой, для которой знания из CS не только не нужны, но могут оказаться и вредны (например, если «фича» может быть реализована за полчаса с помощью O(n^2) алгоритма либо за неопределенный срок с помощью O(1) алгоритма, то CS-aware программист может потратить месяц на реализацию этой задачи, а «прогромист» сделает все за полчаса не задумываясь). Поэтому с каждым годом спрос на «прогромистов» будет только расти. Работа найдется и для CS-гуру и для «прогромистов».

Насчет «Java vs Python в контексте обучения программированию», я придерживаюсь точки зрения, что чем проще и понятнее ЯП, тем лучше — ведь больше людей смогут научиться программировать. В силу философии Python’а и его простоты, на нем намного сложнее наговнокодить по сравнению с Java, где даже простейшие задачи обычно делаются с помощью 100500 бесполезных классов, интерфейсов и абстракций.

Вспомните, когда в последний раз вы занимались core CS-задачами, а когда — программированием очередной «фичи» с «тупой» бизнес-логикой
ВУЗ/Университет — это про «формирование (способа) мышления», про понимание того как это все работает. А вот ваш же пример:
В силу философии Python’а и его простоты, на нем намного сложнее наговнокодить по сравнению с Java, где даже простейшие задачи обычно делаются с помощью 100500 бесполезных классов, интерфейсов и абстракций.
Человек который понимает что стоит за созданием объекта или даже класса не будет создавать __ненужные сущности__. Ну и про философию питона dou.ua/...ums/topic/7732 — 100 строк на функцию? Окуеть философия!
И вторая проблема:
я придерживаюсь точки зрения, что чем проще и понятнее ЯП, тем лучше — ведь больше людей смогут научиться программировать.
Больше не значит лучше. Вроде как, в той же стать е Джоел писал что более простоя ЯП (и программа обучения) уменьшают отсев «случайных людей».
Почему это плохо:
В вашем же примере (цитата ниже), если добавить вводную что решение O(1) реализуемо за соизмеримое время с реализацией O(n^2)-алгоритма, то «случайный человек» просто не сможет его реализовать, а это значит что потом возможно вам прийдется вместо реализации новой функциональности исправлять ошибки одного из «людей которые научились програМировать» (надеюсь я правильно понял что програмист с одной М — это толерантная замена слова «неуч»)
.
например, если «фича» может быть реализована за полчаса с помощью O(n^2) алгоритма либо за неопределенный срок с помощью O(1) алгоритма, то CS-aware программист может потратить месяц на реализацию этой задачи, а «прогромист» сделает все за полчаса не задумываясь
Налицо непонимание того что оценка сроков — это так же важный навык, который не является противоположным для знания CS.

Python Jav’’е ничего не сделает. В силу ряда его свойств он из другой категории. Его удел бороться с PHP, Ruby и серверсайдным JavaScript (или CoffeeScript, TypeScript, ...)
ну и для преподавания да, возможно вполне хорош.

А учитывая наличие Groovy и Clojure — Python’у нужно побороться с миром JVM а не собственно с Java.

«Java vs Python» это просто частный случай «static vs. dynamic typing» — а победитель в этом противостоянии невозможен.
Только — ЯП с опциональной, гибридной, смешанной типизацией, или с автовыводом типом не приводящим к умопомешательству.

Гипотетически Jav’у если кто и уделает то Dart, Rust, Shalaskell.

большинство кода на С++ в Google можно автоматически заменить на аналогичный код на C, не ухудшив при этом читабельность

Но... но как же RAII? ;-)

RAII в гугл стараются заменять на явные вызовы Init()/Destroy()-функций, которые легко переносятся на C:

If your object requires non-trivial initialization, consider using a factory function or Init() method

См. google-styleguide.googlecode.com/...in_Constructors .

То, что вы процитировали, никак не относится к RAII, вы не находите?

Там еще и такое есть:


Exceptions

We do not use C++ exceptions.
В целом там такие плюсы, что лучше б они на голом C писали.
Из моей практики, среднестатистический код на Python получается проще и понятнее аналогичного кода на Java.
Мне интересно:
Комплексы по поводу размера Питон против Джава — это у всех питонистов или только у сотрудников прома?
Читабельность, понятность, часто сокрость и другие метрики кода куда больше зависят от программиста (его опыта и навыков), а не от языка. Первые 2 так же зависят и от того кто читает код.
.
Но код на Python можно легко оптимизировать в случае необходимости до скорости, равной или превышающей скорость аналогичного кода на Java. Для этого нужно лишь грамотно использовать средства, предоставляемые Python, только в крайних случаях прибегая к переписыванию “узких мест” на C с использованием ctypes или Swig.
Як діти, їй-Богу © А на джаве нельзя переписать “узкие места” на Ц? Или переписать “понятный код” на мутотень но быструю"? Меня всегда забавляли такие аргументы.
.
В отличие от Google, в Prom.ua еще не потерян дух стартапа.
Я что-то пропустил или у прома уже:
As of 2013, Google had 47,756 employees (in the fourth quarter, including the Motorola subsidiary),[6] among them more than 10,000 software developers based in more than 40 offices
А если нет то зачем сравнивать палец с ...?
Читабельность, понятность, часто сокрость и другие метрики кода куда больше зависят от программиста (его опыта и навыков), а не от языка. Первые 2 так же зависят и от того кто читает код.
Особенно на брейнфаке. Но в целом, я согласен.
Читабельность, понятность, часто сокрость и другие метрики кода куда больше зависят от программиста (его опыта и навыков), а не от языка. Первые 2 так же зависят и от того кто читает код.

Согласен. Говнокод можно написать на любом языке программирования. Аналогично, супер-понятный, расширяемый и быстрый код можно написать также на любом ЯП. Разница лишь в том, что при одинаковом уровне квалификации с помощью некоторых ЯП проще написать говнокод, с помощью других — классный код. Качество кода зависит не только от инструментов, предлагаемых ЯП (синтаксис, библиотеки функций, IDE), но и от идеологии ЯП. Идеология Java — “всё вокруг — объекты”. Идеология Python — “код должен быть легким в написании, чтении, поддержке и последующем расширении”. Может быть, поэтому встречавшийся мне код на Python в среднем лучшего качества кода на Java.

Як діти, їй-Богу © А на джаве нельзя переписать “узкие места” на Ц? Или переписать “понятный код” на мутотень но быструю“? Меня всегда забавляли такие аргументы.

Вопрос не в том, что код на Java нельзя оптимизировать — на любом ЯП при желании можно успешно заниматься оптмизацией. В статье было написано, что код на Python обычно получается лучшего качества, но медленнее, чем код на Java. В качестве оправдания “тормознутости” Python’а было указано, что узкие места в коде на Python можно легко оптмизировать, воспользовавшись штатными средствами, только в крайнем случае прибегая к переписыванию узких мест на C.

Попробуем на примере:

Может быть, поэтому встречавшийся мне код на Python в среднем лучшего качества кода на Java.
А я не встречал (не могу вспомнить) читабельного кода на питоне. Причин тому может быть много: качество того кода который я видел, мои навыки, расово-религиозная ненависть к этому языку :)
Все в этом мире субъективно, поэтому формулировка «Из моей практики» не является корректной, а более корректно «Мне кажется». Но в таком случае 2 абзаца из вашей статьи можно было бы и не писать :)
Идеология Java — «всё вокруг — объекты». Идеология Python — «код должен быть легким в написании, чтении, поддержке и последующем расширении».
Самый подходящий комментарий к этому: И че?
.
В статье было написано, что код на Python обычно получается лучшего качества, но медленнее, чем код на Java.
Читаемость кода — это один из показателей его качества.
Мой посыл в том что читаемость не зависит (или зависит несущественно) от языка программирования.
Сейчас внимательно:
узкие места в коде на Python можно легко оптмизировать, воспользовавшись штатными средствами, только в крайнем случае прибегая к переписыванию узких мест на C.
Если «узкие места» легко оптимизировать при этом не прибегая (в общем случае) к переписыванию на Ц и прочей «черной магии», то почему в такой «инженерной конторе» как Гугл происходит «Постепенное вытеснение кода на Python кодом на Java под флагом того, что „код на Java быстрее“.»?
«Тупые» гуглеры не смогли провести легкую оптимизацию, которая не повредит читабельности? Не верю.

Мне интересно:
Комплексы по поводу размера Джава против Питона — это у всех джавистов или только у вас?

Если «узкие места» легко оптимизировать при этом не прибегая (в общем случае) к переписыванию на Ц и прочей «черной магии», то почему в такой «инженерной конторе» как Гугл происходит «Постепенное вытеснение кода на Python кодом на Java под флагом того, что „код на Java быстрее“.»?
«Тупые» гуглеры не смогли провести легкую оптимизацию, которая не повредит читабельности? Не верю.

Может, причина постепенного перехода на Java состоит в том, что большой процент Python кода создавался джавистами в соответствии со стилем, принятым в джава — спрятать полезный код за кучей бесполезных классов и абстракций. В итоге поняли, что проще и эффективнее писать весь код на Java, чем «мучать» Python в стиле Java.

Вышесказанное является лишь моей догадкой и может иметь мало общего с реальностью.

Отличный рассказ, спасибо.

Можно узнать вкратце о рекрутмент-процессе в гугл, первой должности там и уровне опыта, которым вы обладали на момент рекрутмент процесса

Можно узнать вкратце о рекрутмент-процессе в гугл
Что-то мне подсказывает что вам расскажут про рекрутмент в Епаме :)

Я не устраивался напрямую в Google — работал как контрактор через фирму-посредника.

некоторые цитаты тут — это очень тонкий но при этом жирый тролинг.

Некоторые цитаты тут — жесточайшее нарушение NDA вдоль и впоперек, пусть даже чисто формально, без реальных разглашений чего-то важного

Рекомендую удалить статью еще позавчера

Главное правило Бойцовского Клуба достаточно хорошо помогает в таких случаях.

Попкорн приготовил...

Подтверждаю, большинство описанных тут вещей о технологиях и процессах — строго internal. Народ тут еще не привык особо, но NDA таки вдоль и впоперек.

Что именно из этой статьи — строго internal?

Кроме личных впечатлений, почти все, к сожалению.

ПС. Ох и везет же мне на компании со строгими NDA

Приведите, пожалуйста, цитаты, нарушающие NDA. Желательно с пояснениями, почему они нарушают NDA.

Очень много разглашений как именно устроен внутренний софт, само существование которого не анонсировалось компаний в публичных СМИ или исследовательских публикациях. То же касается процессов и внутренних событий компании. Это вроде очевидные вещи.

Нарушение чисто формальное, так как особо ничего важного, мелочи. Но формальное тоже не очень хорошо делать.

Кстати, победа надо мной в этом блистательном споре не отменит вашего нарушения NDA

Очень много разглашений как именно устроен внутренний софт, само существование которого не анонсировалось компаний в публичных СМИ или исследовательских публикациях. То же касается процессов и внутренних событий компании. Это вроде очевидные вещи

Можно привести цитаты? А не то не могу спать спокойно, размышляя над тем, где же «скрыто» нарушение NDA. Может, я нарушил NDA и prom.ua, рассказав, как устроен внутренний софт и какие процессы происходят внутри компании?

хороший рассказ. информативно и без лишнего графоманства.
Спасибо!

Постепенное вытеснение кода на Python кодом на Java под флагом того, что «код на Java быстрее». Из моей практики, среднестатистический код на Python получается проще и понятнее аналогичного кода на Java. В результате разработка и расширение кода на Python занимает в несколько раз меньше времени и усилий по сравнению с аналогичным кодом на Java.
меня самого интересует, какие факторы влияют на то, что «скорость разработки» становится некритичной. Пока пришел к выводу, и по вашему рассказу тоже — рост размера компании или проекта приводит к увеличению горизонта планирования (=уменьшению количества ситуаций — «это нужно сделать на вчера!»).
в тех же джава проектах многие части систем не являются критическими по «скорости выполнения», и могли бы реализовываться скажем на Groovy, для «скорости разработки», но, похоже, такого в действительности не происходит — пишется на Java все, даже временное решение, которое в планах будет заменено другим. т.к. сказать — «пишем и скрипты на Java!»
меня самого интересует, какие факторы влияют на то, что «скорость разработки» становится некритичной. Пока пришел к выводу, и по вашему рассказу тоже — рост размера компании или проекта приводит к увеличению горизонта планирования (=уменьшению количества ситуаций — «это нужно сделать на вчера!»)

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

Java лучше всех подходит в качестве основного ЯП для компании «бюрократов», т.к. несет меньше всего рисков при найме новых сотрудников / замене существующих — программистов на Java — больше всего на рынках труда на любом континенте.

С ростом компании или проекта ...
растет и процент затрат времени НЕ на программирование.
упомянуты вами и ожидание код ревью, и одобрям по цепочке руководства и бесконечные митинги.
это тоже уменьшает эффект от «скорости разработки» конкретного разработчика.
ожидание код ревью
Позволю не согласиться, подход хуяк-хуяк и в продакшен, свойственный, или оправдываемый «стартапами» ведет к человеко-неделям перелопачивания проекта и громких докладов на очередной конфочке в стиле «как я занимался сизифовым трудом» и «ребята — так делать нельзя». Даже 100/500 тестов не уменьшат боли от расширения/изменения логики в таком добре.

В статье указано то что и я видел — код ревью быстро превращается в пустую формальность, никто всерьёз не смотрит код коллеги которому доверяет.

ну так это ж камень в огород коллегам, нет?

а коллеги не люди что-ли?

человек, в отличие от искусственного автомата, с трудом выполняет действия смысла которых — не видит. «формально».

в тех же джава проектах многие части систем не являются критическими по «скорости выполнения», и могли бы реализовываться скажем на Groovy, для «скорости разработки»
Возможно вам будет интересна эта статья:
www.hemju.com/...ava-spring-mvc

разделение на чистый REST, с использованием Spring MVC и Web UI на Angular никак не мешает использовать Groovy.
Почему не используется — вот мой вопрос...

ну а переход на JRuby из-за наличия легаси кода это другая история.

никак не мешает использовать Groovy
Прочитайте статью внимательнее, хотя бы до фразы:
Old or young woman? In Development you wanna avoid ambiguity.
Там ряд моментов: у джавы лучше тулинг, меньше двусмысленности и всякие мелочи.
Но если мы говорим Джава против Груви, то важны эти моменты, при этом уменьшение двусмысленности важнее.
Снова же, все относительно.

я прочел всю.

вы мне ее предложили прочесть на мое о Groovy, хотя там о — «сходе с рельс».

не поверите, с рельс даже на php сходят.

Там ряд моментов: у джавы лучше тулинг, меньше двусмысленности и всякие мелочи.
ну как бы около 4ех лет на ней, в сумме.
Но если мы говорим Джава против Груви
я говорил — реализовываться скажем на Groovy, для «скорости разработки»
у Groovy начиная с 2.1, или 2.2 появилась статик типизация.

вобщем моя твоя не понимай.
я не понял зачем вы мне предложили почитать один из случаев «схода с рельс»

можно кратко, что хотели сказать то?

я говорил — реализовываться скажем на Groovy, для «скорости разработки»
у Groovy начиная с 2.1, или 2.2 появилась статик типизация.
Я так понимаю речь про @TypeChecked. Если да, то это не особо решает проблему «In Development you wanna avoid ambiguity». Хотя все-таки с Груви не так все печально, как с руби/питоном/пхп в этом плане. Та и в плане туллинга не так печально.
.
можно кратко, что хотели сказать то?
Если кратко, то «скорость разработки» включает в себя «скорость написания нового кода» и «скорость понимания старого кода». И одна из сильных сторон джавы — это как раз второе.
«скорость разработки» включает в себя «скорость написания нового кода» и «скорость понимания старого кода». И одна из сильных сторон джавы — это как раз второе.
из чего следует что Groovy с прочими хороши для прототипирования, или быстрых заплаток-времянок, при условии(!) что читать этот код с большой вероятностью будет сам автор.

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

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

вобщем то и получается:
в одиночку лучше писать на каком-нить руби пайтоне
а при росте количества кода и участников команды, которые знают друге о друге только ники в поле «комитер» — лучше статик типизированный, и — простой.

скаловский код читать, не проще хаскелевского.

Підписатись на коментарі