В день создания продуктовой группы она отстает от графика и превышает свой бюджет.

Дон Норман

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

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

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

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

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

Поскольку я собрал здесь мысли и идеи некоторых из лучших людей отрасли, я частично позаимствовал название статьи у Тима Ферриса и его великой книги Инструменты титанов.

СОДЕРЖАНИЕ

Идеи
Дизайн:
* Базовые идеи
* Технические советы и рекомендации
* Доступность
Архитектура
Работа над проектами :
* Когнитивные предубеждения и ментальные модели
* Коммуникации
* Наем
Разработка:
* Рефакторинг
Безопасность

Идеи

  • Генерируйте сразу много идей. Не останавливайтесь на одной или двух идеях.
  • Будьте изобретательны, независимо от обстоятельств. Не критикуйте идеи ни свои, ни чужие. Даже сумасшедшие идеи, которые часто кажутся заведомо неправильными, могут содержать некую творческую мысль. Отделите этапы генерации идеи от этапов оценки идеи. Не отказывайтесь от идей слишком рано.
  • Ограниченное время для генерации идей приводит к гиперфокусировке, и в этих условиях легче разделить этапы генерации идеи и оценки, поскольку нет времени для оценки.
  • Иногда вы можете добавить ограничения или удалить существующие, чтобы изменить процесс.

Страхи, мешающие творчеству:

  • Страх кажется глупым.
  • Боязнь плохих идей.
  • Страх, что вы делаете что-то не так. Оценка того, как люди выполняют свою работу, должна основываться не на том, делают ли они ее по-вашему, а на том, насколько они эффективны. Если человек что-то делает и преуспевает, не пытайтесь его переучивать.
  • Страх неизвестности.
  • Страх не понравиться другим, что-то делают.
  • Бойтесь, что вы не так хороши, как думаете.
  • Боязнь синдрома самозванца (вы знаете меньше других).

Дизайн

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

Базовые идеи

  • Помните, что, несмотря на быстрое изменение технологий, человеческое поведение меняется не так быстро. И то, как мы действовали 20 лет назад, по-прежнему актуально. См., Например, последний отчет [how-people-read-online] (https://www.nngroup.com/articles/how-people-read-online/).
  • Используйте дизайн вместо функциональных спецификаций, которые создают только иллюзию согласия. Люди читают один текст и понимают его по-разному.
  • Не обращайте внимания на детали в начале процесса. Переходите от большого к малому. Начнем с дизайна и верстки. Их гораздо легче изменить, чем код. В дизайне начнем с эпицентра.
  • Должны быть очевидны допущения и анти-допущения вещей.
  • Когда аффорданс и анти-аффорданс трудно обнаружить, мы должны дополнить объект означающими.
  • Связанные элементы следует размещать вместе. Разместите элементы управления и важную информацию именно там, где они необходимы.
  • Обратная связь должна быть мгновенной: задержка даже на десятые доли секунды может заставить человека понервничать. Если задержка длится слишком долго, люди часто сдаются и уходят заниматься чем-то другим.
  • Если обратной связи слишком много, это может раздражать даже больше, чем ее слишком мало. Если мы слышим слишком много сообщений, мы игнорируем их все или отключаем все. А это значит, что мы можем пропустить действительно важные сообщения.
  • Удалите все сообщения об ошибках. Вместо этого предоставьте пользователям помощь и рекомендации. Убедитесь, что вы можете сразу решить проблему с помощью всплывающих подсказок.
  • Не ждите, что люди что-то сохранят в краткосрочной памяти. Часто, когда что-то идет не так, компьютерные системы показывают сообщение с важной информацией, которое исчезает с экрана в тот момент, когда человек хочет его прочитать.
  • Избегайте алгоритмов, которые начинаются одинаково, а затем становятся разными. Чем опытнее сотрудник, тем больше вероятность, что он станет жертвой такого промаха. По возможности алгоритмы должны быть прописаны таким образом, чтобы они с самого начала отличались друг от друга.
  • На этапе тестирования достаточно опросить 5 независимых людей / групп, чтобы получить адекватную оценку. Вы можете начать с других членов команды. При тестировании используйте открытые вопросы.
  • Не собирайте ненужную информацию, которой вы сейчас не пользуетесь.
  • Люди часто выбирают первый удовлетворительный вариант, а не ищут лучший. Наши представления о том, как что-то работает, часто ошибочны, поэтому, когда мы понимаем, как что-то работает, мы не ищем альтернативного решения, даже если текущее плохое.
  • Укради как художник. Для вдохновения воспользуйтесь этими сайтами: (dribble, pinterest, pttrns).

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

  • Логотип находится в верхнем левом углу.
  • Знакомые иконки для корзины, видео и т. Д.

Способы уменьшить количество ошибок:

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

Технические советы и хитрости

  • Учитывайте в проекте нормальные, пустые и ошибочные состояния. Пустое состояние производит первое впечатление, поэтому это очень важно.
  • Реализуйте светлую и темную тему.
  • Не устанавливайте слишком строгих ограничений на ввод полей формы. Особенно в именах. Если возможно, предоставьте пользователю право определять, как пишется его имя. И не наказывать за несоблюдение фиктивных правил и ограничений (форматирование полей и т. Д.). Если возможно, отформатируйте форму автоматически.
  • Кликабельные вещи должны быть очевидны. Не используйте один и тот же цвет для ссылок или кнопок, а также для заголовков, не вызывающих кликов. Сделайте различие между посещаемыми и невидимыми ссылками видимыми.
  • Используйте четкие заголовки и подзаголовки, чтобы разбить контент на разделы, чтобы пользователи могли сканировать контент в поисках информации.
  • Не позволяйте заголовкам плавать между двумя блоками текста, он должен быть ближе к своему блоку.
  • Делайте абзацы короткими. Сократите тексты, удалив все несущественные слова и предложения. Используйте простой язык.
  • Используйте списки. Выделите ключевые слова. Это позволяет глазам сосредоточиться на самой важной информации.
  • Возможно, вам не нужна большая картинка на главной странице. Когда люди понимают, о чем сайт, их раздражает его размер. Тем, кто уже знает вас, это не нужно.
  • Свет исходит с неба. Тени - бесценный сигнал, сообщающий человеческому мозгу, на какие элементы пользовательского интерфейса мы смотрим.
  • Сначала черное и белое. Проектирование в оттенках серого перед добавлением цвета упрощает самый сложный элемент визуального дизайна и заставляет вас сосредоточиться на размещении и размещении элементов.
  • Удвойте пробелы. Чтобы пользовательский интерфейс выглядел спроектированным, добавьте больше места для передышки.
  • Используйте только хорошие шрифты.
  • Учитывайте проблемы доступности. В нынешней ситуации огромное количество людей, не очень знакомых с компьютерами, вынуждены использовать их в гораздо больших объемах, чем раньше.

Доступность

  • Увеличьте текст до 200% и проверьте, как выглядит ваш товар.
  • Проверьте контраст. Браузеры знают, как сказать вам, что контраста недостаточно. Вы также можете включить режим высокой контрастности в операционной системе.
  • Добавьте атрибуты alt.
  • Правильно используйте заголовки. Не перепрыгивайте через размеры.
  • Проверьте метки для полей формы.
  • Следите за доступностью контента с клавиатуры.

Вы можете увидеть более подробную информацию здесь:

Архитектура

Если вы считаете, что хорошая архитектура стоит дорого, попробуйте плохую архитектуру.

Брайан Фут и Джозеф Йодер

  • Не создавайте сложную архитектуру в новых проектах, это не только долго и дорого, но если ваша первоначальная идея и планы не востребованы, сложно скорректировать идею и быстро изменить продукт.
  • Разработайте язык, основанный на модели предметной области, для общения программистов со специалистами.
  • Разбейте программу на уровни и изолируйте их друг от друга. Знание предметной области должно быть только на одном уровне. Графический интерфейс не имеет значения для бизнес-правил, поэтому проведите между ними черту. База данных не имеет значения для графического интерфейса, поэтому проведите между ними границу. База данных не имеет отношения к бизнес-правилам, поэтому между ними следует провести границу.
  • База данных - это не модель данных. База данных - это часть программного обеспечения. База данных - это служебная программа, обеспечивающая доступ к данным. С архитектурной точки зрения эта утилита не имеет значения, это мелкая деталь - механизм.
  • Пользовательский интерфейс - это деталь. Интернет - это пользовательский интерфейс. То есть Интернет - это деталь. И как архитектор, размещайте подобные детали вне основной бизнес-логики.
  • Убедитесь, что связь между модулями низкая, в то время как внутри модуля связь может быть выше, чем снаружи.
  • Если при разработке программы выясняется, что специалисты не понимают некоторых технических деталей из упрощенных схем, или вы не понимаете описания специалистов, это сигнал о том, что у вас, скорее всего, есть пробелы в знаниях в предметной области. И архитектура выйдет из строя, если не внести никаких изменений.
  • Дайте подходящие имена классам и методам. Если вам нужно изучить его реализацию, чтобы понять, как работает объект, то смысл инкапсуляции теряется.
  • Вдохновляйтесь математикой. Введите математические операции для объектов. Он может улучшить архитектуру и внести красоту в код.
  • Придерживайтесь минимализма.

Стратегия Кента Бека:

  • Сначала заставьте это работать. Вы вылетите из бизнеса, если это не сработает.
  • Тогда сделай это правильно. Организуйте код так, чтобы вы и другие могли понять и развить его, когда вам нужно что-то изменить или понять.
  • Наконец, сделайте это быстро. Организуйте код для достижения желаемой производительности.

Проектная работа

Если вы не волнуетесь, вам нужно волноваться. А если вы волнуетесь, не беспокойтесь.

Рэй Далио

  • Используйте метрики для отслеживания разработки продукта. Важно найти баланс в количестве показателей. Их не должно быть много, чтобы сделать это дешево и быстро, но достаточно, чтобы увидеть проблемы. 3–4 метрики может быть достаточно. Если ваш показатель близок к 100%, возможно, стоит его изменить. Но не забывайте об общении, показатели - это просто числа.
  • Имейте в виду, что при отсутствии данных люди реагируют иначе, чем при наличии бесполезных данных. При отсутствии конкретных данных правильно используется априорная вероятность; при наличии бесполезных данных априорная вероятность игнорируется.
  • В случае возникновения проблем используйте метод «5 почему», чтобы понять причину. Вы должны спросить «почему», постоянно углубляясь в проблему, чтобы найти истинную причину. Определите, кто отвечает за результат. Если результат плохой, это из-за отсутствия у человека навыков или ошибок в плане действий?
  • Вы можете управлять проектом с учетом затрат, времени, качества и масштаба. Каждый должен видеть и понимать эти переменные и их взаимосвязь, чтобы принимать правильные решения. Лучший способ управлять переменными - использовать масштаб. Так что придерживайтесь своего бюджета и временных планов, но жертвуйте масштабом. Отрежьте половину идей, затем просмотрите остальные и повторите снова. Чем ты легче, тем легче тебе измениться.
  • Начните с небольшого бюджета - он фокусируется на самых важных задачах, приводит к смекалке.
  • Путешествуйте налегке, это позволяет быстро адаптироваться. Старайтесь не привязываться к производителям, проприетарным форматам, жестко фиксированным дорожным картам.
  • Не решайте несуществующие проблемы. Для каждой новой задачи старайтесь найти способ реализовать ее быстрее и дешевле. Будьте проще: завтра может никогда не наступить, или к тому времени мы будем знать лучший способ решить проблему. Не платите за гибкость, которая вам не нужна. ЯГНИ
  • Подумайте о найме тестировщиков. Стоимость тестировщиков намного ниже, чем у разработчиков.
  • Научитесь говорить «нет» идеям. Учитывайте скрытую стоимость внедрения.
  • Не ограничивайте людей процессами, позвольте им самим решить, как решить проблему. Пусть ошибаются. Вы можете даже заложить в бюджет дешевые ошибки. Эти ошибки важно анализировать, чтобы не повторять их слишком часто. В большинстве случаев люди хотят выполнять работу на высшем уровне, и руководитель должен им в этом помогать. Ошибки - естественная часть процесса разработки. У каждого есть право и ответственность пытаться разобраться в важных вещах.
  • Избегайте настроек, за них приходится платить.
  • Двигайтесь вперед небольшими шагами. Используйте итеративный процесс для улучшения продукта. Как можно скорее протестируйте свои решения, не копируйте их до финальной версии. Прототип, не отвечающий всем условиям, уже может быть полезен для тестирования со специалистами или другими командами.
  • Учитесь и убедитесь, что команда тоже учится. Хотя в конечном итоге человек может достичь высочайшего уровня мастерства в определенной области, задачи не становятся для него легче: олимпийский спортсмен считает свой вид спорта столь же сложным, как и новичок. Не ждите, что ваши сотрудники сами будут определять свои слепые зоны и компенсировать их.
  • Играйте, чтобы выиграть, а не проиграть. Не прикрывайся бумагами и планами рассказать после этого, это не твоя вина.
  • Возьмите на себя ответственность за свои действия.
  • 40-часовая рабочая неделя (± 5 часов) позволяет вам быть эффективными и сосредоточенными. Избегайте лишнего рабочего времени в течение двух недель подряд.
  • Помните о балансе бизнеса и развития. Каждый должен нести ответственность за свою часть и быть доступным для другой стороны.
  • Подробно планируйте только текущий выпуск или итерацию. Чем дольше вы откладываете планирование, тем больше у вас данных и тем точнее вы можете предсказать следующие шаги.
  • Время не является отрицательным значением, поэтому ошибки времени всегда накапливаются справа. Это асимметрия. Вот почему мы часто делаем ошибки при планировании.
  • Срочные вопросы не важнее стратегических. Иногда меньше означает больше, и нам часто следует выбросить ненужную и незначительную информацию и сосредоточиться на ключевых вещах. Помните принцип Парето 20/80.
  • Актуальность - одна из основных причин нашего искаженного восприятия мира. Когда мы находимся под давлением срочности, мы принимаем неверные аналитические решения. Всегда нужно смотреть и измерять данные.
  • Журнал проблем может стать отличным инструментом для компании: сотрудники записывают все проблемы, уровень их важности и ответственности. Это помогает понять причины.
  • Боль + анализ = прогресс. Примите жесткость, исходящую от лучших мотивов.
  • Один из самых важных навыков, который вам необходимо развить, - это спрашивать совета у людей, которые компетентны в тех областях, в которых вы не сильны.
  • Делать предположения и задавать вопросы - это не то же самое, что критиковать, поэтому не принимайте их таким образом.
  • Одновременно оцените скорость изменений, уровень, на котором стоит цель, и взаимосвязь между ними. Если ситуация улучшится, но скорость изменений будет низкой, то в надлежащее время цель не будет достигнута.
  • Чтобы принимать эффективные решения, достаточно понимать большинство вещей на общем уровне.
  • Расставьте приоритеты, оценив важность дополнительной информации относительно затрат на откладывание решения.
  • Сначала делайте то, что вы должны делать, а затем делайте то, что вам нравится. Не отвлекайтесь на яркие безделушки и не забывайте о механизме выполнения повседневных задач.
  • Может не хватить времени на незначительные дела, но это лучше, чем не иметь достаточно времени на важные дела. Вы можете использовать матрицу Эйзенхауэра для определения приоритетов, разделив задачи по срочности и важности.
  • Любую задачу следует оценивать по вероятности ее успешного выполнения и уровню приоритета.
  • Если вы организовали встречу, управляйте обсуждением.
  • Определите области личной ответственности за коллективное принятие решений. Безличное «мы» - очевидный намек на то, что человек пытается избежать признания ошибки.
  • Настроить баг-трекер. Попытайтесь исправить ошибки, прежде чем писать новый код.
  • Часто вам приходится менять продукт, даже если он уже хорошо работает, чтобы поддержать интерес пользователей.

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

  • Архитектурные проблемы - решаемы тщательным рефакторингом, проверенным всей командой.
  • Проблемы с производительностью - часто 1% изменений может дать прибавку в 99%.
  • Уродливый код - это можно решить, приняв стандарты форматирования, настроив автоформатирование, git-hooks и т. Д.

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

  • Если вы покажете непрограммисту экран, который выглядит на 100% готовым, он подумает, что весь продукт почти готов.
  • Если вы покажете непрограммисту экран, который в финальной версии выглядит намного хуже, чем ожидалось, он подумает, что весь продукт намного хуже.

Когнитивные предубеждения и ментальные модели

Есть много когнитивных искажений, а также ментальных моделей. Многие из них описаны у Канемана, Чалдини и т. Д. Знание об их существовании поможет избежать некоторых ошибок при принятии решений или улучшить дизайн продукта. Ниже приведены лишь некоторые из тех, которые, на мой взгляд, наиболее актуальны для данной статьи.

  • Избегайте смещения конъюнктивных событий. Мы часто переоцениваем вероятность конъюнктивных событий-событий, которые должны происходить в сочетании друг с другом. Вероятность того, что произойдет серия конъюнктивных событий, ниже, чем вероятность любого отдельного события. Таким образом, мы рискуем серьезно недооценить время, деньги и усилия, необходимые для достижения наших целей.
  • Заблуждение о невозвратных затратах - склонность людей нерационально доводить дело до конца, не отвечающего их ожиданиям, из-за времени и / или денег, которые они уже потратили на это. Заблуждение о невозвратных расходах объясняет, почему люди заканчивают фильмы, которые им не нравятся, заканчивают обеды в ресторанах, даже если они переполнены, держатся за неэффективные инвестиции и хранят в шкафу одежду, которую никогда не носили.
  • Эффект фрейминга - когнитивная предвзятость, при которой люди по-разному реагируют на конкретный выбор в зависимости от того, как он преподносится, как потеря или как приобретение.

Связь

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

Управляйте обсуждениями:

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

Наем

  • Не нанимайте и не нанимайте как можно позже. Оцените, можете ли вы что-то не делать или уменьшить функциональность.
  • Если вы нанимаете, вы бы предпочли меньшее количество более талантливых людей, чем большее количество посредственных. Это снизит затраты на связь.
  • На практике наиболее эффективны группы от 3 до 5 человек.
  • Как гласит закон Брукса, добавление рабочей силы в поздний программный проект делает это позже.
  • Подумайте о сотруднике, с какими ценностями, способностями и навыками вы ищете. Здесь важен порядок слов.
  • Предположим, что большинство людей не меняются.
  • Предпочитаю универсалов. Члены многозадачной команды позволяют быстрее адаптироваться к меняющимся условиям.
  • При прочих равных выбирайте талантливого писателя. Эти люди обычно яснее думают и лучше общаются.
  • Думайте о своих командах как о спортивном менеджере: ни у кого нет всех навыков, необходимых для успеха, но каждый должен быть в чем-то лучше. Итак, проанализируйте, где вы чаще всего терпите неудачу, и укрепите себя. Если вы набираете людей с такими же сильными и слабыми сторонами, что и лидер, это с большей вероятностью приведет к отрицательному результату. Разнообразный опыт кандидатов увеличивает шансы на то, что они привнесут в проект свежие идеи.
  • Ищите людей, которые знают, как выполнять проекты.
  • Во время собеседования кандидат должен показать, что умеет писать код.

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

  • Страсть к программированию.
  • Интерес к новым языкам и технологиям, потому что это может показать интерес к профессии.
  • Навыки работы с низкоуровневыми технологиями.

Пример интервью:

  • Введение. Ваш краткий рассказ о себе, компании, должности. Здесь вы можете заверить кандидата, что вам важен процесс решения проблемы, а не реальные ответы.
  • Задавайте открытые вопросы о его / ее предыдущем опыте. Иногда углубляюсь в детали. Вы можете попросить их описать некоторые сложные вещи простыми словами, чтобы определить, насколько реально их понимает кандидат. Обратите внимание на страсть, с которой кандидаты рассказывают о своем опыте.
  • Дайте простые задачи по программированию. Здесь стоит обратить внимание на скорость выполнения задачи. Это может быть хорошим индикатором того, как человек в дальнейшем будет решать реальные задачи.
  • Переходите к более сложным вещам.
  • Раздел для вопросов от кандидата.

Разработка

Я не лучший программист; Я просто хороший программист с прекрасными привычками.

Кент Бек

  • Кодовая база - это место, где мы живем, и наша цель - сделать его пригодным для жизни для нас самих и для всех других людей, которые там живут. Когда мы пишем код, наша цель - не закончить его и двигаться дальше, наша цель - сделать его устойчивым и пригодным для жизни для команды, которая его населяет.
  • Вы можете думать о себе как о разработчике программного обеспечения, а не как о разработчике программного обеспечения. «Письмо» - гораздо более подходящая метафора для того, чем мы занимаемся большую часть времени, чем «инженерия». Письмо - это ясность и представление информации в ясной и понятной форме, чтобы ее мог понять любой.
  • Пишите тесты и делайте код максимально простым. Таким образом, вы можете снизить стоимость изменений, избежать чрезмерной инженерии и сосредоточиться на текущих проблемах. Тесты дают мгновенную обратную связь.
  • Ввести в практику обновление зависимостей каждые N дней. Это может быть раз в неделю или пару дней в месяц.
  • Настройте процессы развертывания, чтобы это происходило безболезненно. Это позволит вам быстро протестировать продукт и получить обратную связь. Имея отрицательный отзыв, вы можете легко откатить изменения.
  • Автоматизируйте процессы (восстановление после сбоев, рутинные операции и т. Д.), Так как вы не самый надежный компонент системы.

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

Используйте валидаторы:

  • Доступность: a11y-checker
  • Проверка HTML: validator.w3.org/nu
  • Структурированные данные: «search.google.com/structured-data/testing-tool

Рефакторинг

  • Тесты значительно упрощают рефакторинг.
  • Двигайтесь крошечными шагами и запускайте тесты после каждого шага.
  • Рефакторинг можно выполнить непосредственно перед добавлением дополнительной функции. Это позволяет понять код и улучшить его.
  • Всегда старайтесь оставить код лучше, чем он был до вас. Не делайте код хуже.
  • Не займет много времени, чтобы выбрать имя для функции / переменной во время рефакторинга. Выберите ту, которая пришла вам в голову, и измените ее, когда выберете лучший вариант.
  • В большинстве случаев вы можете игнорировать производительность во время рефакторинга (например, разбить один цикл на несколько). После рефакторинга исправьте проблемы с производительностью, если они возникнут.
  • Рефакторинг - это ваша работа. Не спрашивайте разрешения, а попросите совета. Вот как вы делаете свою работу как профессионал.
  • Всегда следите за тем, чтобы тесты падали тогда, когда должны были упасть.

Безопасность

  • Обратите внимание на хранение конфиденциальных данных в репозитории. Не храните их открытыми. Иногда фреймворк может решить эту проблему, например [Ruby On Rails] (https://guides.rubyonrails.org/security.html#environmental-security) или [Phoenix] (https: // hexdocs. pm / phoenix / deployment .html). Или вы можете выбрать другой подход, например [git-secret] (https://git-secret.io/).
  • Позаботьтесь о базовой безопасности своих серверов. Например, если у вас несколько серверов, вы можете ознакомиться с советами в статье Мои первые 10 минут на сервере и обсуждении ycombinator. Либо вы можете автоматизировать развертывание сервера и создавать / находить рецепты для вашей любимой системы: ansible, chef или что-то еще.

Убедитесь, что вы учли наиболее распространенные ошибки безопасности. Например, вы можете просмотреть список owasp.org/www-project-top-ten и проверить, что:

  • Вы позаботились об отсутствии в коде инъекций: SQL, NoSQL и т. Д.
  • Убедитесь, что аутентификация не нарушена и работает правильно.
  • Проверено, что в открытом доступе нет конфиденциальных данных и API.
  • Не допустил ошибок в настройке безопасности, например: поменял пароли по умолчанию, правильно настроил фаервол (особенно актуально для тех, кто пользуется докером).
  • Позаботьтесь о XSS.
  • Настроены процессы обновления зависимостей при появлении в них уязвимостей. Например, github отправляет отчеты об уязвимостях зависимостей для разных языков. Этот момент также можно смягчить, если вы внедрили практику периодического обновления зависимостей, описанную выше.
  • Настройте ведение журнала и мониторинг ваших систем

Вывод

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

использованная литература