Должен ли я сказать своей команде/менеджеру, что текущее мобильное приложение плохое?

Я думаю, что сказать что-то — хорошая идея, но то, как вы это скажете, будет так же важно, как и то, что вы скажете.

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

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

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

2. Заинтересованные стороны. У вас их не было, вы работали в вакууме и отвечали только за себя, тогда как первоначальные разработчики, вероятно, работали в соответствии с требованиями и предпочтениями людей, управляющих проектом. Этот ужасный пользовательский интерфейс, который вы ненавидите? Вероятно, это ужасно, но на этой ужасности могли легко настаивать заинтересованные стороны и владелец продукта (вы должны видеть некоторые из полнейших мерзостей, которые мне приходилось производить на протяжении многих лет, потому что это нравилось PO или директору). То же самое и с функциональными требованиями — вы знали полный набор функций с самого начала, поскольку у вас было готовое приложение для работы. Первоначальный процесс разработки, скорее всего, был так же связан с выяснением того, что они хотели сделать, и с тем, чтобы заставить его это сделать.

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

Итак, как вы относитесь к этому?

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

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

Не вызывайте их, что вы бы сделали. Вместо этого задавайте вопросы.

«Почему пользовательский интерфейс такой? Не было бы более стандартно сделать ____?»

«Держу пари, мы могли бы получить гораздо более стабильный код, если бы сделали _____»

Печальный факт заключается в том, что вам 23 года. 4-5 лет могут показаться вам много, но на самом деле это не так, если учесть, что некоторые из нас занимаются этим уже более 30 лет. Поскольку вам всего 23 года, ваши идеи скорее всего будут уволены. Вот почему я предлагаю скромный подход предложения. Формулируйте вопросы таким образом, чтобы заставить их объяснить это, не бросая вызов и не вызывая конфронтации.

Стоит ли упоминать, что приложению не хватает UI-дизайна и качества кода? Если да, то кому?

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

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

вот почему я решил воссоздать приложение в свое личное время с нуля - это заняло у меня 2/3 недели, и это было сделано.

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

Должен сказать, что это был безумно смелый поступок с твоей стороны, но если ты действительно сделал это правильно, то наверняка сможешь решить это в свою пользу. Я предлагаю вам лично встретиться с вашим менеджером , где вы можете изложить свои опасения по поводу текущей версии приложения, а также решения и методов, которые вы предлагаете.

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

Затем вы можете упомянуть, что вы работали над проектом в свободное время в качестве доказательства концепции, и приступить к демонстрации своего приложения. Если то, что вы описываете, правда, ваш менеджер наверняка будет впечатлен и, вероятно, примет во внимание предлагаемые вами изменения.

Хорошо, что «недостатки» здесь сведены к минимуму, поскольку вы уже потратили время на исследование и кодирование этих альтернатив. Просто убедитесь, что вы сделали это в свое личное время (чтобы не «тратить впустую» время компании). Надеюсь, вы сможете уладить это в свою пользу.

Это загадка.

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

Ваш подход здесь имеет решающее значение для вашего долголетия в этой фирме.

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

Через две недели сделайте последний шаг. Назначьте встречу, чтобы поговорить с вашим менеджером. Покажите им свое приложение рядом с текущим предложением. Ничего себе. Ослепить его. Поразите его новым крутым дизайном пользовательского интерфейса и стабильностью кода.

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

Мат

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

Это азартная игра в любом случае. Удачи.

Т

Я бы порекомендовал вам начать с конца — какой результат вы хотите увидеть? Читая ваш вопрос, я предполагаю, что он выглядит примерно так:

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

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

• Определите «ключевых заинтересованных лиц»: кто получит наибольшую выгоду от будущего, к которому вы стремитесь? Кто больше всего пострадает от изменений? Кто будет заботиться больше всего, независимо от того, входят ли они в эти две другие группы? Это те люди, которые вам нужны на вашей стороне, когда придет время предлагать изменения и когда пора начинать их реализовывать.
• Лучше поймите своих заинтересованных лиц и свой бизнес: вы, вероятно, много знаете о своем пространстве и мобильной разработке. Узнайте больше о своей команде, о том, как они стали такими и где они находятся, а также о своей кодовой базе. Является ли это Java-ориентированным Objective C, потому что у них была такая парадигма, или потому, что первый человек, который создал его, работал быстро, и ни у кого не было времени переписать его? Каково тестовое покрытие и можно ли его улучшить? Это понимание будет иметь неоценимое значение, когда придет время составить план изменений, которые вы хотите, и процесс его получения построит отношения, которые вам понадобятся для его реализации.
• Создайте общее понимание и общий аппетит к переменам: начните говорить с этими людьми и другими о будущем состоянии, на которое вы надеетесь. Это не обязательно должно быть непосредственно связано с вашим приложением; на самом деле часто лучше начинать с областей, которые явно от него не связаны, чтобы избежать возникновения беспокойства и защитных реакций. Например, вы можете регулярно проводить некоторое время, разбирая и обсуждая какое-то другое приложение, которое, по вашему мнению, действительно хорошо сделано, особенно в отношении аспектов, которые, по вашему мнению, применимы к вашему собственному приложению. Не важно заканчивать эти разговоры фразой «… значит, мы тоже должны это сделать». Вы исследуете вместе, и вы вместе придете к тому, чтобы ценить самые важные вещи.
• Начните с малого, наращивайте темп:Не предлагайте двухлетний план по изменению всей кодовой базы или проект «остановим мир, пока мы переписываем». Вместо этого ищите ряд изменений, которые вы можете использовать для развития приложения в сторону лучшего будущего, продолжая разработку функций. Выбирайте маленькие вещи, которые имеют большой положительный эффект, и занимайтесь ими в первую очередь, если можете; они оба помогут вам проверить свое направление, а также придадут вам импульс, добившись успеха. Возможно, наиболее важными отправными точками являются небольшие рефакторинги, облегчающие реализацию некоторых важных функций; может быть, это перестройка части приложения на лучшую основу, чтобы оно не ломалось так часто (потому что его легче хорошо тестировать, верно? ;) Что бы это ни было, сделайте их небольшими и инкрементными, чтобы вы

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

Удачи!

Технический долг

https://www.techopedia.com/definition/27913/технический долг

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

Технический долг неизбежен. Главное — управлять им.

• писать модульные тесты
• использовать инструменты покрытия кода для отслеживания изменений кода
• использовать инструменты линтинга исходного кода
• отслеживать частоту багов (показатель технического долга)

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

Технический долг быстро проползет обратно в исходный код.

Я бы пошел к вашему менеджеру и поговорил бы с ним об этом.

Привет, я здесь совсем недавно. За это время я обнаружил, что добавление новых функций, исправление ошибок и следование вашим индивидуальным подходам к дизайну пользовательского интерфейса занимают намного больше времени, чем, по моему мнению, должны. Хотя мне не хватает опыта, чтобы точно определить, почему это так. Это заставляет меня чувствовать себя некомфортно. Вы знали, что у нас здесь проблемы с техническим долгом?

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

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

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

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

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