Робота в 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 , в ще не втрачений дух стартапу. Керівники з менеджерами не ховаються від співробітників, тому швидше вирішуються оперативні питання . Якість коду тут поки ще краще , ніж на більшості моїх попередніх проектів схожою складності. Розробка і Деплой йде швидше - у нас код потрапляє в продакшн протягом декількох днів ( а іноді й годин) , тому відразу видно відгук реальних користувачів на нові зміни в коді. Ми можемо набагато швидше реалізовувати необхідні функції і « відточувати » їх на основі зворотного зв'язку . Серед потоку завдань знаходиться великий відсоток цікавих (наприклад , оптимізація по продуктивності і споживання пам'яті , рефакторінг коду , поліпшення UX) . Більш того , деякі не зовсім цікаві завдання стають цікавими , тому що тут відразу видно реакція відвідувачів на результати твоєї роботи . У нас не доводиться писати код « на склад» , який в кращому випадку вийде в продакшн через пару місяців.

На даному етапі розвитку компанії тут я бачу для себе більше можливостей для самореалізації та кар'єрного зростання , в порівнянні з Google. Що буде далі , покаже час.

Опубліковано: 01/07/14 @ 07:06
Розділ Пошуковики

SEO Блог