Комментарии 16
Очень многие бэкенд разработчики при разработке web приложений забывают о фронт разработчиках, и дедлайнах, если они есть. А то и другое обычно есть.
Получается ситуация, когда до дедлайна остается одна неделя, а то и два три дня, бэкенд готов, а фронт только на 50 процентов, потому что моки все кейсы не покрывают да и в последний момент половина эндпоинтов начинает разительно от них отличаться.
В итоге заказчик смотрит на сырой продукт, при том, что бэкенд собран на 100 процентов. А избежать такой ситуации можно было бы сместив все сроки разработки бэкенда по времени хотя бы на 1-2 недели влево ( в начале разработки договориться о сроках, когда и что ждать)
Извините, но немного наболело. ))
Эту проблему очень легко решить организационно.
На каждый эндпойнт, на каждый ресурс между бэкендом и фронтендом должен заключаться "контракт" с полным описанием интерфейса взаимодействия, в том числе и описание возможных исключительных ситуаций.
Понятно, что многое надо будет изменять в процессе разработки, в том числе и то, что входит в "контракты". При этом на своей стороне можно менять что угодно, кроме того, что включено в "контракты". Если же надо изменить это, то собирается митинг между фронтендом и бэкендом и заключается новый "контракт".
Потеря времени на эти митинги - мизер по сравнению с потерей времени после обнаружения несоответствий контрактам с той или иной стороны.
Уверен, что сообщество разработчиков должно быть не только компетентным, но и поддерживающим обмен знаниями и опытом, поэтому буду благодарен всем, кто поделитcя в комментариях своими наблюдениями
Я лишь поделился опытом.
собирается митинг между фронтендом и бэкендом и заключается новый "контракт".
Спасибо. Это как раз то, что я хотел сказать. Только этот митинг должен проходить не в самом конце разработки.
Как только нужно хоть на один символ изменить контракт, сразу митинг. Без раздумий и задержек. Митинг не обязательно должен быть какой-то встречей. Иногда даже двух сообщений в чате достаточно. Главное, чтобы оба конца разработки были в курсе и были согласны с изменениями.
Мне кажется, что в статье написано то же самое с точки зрения обеспечения ИБ - в начале договориться о требованиях ИБ (shift left, об этом же и говорит методология DevSecOps)
За один только 2022 году GitHub выявил более 1,7 миллионов потенциальных секретов, раскрытых в общедоступных репозиториях.
Звучит грозно. Только думаю, что большая часть из них — какие-то пет проекты или тестовые, где ради простоты может и токен быть зашит в код, или пароль в json конфигурации лежать.
Вот только если это, скажем, API ключ к какому-нибудь пусть даже Google Maps API, ключ может оказаться неограниченным по доменам, кто-то может использовать этот ключ у себя, а потом гугл владельцу ключа выставит счёт. Это не говоря уже о том, что бывают довольно дорогостоящие API, и для какого-нибудь школьника или студента счёт в 500 долларов может оказаться ощутимой проблемой.
К сожалению, мы не можем получить статистику о наличии секретов в закрытых проектах. Однако факт наличия 1,7 миллиона секретов в общедоступных проектах, которые авторы намеренно разместили в открытом доступе, зная, что они будут доступны буквально каждому, уже говорит о многом.
Из собственного опыта могу сказать, что в закрытых проектах вопросы безопасности часто игнорируются (особенно новичками), поскольку проект считается «закрытым», а дополнительные меры безопасности воспринимаются как «лишняя работа».
Пет ни пет, к плохому привыкать не надо. Да и что мешает json конфиг добавить в gitignore.
Совет "Не забывайте обновлять зависимости проекта и используемое ПО" весьма неоднозначный - !!!тем более!!! его автоматизация. Вот буквально на днях в проекте решил так, за-между-прочим обновить спринг, причем там минорные версии, по итогу задача изначально которая была на час, едва не растянулась на весь вечер, потому что эта обнова мне весь мозг вы..несла, из-за обновления зависимостей своего спринга там начали конфликтовать (как я помню) UserType гибернейта с JsonType расширения для всё того же гибернейта и оно кидало ClassCastException и хоть ты кричи) Потому лучше не сильно автоматизировать сие, т.к. пайпа умрет в самый не подходящий момент, а как в моем случае, пайпа бы даже не умерла, т.к. сборка-то проходит, ошибка уже при старте в рантайме, вот это был бы сюрприз)
Тоже самое можно сказать и про ПО на машинке. Если обновится какая-нибудь .dll аля open-ssh, то легко могут отпасть какие-то еще не успевшие обновиться либы (такое тоже иногда случается). Как пример - ruby 2.7 отказывается хоть стреляй работать с новым libssl, при этом обновлять весь проект с 2.7 на актуальную (3.x вроде??), как понимаете, не всегда есть время и бюджет.
В общем и целом совет полезный, но, обновлять нужно понимая что делаешь, иметь запас времени на случай если обнова начнет делать мозг и, самое главное, иметь "План Б-бекап" на случай если уж прям совсем тупик, чтобы откатиться быстро назад без потерь
Как бы это ни было больно, периодически необходимо обновлять используемое серверное ПО и библиотеки, иначе проект в конечном итоге рискует стать легкой мишенью для злоумышленников. Да, это может привести к множеству проблем и сложностей в моменте, но чем дальше откладывать обновление, тем более болезненным оно может стать. Ну а если затягивать с этим слишком сильно, в какой-то момент обновление зависимостей становится почти равносильным переписыванию всего проекта с нуля.
Не могу сказать, что утверждение "Новее = безопаснее" - верно) В новых версиях иногда, бывает, даже добавляется уязвимостей, тут следует держать баланс между "keep it fresh" и "работает - не трогай", тем более, что довольно редко проект поддерживается вечно. Зачастую устаревшие версии как раз появляются либо в давно забытых легаси, к которым решили вернуться, либо, как вариант, если на конечных стадиях разработки выходят какие-то мажорные обновления из-за которых могут возникнуть проблемы. Сдвигать срок заказчики/инвесторы из-за "ваших этих обновлений" не будут, конечно же, а потом уже как бы "было поздно раньше начинать" обновление действительно превратится в переписывание половины проекта.
Но я даже не об этом всем говорил, скорее о том, что эта статья подходит под что-то вроде "предостережения для новичка", потому, думаю, для начинающих было бы неплохо привести какой-то чек-лист когда обновляться можно и нужно, а когда лучше повременить, особенно если получится с примерами из личного опыта. То есть я хотел сказать, что обновляться бездумно - смэрть. А так, конечно, ничего совершенно не имею против регулярных обновлений, если получается
Если это обновление безопасности, то надо его делать как можно скорей.
А все остальные обновления я считаю по умолчанию злом. Их стоит делать только тогда, когда пакет как-то связан с безопасностью, и поддержка разработчиком данной конкретной версии близится к концу. О прекращении поддержки почти всегда объявляют сильно заранее, поэтому, как только объявили, так сразу и приступать к обновлению.
Конечно же, это не догма, а общий принцип, и всегда нужно исходить из конкретной ситуации.
Отличная статья! Простые и понятные правила современной разработки. В начале резанула отсылка к Сократу. Дело в том, что scio me nihil scire - латынь. Во время жизни Сократа на латыни говорили только племена латинского союза, Рим был глухоманью, а до начала его экспансии было не меньше века. Так что не мог Сократ во всеуслышание говорить на латыни. Хотя древнейшие переводы диалогов Платона (в которых как раз философствует Сократ), скорее всего, должны быть латинскими.
Важные советы backend-разработчику: защити себя от нежелательных проблем