Куда оно летит?
Недавно вспоминал свой опыт работы в одной платежной системе, которая ныне уже, похоже, не существует. Работал я там много лет, явно больше, чем нужно, поэтому есть, что вспомнить. В этот раз хочу поговорить как меня и моего коллегу сделали Android программистами, и почему мне от этого не было толка.
Шёл далекий 2018ый год, Android был популярен примерно, как сейчас, приложения под него не писал только ленивый, компания, где мы работали тоже их писала, причём довольно активно, наш же проект на C++ подходил к жизненной стадии излёта – поддержка, поддержка, новых фич очень мало и не планируется. Всё закономерно: есть такое понятие жизненный цикл продукта, а программное обеспечение – тоже продукт, но об этом поговорим как-нибудь в другой раз. Компания занимала тогда весьма спокойную позицию по поводу таких проектов, которую можно описать словами: если они хотят работать, пусть работают как могут, мы их увольнять не будем (но и зарплату повышать – тоже). Соответственно, когда в ходе очередной беседы с менеджментом поступило предложение позаниматься Android (без предварительно имеющегося опыта), конечно, я и мой коллега тут же согласились.
Конкретика, звучала тоже довольно интересно: разработать с нуля приложение в несколько десятков экранов, взаимодействующая с backend и так далее, и кстати, — вот вам аналитик/прожект менеджер в придачу и “наставник” – опытный программист Android с флагманского проекта компании. Огонь! Описания функционала и предметной области тут не будет – это не так важно.
Глянув документацию по Java и код в соседнем проекте, осознал, что Java – это C++ из которого выкинули всё самое сложное (жду ваших гневных комментариев), и вся сложность в особенностях Android SDK: жизненный цикл Activity, жизненный цикл Fragment, разветвлённые переходы между экранами… Наставник тут помог: “вам нужно Moxy, Cicerone, RxJava, Retrofit и, конечно, Dagger”. Сказано – сделано, не все эти технологии выглядят очевидно для разработчика на C++, но, в принципе, не rocket science и по сравнению с голым AndroidSDK разработка упрощалась.
Заметка получается длинной, поэтому продолжим в следующий раз.
#job #IT #Android #Java #memories #ToBeContinued #interesting_tasks
Недавно вспоминал свой опыт работы в одной платежной системе, которая ныне уже, похоже, не существует. Работал я там много лет, явно больше, чем нужно, поэтому есть, что вспомнить. В этот раз хочу поговорить как меня и моего коллегу сделали Android программистами, и почему мне от этого не было толка.
Шёл далекий 2018ый год, Android был популярен примерно, как сейчас, приложения под него не писал только ленивый, компания, где мы работали тоже их писала, причём довольно активно, наш же проект на C++ подходил к жизненной стадии излёта – поддержка, поддержка, новых фич очень мало и не планируется. Всё закономерно: есть такое понятие жизненный цикл продукта, а программное обеспечение – тоже продукт, но об этом поговорим как-нибудь в другой раз. Компания занимала тогда весьма спокойную позицию по поводу таких проектов, которую можно описать словами: если они хотят работать, пусть работают как могут, мы их увольнять не будем (но и зарплату повышать – тоже). Соответственно, когда в ходе очередной беседы с менеджментом поступило предложение позаниматься Android (без предварительно имеющегося опыта), конечно, я и мой коллега тут же согласились.
Конкретика, звучала тоже довольно интересно: разработать с нуля приложение в несколько десятков экранов, взаимодействующая с backend и так далее, и кстати, — вот вам аналитик/прожект менеджер в придачу и “наставник” – опытный программист Android с флагманского проекта компании. Огонь! Описания функционала и предметной области тут не будет – это не так важно.
Глянув документацию по Java и код в соседнем проекте, осознал, что Java – это C++ из которого выкинули всё самое сложное (жду ваших гневных комментариев), и вся сложность в особенностях Android SDK: жизненный цикл Activity, жизненный цикл Fragment, разветвлённые переходы между экранами… Наставник тут помог: “вам нужно Moxy, Cicerone, RxJava, Retrofit и, конечно, Dagger”. Сказано – сделано, не все эти технологии выглядят очевидно для разработчика на C++, но, в принципе, не rocket science и по сравнению с голым AndroidSDK разработка упрощалась.
Заметка получается длинной, поэтому продолжим в следующий раз.
#job #IT #Android #Java #memories #ToBeContinued #interesting_tasks
👍1🔥1
Куда оно летит?
Часть 2.
В прошлый раз мы остановились на самом начале процесса разработки. Помня свой успешный (а иногда не очень) опыт из Desktop разработки, мы с коллегой начали с разработки архитектуры, было желание сделать сначала “каркас”, а потом планомерно его наполнять экранами, логикой и так далее, были там и более интересные технологические моменты: библиотека на C++ для обработки звука, кое-что там втягивали стороннее для обработки фото и тд.
Наша команда постепенно наполнялась: присоединились дизайнер, пара бэкендеров, сильно позже – тестировщик. Работать было интересно и комфортно – с моим напарником, другим разработчиком C++/Android никаких конфликтов никогда не бывало, задачи мы пилили сами, как считали справедливым, с дизайнером бывали абсолютно типичные моменты: дизайн бывал настолько красивый (сложный) – непонятно, точно ли нужно тратить трудодни на его реализацию – решали с участием упомянутого в прошлый раз аналитика/прожект менеджера, обладающего крайне высокими компетенциями и знаниями (здесь нет никакого сарказма). Разработчиками backend были двое студентов (возможно, вчерашних), из всей команды они выделялись своей незаинтересованностью в результате и срывом сроков – бывало трудновато, но опять же, всё в пределах нормы.
Замечу, что работать в любом проекте с нуля, совсем ни то же самое, что приходить в проект на других стадиях жизненного цикла. И дело тут не в атмосфере стартапа – её на самом деле не было, приложение нужно было разработать ни “как можно быстрее, что б отбить денег”, а к фиксированному сроку, ТЗ было практически фиксировано с первого дня и менялось очень мало – редкий случай. Дело тут в том, что гораздо интереснее самому вырабатывать архитектуру и потом работать, зная её особенности.
Коммиты успешно заливались в git, задачки пилились и брались в темпе, который нравился прожект-менеджеру, приложение стабильно прибавляло экраны, запросы, обработку ошибок, а Scrum не обрастал “религиозными встречами” – всё шло прекрасно.
Продолжим в следящий раз: опять не хватило пространства выдать сюжетный поворот.
#job #IT #Android #Java #memories #ToBeContinued #working_days
Часть 2.
В прошлый раз мы остановились на самом начале процесса разработки. Помня свой успешный (а иногда не очень) опыт из Desktop разработки, мы с коллегой начали с разработки архитектуры, было желание сделать сначала “каркас”, а потом планомерно его наполнять экранами, логикой и так далее, были там и более интересные технологические моменты: библиотека на C++ для обработки звука, кое-что там втягивали стороннее для обработки фото и тд.
Наша команда постепенно наполнялась: присоединились дизайнер, пара бэкендеров, сильно позже – тестировщик. Работать было интересно и комфортно – с моим напарником, другим разработчиком C++/Android никаких конфликтов никогда не бывало, задачи мы пилили сами, как считали справедливым, с дизайнером бывали абсолютно типичные моменты: дизайн бывал настолько красивый (сложный) – непонятно, точно ли нужно тратить трудодни на его реализацию – решали с участием упомянутого в прошлый раз аналитика/прожект менеджера, обладающего крайне высокими компетенциями и знаниями (здесь нет никакого сарказма). Разработчиками backend были двое студентов (возможно, вчерашних), из всей команды они выделялись своей незаинтересованностью в результате и срывом сроков – бывало трудновато, но опять же, всё в пределах нормы.
Замечу, что работать в любом проекте с нуля, совсем ни то же самое, что приходить в проект на других стадиях жизненного цикла. И дело тут не в атмосфере стартапа – её на самом деле не было, приложение нужно было разработать ни “как можно быстрее, что б отбить денег”, а к фиксированному сроку, ТЗ было практически фиксировано с первого дня и менялось очень мало – редкий случай. Дело тут в том, что гораздо интереснее самому вырабатывать архитектуру и потом работать, зная её особенности.
Коммиты успешно заливались в git, задачки пилились и брались в темпе, который нравился прожект-менеджеру, приложение стабильно прибавляло экраны, запросы, обработку ошибок, а Scrum не обрастал “религиозными встречами” – всё шло прекрасно.
Продолжим в следящий раз: опять не хватило пространства выдать сюжетный поворот.
#job #IT #Android #Java #memories #ToBeContinued #working_days
👍1
Куда оно летит?
Часть 3.
Итак, мы остановились на том, что команда, включая меня, успешно пилила проект и ничто, в целом, не омрачало нашу рабочую атмосферу. Тут, нужно заметить одну важную вещь: формально ни моя должность, ни должность моего коллеги разработчика не поменялись, мы оставались в том же самом полуразвалившемся отделе с кучей вялотекущих проектов на поддержке. И, опять же, формально все эти проекты так и оставались у нас на поддержке, конечно, буду честен, по факту, им уделялось очень мало времени, от силы процентов 10, но это важно для дальнейшего понимания событий.
Где-то в 2019ом году, состоялся первый релиз приложения. Как я уже упоминал, приложение – не настоящий стартап, иначе говоря, его функционал лежал вне основных интереса бизнеса, поэтому после релиза дальнейших задач по этому приложению не было (и не планировалось – это не было сюрпризом). Что несколько удивляло – так это реакция менеджмента: “Отлично, что вы с этим справились, мы подумаем, что дальше, а пока занимайтесь поддержкой своих проектов”.
Теперь, зная, что было дальше, я понимаю: нужно было уволиться в тот же момент спокойно (или не очень), пройдя собеседования на Android-senior в другие компании. На тот момент, лояльность компании, иллюзия что “они найдут чем заниматься” и так далее удержали меня от этого шага.
Спустя несколько месяцев, мы вернулись к разработке этого приложения: кое-что писали уже на Kotlin, активно продвигаемый Google, на нас же свалили и поддержку backend для этого приложения, так же (коряво) написанный на Kotlin, но…объем фич был уже ни тот, и за это время технологии модные ещё вчера стали устаревать. Да, до сих пор некоторые технологии из моего первого поста используются в реальных проектах, но в тренде прежде всего Kotlin, Coroutines, Clean Architecture…
В следующий раз, я точно закончу этот цикл! Будьте на связи
#job #IT #Android #Java #memories #ToBeContinued #working_days
Часть 3.
Итак, мы остановились на том, что команда, включая меня, успешно пилила проект и ничто, в целом, не омрачало нашу рабочую атмосферу. Тут, нужно заметить одну важную вещь: формально ни моя должность, ни должность моего коллеги разработчика не поменялись, мы оставались в том же самом полуразвалившемся отделе с кучей вялотекущих проектов на поддержке. И, опять же, формально все эти проекты так и оставались у нас на поддержке, конечно, буду честен, по факту, им уделялось очень мало времени, от силы процентов 10, но это важно для дальнейшего понимания событий.
Где-то в 2019ом году, состоялся первый релиз приложения. Как я уже упоминал, приложение – не настоящий стартап, иначе говоря, его функционал лежал вне основных интереса бизнеса, поэтому после релиза дальнейших задач по этому приложению не было (и не планировалось – это не было сюрпризом). Что несколько удивляло – так это реакция менеджмента: “Отлично, что вы с этим справились, мы подумаем, что дальше, а пока занимайтесь поддержкой своих проектов”.
Теперь, зная, что было дальше, я понимаю: нужно было уволиться в тот же момент спокойно (или не очень), пройдя собеседования на Android-senior в другие компании. На тот момент, лояльность компании, иллюзия что “они найдут чем заниматься” и так далее удержали меня от этого шага.
Спустя несколько месяцев, мы вернулись к разработке этого приложения: кое-что писали уже на Kotlin, активно продвигаемый Google, на нас же свалили и поддержку backend для этого приложения, так же (коряво) написанный на Kotlin, но…объем фич был уже ни тот, и за это время технологии модные ещё вчера стали устаревать. Да, до сих пор некоторые технологии из моего первого поста используются в реальных проектах, но в тренде прежде всего Kotlin, Coroutines, Clean Architecture…
В следующий раз, я точно закончу этот цикл! Будьте на связи
#job #IT #Android #Java #memories #ToBeContinued #working_days