Призыв к кроссплатформенным разработчикам
вступление
Когда я смотрю на нашу отрасль, я вижу два основных и до определенного момента противоречащих друг другу подхода к организации команды. С одной стороны, мы стремимся продвигать специализацию, которая увеличивает скорость разработки и улучшает качество кода. С другой точки зрения, теории бережливого производства говорят, что мы должны смотреть на продукт в целом, независимо от используемых в нем технологий, и всегда развивать функции, которые приносят большую ценность.
Внутри урагана
В прошлом я стал жертвой определенного недостатка специализации. Я бы переключал продукты (не только технологии или проекты в одном и том же продукте, я говорю о совершенно разных продуктах), может быть, каждые 6 месяцев. Я переходил от работы в iOS к Android, к C обратно к Android, затем к Back-End на Java, снова к C, а затем снова к iOS. Не говоря уже о нескольких стажировках в веб-разработке.
Я хорошо схватывал новые технологии, может быть, поэтому меня часто звали на проекты «протянуть руку помощи». Но, в конце концов, со всем переключением как технологий, так и продуктов, я чувствовал, что на самом деле ни в чем не разбираюсь, и у меня не было разумных знаний о каждом продукте, над которым я работал.
Это вызвало много выгорания. Мало того, что мне приходилось постоянно изучать новые технологии или, по крайней мере, следить за тем, что изменилось с тех пор, как я в последний раз прикасался к технологии, огромная задержка в начале работы над проектом означала, что я мог только начать предоставлять ценную информацию. функции спустя разумное время.
Было несколько причин, по которым это не было устойчивой ситуацией, как для меня на профессиональном уровне, так и для проектов:
· Я должен был успеть за изменениями, внесенными в технологию (я боюсь подумать, что Swift был выпущен тогда);
· Мне пришлось переучиваться новым передовым практикам или даже изменениям в архитектуре, которые были введены или сделаны за время моего отсутствия в проекте;
· Мне пришлось забыть о вредных привычках, которые я мог подцепить из другого проекта/технологии, над которым я работал;
· Мне потребовалось довольно много времени, чтобы внести полноценный вклад в новый проект, поскольку я должен был знать, почему был сделан тот или иной выбор (некоторые варианты могли показаться странными, но, возможно, для них были веские причины. Мне пришлось изучить все эти причины с нуля, чтобы я перестал делать некоторые предложения, которые были сделаны раньше и уже отброшены);
· В целом, хотя некоторые знания высокого уровня действительны для разных проектов, я чувствовал, что ничего не осваиваю, кроме искусства прыгать между случайными проектами и помогать возвращать вышедший из-под контроля проект в нужное русло.
Должен отметить, что все проекты были очень интересными и сложными сами по себе, и я был бы рад остаться с одним из них, получить реальные бизнес-знания и помочь определить лучшее технологическое решение для этого проекта. К сожалению, это было невозможно.
В конце концов, ситуация меня просто не устроила. Я хотел получить более глубокие знания о технологиях, с которыми я работал, но я не продвинулся очень далеко.
Солнечные дни
В конце концов я попал в ситуацию, когда наконец-то смог сосредоточиться не только на одной технологии, но и всего на одном продукте. Это были довольно замечательные годы; Я смог на 100 % сосредоточиться на разработке iOS.
Количество знаний, которые я получил о различных API, от Core Data до CoreAnimation, было для меня невероятным, возможно, потому, что я потратил так много времени, не вдаваясь в такие детали, что весь этот опыт открыл глаза.
Наконец-то я потратил достаточно времени на проект, чтобы на собственном опыте понять, почему MVC может стать проблемой. Я был поражен тем фактом, что при использовании CoreGraphics вы взаимодействуете со слоем модели, и я планировал и заменял архитектуры по мере необходимости.
Наши методы кодирования улучшились, внедрение зависимостей стало первостепенным для наших проектов, и мы начали проводить настоящую непрерывную интеграцию.
Конечно, в то время я заботился о REST API, а не о том, как кодируется серверная часть. Меня заботила совместимость между платформами, когда речь шла об Android, но не столько о том, как Android был закодирован, или даже о том, смогут ли iOS и Android предоставлять функции примерно за одинаковое время.
Я не думаю, что смогу достаточно подчеркнуть, как легко попасть в такую ловушку, когда вы создаете что-то, что работает, вы видите, как оно развивается и улучшается, вы видите небольшие архитектурные решения, которые вы сделали голыми плодами, решения вы не вернулись, чтобы укусить вас, вы получаете определенное туннельное видение, из которого очень трудно выбраться. После того, как все, что вы делаете, работает нормально, потенциально вы предоставляете функции быстрее, чем кто-либо другой.
Оптимизация стоимости
Но это довольно узкий взгляд на вещи. Вопрос, который вы должны задать на этом этапе, заключается не в том, работаете ли вы так быстро, как можете, а в том, насколько быстро работает команда. Если разработчик завершает свою часть истории, но история все еще ждет, пока другие разработчики закончат свои части, то история не будет завершена, независимо от того, насколько быстро первый разработчик смог закончить свою часть.
На самом деле, даже не имеет значения, является ли разработчик самым быстрым разработчиком в мире, если команда не успевает, истории всегда будут доставляться со скоростью самого медленного разработчика.
Я считаю, что как общество мы часто превозносим специализацию и на каком-то уровне индивидуализм. Адам Смит защищал специализацию как первостепенное значение для прогресса. Но если подумать, например, с точки зрения автомобильной промышленности (неудивительно, что теории бережливого производства стали более популярными в Toyota), если часть завода превосходно производит шины, вплоть до того, что является самым быстрым в мире. мир, но остальная часть завода не может производить остальную часть автомобиля для этих шин, тогда вы просто накапливаете запасы, которые не будут использоваться, и к тому времени, когда они будут использоваться, возможно, новая резина тип сделает эти шины устаревшими.
В этот момент лучше отступить и подумать, как можно оптимизировать весь завод, чтобы производить автомобили и шины, когда они вам нужны.
Разработка программного обеспечения не очень далека от этого. У вас может быть несколько конечных точек на вашем сервере, готовых к использованию, но если приложения или веб-сайт развиваются недостаточно быстро, чтобы использовать эти конечные точки, все, что у вас есть, — это много мертвого кода, который вам нужно поддерживать.
Но какова ваша точка зрения?
Я не уверен, я думаю, что составил свое представление о том, что лучше для команды, но я не знаю, как к этому прийти. Я начал эту статью со слабой надеждой, что она поможет мне в этом, но я не уверен, помогла ли она.
Я действительно думаю, что нам нужна смена парадигмы; если компания хочет оставаться конкурентоспособной и предоставлять своим пользователям наиболее ценные функции как можно быстрее, это должно произойти.
Я наблюдал за тем, как работают команды, и задавался вопросом, как лучше всего мотивировать команды использовать этот способ работы, но я пока не смог найти ничего близкого к решению, но я также думаю, что я только начал поцарапать поверхность этого вопроса…
