Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 30 сентября 2020 года. Оригинальная версия на украинском языке доступна по ссылке. Редакция DOU пообщалась с разработчиками, которые проводят технические собеседования Python-специалистов для различных уровней, и собрала примерный список вопросов к кандидатам. Конечно, он не является исчерпывающим, однако содержит типичные вопросы.   Вопросы для Junior   От джуниоров требуют знать и уметь применять базовые структуры данных и модули, простейшие запросы к базам данных, знать простейшие команды системы контроля версий и тому подобное. Общее по Computer Science и Web Development: 1. Что такое инженерия и процесс разработки в целом? 2. Какие знаете принципы программирования? 3. Чем отличаются процедурная и объектов-ориентированная парадигмы программирования? 4. Какие основные принципы ООП (наследование, инкапсуляция, полиморфизм)? 5. Что такое множественное наследование? 6. Какие есть шесть этапов разработки продукта в Software Development lifecycle и какая разница между Agile и Kanban? 7. Какие есть методы HTTP-запросов и какая между ними разница? 8. Как выглядят HTTP-request / response? 9. Что такое авторизация и как она работает? 10. Что такое cookies? 11. Что такое веб уязвимость? 12. Какие знаете классические базы данных? 13. Как читать спецификацию в конкретном языке (например, PEP8 в Python)? 14. Как происходит взаимодействие клиента и сервера? 15. Какие есть подходы к проектированию API? 16. Как использовать паттерны программирования? 17. Что такое Acceptance Testing и зачем его используют? 18. Что такое модульные и интеграционные тесты, API-тесты? 19. Как писать unit-тесты? 20. Какие есть best practices в написании автотестов? 21. Какие базовые команды системы контроля версий? 22. Как использовать Git? 23. В чем разница между хешированием и шифрованием? Ответы на некоторые из этих вопросов вы можете найти в видео курсах Python Базовый, Python Углублённый, Основы работы с Git.   Python: 24. Python - интерпретируемый язык или компилируемый? 25. Какие есть меняющиеся и постоянные типы данных? 26. Что такое область видимости переменных? 27. Что такое introspection? 28. Разница между is и ==? 29. Разница между __init __ () и __new __ ()? 30. В чем разница между потоками и процессами? 31. Какие есть виды импорта? 32. Что такое класс, итератор, генератор? 33. Что такое метакласс, переменная цикла? 34. В чем разница между итераторами и генераторами? 35. В чем разница между staticmethod и classmethod? 36. Как работают декораторы, контекстные менеджеры? 37. Как работают dict comprehension, list comprehension и set comprehension? 38. Можно ли использовать несколько декораторов для одной функции? 39. Можно ли создать декоратор из класса? 40. Какие есть основные популярные пакеты (requests, pytest, etc)? 41. Что такое lambda-функции? 42. Что означает *args, **kwargs и как они используются? 43. Что такое exceptions, <try-except>? 44. Что такое PEP (Python Enhancement Proposal), какие из них знаете (PEP 8, PEP 484)? 45. Напишите hello-world сервис, используя один из фреймворков. 46. Какие есть типы данных и какая разница между list и tuple, зачем они? 47. Как использовать встроенные коллекции (list, set, dictionary)? 48. В чем заключается сложность доступа к элементам dict? 49. Как создается объект в Python, для чего __new__, зачем __init__? 50. Что знаете из модуля collections, какими еще built-in модулями пользовались? 51. Что такое шаблонизатор и как в нем выполнять базовые операции (объединять участки шаблона, выводить дату, выводить данные с серверной стороны)? 52. Как Python работает с HTTP-сервером? 53. Что происходит, когда создается виртуальная среда? Ответы на некоторые из этих вопросов вы можете найти в видео курсах Python Стартовый (урок 2, урок 4-8), Python Базовый (урок 1, урок 6, урок 7, урок 9), Python Углублённый (урок 1, урок 4).   Базы данных: 54. Какие есть базовые методы работы с SQL- базой данных в Python? 55. Что такое SQL-транзакция? 56. Как сделать выборку из SQL-базы с простой агрегацией? 57. Как выглядит запрос, который выполняет JOIN между таблицами и к самим себе? 58. Как отправлять запросы в SQL-базу данных без ORM? Ответы на некоторые из этих вопросов вы можете найти в видео курсе SQL Базовый.   Алгоритмы: 59. Что такое алгоритмы (например, Big-O notation)? 60. Какие есть базовые алгоритмы сортировки? 61. Что такое Bubble Sort и как это работает? 62. Что такое линейная сложность сортировки?   Вопросы для Middle   Если джуниору все надо подсказывать и помогать, то мидл может самостоятельно взять что-то новое и быстро его изучить и понять. У него накоплено достаточно знаний и опыта, чтобы быстро овладевать новым. Он может прийти и обсудить с опытным разработчиком, проконсультироваться, но окончательных решений не принимает. Обычно у мидлов спрашивают: 63. Ориентируетесь ли в *nix, можете ли написать скрипты/автоматизацию для себя и коллег? 64. Что такое многопоточность? 65. Что такое архитектура веб сервисов? 66. Как работает современное нагруженное веб приложение (нарисовать и обсудить примерную архитектуру, например, Twitter или Instagram)? 67. Что нужно для сайта / сервиса среднего размера (redis \ celery \ кэш \ логирование \ метрики)? 68. Как написать, задеплоить и поддерживать (микро) сервис? 69. Как масштабировать API? 70. Як проводить Code review? 71. Что такое абстрактная фабрика, как ее реализовать и зачем ее применяют? 72. Что такое цикломатическая сложность?   Python: 73. Async Python: как работает, зачем, что под капотом? 74. Сравнить асинхронные web-фреймворки. 75. Что такое модель памяти Python? 76. Что такое SQLAlchemy (Core и ORM частей) и какие есть альтернативы? 77. Принципы работы и механизм Garbage collection, reference counting? 78. Как работает thread locals? 79. Что такое _slots_? 80. Как передаются аргументы функций в Python (by value or reference)? 81. Что такое type annotation? 82. Для чего используют нижние подчеркивания в именах классов? 83. Статические анализаторы: Flake8, Pylint, Radon. Ответы на некоторые из этих вопросов вы можете найти в видео курсе Python Углублённый (урок 3).   Базы данных: 84. Разница между SQL и NoSQL? 85. Как оптимизировать SQL-запросы? 86. Какие есть уровни изоляции транзакций? 87. Какие есть виды индексов? 88. Точечные вопросы по выбору БД, движков БД? 89. Front-end: есть ли опыт работы с «современным» JS (Babel, Webpack, TS, ES)? 90. DevOps: работали ли с Docker-контейнерами, объяснить основные термины K8s (кластер, pod, node, deployment, service), что такое Kibana? 91. Алгоритмы: что такое временная сложность алгоритма (time complexity)? 92. Углубленные знания Linux: как зайти на внешний сервер, работать с пакетами, настроить среду и выполнять операции? 93. Специфично для Data Science: как работать с пакетами для обработки и визуализации данных (NumPy, Pandas и другие)? Ответы на некоторые из этих вопросов вы можете найти в видео курсе SQL Базовый.   Вопросы для Senior   На собеседованиях с Senior`ами обычно мало говорят о теоретической стороне технологии, больше обсуждают конкретный опыт разработчика. Поэтому формализованных вопросов здесь нет. Однако, примером могут быть: 94. Что такое @property? 95. Каким образом можно запустить код на Python параллельно? 96. Как работать с stdlib? 97. Какие задачи решали с помощью метаклассов? 98. Что такое дескрипторы? 99. Знания других языков, кроме Python (опыт). 100. Какие технологические особенности реализации распределенных систем? 101. Какие есть низкоуровневые особенности языков и фреймворков? 102. Способы и методы управления памятью.   Бонус. Практические задания   1. Спроектировать клон Instagram. Это сервис, который понятен практически любому кандидату, даже если у него нет аккаунта. На высоком уровне он очень прост: картинки, описания, комментарии. Поэтому что-то минимальное сможет описать и джуниор. Если кандидат претендует на высшие позиции, можно бесконечно копать вглубь, касаясь API, тротлинга запросов, защиты от фрода, построения фидов пользователя и тому подобное. 2. Дано рекурсивное определение чисел Фибоначчи, надо написать функцию, которая реализует это определение. 3. Есть база данных из трех таблиц — стандартная many-to-many схема. Нужно написать запрос, который объединяет три таблицы и возвращает определенный результат. 4. Даем ТЗ какого-то полезного микросервиса (сокращалка url-ов, поиск дубликатов картинок, поиск тегов в текстах) или функции (rate limiter). Просим кандидата рассказать, как бы он его реализовал. Это дает возможность узнать, что привык использовать специалист, насколько глубоко он знает и понимает различные технологии. 5. Написать какой-то несложный декоратор (выводит аргументы функции на экран или, например, измеряет сколько времени выполнялась функция). 6. Junior`у можно предложить реализовать задачу FizzBuzz test. 7. Для Middle+ я люблю давать несложные задачки на рекурсию. Например, есть вложенный список чисел и нужно что-то на нем посчитать (скажем, найти максимум). Также, можно предложить написать аналог deepcopy для конкретной структуры данных (tree, graph). 8. Для Senior - игра «спроектировать за 5 минут...». Это может быть Google, FB, Twitter, высоконагруженный интернет-магазин, сервис поиска, продажи и бронирования билетов, сайт новостей и тому подобное. Такая задача помогает понять, как кандидат решает проблемы, ход его мыслей, умеет ли он отделять главное от второстепенного, понять, какого он типа ( «в глубину» или «в ширину»). 9. Игра «у юзера что-то не работает». На примере спроектированной системы собеседователь придумывает ошибку с «дикими симптомами», которую очень сложно понять, воспроизвести. Но нужно быстро решить проблему. 10. Задание, которое демонстрирует знание и понимание list и dict comprehensions. Looking at the below code, write down the final values of A0, A1, ...An.             A0 = dict(zip(('a','b','c','d','e'),(1,2,3,4,5)))             A1 = range(10)             A2 = sorted([i for i in A1 if i in A0])             A3 = sorted([A0[s] for s in A0])             A4 = [i for i in A1 if i in A3]             A5 = {i:i*i for i in A1}             A6 = [[i,i*i] for i in A1]             A7 = [i if i%2 else 0 for i in A1 if 2 < i < 8]             ','.join(str(j**2) for j in range(10)) – what is this object ?   11. Задача, в которой есть три функции, в них выполняются базовые операции (сортировка, фильтрация, поднесение массива к квадрату). Нужно упорядочить эти три функции в порядке возрастания времени, которое уходит на их выполнение. Place the following functions below in order of their efficiency. They all take in a list of numbers between 0 and 1. The list can be quite long. An example input list would be [random.random () for i in range (100000)]. How would you prove that your answer is correct? - profiling? def f1 (lIn):             l1 = sorted (lIn)             l2 = [i for i in l1 if i <0.5]             return [i * i for i in l2] def f2 (lIn):             l1 = [i for i in lIn if i <0.5]             l2 = sorted (l1)             return [i * i for i in l2] def f3 (lIn):             l1 = [i * i for i in lIn]             l2 = sorted (l1)             return [i for i in l1 if i <(0.5 * 0.5)]   То есть, на входе все функции имеют одинаковые данные, на выходе выдают одинаковый результат. Но из-за того, что внутри операции выполняются в разном порядке, время выполнения будет отличаться. Здесь нужно разбираться в алгоритмах и понимать, что происходит с твоими данными в процессе. Эту задачу может решить Junior, а может не решить и Middle. Казалось бы, такая мелочь, но когда мы работаем с большим количеством данных, важно, чтобы код был оптимизирован и программа выполнялась максимально быстро.   12. Простые задачи на статистику или логику. Например, определить угол между стрелками часов, которые показывают 8:40. За подготовку материала редакция DOU выражает благодарность Михаилу Кашкину (Founder в Okumy и курсов по Python), Руслану Скире (Python Developer в CodeIT LLC), Бориславу Ларину (Python Developer в Prom.ua), Владимиру Обризану (Director в Design and Test Lab), Виктору Свирскому (Senior Developer в DataArt), Николаю Зорину (CTO в Jiji, проект Genesis), Владимиру Селюху (Team Lead в Prom.ua), Сергею Галабурде (Software Engineer в N-iX), Алексею Чуприкову (Lead Python Engineer в EPAM), Ивану Лучку (TL Data Science Specialist в Boosta), Олегу Новикову, Владимиру Щербинину, Роману Могилатову (Technical Leader в SoftServe), Вадиму Рудю, Натальи Кушнир, Андрею Лейцюсю, Роману Луцю и другим. Перевел на русский язык Владислав Сверчков

Навіщо потрібний гарний баг-репорт? Які якості гарного баг-репорту у розробці програмного забезпечення? Характеристики та методи для повідомлення про баг Ефективний баг-репортинг Простий шаблон баг-репорту Важливі фічі у вашому звіті про помилки Номер помилки/ідентифікатор Найменування помилки Пріоритет Платформа/Середовище Опис Кроки для відтворення помилки Очікуваний та фактичний результат Скріншот Додаткові поради для написання гарного баг-репорту Висновок Навіщо потрібний гарний баг-репорт? Баг репорт це звіт про помилки. І якщо його складено правильно, то шанси на швидке виправлення цих багів вищі. Таким чином, виправлення помилки залежить від того, наскільки якісно ви про неї повідомите. Складання звітів про помилки - не що інше, як навичка, і зараз ми розглянемо, як її сформувати. "Сенс написання звіту про проблеми (баг-репорту) полягає в тому, щоб виправити ці проблеми" - Cem Kaner. Якщо тестувальник не повідомляє про помилку правильно, програміст, швидше за все, відхиляє цю помилку, заявивши, що вона невідтворювана. Це може нашкодити робочому настрою тестувальників, зачепити їх професійну гордість, їх его. Які якості гарного баг-репорту у розробці програмного забезпечення? Будь-хто може скласти приклад баг репорту. Але не кожен може написати ефективний баг-репорт. Ви повинні вміти добре розрізняти баг-репорт середньої якості та гарний баг-репорт. Як відрізнити гарний та поганий баг-репорти? Це дуже просто – застосуйте наступні характеристики та методи, щоб якісно повідомити про помилку. Характеристики та методи включають в себе: 1) Наявність чітко визначеного номера помилки: Завжди надавайте унікальний номер кожному повідомленню про помилку. Це, у свою чергу, допоможе вам чітко ідентифікувати запис про помилку. Якщо ви використовуєте будь-який інструмент автоматичного формування баг-репортів, цей унікальний номер буде генеруватися автоматично кожного разу, коли ви робите звіт. Запишіть номер та короткий опис кожної помилки, про яку ви повідомили. 2) Відтворюваність: Якщо знайдена вами помилка невідтворювана, вона ніколи не буде виправлена. Ви повинні чітко вказати кроки для відтворення помилки. Не приймайте та не пропускайте жодного кроку відтворення. Помилку, яка описана крок за кроком, легко відтворити та виправити. 3) Будьте конкретні: Не пишіть нарис про проблему. Пишіть конкретно і по суті. Спробуйте описати виявлену проблему мінімальною кількістю слів та максимально ефективним способом. Не поєднуйте описи кількох багів в одному звіті, навіть якщо вони здаються схожими. Напишіть різні звіти для кожної проблеми. Ефективний баг-репортинг Звіти про помилки є важливим аспектом тестування програмного забезпечення. Ефективний баг-репорт добре розуміється командою розробників і дозволяє уникнути плутанини чи непорозуміння. Гарний звіт про помилку має бути чітким і коротким, без будь-яких пропущених ключових моментів. Будь-яка відсутність ясності веде до непорозуміння та уповільнює процес розробки. Опис дефектів та складання звітів – одна з найважливіших, але часто ігнорованих областей у життєвому циклі тестування. Правильно складений текст звіту про знайдений баг є дуже важливим для реєстрації помилки. Один із важливих моментів, які повинен мати на увазі тестер, - це не використовувати командний тон у звіті. Такий тон порушує моральний стан колективу та створює нездорові робочі відносини. Використовуйте нейтральний тон. Не думайте, що якщо розробник припустився помилки, то ви можете використовувати грубі слова. Перш ніж повідомляти, не менш важливо перевірити, чи був баг-репорт за цією помилкою раніше, чи ні. Дублікати помилок – це постійна проблема у циклі тестування. Перевіряйте весь список виявлених багів. Іноді розробники можуть знати про проблему і ігнорувати її в майбутньому випуску. Використовуйте спеціальні інструменти, такі як Bugzilla, який автоматично шукає дублікати помилок. Тим не менш, найкраще додатково вручну шукати дублікати помилок. Чітко вказуйте інформацію про помилку: «Як?» і «Де?". Звіт повинен ясно показувати, як було виконано тест і де саме стався дефект. Читач звіту повинен легко відтворити помилку та знайти її. Майте на увазі, що мета написання баг-репорту – дати розробнику можливість візуалізувати проблему. Він повинен чітко розуміти суть дефекту, прочитавши звіт про помилку. Не забудьте надати всю необхідну інформацію, яку розробник шукає. Крім того, майте на увазі, що звіт про помилки буде збережено для майбутнього використання і він повинен бути гарно написаний та містити необхідну інформацію. Використовуйте змістовні речення та прості слова, щоб описати знайдені помилки. Не використовуйте заплутані твердження, які витрачають час читача. Повідомляйте про кожну помилку як про окрему проблему. У разі опису кількох багів в одному звіті, ви не зможете закрити його, доки всі проблеми не будуть вирішені. Таким чином, краще за все розбити великі проблеми на окремі баги. Це гарантує, що кожна помилка може бути оброблена окремо. Добре написаний баг-репорт допомагає розробнику відтворити помилку у своєму терміналі. Це також допомагає їм правильно діагностувати проблему. Простий баг репорт шаблон Це проста форма баг-репорту. Його зміст може змінюватись в залежності від використовуваного вами інструменту для створення звітів про помилки. Якщо ви пишете баг-репорт вручну, необхідно згадати деякі поля, наприклад номер помилки, який повинен бути призначений вручну. Укладач звіту: Ваше ім'я та адреса електронної пошти. Продукт: У якому продукті ви знайшли цю помилку. Версія: Версія продукту з помилкою, якщо така є. Компонент: Основні підмодулі продукту. Платформа: Вкажіть апаратну платформу, де ви виявили цю помилку. Різні платформи, такі як "ПК", "MAC", "HP", "Sun" і т. д. Операційна система: Вкажіть усі операційні системи, у яких ви виявили помилку. Операційні системи, як-от Windows, Linux, Unix, SunOS, Mac OS. Згадайте різні версії ОС, такі як Windows NT, Windows 2000, Windows XP і т. д., якщо це можна застосувати. Пріоритет: Коли потрібно виправляти помилку? Пріоритет зазвичай встановлюється від P1 до P5. P1 слід розуміти як "виправити помилку з найвищим пріоритетом" і P5 - "виправити, якщо дозволяє час". Серйозність помилки: Визначає вплив помилки. Типи Серйозності помилки: Блокувальник (Blocker): подальша робота з тестування неможлива. Критична (Critical): збій застосунку, втрата даних. Major: серйозна втрата функціональності. Minor: незначна втрата функціональності. Незначна (Trivial): деякі поліпшення інтерфейсу користувача. Поліпшення (Enhancement): запит нової функції або деякого покращення існуючої. Статус помилки: Коли ви реєструєте помилку в будь-якій системі відстеження помилок, за замовчуванням статус помилки буде «Новий». Пізніше помилка проходить через різні етапи, такі як "Виправлено", "Перевірено", "Повторно відкрито", "Не виправлено" тощо. Призначити розробнику: Якщо ви знаєте, який розробник відповідає за той конкретний модуль, в якому виникла помилка, ви можете вказати адресу електронної пошти цього розробника. В іншому випадку залиште це поле порожнім, оскільки це надасть полю авторства помилки значення власника модуля, якщо менеджер не призначить помилку розробнику. URL: URL-адреса сторінки, на якій сталася помилка. Коротке резюме: Додайте короткий опис помилки. Орієнтуйтесь на 60 слів або менше. Переконайтеся, що складене резюме відображає проблему та місце, де вона знаходиться. Опис: Детальний опис помилки. Використовуйте такі поля для поля опису: Відтворювані кроки: чітко згадайте кроки для відтворення помилки. Очікуваний результат: як додаток має поводитися на вказаних вище етапах. Фактичний результат: який фактичний результат виконання вищезгаданих кроків, тобто поведінка помилки. Це важливі кроки у звіті про помилки. Ви також можете додати "Тип звіту" як ще одне поле, яке описуватиме тип помилки. Типи звітів включають в себе: Помилка в коді Помилка проєктування Нова пропозиція Проблема із документацією Апаратна проблема Важливі фічі у вашому звіті про помилки Розглянемо кілька складових звіту про знайдений баг. Нижче наведено важливі елементи баг-репорту: 1) Номер помилки/ідентифікатор: Номер помилки або ідентифікаційний номер (наприклад, xyz007) значно спрощує складання баг-репорту та пошук місця помилки. Розробник може легко перевірити, чи виправлено конкретну помилку, чи ні. Це робить весь процес тестування та повторного тестування більш плавним та легким. 2) Найменування помилки: Заголовок помилки читається частіше, ніж будь-яка інша частина баг-репорту. Варто вказати в ньому все про те, що входить в баг. Назва помилки має бути досить осмисленою, щоб читач міг її зрозуміти. Чіткий заголовок помилки полегшує розуміння, і читач легко зможе перевірити, чи було повідомлення про помилку раніше і чи було її виправлено. 3) Пріоритет:  В залежності від серйозності помилки для неї може бути встановлений пріоритет. Помилка може бути Blocker, Critical, Major, Minor, Trivial або пропозицією щодо покращення функціоналу. Пріоритет помилки від P1 до P5 може бути заданий так, щоб найважливіші з них переглядалися першими. 4) Платформа/Середовище:  Вказівка ​​конфігурації ОС та браузера потрібна для більшої точності в баг-репорті. Це найкращий спосіб повідомити, як можна відтворити помилку. Без точної платформи або середовища програма може поводитися по-іншому, і помилка на стороні тестувальника може не повторюватися на стороні розробника. Тому краще чітко вказати середовище, в якому було виявлено помилку. 5) Опис:  Правильний опис помилки допомагає розробнику зрозуміти помилку. Він описує проблему, що виникла. Поганий опис створить плутанину та витратить час розробників і тестерів. Необхідно чітко повідомити про ефект в описі. Завжди корисно використовувати повні речення. Рекомендується описувати кожну проблему окремо. Не використовуйте такі терміни, як «я думаю» чи «я вважаю». 6) Кроки для відтворення помилки:  Гарний звіт про помилку має чітко вказувати кроки для відтворення. Кроки повинні включати дії, які спричиняють помилку. Не робіть загальних заяв. Будьте конкретні у наступних кроках. Гарний приклад правильно написаної покрокової процедури наведено нижче: Послідовність кроків: Виберіть продукт wer05. Натисніть на «Додати до кошика». Натисніть «Видалити», щоб видалити продукт із кошика. 7) Очікуваний та фактичний результат:  Опис помилки буде неповним без зазначення очікуваних та фактичних результатів. Необхідно описати в загальних рисах, який результат тесту і що очікував користувач у разі коректної роботи програми. Читач звіту повинен знати, який результат тесту буде коректним. Чітко згадайте, що сталося під час тесту і який був результат. 8) Скріншот: Одна картинка коштує тисячі слів. Зробіть скріншот із прикладом збою з відповідними виділеннями, щоб вказати дефект. Виділіть несподівані повідомлення про помилки світло-червоним кольором. Це привертає увагу до необхідної області. Деякі додаткові поради для написання гарного баг-репорту Нижче наведено деякі додаткові поради, щоб написати гарний звіт про помилку: 1) Негайно повідомте про проблему: Якщо ви виявите будь-яку помилку під час тестування, не потрібно чекати, щоб написати докладний звіт про помилку пізніше. Натомість напишіть звіт про помилку негайно. Це забезпечить гарну якість звіту та відтворюваність кроків отримання помилок. Якщо ви вирішите написати звіт про помилку пізніше, то є великі шанси пропустити важливі деталі в баг-репорті. 2) Відтворіть помилку тричі перед написанням баг-репорту: Ваш баг має бути відтворюваним. Переконайтеся, що ваші кроки досить чіткі, щоб відтворити помилку без будь-якої двозначності. Якщо ваша помилка не відтворюється щоразу, ви все одно можете помилитися, вказавши періодичну природу багу. 3) Протестуйте цю ж помилку на інших схожих модулях:  Іноді розробник використовує один і той самий код для різних схожих модулів. Таким чином, ймовірність того, що помилка в одному модулі виникне і в інших подібних модулях, вища. Ви навіть можете спробувати знайти серйознішу версію знайденої помилки. 4) Складіть гарне резюме помилки: Короткий опис помилки допоможе розробникам швидко проаналізувати природу помилки. Низька якість звіту надмірно збільшить час розробки та тестування. Правильно взаємодійте з вашим баг-репортом. Майте на увазі, що зведення про помилки використовується як довідкова інформація для пошуку помилки в інвентарі помилок. 5) Прочитайте декілька разів звіт про помилку, перш ніж натиснути кнопку «Надіслати»:  Прочитайте всі речення, формулювання та кроки, які використовуються у баг-репорті. Подивіться, чи не створює якесь речення двозначність, яка може призвести до неправильної інтерпретації. Слід уникати слів або речень, що вводять в оману, щоб скласти чітке повідомлення про помилку. 6) Не використовуйте образливих виразів:  Приємно, що ви зробили хорошу роботу і виявили помилку, але не використовуєте це для критики розробника чи нападок на будь-яку людину. Висновок Що таке баги? Це недосконалості ПЗ, з якими необхідно боротися, і один із головних помічників у цьому – репорти про помилки. Ми розглянули деякі особливості складання звіту про знайдений баг. Немає сумнівів, що ваш баг-репорт повинен бути якісним документом. Зосередьтеся на написанні гарних звітів про помилки і витратьте деякий час на виконання цього завдання, оскільки саме якісний баг-репорт є основною точкою зв'язку між тестером, розробником та менеджером. Менеджери зі свого боку повинні пояснити своїй команді, що складання гарного звіту про помилки є основним обов'язком будь-якого тестувальника. Ваші зусилля щодо написання гарного звіту про помилки не тільки збережуть ресурси компанії, але й створять гарні стосунки між вами та розробниками. Для кращої продуктивності команди намагайтеся написати якомога гарний звіт про помилки. З нашого боку для якісної підготовки тестувальників пропонуємо вам ознайомитися з курсом підготовки спеціаліста-тестувальника на ITVDN - Quality Assurance. За матеріалами статті.

Кар’єрний шлях сьогодні виглядає зовсім не так, як десять років тому. Ринок праці змінюється швидше, ніж ми встигаємо оновлювати резюме. Нові професії з’являються щороку, компанії скорочують команди або перебудовують процеси, а конкуренція за хороші вакансії стає все жорсткішою. У таких умовах навіть досвідчені фахівці іноді губляться — не розуміють, у який бік рухатися, як ефективно подати себе або як повернути впевненість після невдачі. Саме тут у гру вступає кар’єрний консультант — фахівець, який допомагає розібратись у професійних цілях, знайти стратегію і сформувати сильне позиціонування на ринку. 🔹 Коли варто звертатися до кар’єрного консультанта Кар’єрна консультація — це не лише для тих, хто «не знає, ким бути». Насправді вона корисна на будь-якому етапі професійного життя. 1. Якщо ви — студент або джун, який робить перші кроки Ви закінчили курси, маєте базові навички, але не розумієте, як потрапити на першу роботу? Кар’єрний консультант допоможе: скласти резюме, яке справді читають рекрутери, правильно оформити профілі на джоб-бордах і LinkedIn, зрозуміти, які навички варто прокачати першими, підготуватися до співбесіди без паніки. 💡 Результат: ви не витрачаєте місяці на безуспішні відгуки, а швидше потрапляєте на інтерв’ю і отримуєте перший оффер. 2. Якщо ви хочете перейти в ІТ з іншої сфери Світчинг — це сміливий крок, але без чіткої стратегії легко застрягти. Кар’єрний консультант допоможе трансформувати ваш попередній досвід у перевагу, а не слабке місце. Ви навчитеся грамотно пояснювати, чому ваш бекграунд цінний, навіть якщо він не технічний. 💬 Приклад: Бухгалтер, який переходить у тестування, може подати себе як уважного аналітика з високою відповідальністю. Вчитель, який став FrontEnd-розробником, — як людину, що вміє структурувати складне і пояснювати логіку рішень. Кар’єрний консультант допоможе знайти саме цю історію. 3. Якщо ви вже працюєте, але хочете кар’єрного росту Часто фахівці роками залишаються на одній посаді не тому, що не заслуговують підвищення, а тому що не знають, як заявити про себе. Консультант допоможе оцінити ваші досягнення, побудувати аргументацію для перегляду зарплати або підготовку до переходу на новий рівень (Middle → Senior, Senior → Team Lead). 💡 Ви отримаєте: чітку стратегію розвитку, план навчання і розвитку soft skills, нове бачення ринку і своїх можливостей. 4. Якщо ви шукаєте нову роботу після перерви Після декрету, релокації, війни чи довгого “вигорання” часто складно знову повірити у свої сили. Кар’єрний консультант допоможе: оновити резюме та профілі, визначити актуальний рівень навичок, знайти реалістичні вакансії, відновити впевненість у спілкуванні з рекрутерами. 🎯 Це особливо важливо в ІТ, де технології змінюються щороку, і потрібен зовнішній погляд, щоб оцінити, як повернутися в ритм. 5. Якщо ви не розумієте, чого хочете далі Навіть досвідчені спеціалісти часом губляться у питанні «що далі?». Кар’єрний консультант не дає готових відповідей — він допомагає знайти ваші власні орієнтири: у чому ваша цінність, який формат роботи підходить вам (офіс, remote, фріланс), що вас реально мотивує. Після такої консультації ви перестаєте бігти навмання — і рухаєтеся усвідомлено. 🔹 Як кар’єрний консультант заощадить ваш час і гроші На перший погляд здається, що звернення до консультанта — це додаткові витрати. Але насправді — це інвестиція, яка повертається у вигляді прискорення результатів. 1. Економія часу Кар’єрний консультант допоможе уникнути місяців хаотичного пошуку. Він уже знає, як працює ринок, де шукати роботу, як комунікувати з рекрутерами і що реально цінується у кандидатах. Замість того, щоб “губитися” в десятках вакансій, ви отримуєте чітку дорожню карту. 💬 Наприклад: Без стратегії ви можете надсилати резюме пів року й не отримати жодної відповіді. З консультантом — ви розумієте, які позиції вам підходять, як адаптувати резюме під кожну, і отримуєте зворотний зв’язок уже за кілька тижнів. 2. Економія грошей Кар’єрна консультація часто коштує менше, ніж один місяць пошуку “в сліпу”. Але допомагає вам: отримати вищу зарплату завдяки правильно підготовленій аргументації, уникнути неправильного вибору (наприклад, курсів чи компанії, які не дадуть розвитку), не витрачати гроші на безрезультатні сертифікати або “псевдо тренінги”. 💡 Консультант підкаже, де варто інвестувати час і ресурси, а що не має сенсу саме для вас. 3. Об’єктивний погляд ззовні Ми часто не бачимо власних сильних сторін.Кар’єрний консультант допомагає оцінити ваш досвід очима роботодавця, знайти формулювання, які викликають довіру. Це особливо важливо в ІТ, де багато схожих кандидатів, і потрібно чітко показати, чому обрати саме вас. 4. Стратегічний ефект Консультація — це не одноразова допомога. Це стратегія. Після неї ви розумієте, куди рухаєтесь, що вам потрібно для наступного рівня, і як вибудувати кар’єру на роки вперед. Це не просто пошук роботи — це управління власним професійним шляхом. 🔹 Висновок Кар’єрний консультант — це не «психолог для роботи», а партнер, який допомагає побачити вашу цінність і перетворити досвід у можливості. Він не шукає вакансії за вас — він вчить вас робити це ефективно. Допомога консультанта потрібна не лише початківцям, а й тим, хто стоїть на роздоріжжі, прагне розвитку або втратив упевненість. Бо найцінніше, що ви отримуєте після такої співпраці, — це ясність: хто ви, куди йдете і як саме туди потрапити. І якщо порахувати скільки часу, нервів і ресурсів витрачають люди, які шукають роботу самостійно, — то кар’єрна консультація стає не витратою, а розумною інвестицією у власне майбутнє. 💬 Пам’ятайте: правильна порада вчасно може заощадити вам не один місяць пошуку — і принести роботу, яка дійсно змінить ваше життя.

Пошук роботи в ІТ — це процес, який часто здається марафоном без фінішу. Ти надсилаєш десятки резюме, проходиш співбесіди, виконуєш тестові — і раптом отримуєш сухе повідомлення: «На жаль, ви нам не підходите». Чому саме? Адже ти вчився, мав мотивацію, виконав завдання. Відповідь проста: на кожному етапі рекрутинг-процесу роботодавець шукає не просто знання, а сигнали — про твоє мислення, готовність до роботи, поведінку і навіть енергію, яку ти передаєш. Розберімо докладно кожен етап і те, як уникнути типових помилок. Етап 1. Відмова після подачі резюме Це найпоширеніший і найболючіший момент: ти надсилаєш десятки відгуків і отримуєш тишу. Що відбувається насправді Рекрутер витрачає на одне резюме від 7 до 15 секунд. За цей час він вирішує, чи варто читати далі. Якщо твій документ виглядає неструктуровано, без конкретики, без GitHub або портфоліо — він просто губиться серед сотень інших. ⚠️ Типові помилки Заголовок “Junior Developer” без уточнення напряму. Потрібно конкретно: “Junior Python Developer”, “QA Manual”. Опис у стилі “вивчав HTML/CSS/JS, маю базові знання SQL”. Це виглядає як список зі шпаргалки. Відсутність результатів. Навіть на етапі навчання варто показувати, що ти вже зробив: pet-проєкти, сертифікати, дипломні завдання. Неадаптоване резюме. Якщо ти шлеш одне й те саме всім — видно, що ти не читав опис вакансії. ✅ Як зробити краще Почни резюме з короткого профілю: хто ти, що вмієш і чим можеш бути корисним. Додай результати навчання: проєкти, технології, що використовував, лінки. Замість фрази “Хочу розвиватися в ІТ” напиши “Прагну приєднатися до команди, де зможу працювати над продуктом, вдосконалюючи свій код і процеси тестування”. 💡 Резюме — це не твоя біографія, а перша презентація твоєї професійної цінності. Етап 2. Відмова після розмови з рекрутером Якщо тебе запросили на першу співбесіду — резюме зацікавило. Але далі важливо закріпити враження. Як мислить рекрутер HR оцінює не твої знання коду, а твою мотивацію, емоційний інтелект, комунікаційність і відповідність культурі компанії. Кандидати часто забувають: ця розмова — не формальність, а тест на зрілість. ⚠️ Типові причини відмови Ти не можеш чітко пояснити, чому саме ІТ і чому цей напрям. Ти не розповідаєш, що вже робив, а лише підкреслюєш, чого не знаєш. Ти виглядаєш пасивним або невпевненим, не ставиш питань і не проявляєш зацікавленості в компанії. Ти знецінюєш попередній досвід (“це неважливо, я тепер у ІТ”). ✅ Як діяти Підготуй чітку історію переходу: хто ти був, чому вирішив змінити сферу, що зробив для цього і які результати отримав. Говори про свій бекграунд як про силу, а не як про тягар. “Раніше працював у фінансах, тому уважність до деталей допомагає мені як тестувальнику.” Став запитання: “Як виглядає адаптація новачків у вашій компанії?”, “Які є шляхи росту?” 💬 Рекрутер шукає людей, які хочуть не просто роботу, а розвиток. Етап 3. Відмова після тестового завдання Цей етап показує, як ти мислиш і як ставишся до роботи. Як мислить техлід Тестове — це не про “ідеальний код”. Це про відповідальність, логіку та ставлення до задачі. Навіть якщо рішення неідеальне, але зрозуміле, акуратне й пояснене — це плюс. ⚠️ Типові причини відмови Затримка з виконанням без попередження. Відсутність опису або коментарів. Техлід не розуміє твоїх рішень. Ігнорування вимог. Наприклад, попросили зробити адаптивний інтерфейс, а ти зробив лише десктоп. Плагіат або шаблонні рішення. Досвідчені розробники бачать це миттєво. ✅ Як діяти Якщо не встигаєш — попередь заздалегідь. Це професійно. Додай короткий README: які технології використав, чому саме так, які були складнощі. Не бійся показати процес: краще пояснити логіку, ніж залишити “ідеальний, але непрозорий код”. 💡 Тестове завдання — це твій шанс показати недосконалість, а потенціал співпраці. Етап 4. Відмова після технічної співбесіди Це етап, де “вилітають” навіть найсильніші. Тут важливо не лише знати, а й уміти мислити вголос. 💥 Що оцінює техлід Чи розумієш ти принципи, а не лише визначення. Як реагуєш на складні або невідомі питання. Як мислиш під тиском. Наскільки комфортно з тобою спілкуватися як з колегою. ⚠️ Типові помилки Відповіді “з книжки”, без розуміння контексту. Агресивна реакція на фідбек або виправдання: “Так мене вчили”. Мовчання, коли не знаєш відповіді. Відсутність питань про команду, продукт, стек. ✅ Як діяти Якщо не знаєш — скажи: “Я не стикався з цим на практиці, але припускаю, що…” Не бійся мислити вголос: техлід хоче почути логіку, а не вгадування. Наприкінці обов’язково запитай: “Чи могли б ви дати фідбек, що покращити?” — це справляє враження зрілості. 💬 Технічна співбесіда — це не перевірка, а діалог. Етап 5. Відмова після фінального етапу Іноді ти пройшов усе: тест, технічну, фінальну розмову — і все одно отримуєш відмову. 💥 Що може бути причиною Компанія обрала кандидата з трохи більшим досвідом. Ти не зовсім підходиш під “культурний фіт” — не стиль роботи команди, не співпадає енергія. Твоя комунікація була занадто формальною або, навпаки, надто емоційною. Іноді це не означає, що ти “поганий”. Це просто невідповідність середовищу, і вона взаємна. ✅ Як реагувати Подякуй за можливість. Запитай, чи можеш отримати фідбек — короткий, конкретний. Не сприймай це як провал, а як інформацію для зростання. 💡 Іноді «ні» зараз — це «так» через кілька місяців, коли з’явиться інша позиція. Висновок Кожна відмова — це дзеркало. Воно показує не те, що ти “недостатньо хороший”, а те, де ще можна рости. Ніхто не будує кар’єру без відмов. Але ті, хто аналізує, робить висновки і вдосконалює себе після кожного етапу — у підсумку отримують не просто роботу, а впевненість у власній професійності. Не бійся фрази «ми обрали іншого кандидата». Бійся одного — не зробити висновків і не використати шанс стати кращим.

Зміна професії це завжди виклик, для кожного з нас, і якщо ви вирішили перейти в ІТ з іншої сфери, вас чекатиме ряд випробувань. Але найскладніший етап — це перша співбесіда. Часто світчери (career switchers) хвилюються: «Що сказати про себе, якщо я не маю комерційного досвіду? Чи буде мій попередній бекграунд корисним у новій сфері?». Насправді правильна самопрезентація може стати вашим головним козирем. Чому самопрезентація критично важлива Рекрутер чи техлід під час знайомства не просто оцінюють ваші знання. Вони хочуть зрозуміти, як ви мислите, чи бачите свою цінність і чи зможете інтегруватися в команду. Якщо ви самі сумніваєтесь у собі, це буде помітно. Але якщо вміло подати свій попередній досвід і навчання, ви отримаєте плюс навіть там, де ще бракує технічних навичок. Типові помилки світчерів Знецінення минулого досвіду  ❌ «Я працював бухгалтером, але це неважливо, бо тепер я хочу в ІТ».  — Так ви показуєте, що не вмієте інтегрувати минулі знання у новий контекст.   Занадто загальні відповіді  ❌ «Я вивчив JavaScript і хочу розвиватися».  — Це звучить однаково у десятків кандидатів, немає індивідуальності.   Надмірний акцент на відсутності досвіду  ❌ «Я ще не працював в ІТ, тому можу бути не дуже компетентним».  — Така фраза одразу знижує довіру. Успішні приклади самопрезентації 🔹 Приклад 1. Перехід з фінансів у тестування (QA) «Я понад 5 років працював у фінансовій сфері, де відповідав за аналіз великих обсягів даних і точність звітності. Ця робота навчила мене уважності до деталей, відповідальності та структурного мислення. Під час навчання на курсах QA я побачив, що ці навички напряму застосовуються у тестуванні: знаходження помилок, перевірка відповідності результатів очікуванням, складання зрозумілої документації.  Зараз у мене є кілька власних проєктів на GitHub, де я створював тест-кейси та проводив ручне й автоматизоване тестування. Я прагну застосувати ці навички у професійній команді, допомагаючи підвищувати якість продукту й розвиватися як спеціаліст». 👉 Чому це працює? Кандидат не відкидає минулий досвід, а показує його як сильну базу. Він доводить, що аналітичність і точність із фінансів чудово перетворюються на цінність у QA. 🔹 Приклад 2. Перехід з освіти у FrontEnd «Я 7 років працювала викладачем англійської мови. Моя робота була пов’язана з тим, щоб складне робити простим: пояснювати граматику, будувати зрозумілі приклади, допомагати студентам не губитися в деталях. Коли я почала вивчати веброзробку, зрозуміла, що ці навички напряму допомагають створювати зручний інтерфейс — коли користувач швидко розуміє, як працює сайт чи додаток.  За останні пів року я опанувала HTML, CSS і JavaScript, створила кілька pet-проєктів: сайт-візитку, блог і невеликий інтернет-магазин. У процесі я навчилася працювати з Git та базовими інструментами командної роботи. Зараз хочу стати частиною команди, де зможу зростати як FrontEnd-розробник і створювати продукти, якими зручно користуватися людям». 👉 Чому це працює? Кандидатка підкреслює soft skills із минулої професії (уміння пояснювати складне, робота з людьми), а також демонструє вже зроблені кроки у сфері ІТ (технології, проєкти). Це створює образ людини, яка вчиться й уже приносить користь. 🔹 Приклад 3. Перехід із продажів у Python-розробку «Упродовж 4 років я працював у сфері продажів, де щодня спілкувався з клієнтами, шукав рішення їхніх проблем і домовлявся про результат. Цей досвід дав мені сильні навички комунікації, роботи під тиском і досягнення цілей. Коли я почав вивчати Python, зрозумів, що такий підхід допомагає і в розробці: потрібно аналізувати задачу, знаходити оптимальний шлях і пропонувати рішення.  За останній рік я пройшов кілька курсів, створив чат-бота, веб-додаток і систему для збору даних. Усі проєкти виклав на GitHub. Мені подобається розв’язувати завдання, які роблять життя людей простішим, і я хочу застосувати свої технічні навички та комунікаційний досвід у продуктовій команді». 👉 Чому це працює? Кандидат показує, що досвід у продажах дав йому soft skills, які роблять розробника сильнішим: вміння слухати клієнта, досягати результату й працювати під тиском. При цьому він підтверджує технічну підготовку власними проєктами. Як будувати свою відповідь Використовуйте просту формулу: Минуле — чим ви займалися раніше і які навички можна перенести в ІТ. Теперішнє — що ви вже зробили для переходу: курси, проєкти, сертифікати. Майбутнє — чого хочете досягти та чому саме ця компанія для вас цікава. Приклад:  «У минулому я працював у продажах і розвивав комунікативні навички. Це допомагає мені зараз у роботі з командою й клієнтами. Протягом останнього року я вивчав Python, створив кілька проєктів (чат-бот, веб-застосунок), виклав їх на GitHub. У майбутньому хочу стати частиною продуктової команди, де можна рости до ролі мідла та брати участь у створенні складних сервісів». Що оцінює рекрутер і техлід Рекрутер дивиться на вашу мотивацію, здатність вчитися, комунікабельність. Йому важливо, щоб ви вписалися в культуру компанії.   Техлід більше цікавиться вашими технічними знаннями та логікою мислення. Але якщо ви зможете показати структурність, уважність і бажання рости, це буде величезним плюсом навіть на початковому рівні. Практичні поради Підготуйте 2–3 приклади з минулого досвіду, які можна «перепакувати» в ІТ-контекст (аналітика, робота з людьми, управління проєктами, точність).   Обов’язково покажіть pet-проєкти: сайт, застосунок, бот, тести. Це доказ, що ви не тільки вчилися, а й практикувалися.   Відпрацюйте самопрезентацію вголос. Запишіть себе на відео — ви одразу побачите, де звучите невпевнено.   Додайте трохи особистої мотивації: «Я свідомо обрав ІТ, бо люблю вирішувати задачі й створювати продукти, якими користуються люди». Не бійтеся, що ваш шлях «незвичний». Саме це і робить вас цікавим кандидатом. У багатьох ІТ-командах цінують різноманітність бекграунду: хтось прийшов із педагогіки, хтось із юриспруденції чи медицини — і кожен приносить у команду нову перспективу. Ваше завдання — не приховувати минулий досвід, а показати його як перевагу. Пам’ятайте: ІТ — це не тільки про код, а й про вміння мислити, комунікувати, працювати в команді. ✨ Правильна самопрезентація — це місток між вашою попередньою сферою та новою професією. Якщо ви вірите у свій шлях і вмієте це донести, роботодавець теж у вас повірить.

Junior 1.1 Общие вопросы и Linux. 1.2 Networks, Clouds. 1.3 Automation, Information Security. 1.4 Виртуализация, CI/CD, Development. 1.5 Monitoring/Logging. 1.6 Практические задания. Middle 2.1 Linux. 2.2 Networks. 2.3 Container orchestration. 2.4 Виртуализация и контейнеризация. 2.5 CI/CD, Clouds and Automation. 2.6 Monitoring/Logging. 2.7 Information Security. 2.8 Development, Databases. 2.9 Практические задания. Senior 3.1 Linux. 3.2 Networking, Разное. 3.3 Container orchestration, Clouds and Automation. 3.4 CI/CD, Information Security. 3.5 Observability, Databases. 3.6 Практические задания.     Дорогие друзья! Предлагаем вашему вниманию перевод статьи, опубликованной на DOU.ua 7 декабря 2021 года. Оригинальная версия на украинском языке доступна по ссылке. Можно спорить о популярности DevOps, а можно просто готовиться к собеседованию и получить желанные 9K :) Чтобы помочь вам сориентироваться в вопросах, которые задают на интервью, мы поговорили с теми, кто их проводит, и составили список возможных вопросов.   Junior   Общие 1. Что такое DevOps? 2. Вы набираете google.com в браузере. Расскажите как можно подробнее, что происходит в это время? 3. Как работает HTTPS? 4. Объясните концепцию Infrastructure as Code, зачем это нужно и какие проблемы решает?   Linux 5. Опишите общую архитектуру операционной системы. 6. Опишите основное предназначение операционной системы. 7. Зачем нужны файловые системы? Какие существуют? 8. В чем разница между виртуализацией и контейнеризацией? 9. В чем преимущества контейнеров? 10. Какова файловая структура в Linux (UNIX) системах, расположенных в /etc, /dev, /proc, /sys, /lib, /var (несколько директорий на выбор)? 11. Что такое Load Average? 12. В чем разница между soft и hard symlink? 13. Как работают file permissions, зачем директории права исполнения (+x)? 14. Что такое zombie process? 15. С помощью чего можно собрать информацию о текущем состоянии процессора, памяти, диска, сети? 16. Что такое swappiness? 17. Как посмотреть свободное место на диске? 18. Что такое inode? 19. Расскажите поэтапно процесс загрузки Linux с момента включения питания компьютера. 20. Что произойдет при выполнении команд: 1. cat file1 > file2 2. cat file1 >> file2 21. В чем разница между Ctrl+C и Ctrl+Z? 22. Как перенаправить одновременно stderr и stdin? 23. Как убить процесс? Какие есть типы сигналов? 24. Что делает команда grep? 25. Что такое скрипт bash? 26. Какие типы переменных используются в bash? 27. Что выведут команды: 1. echo ${hostname}; 2. echo $(hostname);   Networks 28. Что такое модель OSI, TCP/IP? 29. Для чего нужны network masks? 30. Структура IP-пакета. Из чего состоит? Что такое фрагментация и почему она происходит? 31. Что такое коллизия? Почему возникает? 32. Что такое прокси? 33. Что такое firewalls и зачем они нужны? 34. Что такое NAT и для чего он нужен? 35. Какие типы IP-адресов вы знаете? 36. По какому порту и протоколу работают Ping и Traceroute?   Clouds 37. В чем разница между IaaS, PaaS и SaaS? 38. Что такое VPC и из каких компонентов должно состоять? 39. Что такое cloud-init? init/systemd/upstart configs?   Automation 40. Что такое IaaC и зачем он нужен? 41. Что такое Terraform? 42. Какие инструменты автоматизации вы знаете?   Information Security 43. В чем разница между аутентификацией и авторизацией? 44. Сертификаты. Как работает HTTPS? Что такое certificate ciphers? 45. Как безопасно передать данные своему коллеге? 46. ​​Что такое MFA, TOTP?   Виртуализация 47. В чем разница между виртуализацией и контейнеризацией? В чем плюсы и минусы? 48. Как при запуске Docker-контейнера «повесить» его из 80-го порта в контейнере на 8081 на хост? 49. Как передать в виртуальную машину USB device? 50. Docker-контейнер потребляет многие SWAP. Что делать?   CI/CD 51. Что такое Continuous Integration и Continuous Deployment? В чем разница между Continuous Deployment и Continuous Delivery? 52. Опишите основные этапы CI/CD. 53. Опишите пример процесса CI (и/или CD), который начинается с момента, когда разработчик запушил изменения/PR в Git? 54. Расскажите о разновидностях тестов, которые мы можем использовать в CI пайплайне. 55. Какие инструменты CI вы использовали? Есть ли опыт работы с Jenkinsfile? 56. Какие виды тестов вы знаете и зачем они нужны?   Development 57. Git. Как решить merge conflict? Что такое rebase, cherry-pick? 58. В чем разница между git merge и git rebase? 59. Какие UI использовали? 60. Какая разница между GitLab/GitHub/Bitbucket? 61. Какая разница между Git pull/Git fetch? 62. Что такое Git-Flow? 63. Версионирование. Какая разница между SemVer и CalVer? 64. Тестирование. Какие существуют виды? Как писать тесты, TDD? 65. В чем разница между компилируемыми и интерпретационными языками программирования?   Monitoring/Logging 66. Какие метрики нужно собирать? Разница между infrastructure и application monitoring. 67. Какая разница между pull и push model в системах мониторинга? 68. Какая разница между Black box и White box monitoring? 69. Расскажите о подходах к сбору application логов.   Практические задания 71. Напишите простую программу на ваш выбор. Программа должна получать сообщения из сервиса очередей и печатать его в stdout. Сервис очередей — по вашему усмотрению. 72. Разберите структуру сервиса (на примере Docker-Compose). 73. Практическая сессия работы с Git (Git command line: fetch, push, pull, rebase, checkout, submodules).   Middle   Linux 1. Опишите архитектуру ядра Linux. 2. Что такое ядро ​​и каково его предназначение? 3. Опишите общие части файловой системы Unix/Linux, архитектуру файловой системы. 4. В чем разница между RedHat и Debian? 5. В чем разница между /proc и /sys? 6. Ситуация: указывает, что на диске занято 50% места, а сделать файл даже под root юзером не можем. В чем проблема? 7. Мы удалили файл, открывший приложение. Как нам его восстановить? 8. Как найти PID процесса, его стартовые параметры? 9. Как проверить, открыт ли порт на удаленном хосте, локальном хосте? 10. Как искать файл по его содержимому? 11. Что такое SSH, как организовать доступ на сервер без пароля или с определенных хостов? Как ограничить доступные для выполнения команды? 12. Как проверить потреблённые ресурсы во время сеанса SSH? 13. Что означает разрешение на файл 755? 14. Что такое SELinux и зачем он нужен? 15. Как определить PCI-устройство в системе, например, RAID controller? 16. Как переименовать устройство, например, сетевую карту или диск? 17. Что такое LVM? Какие знаете примеры использования? 18. Что такое root reserved space? 19. Что такое exit code и как его узнать? 20. Почему вывод df -h указывает, что на диске занято мало места, но система не дает записать файл с сообщением “no space left on device”? 21. В чем разница между command1 & command2 и command1 && command2, а также command1 && command2 || command3? 22. Из сети резко вырос исходящий трафик на 25-й порт. Как, имея доступ на гейтвей, обнаружить вредителя из внутренней сети? 23. Как затюнить параметры Linux Kernel? 24. Что такое ulimits? 25. В чем разница между символическими и hard links? 26. Что такое фрагментация ext3 и ext4? 27. Зачем файловые системы ext* резервируют 5% места? 28. Как увеличить размер файловой системы? 29. Можем ли мы уменьшить размер файловой системы? 30. Что такое chroot и для чего он нужен? 31. У нас есть Linux box с 2 Гб оперативной памяти и Java-приложение, которое пытается выделить 4 Гб во время запуска. Удастся ли это? 32. Есть приложение, которое читает файл, который пользователь пытается удалить. Что случится? Можно ли удалить этот файл? Можно ли восстановить этот файл? 33. Какие механизмы создания процессов в Linux вы знаете? 34. Сравните systemd и init system. 35. У вас есть папка с большим количеством файлов, и вы хотите удалить все файлы с именами, начинающимися на A (прописная буква). Но команда rm –f A* выдает Argument list too long. Как удалить эти файлы? 36. Вы начинаете удалять файлы первым методом из предыдущего вопроса, но каждый rm запрашивает подтверждение. Это очень долго. Как можно ускорить эту операцию?   Networks 37. Расскажите о модели OSI. Опишите функции и назначение каждого уровня. 38. Какие сетевые топологии вы знаете? Опишите разницу между ними. 39. Зачем нужен IP-адрес, если MAC-адрес уникален? Разве мы не можем общаться только по MAC-адресу? 40. В чем разница между концентратором и коммутатором L2 в сетях Ethernet? 41. Что такое VLAN и для чего существует разделение на виртуальные локальные сети? 42. Какой номер порта используется для PING-коммуникации? 43. Что такое сеанс связи? Какой алгоритм использует TCP для доставки? 44. В чем основное отличие между TCP и UDP? 45. Зачем нам маршрутизатор по умолчанию? 46. Как хост решает DNS по умолчанию? 47. Компьютер начал получать IP-адрес из другой сети (есть подозрение, что в сети работает другой DHCP-сервер): как его найти и отключить? Какие методы защиты от такой проблемы? 48. Мы будем мигрировать сайт на новый IP-адрес. Как сделать, чтобы пользователи этого практически не заметили? 49. Что такое socket? 50. Как узнать, какие удаленные хосты подключаются к хосту через порт 8888? (с помощью команд и не используя /proc или /sys). 51. У нас есть несколько сетевых карт. Как увеличить пропускную способность сервера? 52. Как проверить открытые порты на удаленном сервере без команд Netcat или Nmap Linux?   Container orchestration 53. В чем преимущества Kubernetes как платформы? 54. Что такое control plane и из каких компонентов состоит? 55. Какие CNI вы использовали и чем они отличаются? 56. Чем отличается managed Kubernetes от self-deployed? 57. Как можно контролировать размещение подов в кластере? (taints/tolerations, affinities, topologies etc.) 58. Скейлинг кластера. Cluster autoscaler vs HPA vs VPA? Как сделать zero-downtime node decommission/cluster upgrade? PDB? Lifecycle hooks? 59. Какие способы для внешнего доступа к кластеру? ingress, node port, port-forward и т. д. 60. С каким PID запускается процесс в контейнере? 61. Что лучше использовать для изоляции окружения – Vagrant или Docker? 62. Какой инструмент оркестрирования контейнеров использовали? (Swarm, Kubernetes, Openshift, Rancher и т. д.) 63. Что происходит в Kubernetes после запуска kubectl (API, ReplicaSet Controller, storage back-end, scheduler, kubelet, worker node, pod)? 64. Какая разница между pod и контейнером в K8s? 65. Как мы можем сделать любой микросервис, работающий на K8s, доступным из внешней среды?   Виртуализация и контейнеризация 66. Какие типы виртуализации вы знаете? 67. Как работает Docker на macOS/Windows? 68. Что такое Docker-image и Docker-контейнер? Как они между собой связаны? 69. Каковы основные отличия между контейнерами докеров и виртуальными машинами? 70. Что такое image layer? Какое максимальное количество layers возможно? Почему нужно пытаться иметь малое количество layers? Какое оптимальное количество? 71. Как в виртуальной машине изменить размер диска после создания? Что нужно сделать с гостевой ОС? 72. Как в Docker реализовано ограничение ресурсов? 73. Существует виртуальная машина, к которой потерян доступ. Как, имея доступ к диску, восстановить root пароль/SSH-ключ? 74. Оптимизировать Dockerfile, объяснить, что и почему так: FROM golang RUN apt install -y pkg1 pkg2 pkgN # Dependencies for app COPY. . RUN go build -o app main.go CMD ./app 75. Что такое IPVS и какой у него функционал? 76. Какова структура API в Kubernetes? 77. Что такое operators и зачем они нужны?   CI/CD 78. Какие стадии должны быть в любом пайплайне (lint, test, build, deploy etc.)? 79. Как и где хранить build artifacts? 80. Что такое артефакт? 81. Есть два бренча: dev и stage. Мы забросили Dockerfile в dev, а затем сбилдили в dev и stage. Это будет одним артефактом или разными? 82. Что вы использовали для автоматизации настройки Jenkins и GitLab CI? 83. Сравните CI инструментов: Jenkins, GitLab CI, AWS Code Pipeline, GCP cloudbuild, GitHub actions, Circle CI. 84. Deployment strategies. Какие существуют и чем отличаются (recreate, blue-green, canary etc.)? 85. Как реализовать СI/CD для программы, которая зависит от нескольких других программ? 86. GitOps. В чем его преимущества и недостатки?   Clouds and Automation 87. Какова роль и преимущества облачных сервисов для DevOps? 88. Что такое immutable infrastructure? Как достичь? В чем преимущества и недостатки? Packer, AMI и т. д. 89. Структура Terraform. Как организовать multi-environment project? Terraform workspaces? 90. Лучшие практики по использованию многих Terraform states. 91. Как организовать доступ команде разработчиков к AWS/GCP/Azure? Role-based access, assume role, SSO. 92. Что такое Terraform provider, module? 93. Как версионировать Terraform modules? 94. Когда нужно использовать local-exec и remote-exec? 95. Что такое golden image и как его создать?   Monitoring/Logging 96. Как мониторинг помогает поддерживать всю архитектуру системы? 97. Какие инструменты мониторинга вы использовали? 98. Что такое медиана и процентиль? 99. Что такое SLI, SLO, SLA? Зачем это нужно? 100. Архитектура системы для сбора логов, ELK, EFK etc. Как сохранить логи при отказе хранилища? Нужно ли использовать для этого брокер сообщений? Нужно ли делать throttling/rate limits? 101. Prometheus long-term storage. Какие варианты? 102. Как работает Prometheus? 103. В чем принципиальное отличие между Grafana и Kibana? 104. В чем главное отличие между Ansible and Terraform? 105. Что такое SAAS monitoring и какие виды знаете? 106. Если вы используете Datadog/NewRelic, то как нам отслеживать падение инструментов мониторинга? 107. Что такое distributed tracing и error tracking systems? Как вы думаете, когда следует их использовать?   Information Security 108. В чем разница между RBAC и ABAC? 109. В чем заключается XSS атака? SQL injection? Что такое CSP? 110. Какие базовые меры можно предпринять для защиты SSH-соединения? 111. Root-пароль неизвестен или потерян. Какова процедура восстановления? 112. Как управлять правами на файловой системе в Linux? 113. Что такое Firewall? 114. Чем отличается stateless от stateful фаерволов? 115. Сколько таблиц в iptables? 116. Можно ли настроить трансляцию NAT с помощью iptables? Какую таблицу следует использовать? 117. Какую таблицу используют для смены заголовков пакетов? 118. Если вам ломают Linux-сервер, то как более эффективно блокировать трафик с IP-адресов? 119. Принцип работы GCP Firewall: можем ли мы профильтровать трафик на Load Balancer? 120. Что такое SELinux? 121. Можно ли полностью отключить SELinux на лету? 122. С какими secrets management systems вы работали? 123. У нас есть сервер NAT, и мы хотим обеспечить доступ по IP к серверу снаружи. Как нам это реализовать? 123. Чтобы попасть на сервер клиента, нужно залогиниться на 4+ jump хоста. Как автоматизировать? Где мы будем хранить наш SSH-ключ?   Development 125. Что такое cookies? Зачем нужны? JWT? 126. Что такое feature toggles и зачем они? 127. Что такое TDD (Test Driven Development) и BDD (Behaviour Driven Development)?   Databases 128. Что такое индекс и что такое ключ? 129. Каковы преимущества и недостатки индексов? 130. Представьте, что вы разрабатываете систему биллинга, которая должна обрабатывать тысячи счетов. Какую стратегию обновления данных вы бы выбрали? 131. Какие методы чаще всего используют для масштабирования реляционных баз данных? 132. Опишите механизм транзакций БД. 133. Как мы можем удалить таблицу или базу данных? 134. Как найти медленные запросы в MySQL/PostgreSQL? 135. Какие SQL-операторы манипулирования данными вы знаете? 136. Можно ли вывести список баз данных/таблиц через CLI? Как мы можем переключаться между базами данных MySQL/PostgreSQL? 137. Какие storage engines в MySQL вы знаете? Какие отличия? 138. Как реализована репликация MySQL master-master? Сколько серверов MySQL может быть задействовано в таком взаимодействии? 139. Как работает репликация MySQL/PostgreSQL? Какие параметры должны быть настроены для репликации? 140. Сравните SQL и NoSQL. 141. Sharding vs replication? 142. Какие есть виды индексов? Когда и зачем использовать? 143. Требования к схеме БД. Character sets, collations, default, not null и т. д. 144. Мы мигрируем MySQL/PostgreSQL из on-prem в облако. Как нам это сделать с минимальным даунтаймом? 145. Зачем и как тестировать перформанс баз данных?   Практические задания 146. Напишите Terraform module для инфраструктуры тестового сервиса в AWS. 147. Напишите hello-world программу на ваш выбор и сформируйте для нее helm chart/kustomize. 148. Как организовать деплой без downtime? 149. Опишите способы troubleshooting для Docker-контейнера. 150. Разобрать и объяснить структуру CI/CD pipeline (на примере gitlab.yml). 151. Продемонстрируйте навыки работы с GitOps, опишите деплоймент простенькой программы. 152. Как организовать деплой веб-приложения, запущенный на нескольких серверах без (или с минимальным) downtime? 153. Как с помощью Ansible узнать default gateway для пула серверов, и, если он отличается от желаемого, записать строчку «hostname: gateway» в файл на локальной машине?   Senior   Linux 1. Что может создавать высокую нагрузку на CPU (процессы приложений потребляют очень мало ресурсов CPU)? 2. У нас нет команд ifconfig, ip, и поставить мы их не можем. Как нам узнать ip address, mask, network, routes? 3. Что такое suid, sgid и sticky? 4. Что тюнилось с системой для нагрузки трафика 1GB, 10G, 40G+? 5. Что тюнилось с системой для высокой нагрузки на диск? 6. Что такое Linux namespaces? 7. Что такое Ceph, как работает? 8. Что нужно тюнить для Ceph? 9. Что произойдет, если /dev/sda1 перенесем в /root? 10. Мы удалили /dev/sda1. Как нам его восстановить? Что такое pseudo-devices? 11. Нам хакнули сервер, и в директории /var/www создали два миллиона файлов небольшого размера. Если использовать команду cd /var/www и затем rm -rf*, то у нас зависнет терминал. Как удалить файлы? 12. На каком уровне работает iptables? 13. Что такое eBPF и зачем нужен? 14. У вас есть файл, содержащий IP-адреса серверов (по одному в строке). Есть SSH доступ к этим машинам, и вам нужно выполнить задание (например, установить список пакетов на все узлы). Объясните, как можно это сделать.   Networking 15. В чем отличия между IPv4 и IPv6? Зачем мы мигрируем на IPv6? 16. Сосуществование IPv4 и IPv6: что это значит? 17. Действительно ли работают межсетевые экраны с поддержкой IPv6? 18. Как работает DHCPv6? Чем она отличается от DHCPv4? 19. Как фрагментируются пакеты IPv6 и чем это отличается от IPv4? 20. Нужно ли с IPv6 больше использовать NAT? 21. Что такое DPDK? 22. Что такое SR-IOV? В чем разница между DPDK и SR-IOV? 23. Что такое NetFlow и зачем нужен? 24. Что такое OpenFlow? 25.Что такое SDN и какие контроллеры вы знаете? Сравните контроллеры.   Разное 26. Что такое SDLC? 27. Расскажите о последнем опыте реализации архитектуры для сервиса. 28. Какой самый тяжелый скрипт писали? 29. Что такое configuration drift? Почему это происходит и как это усложняет жизнь инженерам\SRE\Ops? 30. Расскажите об архитектуре, за которую вы отвечаете, и укажите, как она масштабирована и отказоустойчива. 31. Назовите три важных KPI для DevOps-специалиста. 32. Как работает Kafka (clusters(brokers, controllers), topics, partitions)? 33. GitOps: Rancher Fleet vs Flux vs Argo? 34. Как использовать GitOps для обновления документации DevOps-приложений? 35. Расскажите об особенностях проектирования Kubernetes on-premise. 36. Как организовать On-call процесс для команды DevOps? 37. Опишите главные шаги загрузки операционной системы Linux.   Container orchestration 38. Service mesh. Что это такое и зачем нужно? 39. Cluster federation. Что это такое и зачем нужно? 40. Pod fine-grained access. Как реализовать? IRSA vs kube2iam vs kiam? 41. Как реализованы услуги в кубернетах? 42. Как дебажить трафик контейнера? 43. Что такое unikernel и зачем он нужен? 44. Почему коммьюнити переезжает из Docker containerd?   Clouds and Automation 45. Какие преимущества и недостатки cloud-провайдеров? 46. Cost оптимизация. Какие инструменты? Spot/preemptible instances, reservations? 47. Как организовать multi-account, multi-region cloud setup? 48. В чем разница между частными и публичными сетями в AWS? 49. AWS Lambda: имели ли опыт работы? 50. Когда следует переходить на AWS Lambda? Когда не стоит? Аналогичные решения в GCP или Kubernetes? 51. Когда лучше использовать CloudFormation, а когда Terraform?   CI/CD 52. Что такое state в контексте использования Terraform? 53. Какие существуют branching strategy? На что опираться при выборе? 54. Как реализовать feature/dynamic environments? 55. Как сделать эмуляцию ресурсов cloud-провайдера для локального тестирования и ускорения разработки? 56. Что такое MultiCloud? 57. Что такое Cloud-Agnostic и когда он потребуется? 58. Что такое Hybrid-Cloud и с какими решениями вы работали?   Information Security 59. Как должны храниться пароли в базах данных (Salt&Pepper, Rainbow Tables, Adaptive Hashing)? 60. Как передавать секреты в application (Secrets management)? 61. Сравните CI/CD SAST и DAST? 62. Какие вы знаете Kubernetes security practices? RBAC? OPA? Какие недостатки RBAC и какие кейсы знаете? 63. Расскажите о защите от DDOS атак, WAF. 64. Что такое Rootless containers и для чего он нужен? 65. Что такое AppArmor и Seccomp и зачем они нужны? 66. Приходилось ли работать с Falco? Если да, то что реализовывали? 67. HashiCorp Vault и как правильно передать нам секреты в контейнере и CI pipeline? 68. Что такое Admission Controllers и какие вы использовали? 69. Как хранятся секреты etcd? Как просмотреть ресурсы в etcd? 70. Чем проверяете на уязвимости ваш Kubernetes cluster? 71. Что такое Secure SDLC? 72. Что вы знаете о Cloud Infrastructure Attack via a Pull Request и как этого избежать?   Observability 73. Что такое observability и чем отличается от обычного мониторинга? Какие особенности необходимо учитывать в микросервисной архитектуре (tracing)? 74. Что такое SLI, SLO, SLA и зачем они нужны? Для чего используют error budget?   Databases 75. Что такое теорема CAP? Зачем это нужно? 76. Как работать с миграциями? Что делать в случае rollback? Как проверить, что миграция backward-compatible? 77. Опишите, как бы вы оптимизировали работу базы данных? (БД по выбору кандидата) Slow queries, buffers, thread pools? 78. Зачем нужно тестировать перформанс базы данных и какими инструментами?   Практические задания 79. Представьте, что вы CTO Booking или Airbnb. Какие бы вы принимали решения касательно: языков программирования. Infrastructure as a Code. архитектуры инфраструктуры. настройки CI/CD. 80. У вас есть файл, содержащий патчи в директории. Например: /var/tmp/temp/file1.c /var/tmp/file.ext /var/tmp/temp/ etc... один путь в строке. Если путь заканчивается на '/' — это путь в каталог. Вам нужно восстановить это дерево каталогов с пустыми файлами в другой файловой системе. Напишите bash-скрипт. 81. Представьте, что вам нужно убедить Spotify, использующего AWS, перейти на GCP. Как вы будете мотивировать Spotify мигрировать на GCP? 82. Есть сервисная компания, предоставляющая сервис трекинга перевозок. Есть клиенты, которые не желают, чтобы их данные процессировались в AWS. Как нам реализовать multi-cloud solution?   Редакция DOU выражает благодарность за помощь в подготовке статьи: Владу Волошину, Павлу Петриченко, Виталию Гарбулинскому (BrightLocal), Евгению Думе, Сергею Яремчуку, Вадиму Шкилю, Александру Билюку, Александру Нежинскому, Владиславу Граму, Станиславу Коленкину, Олегу Миколайченку, Антону Гаврилову.

Тип сайта и его тематика Функциональность сайта На сегодняшний день более половины всех сайтов в сети Интернет используют ту или иную систему управления контентом (Content Management System – CMS). Однако термин CMS не получил, к сожалению, четкого определения. Он может иметь несколько значений в зависимости от сценариев и целей человека или проекта. Некоммерческая международная организация AIIM (Association for Information and Image Management - Ассоциация по вопросам Управления Информацией и Изображениями) ввела в обиход понятия ECM (Enterprise Content Management) и WCM (система управления веб-контентом) как две составных части CMS.  В этом случае под ECM подразумевается программный комплекс, обеспечивающий документооборот, работу внутренней базы знаний и организующий в общем виде набор бизнес-процессов предприятия. Как одну из функций ECM может включать в себя и работу с веб контентом. Хорошим примером такого типа систем является платформа Microsoft SharePoint. В свою очередь WCM стало включать в себя набор инструментов в некотором комплексе, позволяющем управлять веб-сайтом и контентом на нем. Часто также CMS также называют «движком» сайта. В обиходе у разработчиков устоявшимся значением, подразумеваемым под CMS, является некоторая программная система, применяемая для создания, редактирования и управления контентом сайта и устанавливаемая на свой хостинг. В дальнейшем, в этой статье мы примем за основу именно это - последнее определение, более похожее на WCM. Стоит отметить и часто включаемые в число CMS так называемые SaaS решения (software as a service – услуга доступа к программному обеспечению). В случае такого типа услуг компании не предоставляют код, который вы можете скачать, установить и настроить под себя на своём хостинге. Провайдеры услуги SaaS предлагают для клиентов свои платформы, со своим хостингом, своими индивидуальными возможностями без предоставления CMS в обиходном понимании. При такой схеме вы фактически оплачиваете не владение вашим сайтом, а его аренду. В нашей статье мы не будем рассматривать такой тип услуг.   Рассмотрим подходы, которых следует придерживаться, решая вопрос как выбрать движок для сайта.   Критерии выбора CMS для вашего сайта Тип сайта и его тематика Большой выбор различных систем управления контентом на рынке объясняется различиями в типах сайтов, для которых лучше всего конкретная CMS подойдет. Будет это форум или интернет магазин, блог или корпоративный сайт, сайт-визитка или новостной портал – определенность с тематикой сайта это первое, от чего будет зависеть правильный выбор CMS. Функциональность сайта Не смотря на определенную специализацию каждой CMS под определенные задачи, на сегодняшний день для ТОП CMS существует огромное количество различных расширений (плагинов, модулей), существенно увеличивающих их функциональность и возможности «донастройки». К примеру существующими плагинами можно превратить «блоговый» движок в интернет-магазин, а на движке портала сделать форум. Однако нужно понимать, что большое количество дополнительных плагинов будут влиять и на быстродействие, и на безопасность, и на внутреннюю слаженность работы механизмов сайта, из-за возможных конфликтов этих расширений. Также определенный набор проблем может доставить и необходимость регулярных обновлений как самого движка, так и установленных плагинов. Без таких обновлений у вас будут открываться дыры в безопасности, а это вряд ли вам понравится. А обновление большого числа расширений может вызвать конфликты совместимости. Поэтому правильный выбор CMS это баланс между нужной готовой функциональностью движка «из коробки» и количеством (и качеством) установленных расширений. Исходя из задач и потребности в балансе, сложно однозначно ответить на вопрос «какая CMS лучше?». Требовательность к ресурсам Правильный выбор тематики сайта приводит к необходимости выбора условной «мощности» движка. «Мощнее», в нашем случае, вовсе не обязательно значит – «лучше». Если вы нуждаетесь, к примеру, в сайте-визитке, установка движка портала для вас будет избыточной. Значительная часть ресурсов мощной CMS останется не задействованной. При этом требования к хостингу такого сайта будут выше – вам понадобится больше оперативной памяти, больше ресурсов процессора, могут понадобиться некоторые специфические настройки сервера и предустановленное программное обеспечение. Также стоит понимать, что, к примеру, сайты администрации для поселка и для города миллионника хоть и имеют общую тематику, но будут иметь разный дизайн, функциональность, наполнение, разную посещаемость и, соответственно, разные требования. Поэтому, при выборе вам следует исходить и из масштабов вашего будущего сайта. Неправильный выбор выльется либо в необоснованное удорожание и хостинга, и администрирования вашего сайта, либо в нехватку ресурсов. Возможность кастомизации движка Многим владельцам сайтов не хватает возможностей «голой» CMS. Кроме того, из-за специфики каждого конкретно бизнеса и каждого конкретного сайта, возможности расширения с помощью дополнительных плагинов тоже может быть недостаточно. Может потребоваться индивидуальная доработка движка, тем оформления или доработка под заказчика тех плагинов, функциональности которых не вам хватает. В этом вопросе нам очень важно будет понимать следующие моменты: Количество разработчиков на рынке – специалистов по конкретной CMS; Количество и качество документации к CMS и плагинам; Развитость сообщества пользователей и разработчиков конкретной CMS. Можно с уверенностью сказать, что чем более распространён движок – тем больше доступных специалистов, тем проще внести нужные правки и тем дешевле эти правки обойдутся. Стоит уделить внимание и особенностям SEO-оптимизации конкретного движка. Если вы хотите, чтобы аудитория вашего сайта росла, вам придется соответствовать ряду правил, касающихся и скорости работы сайта на различных типах устройств, и внешнего дизайна сайта вообще и конкретных страниц в частности, и внутренней иерархии страниц, и правильной настройки индексации и т.п. Возможность проведения SEO оптимизации вашего сайта сложно переоценить.  Наличие уже встроенных в CMS SEO инструментов или доступных качественных плагинов, а также возможность доработки их под ваши нюансы проекта привлеченными разработчиками, будут очень важны на этапе продвижения вашего сайта. Стоимость CMS и доработки. На рынке сегодня присутствуют как качественные бесплатные, так и значительное количество различных платных CMS. Кроме того, выбирая бесплатные CMS, вам вероятно захочется добавить в них платные расширения.  Выбирая между платными и бесплатными вариантами вам стоит заранее определиться с несколькими моментами: Представить себе (хотя бы приблизительно) стратегию развития вашего сайта. От понимания дальнейших перспектив будет зависеть комбинация доступных расширений и необходимость их доработок. Может так сложиться, что выбор бесплатной CMS, с учетом плагинов и доработок для получения нужного функционала, окажется существенно дороже, чем купить платную CMS и платный плагин, получив при этом техническую поддержку разработчиков этой CMS. Также может оказаться, что нужный для вас плагин под конкретную CMS нужно будет разрабатывать с нуля, тогда как под другую CMS такой плагин есть уже готовый, давно выпущенный и протестированный в реальной работе.   Распространенность CMS и ее востребованность Если выбранный вами движок сайта окажется непопулярным и его разработчики решат перестать выпускать обновления, вы столкнетесь с рядом проблем. Это и падение уровня безопасности системы, и ухудшение внешней привлекательности на фоне новых сайтов-конкурентов, использующих новые технологические решения. Также существенно сложнее будет найти специалиста для внесения доработок в движок, использующий уже устаревшие и непопулярные технологии. В свою очередь выход новейшей версии движка может быть связан с кучей багов системы, наличия новых дыр безопасности, несовместимости со старыми плагинами и другими сложностями. Самописные движки Наличие такого числа сложностей при выборе системы управления для своего сайта может вызвать у вас желание заказать или написать свой сайт с нуля. Действительно, ряд проектов прямо потребует от вас такого подхода. Подключение к своим специфическим сервисам, интеграция с другими уникальными проектами, гибкость в дизайнерских и архитектурных решениях – в определенных обстоятельствах написание своего движка будет правильным решением. Однако стоит сразу учитывать набор проблем, с которыми вам предстоит столкнуться: Подсадка «на иглу» одного разработчика. Полноценно разбираться в куче кода, с слабо или вовсе недокументированными возможностями, сможет только сам автор кода. Новому разработчику может оказаться проще переписывать модули вашего сайта с нуля, чем тратить время на разбор чужого кода. Это с одной стороны существенно удорожит работу, а с другой жестко привяжет вас к конкретному разработчику. Даже сменив одного программиста на другого, вы оказываетесь в той же ситуации, только теперь с новым разработчиком. Сроки и цена разработки. Написание нужных модулей «с нуля» будет стоить значительно дороже и займет значительно больше времени, чем адаптация уже существующего движка и плагинов с хорошей документацией от авторов. Проблемы тестирования и ошибок. В движках, которые используют каждый день миллионы человек, есть значительный плюс – большинство багов выявляются мгновенно и быстро перекрываются обновлениями. Наличие багов в вашей самописной системе будет зависеть как от навыков вашего разработчика, так и от применяемых им технологий. Эта комбинация может нести большое количество скрытых проблем как работоспособности, так и безопасности, которые останутся не выловленными, пока не станет слишком поздно. В результате разработка своего движка оказывается выгодна, практически, только крупным компаниям со своими внутренними отделами разработки и тестирования, которые будут писать свой сайт и поддерживать его работоспособность независимо от сторонних разработчиков. Статистика использования CMS   По данным сайта w3techs.com более 55% всех Web-сайтов в Интернете управляются теми или иными CMS. Как видно из диаграммы более 33% всех сайтов в Интернете работают на движке WordPress. Фактически это более 60% от сайтов, управляемых теми или иными CMS. Следующие по популярности системы CMS: Joomla – 5.4%, Drupal – 3.5%, Magento – 1.8%, PrestaShop – 1.4%. Набравшие в этой диаграмме высокие места Shopify (2.7%), Squarespace (2.7%) и Wix (1.8%) предлагают услуги SaaS (которые мы здесь не рассматриваем). По данным портала WhatСms первое место по числу сайтов среди популярных CMS также принадлежит WordPress - 52.74%. Затем идут Joomla - 5.219%, Drupal - 3.953%, Magento - 2.840%, PrestaShop - 1.671%. Blogger, как и несколько компаний в предыдущей диаграмме, является SaaS платформой. По данным портала BuiltWith первые три места среди не SaaS CMS занимают: WordPress - 28.27%, Joomla – 26.93%, Drupal – 8.84%. По данным портала SimilarTech, предлагающего свой ТОП движков для сайтов, среди 9,5 млн сайтов на CMS также лидирует WordPress, заняв 68% рынка CMS. Слетом идет Drupal (версии 6 и ниже) – 4%, Joomla – 3%, Drupal 7 – 1%, Typo3 – 1%. В число других CMS вошли как SaaS решения, так и другие полноценные CMS, включая и Drupal 8. Проанализировав указанную статистику, мы выбрали следующий 6 ТОП CMS: WordPress, Joomla, Drupal, Magento, PrestaShop и Typo3. Проведем краткий обзор движков для сайтов, входящих в наш ТОП CMS.   1) WordPress Выпущенный впервые в 2003 году, CMS WordPress быстро завоевал популярность как у продвинутых разработчиков, так и простых пользователей. Благодаря простой настройке, не самой высокой требовательностью к ресурсам хостинга и огромному количеству расширений эта CMS уже многие годы занимает первое место. На сегодня именно WordPress называют лучшей CMS для блога. WordPress идеально подходит для довольно простых веб-сайтов, таких как ежедневные блоги и новостные сайты, и для тех, кто ищет для себя простую CMS. Дополнения позволяют легко расширять функциональность сайта. К примеру, благодаря плагину WooCommerce, из сайтов на движке WordPress получается удобный для управления интернет-магазин – один из самых распространенных вариантов интернет-магазинов в сети. Нужно отметить и большое количество SaaS решений, использующих на своей платформе этот движок. Часть успеха WordPress в представленных диаграммах без сомнения относится к SaaS решениям. Официальный сайт WordPress: https://wordpress.org/ Особенности WordPress: Последняя версия - 5.0.3 от 09.01.2019. Написан на PHP. Более старые версии чем 5.0 официально объявлены «небезопасными». Минимальные требования к хостингу, поддержку которых обещает разработчик: PHP 7.3 MySQL 5.6 или MariaDB 10.0; HTTPS; Apache или Nginx. Плюсы WordPress: Бесплатная CMS распространяется с открытым исходным кодом. Огромное количество как платных, так и бесплатных шаблонов, и плагинов. Удобная панель администратора. Простая CMS для пользователя. Отмечают простоту использования и легкость установки как движка, так и тем, и расширений. Большое сообщество. Достаточно высокая производительность. Доступные платные плагины с проверенным качеством. Минусы WordPress: Относительно не маленькая требовательность к ресурсам, особенно при установке значительного числа плагинов. Отсутствие технической поддержки в не SaaS вариантах. Многие плагины написаны некачественно, что создает проблемы в работе и дыры в безопасности. Сайты на WordPress взламывают чаще всего.   Для каких сайтов используют CMS WordPress: Популярность WordPress продолжает расти: При этом в Украине сейчас 34910 сайтов используют эту CMS, а в Российской Федерации - 297353.   2) Joomla CMS Joomla впервые увидела свет в 2005 году. Отражая философию этого движка, его назвали словом, звучащим на суахили как «всё вместе». Фактически разрабатываемая как CMS для порталов, Joomla позволяет создавать сайты с большей гибкостью контента и внутренней структуры, чем WordPress, но при этом с достаточно простым и интуитивно понятным интерфейсом. Эта CMS поддерживает электронную коммерцию, социальные сети и многое другое. Используя этот движок, разработчики создают сайты-визитки, интернет-магазины, фотогалереи, порталы (включая новостные), блоги и другие сайты. Рядом пользователей, Joomla признается лучшей CMS для сайта типа портал. Официальный сайт: https://www.joomla.org/ Особенности движка Joomla: Последняя версия – 3.9.3 от 12.02.2019. Написана на PHP и JavaScript. Минимальные системные требования: PHP 5.3.10; MySQL  5.1 или SQL Server 10.50.1600.1 или PostgreSQL 8.3.18; Apache 2.0 или Nginx 1.0 или Microsoft IIS 7. Плюсы Joomla: Бесплатное распространение с открытым исходным кодом по лицензии GNU GPL v2, включая обновления; Частое предоставление обновлений движка; Большое сообщество пользователей и разработчиков; Большое количество доступных платных и бесплатных тем и плагинов; Относительно не высокий уровень требований к разработчику и пользователю. Минусы Joomla: Отсутствие технической поддержки. Вторая CMS по числу взломов. Joomla применяется в следующих сферах: В Украине 907  сайтов используют эту CMS и 3800 сайтов - в Российской Федерации. Есть определенная тенденция по снижению популярности CMS Joomla: 3) Drupal Впервые вышедшая в 2000 году, CMS Drupal является мощным, удобным для разработчиков инструментом для создания сложных сайтов. Как и большинство мощных инструментов, Drupal требует определенных знаний и опыта для работы. На основе Drupal часто создают порталы, новостные сайты, форумы, интернет-магазины - одни из самых продвинутых сайтов. Тем не менее Drupal является самым сложным для пользователя движков из тройки лидеров. Хотя его использование с каждым выпуском и становится все проще, если вы не готовы погрузиться в изучение этого программного обеспечения или не можете нанять кого-то, кто его знает, возможно, это не лучшая система управления контентом для вас. Официальный сайт: https://www.drupal.org/   Особенности Drupal CMS: Последняя версия 8.6.10; Ядро предоставляет только минимальный функционал, нужный для работы CMS, остальной функционал добавляется за счет плагинов. Установка модулей происходит в связке. Если для реализации функционала какого-то модуля нужны другие модули – они установятся автоматически в связке с первым модулем. Минимальные требования к хостингу для CMS Drupal 8: PHP 5.x/7.x для x86 и PHP 5.x для x64; MySQL 5.5.3 или MariaDB 5.5.20, или Percona Server 5.5.8, или PostgreSQL 9.1.2, или SQLite 3.6.8; Microsoft SQL Server и MongoDB поддерживаются благодаря отдельным модулям; Apache 2.x (используется в качестве Web-сервера для Drupal чаще всего) или Nginx (0.7.x, 0.8.x, 1.0.x, 1.2.x), стабильная версия 1.8.x или 1.9.x. Плюсы Drupal: Бесплатная CMS с открытым исходным кодом GNU GPL 2+. Стабильная работа ядра движка. Большое количество бесплатных тем, и различных расширений. Достаточно развитое сообщество разработчиков. Для решения типовых задач есть готовые наборы плагинов. Drupal известен своей мощной таксономией и способностью отмечать, классифицировать и организовывать сложный контент. Минусы Drupal: Сложность использования для начинающих пользователей. Меньшее количество доступных бесплатных плагинов чем у предыдущих CMS. Отмечают большую требовательность к хостингу за счет более частых обращений движка к базе данных, чем у других движков. Сегодня эту CMS используют в 7110 сайтов в Украине и 45189 сайтов в Российской Федерации. Можно наблюдать определенное снижение интереса к этой CMS по сравнению с 2016 годом:   4) Magento CMS Magento — движок для интернет-магазинов и других вариантов электронной коммерции. В основном популярен в западных странах и слабо представлен в русскоязычной части Интернета из-за слабой интеграции с местными сервисами. В настоящий момент является собственностью Adobe Inc. В основном Magento используется для крупных проектов. Считается не рентабельным использовать его для магазинов с несколькими сотнями позиций в обороте из-за относительно высокой стоимости разработки. Официальный сайт: https://magento.com/. Особенности CMS Magento: Написан на PHP. Последняя версия 2.3.0 от 28.11.2018. Требования к хостингу: LAMP (Linux, Apache, MySQL, and PHP) или LNMP; Apache 2.x или Nginx 1.7.x; PHP 5.6 или 5.5 или 5.4; MySQL 5.6 (Oracle or Percona); HTTPS; Доступ к crontab и к записи в .htaccess. Плюсы Magento: Бесплатная система с открытым исходным кодом. Движок оптимизирован под требования поисковых систем «из коробки». Готовая функциональность движка в базовой версии. Являясь собственностью Adobe Inc., отлично поддерживает интеграцию с сервисами Adobe. Минусы Magento: Несмотря на открытый исходный код, многими разработчиками считается не удобным работать с этой CMS из-за особенности организации ее кода. В бесплатной версии нет технической поддержки, платная версия будет стоить несколько тысяч долларов в год. Отсутствует интеграция с платежными средствами и другими локальными сервисами на постсоветском пространстве. Низкая скорость загрузки страниц сайта «из коробки». Большая часть настроек сайта потребует специфических знаний и навыков.   В Украине на сегодня 1113 сайтов используют CMS Magento и 1774 используют ее в Российской Федерации. После 2016 года можно наблюдать некоторое снижение числа сайтов на этой CMS:    5) PrestaShop PrestaShop – это еще один пример простой CMS с открытым исходным кодом для создания интернет-магазина. Созданный в 2008 году, этот движок достаточно быстро обрел популярность и продолжает ее наращивать. Это достаточно простая бесплатная CMS создана для организации торговых площадок и интернет магазинов. Официальный сайт: https://www.prestashop.com Особенности PrestaShop: Текущая версия – 1.7.5.1 от 18.02.2019. Написан на PHP с применением фреймворка Symfony. Минимальные требования к хостингу: PHP 5.6; MySQL 5.0; Server RAM – чем больше, тем лучше; Unix, Linux или Windows; Apache 2.2 или Nginx 1.0 или Microsoft’s IIS Web server 6.0. Плюсы PrestaShop: Бесплатный движок с открытым исходным кодом. Большое количество доступных тем оформления и расширений. Достаточный для начала работы интернет-магазина стандартный набор базовой версии движка. Имеет отличную русскую локализацию. Богатый выбор модулей для развития интернет-магазина. Хорошая интеграция с различными сервисами на постсоветском пространстве. Простота установки и работы. Удобная интуитивно понятная панель администрирования. Базовая версия имеет хорошую SEO-оптимизацию. Активные сообщества разработчиков. Минусы PrestaShop: Качественные темы и расширения являются платными. Более требователен к ресурсам чем WordPress. Низкая безопасность у бесплатных тем и плагинов. Наблюдаются баги при проведении внутренней оптимизации. Можно видеть рост популярности CMS PrestaShop. Например, на сегодня уже 2461 сайт работает на этом движке в Украине, и 8423 сайтов - в Российской Федерации.    6) Typo3 Typo3 это CMS с открытым исходным кодом. Впервые этот относительно универсальный движок был представлен в 1998 году. Typo3 часто применяется для новостных порталов, интернет-магазинов, корпоративных сайтов и других вариантов сайтов.   Официальный сайт: https://typo3.org/.   Особенности Typo3: Написан на PHP. Последняя версия 9.5.4 от 22.01.2019. Особенностью Typo3 является то, что в проектах на этой CMS вся информация публикуется от администратора и сайты не работают с пользовательским контентом. Typo3 не приспособлена для создания блога, активно взаимодействующего с пользователем портала или социальной сети. Минимальные требования к хостингу: Linux, Windows или Mac; PHP> = 7.2; PostgreSQL / Microsoft SQL Server / MariaDB >= 10.2 / MySQL >= 5 <= 5.7 / SQLite; Apache httpd или Nginx или Microsoft IIS, Caddy Server. Плюсы Typo3: Простота администрирования сайта. Возможность управления несколькими проектами из одной панели администратора. Возможность создания отдельных разделов на сайте с раздельным доступом для разных типов пользователей. Минусы Typo3: Относительно высокая требовательность движка к ресурсам сервера. Сложность изучения документации. Основная часть материалов не переведена с английского. Также, как и у ряда предыдущих CMS, у Typo3 наблюдается снижение популярности с 2016 года. В свою очередь в Украине на этом движке зарегистрировано 399 сайтов, в Российской Федерации - 1327. Полезным будет рассмотреть и сравнение производительности среди ТОП CMS.   Популярные CMS. Сравнение производительности. Согласно опубликованным данным тестирования ряда CMS, можно сделать вывод о наиболее быстром движке (пусть и в искусственных  - «тепличных» условиях теста). Указанные данные в таблице – это количество обрабатываемых запросов в секунду. Наиболее быстрой в данном исследовании среди популярных CMS показала себя WordPress 5.0 с версией PHP 7.3.   Вывод В нашем кратком обзоре CMS мы рассмотрели ТОП 6 наиболее распространенных CMS в мире. Как мы видим, каждая из них имеет свою специфику и особенности. Из-за разных возможных сфер применения сложно выбрать лучшую систему управления сайтом. Как лучшая CMS для блогов многими пользователями отмечается WordPress, а PrestaShop многими определяется как лучшая CMS для сайта интернет-магазина. Стоит понимать, что большая часть представленных в нашем ТОП CMS движков являются относительно универсальными. Кроме PrestaShop и Magento, ориентированных на интернет-коммерцию, с помощью других движков можно делать разнотипные проекты. Однако многими разработчиками признается, что никакая универсальная CMS не будет работать в конкретной сфере также хорошо, как специально разработанная для этой цели CMS. Поэтому, полезно кроме данного обзора ТОП CMS, рассмотреть отдельно ТОП CMS для блогов, ТОП CMS для интернет-магазинов, ТОП CMS для форумов, и далее. Такие обзоры помогут лучше понять, как правильно выбрать движок для сайта с вашими уникальными потребностями. Как вы могли заметить, рассмотренные CMS из ТОП движков для сайтов написаны на PHP. Если вы определились с CMS для своего проекта и хотите его сами доработать, или просто хотите научиться работать с топовыми проектами сети Интернет - вам, вероятно, будет интересен наш набор курсов  и вебинаров на портале ITVDN: WordPress Starter и WordPress Essential WordPress: создаем блог за час Интеграция верстки лендинга на CMS WordPress PHP Starter How To PHP Starter PHP Essential 

В этой статье вы найдёте несколько полезных советов для тех, кто хочет стать программистом. Совет 1. Определитесь с языком программирования Выбор языка программирования — первая трудность, с которой встречаются новички. Сколько программистов — столько и мнений о языках, поэтому выделить «лучший» среди них нельзя. Почему? Каждый язык создан для определённой области разработки и решения определённых задач. Для выбора языка программирования, ориентируйтесь на ваши желания. Какие программы и сервисы вы хотите создавать? Делать игры на Unity? Сайты на HTML, CSS и JavaScript? Или, может быть, бизнес-приложения на С# или Java? Python широко используется в науке для быстрых вычислений. При выборе учитывайте порог вхождения языка (Python, например, изучается быстрее и легче С++) и ваши предрасположенности. Кроме того, перед изучением любого языка стоит изучить основы программирования. Разберитесь, что такое двоичный код, компилятор, познакомьтесь с алгоритмами и шаблонами проектирования. Совет 2. Применяйте метод дробления материала Если вы решили стать программистом, вам нужно будет очень мнрогое изучить и запомнить. Сделать это «с наскока» будет трудно. Не хваатайтесь за все сразу. Ставьте перед собой небольшие реальные, достижимые цели. Например, изучайте одну тему за 1 день. При изучении любого языка начинайте с самых основ, постепенно продвигаясь вперёд. Закрепляйте пройденный материал практикой, если есть какие-то небольшие пробелы в знаниях — двигайтесь дальше, возможно, вы заполните их потом. Но не оставляйте слишком много «белых пятен», иначе запутаетесь. На помощь в структурировании информации вам придут различные техники запоминания (ассоциации, карточки) и ваш собственный дневник обучения, в котором вы можете записывать усвоенный материал, как говорят, «своими словами», и затем проверять его на практике. Совет 3.  Не стесняйтесь использовать детские обучающие программы и курсы. В детских программах часто подают упрощенные знания, основы основ. Не стесняйтесь пробовать детские игры и курсы, в которых материал усваивается значительно легче. Кроме того, это бываает весело! Прослушав материал в упрощенном виде, вы сможете понять его, и дальнейшее изучение программирования будет даваться вам значительно легче. Кроме того, к временной помощи детских курсов можно прибегнуть, если какой-то участок материала даётся вам с трудом, и понять его вы никак не можете. Прослушав упрощенный материал, вы получите взгляд со стороны и, возможно, наконец сможете понять материал. Совет 4. Разбирайте чужой код Это больше относится к практике. Разбирая чужой код, вы начнёте понимать, почему программа работает или не работает. Перенимая чужой опыт, вы получаете новые знания и фишки, которые помогут вам в будущем. Читая код другого программиста, вы улучшите своё общее понимание программирования и убережете себя от ошибок. Кроме того, разбор чужого кода также может помочь вам сдвинуться с мёртвой точки. Если вам что-то не понятно, то вы можете просмотреть чей-то код и получить его советы. Таким образом, вы сможете понять, как сделать правильно и почему часть программы у другого человека работает правильно, а у вас — нет. Совет 5. Читайте полезную литературу Не смотря на то, что сейчас больше людей предпочитают литературе курсы, статьи и видео, чтение актуальных книг по программированию поможет вам глубже изучить программирование. Некоторые книги вообще являются признанной классикой, например книга Роберта Мартина «Чистый Код» детально описывает процесс создания чистого кода, и указывает на ошибки, которые могут возникнуть при написании красивого кода. Фактически, эта книга — «библия» для тех, кто стремится писать чистый код. Поискав в Гугле другие книги по вашему направлению, вы можете скомбинировать их со справочниками, и получить «универсальный набор» программиста, в котором вы найдёте ответы на большинство своих вопросов. Общепризнанную литературу можно читать в переводе, но большинство актуальной литературы выходит в мир на английском, и переводится на русский с опозданием в год-два, когда уже всё поменялось. Поэтому дополнительный совет: уделите внимание изучению английского языка! С английским вы всегда сможете получать актуальную информацию, общаться с зарубежными программистами, английский облегчит вам изучение программирования в несколько раз, и, возможно, в будущем вы найдете работу в зарубежной компании. Совет 6. Запишитесь на курсы Для некоторых людей самостоятельное изучение программирование может даваться с трудом, ведь рядом нет никого, кто мог бы в любой момент ответить на их вопросы. Многим не понятно, с чего начинать обучение и как структурировать информацию.С наставником и одногруппниками вы будете продвигаться в обучении быстрее. Если вы хотите начать изучать программирование, вам будет интересно посмотреть записи вебинаров ITVDN из серии «С чего начать?», и «Как стать программистом?» . Ваши вопросы вы можете задать, обратившись в службу поддержки ITVDN. Консультанты нашего образовательного ресурса будут рады помочь вам.

Взято с настоящего поля битвы: работы Спустя практически 10 лет работы на Javascript мне захотелось поделиться своими ежедневными секретами написания кода. Многие советы были позаимствованы у моих коллег, из книг или видео. Такие приёмы не должны оставаться в тайне, поэтому я ими и хочу поделиться!   1. Меньше кода = меньше багов Это может прозвучать тривиально, но всегда держите это в уме. Любую часть можно убрать, даже не сомневайтесь! Просто удалите. Неработающий код, неиспользуемые переменные, лишние скобки: каждый малейший знак учитывается. 2. Развивайте читабельность кода Это дополнение к пункту 1. Если хочется сократить код, всегда нужно помнить о том, что рано или поздно код будет прочитан другими людьми. Может, кто-то другой, может, через несколько месяцев, но будет очень неприятно, если придется потратить больше времени на разбор кода, чем было потрачено на его написание. Запомните: код всегда важнее, чем комментарии или документация. Следите за переменными и именами функций, они должны быть достаточно наглядными, чтобы потом не объяснять их в комментариях. 3. Не пугайтесь функций, возвращающих функции Когда я начал кодить на javascript, мне не нравился метод написания кода с использованием функций, возвращающих функции, потому что, казалось, этому сложно следовать в процессе выполнения. Но этот шаблон, довольно мощный и часто используемый, называется замыканием. Это действительно полезная функция и, как только вы используете её, она значительно облегчает структуру кода. И это первый шаг для погружения в функциональное программирование. 4. Извлекание частей Функция становится слишком большой? Сделайте из нескольких частей отдельные функции! Не совсем понятно? Выделите их в переменную и дайте ей понятное имя. Такой метод, конечно, схож со вторым пунктом, но это сделает ваш код более читабельным. А знаете ли Вы, что Ваша среда разработки может помочь? Ctrl + alt + v выражение извлекается в Webstorm и потом выделяется в переменную. Ctrl + alt + m сделает из него функцию. 5. Переверните мышление Это первый шаг перед TDD. Скорее всего, вы всегда знаете, чего хотите достичь. Так начните с конца, напишите ожидаемый результат и пишите код в обратном порядке, чтобы получить то, что хотите. Если будете писать в прямом порядке, вероятней всего, Вы начнете писать и проверять, работает ли оно. Поменяйте, проверьте, напишите что-то другое, проверьте и…. Возможно, это даже не особо полезно для достижения Вашей цели. Но такое мышление поможет сфокусироваться и потратить меньше времени. 6. Исключите условные операторы Если для функции у вас на уме принцип единственной ответственности, условным операторам тут не место. Они создают ветвления в потоке выполнения. И один маленький if позволит другим разработчикам добавить всё больше логики в него. Я считаю, что условные операторы if вообще не должны использоваться без else, а их размещение внутри другого условного оператора нужно полностью запретить! Опять же, такой подход делает код более сложным, и часто оказывается, что функция выполняет больше, чем нужно. Как же от этого избавиться? Смотрите следующий пункт. 7. Используйте lodash_.get вместо проверки null/undefined Очень часто, анализируя код, я вижу использование ifs для проверки null или undefined значений. Но без использования else! То есть идёт работа только с одним путём, а другой путь остаётся местом загадок (и багов!). Тут на помощь приходит Lodash (лучшее, написанное когда-либо на javascript) с его замечательной функцией get. Её первым аргументом является объект, над которым вы работаете, вторым – путь к дочерним атрибутам, которые вы хотите получить, и третьим является значение по умолчанию в случае с undefined. Два преимущества использования всего одной функции! 8. Используйте тернарные операторы Кто-то может поспорить насчёт их читабельности, но если правильно извлекать функции, они станут превосходным инструментом. Они также заставят Вас сотрудничать с else case. Плюс, они не позволяют содержать в себе больше кода. Чем меньше ваш код похож на смертельную пирамиду, тем лучше. 9. Никаких больше for loops, только map, reduce и filter Мы, наконец-то, подошли тут к теме функционального программирования, так как эти методы являются основой этого стиля. Хоть названия или теории не особо известны, они действительно помогут избежать тяжело читаемого императивного стиля для выражений for. Эти методы сейчас уже встроены в большинство браузеров, так что используйте их! Но если вам всё же нужна совместимость, можно использовать lodash аналоги. Итак, когда их использовать? Выражение for, имеющее дело со всеми точками входа – это map for + if , вероятно, filter sum или accumulation -  это просто reduce  С помощью сочетания этих методов вы можете сделать много работы в хорошей и краткой форме. 10. Читайте исходники Если документации недостаточно - читайте исходники! Это поможет Вам узнать, как их использовать и даст неплохое представление об их качестве. Плюс, некоторые библиотеки имеют исходники, встроенные в их документацию. Так с ними даже быстрее можно ознакомиться. С нашей IDE можно часто обращаться к источнику с помощью ctrl + clic на имя метода. Это отличный способ убрать магию и набраться вдохновения для собственного кода!   В заключение хотелось бы сказать, что это те принципы, которые помогают лично мне. Жаль, что я не знал их раньше, например, в школе… Зато ты знаешь их сейчас. И ими можно пользоваться практически в любом контексте. Некоторые из них распространяются не только на javascript, так что пользуйтесь ими где угодно :) Также хотелось бы обратить ваше внимание на великого Uncle Bob и его сайт . Вам определённо стоит посмотреть эти видео, даже несмотря на то, что они по большей части касаются Java, идеи применимы и в Javascript. Переведено с источника.

Введение Валидация достаточно часто вызывает затруднения с работой в веб-приложениях. Во многих случаях фреймворки должны быть использованы для валидации значений формы. Кроме того, эти фреймворки часто не работают во всех браузерах. AngularJS приходит с проверкой, построенной так, что теперь гораздо легче создать валидацию, которая работает во всех браузерах. На практике Использование angular-message Чтобы использовать angular-message, нужно внести в ваш проект модуль:  angular.module("realestateApp", ["ngMessages"]); Теперь ng-message будет доступен для использования. Формы Для инициализации процесса валидации, Вы должны начать с формы контейнера: <form name="tenantForm"> Теперь внутри тега можно добавить управление и логику на их проверку. В сценариях валидации, как правило, есть несколько основных атрибутов. Те, которые стоит использовать: Required, Minimum, Maximum, Pattern, Email, Number, и URL. Required Этот атрибут заставляет form быть недействительным, если обязательное поле не вводится. <input type="text" required /> Minimum Length Этот атрибут указывает минимум символов для ввода до того, как значение будет принято. <input type="text" ng-minlength=5 /> Maximum Length Этот атрибут указывает максимальную длину или проверка будет неверна. <input type="text" ng-maxlength=20 /> Pattern Matching Эта функция позволяет согласовать совпадения при использовании Regex. <input type="text" ng-pattern="[a-zA-Z]" /> Email Matching Angular обеспечивает пользовательские функции по электронной почте. <input type="email" name="email" ng-model="user.email" /> Number Этот требует ввода в цифровом формате перед проверкой. <input type="number" name="age" ng-model="user.age" /> URL Этот требует ввода в ссылочном формате перед проверкой. <input type="url" name="homepage" ng-model="user.url" /> Сообщение об ошибке Ранее использовался error-container, но теперь можно использовать директиву ng-message: <div ng-messages="tenantForm.Email.$error" ng-messages-include="messages.html" class="errors"></div> Также нужен файл messages.html для хранения сообщений об ошибках: <div class="messages"> <div ng-message="required">Required</div> <div ng-message="minlength">Too short</div> <div ng-message="maxlength">Too long</div> <div ng-message="email">Invalid email address</div> <div ng-message="compareTo">Must match the previous entry</div> <div ng-message="number">Must be a number</div> <div ng-message="url">Must be in URL format</div> </div> Сообщение об отмене ошибки Иногда Вы должны иметь пользовательские сообщения об ошибках, не охватываемых messages.html. Вы можете сделать это, добавив тег span в диапазон для любого сообщения об ошибке. То, что должно отобразиться: <div ng-messages="tenantForm.FirstName.$error" ng-messages-include="messages.html" class="errors"> <span class="messages" ng-message="minlength">Must be more than 3 characters</span> <span class="messages" ng-message="maxlength">Must be more than 20 characters</span> </div> Собираем всё вместе Теперь, объединив messages.html с index.html. <form name="tenantForm" novalidate style="width: 500px">     <div class="row">         <div ng-repeat="tenant in tenant">             <div class="form-group">                 <label>First Name: label>                 <input type="text"                        placeholder="First Name"                        name="FirstName"                        ng-model="tenant.FirstName"                        ng-minlength=3                        ng-maxlength=20 required />                 <div ng-messages="tenantForm.FirstName.$error"                      ng-messages-include="messages.html" class="errors">                     <span class="messages"                     ng-message="minlength">Must be more than 3 charactersspan>                     <span class="messages"                     ng-message="maxlength">Must be more than 20 charactersspan>                 div>             div>             <div class="form-group">                 <label>Home Phone: label>                 <input type="number"                        placeholder="Phone Number"                        name="HomePhone"                        ng-model="tenant.HomePhone"                        ng-minlength=7                        ng-maxlength=10 required />                 <div ng-messages="tenantForm.HomePhone.$error"                      ng-messages-include="messages.html" class="errors">                     <span class="messages"                     ng-message="minlength">Must be more than 7 digitsspan>                     <span class="messages"                     ng-message="maxlength">Must be less than 11 digitsspan>                  div>             div>             <div class="form-group">                 <label>Email: label>                 <input type="email"                        placeholder="Email"                        name="Email"                        ng-model="tenant.Email"                        required />                 <div ng-messages="tenantForm.Email.$error"                      ng-messages-include="messages.html" class="errors">div>             div>             <div class="form-group">                 <label>Webpage: label>                 <input type="url"                        placeholder="Webpage"                        name="Webpage"                        ng-model="tenant.Webpage"                        required />                 <div ng-messages="tenantForm.Webpage.$error"                      ng-messages-include="messages.html" class="errors">                 div>             div>         div>     div>               form> Этот подход кажется чище, чем использование директивы ng-show. Кроме того, это уменьшит дублирование кода путем центрального места хранения ваших сообщений об ошибках, но в то же время используется для пользовательских сообщений. Источник: http://www.codeproject.com/Articles/992545/AngularJS-Validation