Когда написание кода – лишняя трата времени

Представляем вам перевод статьи Джонатана Солорзано-Гамильтона, опубликованной на medium.freecodecamp.org.

Пустая трата времениЗнание, что именно НЕ нужно строить, – критически важная часть современной разработки программного обеспечения.

Одна из самых заметных ошибок, совершаемых командами разработчиков, это выполнение лишней работы.

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

Я провел много лет, занимаясь архитектурой и разработкой промышленных программ. Свой первый опыт я получил на стажировке в HP и выжил на душераздирающей работе в стартапе прежде чем встать на более стабильный карьерный путь. Я провел несколько лет работая в Стэнфордском университете, а затем стал стал помощником директора по архитектуре в UCLA Research Information Systems.

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

Как избежание работы стало моим спасательным кругом

Спасательный круг

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

У нас было два варианта: работать в десять раз быстрее, чем предыдущая команда (а наша рабочая неделя и так превышала 70 часов), или уклониться от большей части работы. Мы выбрали второе.

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

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

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

Мне не пришлось обновлять свое резюме.

Самостоятельное прокладывание пути гарантирует, что вы попадете в волчью яму

Ловушка, волчья яма

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

Пути безопасных приложений просто кишат подобными ловушками.

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

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

Пустая трата времени

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

«Но погодите, – можете подумать вы. – Для меня будет полезным упражнением узнать, как создать это свойство. Обучение это не напрасная трата времени!»

Это правда, но лишь частично. Да, обучение в ходе работы это не пустая трата вашего времени. А вот заставлять вашу команду в целом использовать вашу полусырую «учебную реализацию» распространенного свойства значит зря тратить время ваших коллег, причем в больших объемах.

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

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

Другие выгоды использования стороннего кода

Сторонние пакеты

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

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

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

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

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

Так когда же стоит строить самостоятельно?

Сборка продукта из готовых пакетов

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

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

Первый автомобиль Tesla полностью состоял из готовых узлов. Все, что сделали в Tesla, – поставили свою новую литий-ионную батарею.

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

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

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

Вчитываясь в пакеты

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

Как найти и выделить из общей массы пакеты, которые стоит использовать?

Во-первых, вам нужен источник. GitHub – популярная точка бесплатного программного обеспечения с открытым кодом. На Stack Overflow есть много веток обсуждений, где вы можете попросить совета. Помимо прочего, к этим сообществам стоит присоединиться еще и потому, что они создадут вам публичный профиль разработчика.

Также существуют репозитории, специализирующиеся на языках, например, NPM для JavaScript, RubyGems.org для Ruby и Rails, а также NuGet.org для .NET разработки.

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

Затем вам нужно убедиться, что лицензия подходит для вашего продукта. Некоторые лицензии могут налагать дополнительные обязательства на вас как пользователя пакета. Лицензия MIT и Apache License 2.0 обычно являются безопасным выбором. Они налагают на вас немного обязательств (вы все равно должны придерживаться лицензии, но это минимум).

Есть и другие мысли по поводу отбора правильного пакета. Поддерживается ли он официально какой-нибудь компанией, особенно крупной? Это минимизирует риск отказа в обслуживании. Хорошие примеры – Bootstrap (от Twitter) и React (от Facebook).

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

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

Есть ил выбранный вами язык или платформа в основном релизе? Проверьте и посмотрите, как работает репозиторий. Может, уже начата интеграция новой версии? Сталкиваются ли члены сообщества с какими-то трудностями в этом плане? Как в следующей версии изменится поддержка по сравнению с текущей?

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

Что это значит для вас?

Будьте скромны. То же касается и команды в целом. Вы не лучшие разработчики из всех когда-либо рожденных. У вас нет времени чтобы переделывать весь мир по своему образу и оставаться при этом конкурентоспособными.

Используйте уже существующие пакеты. Вы вернете долг сообществу, став одним из тех, кто вносит в него свой вклад.

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


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

1 комментарий к “Когда написание кода – лишняя трата времени”

  1. Всё начинается с идеи, потом схему этой самой идеи нужно нанести на лист бумаги со всеми подробностями. Только потом можно переходить к практическим действиям.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх