25 мая стартовал BIOS-00, учебный лагерь, призванный сделать из нас, новичков, несколько лучших кодеров, своего рода тренировочный лагерь. В ShopUp такое проходило впервые. Давайте углубимся в то, как это было.

Нам также раздали (метафорически) список правил этикета, которым нужно следовать. Что ж, назвать их правилами этикета было бы преуменьшением, потому что если их не соблюдать, последствия будут ужасными. Нам приходилось "rm -rf", т. е. удалять всю нашу кодовую базу, если этикет не соблюдался. Не будем больше о них.

Со всем этим покончено, давайте просто пробежимся по тому, что произошло на буткемпе.

Day-1 : День, который не имел никакого смысла

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

Инструкции и обсуждения:

  • Нам объяснили, что такое модульное тестирование, зачем пишутся спецификации, как их писать, что тестировать и некоторые другие условности.
  • Нам было приказано использовать Gradle вместо инструмента сборки Maven для Java. Также нам сказали использовать Kotlin вместо Groovy, так как Kotlin более продвинут.
  • Нас попросили назвать файл README.md в верхнем регистре, так как это соглашение.
  • Нам сказали использовать JUnit для тестирования спецификаций.
  • О конвенциях нам было сказано следующее.

Конвенция проекта › Конвенция класса › Рекомендации

  • Нам сказали, что для тестирования спецификаций в Ruby следует использовать RSpec.

День 2: день, когда все стало обретать смысл

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

Инструкции и обсуждения:

  • Принцип YAGNI:
    YAGNI, который является аббревиатурой от «Вам это не понадобится», в основном говорит нам, что если есть какая-либо функция или требование, мы не уверен и не указан бизнес-пользователем, мы не должны реализовывать его, если мы не уверены, что он нам понадобится.
  • Подходы «сверху вниз» и «снизу вверх».
    Эти принципы определяют два возможных подхода к проекту. Подход «сверху вниз» — это тот, в котором мы начинаем с зависимого и, безусловно, необходимого компонента, а снизу вверх — это противоположность тому, когда мы начинаем с независимого компонента, который, как мы уверены, нам нужен, а затем двигаемся вверх. br /> Например:
    Для данной постановки задачи мы могли бы либо начать с самого класса линий, либо перейти к классу точек, — Подход «сверху вниз» и другие, в противном случае мы могли бы начать с класса точек и перейти к классу линий — подход снизу вверх.
    - In В нашем конкретном примере использовался подход снизу вверх, поскольку он требовал меньшего количества переписываемого кода.
  • КРАСНЫЙ ЗЕЛЕНЫЙ Цикл фиксации:
    Это определило для нас рабочий процесс, в котором мы должны:

Написать спецификацию › Ошибка (КРАСНЫЙ) › Написать только код, чтобы спецификация прошла (ЗЕЛЕНЫЙ) › Подтвердить

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

День 3: Давайте встряхнемся!

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

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

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

Другие инструкции и обсуждения:

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

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

должен быть рефлексивным
должен быть симметричным
должен быть последовательным

должен быть транзитивным, если строки a=b, b=c и a=c
не должен быть транзитивным, если строки a=b, b≠c и a≠c

должен иметь такой же хэш

  • Разработка, управляемая поведением (BDD):
    Вместо разработки, управляемой тестированием, которая говорит нам писать тесты, а затем писать код, удовлетворяющий требованиям теста, нам сказали следовать принципам разработки, управляемой поведением. Разработка, которая говорит нам писать тесты не ради их написания, а писать тесты только для того, чтобы получить нужное нам поведение из кода при этом
  • Мета-программирование на Ruby:
    Это кратко обсуждалось вместе с BDD.

Метапрограммирование — это написание программ, которые пишут программы. Например, когда модель User определена в Rails с адресом электронной почты в качестве атрибута, будет сгенерирован метод с именем find_by_email.

  • Переопределение:
    Нам показали, как переопределять функции в Java. Это чрезвычайно полезно, так как в зависимости от языка программирования некоторые функции/методы не удовлетворяют нашим требованиям, даже если должны. Поэтому создаются пользовательские методы переопределения, позволяющие указанной функции вести себя так, как нужно.
  • Краткое обсуждение Ruby Workflow, RSpec, конфигурации GemFile и его функций. Были обсуждены соглашения об именах и структура каталогов.
  • Для создания проекта Ruby была предложена следующая команда:

$ bundle gem <project name> --no-exe --coc --no-ext --mit --test=rspec

День 4: идет дождь из заявлений о проблемах

Нам давали 3 задачи в день. 3!!

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

Другие инструкции и обсуждения:

  • Обсуждалась коммерческая ценность git-коммитов, и то, что git-коммиты должны отражать достигнутое поведение.
  • Фактор грузовика.
     Обсуждался термин фактор грузовика, а также его значение. Этот фактор говорит о влиянии на рабочий процесс и работоспособность и переносимость кодовой базы, если человек, работающий над ней, «сбит грузовиком», т. е. по какой-то причине отсутствует. Это говорит нам о том, что нужно писать код, который легко читать и понимать, чтобы другой человек мог легко заменить его с того места, где я его оставил. Чтобы это произошло, обычно несколько человек работают над одним и тем же проектом и периодически меняют роли, чтобы обеспечить знакомство со всем проектом, чтобы уменьшить «фактор грузовика».
  • Атрибуты (attr) в Ruby:
    Атрибуты в Ruby и их типы были кратко обсуждены. Чтобы включить чтение/запись переменных в классе в Ruby, переменные должны либо иметь функции, возвращающие их, либо иметь attr, attr_reader и attr_writer для их возврата.
    - attr
    Метод attr создает переменную экземпляра и метод получения для каждого имени атрибута, переданного в качестве аргумента.
    - attr_reader
    Метод attr_reader подобен методу attr, поскольку он создает переменную экземпляра и метод получения для нее.
    - attr_writer
    Метод attr_writer создает переменную экземпляра и setter для каждого имени атрибута, переданного в качестве аргумента.
  • Обработка исключений и ошибок.
    Эти темы были кратко обсуждены. Было сделано утверждение, что это должно быть сделано в соответствии с требованиями бизнеса.
  • Самостоятельный программист.
     Обсуждалась важность самодостаточности программиста.
  • Краткое обсуждение того, насколько плохи предположения о требованиях пользователей, и важности получения правильных требований от бизнес-пользователя до начала проекта.
  • Хорошие и плохие пользователи:
    Были изучены различия между хорошими и плохими пользователями.
     – Хороший пользователь — это пользователь, который попытается использовать приложение/библиотеку по назначению и любой взлом кода происходит из-за ошибок использования с их стороны.
    - Плохой пользователь — это пользователь, который пытался использовать безопасность и другие уязвимости кода и чье основное намерение — взломать код.
    Также обсуждались обработка исключений и ошибок, изменяемость и неизменность в соответствии с бизнес-требованиями для двух вышеупомянутых типов пользователей.

День 5: Перегружен

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

Другие инструкции и обсуждения:

  • Обсуждалось, что в спецификациях не должно быть никакой логики. Как поясняется в цитате из «Хранителей», спецификации нужны для того, чтобы контролировать работу логики кодирования, но если даже спецификации содержат логику, кто будет за этим следить?
    Цитата: «Quis custodiet». ipsos custodes”
  • Цикломатическая сложность.
    Цикломатическая сложность участка кода — это количественная мера количества линейно независимых путей в нем. Это программная метрика, используемая для обозначения сложности программы. Он вычисляется с использованием графа потока управления программы. Узлы на графе обозначают наименьшую группу команд программы, а направленное ребро в нем соединяет два узла, т. е. если вторая команда может следовать сразу за первой командой.
  • YMMV:
    "Ваш пробег может меняться" было сказано в отношении написанного кода, поэтому очень важно писать спецификации.
  • IS A vs HAS A:
    Если что-то ЯВЛЯЕТСЯ чем-то, мы должны использовать наследование для использования его свойств вместо жесткого кодирование для этой одной вещи.
    Пример: Квадрат ЯВЛЯЕТСЯ прямоугольником, и поэтому мы должны использовать наследование.
    Если одна вещь "ИМЕЕТ" что-то, что мы следует использовать делегирование/композицию свойств/методов чего-либо, чтобы определить что-то одно.
    Пример: у автомобиля есть двигатель, поэтому мы должны делегировать свойства автомобиля к свойствам двигателя.
  • Неизменяемость выше изменчивости:
    Это была важная обсуждаемая концепция, в которой говорилось, что мы должны предпочесть, чтобы объекты и классы были неизменяемыми после создания, чтобы предотвратить проблемы с безопасностью и ошибки.
    Например, когда все объявлено общедоступным, кто-то может легко получить к нему доступ и изменить его значение или получить к нему прямой доступ, что приведет к проблемам безопасности и неправильным оценкам
    Это также можно интерпретировать как наш код должен быть модульным и ранее написанным кодом. не должны требовать изменения для добавления новых функций или модулей, что делает код неизменным и менее подверженным ошибкам.
  • Лисков Принцип замещения (LSP):
    Фактическое утверждение:

Пусть ϕ(x) — доказуемое свойство объектов x типа T. Тогда ϕ(y) должно быть истинным для объектов y типа S, где S — подтип T.

Проще говоря, принцип подстановки Лисков (LSP) гласит, что объекты суперкласса должны заменяться объектами его подклассов без нарушения работы приложения.
Другими словами, мы хотим, чтобы объекты наших подклассов вели себя как так же, как объекты нашего суперкласса.
Таким образом, в следующий раз, когда вы по ошибке создадите объект подкласса, все будет в порядке (учитывая, что вы реализовали LSP).

  • Заводской шаблон:
    Это был еще один метод, который можно использовать для создания/добавления аналогично сгруппированных модулей.
    Например, если мы пишем код для расчета свойств различных четырехугольников, фабричный шаблон может быть хорошим способом походить на фабрику, которая может генерировать требования, добавляя необходимый код в класс «Фабрика».
  • Конкретный класс:
    Конкретный класс — это класс, который имеет реализацию для всех своих методов. У них не может быть нереализованных методов. Он также может расширять абстрактный класс или реализовывать интерфейс, если он реализует все свои методы. Это полный класс, и его можно создать.

День-6: Поехали!

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

Другие инструкции и обсуждения:

  • Введение в Golang:
     Объявление открытых и закрытых членов в Go:
    — Private: любая функция/метод или переменная, объявленная с верблюжьим регистром, т.е. , начинающиеся с буквы нижнего регистра, будут закрытыми.
    - Общедоступные: любая функция/метод или переменная, объявленные в регистре Pascal, т. е. начинающиеся с буквы верхнего регистра, будут общедоступными.
  • Testify:
    Для тестирования в Go используется библиотека testify.
  • Возможности Golang:
    -    Интерфейс
    - Функции
    - Структуры
    - Каналы
    - Горутины
  • Makefile:
     было сказано об использовании make-файлов.
    Makefile — это файл, в котором перечислены/определены наборы задач, которые необходимо выполнить. Установленным задачам дается имя, и эти задачи можно вызывать, вызывая:
    $ make <alias>
    По сути, это утилита, которая позволяет нам запускать набор предопределенных задач с помощью команды make.
  • Проблемы с Golang:
    В отличие от Ruby и, как и в Java, библиотеки тестирования, testify, Golang не печатает подробный список неудачных и пройденных тестов, если только не используются дополнительные аргументы для test, и даже в этом случае она не так хороша, как RSpec в Ruby.
  • $ go test -v | grep -v RUN
    Эту команду можно использовать для отображения всех пройденных и не пройденных тестов.

День 7: День, который я пропустил

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

Другие инструкции и обсуждения:

  • Проблемы разработки программного обеспечения:
    - Именование переменных
    - Аннулирование кеша
    Недействительность кеша – это процесс, во время которого прокси-серверы веб-кэша объявляют кэшированное содержимое недействительным. , что означает, что он больше не будет отображаться как самая последняя часть контента при запросе. Возможны несколько методов аннулирования, включая очистку, обновление и блокировку.
  • Три столпа обслуживания в программных продуктах:
    - время
    - объем
    - качество
  • Принцип единой ответственности (SRP):
    Функция/метод должны делать только одну вещь и делать это хорошо. Если он выполняет более одной функции, его можно дополнительно разбить.

День 8: Давайте улучшим нашу «ловкость»

Что ж, в тот день мы только узнали об Agile-методологии разработки. Отсюда и ужасный каламбур. Мы также узнали еще о нескольких вещах, обязательно ознакомьтесь с ними ниже!

Постановка задачи на сегодня выглядит следующим образом:

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

Другие инструкции и обсуждения:

  • Эффект Даннинга-Крюгера.
    Эффект Даннинга-Крюгера — это когнитивное искажение, при котором люди с низкими способностями, знаниями или опытом в отношении определенного типа задач или областей знаний склонны переоценивать свои способности. или знания.
  • Методология водопада.
    Методология модели водопада также известна как линейная последовательная модель жизненного цикла. Модель водопада выполняется в последовательном порядке, поэтому команда разработчиков проекта переходит к следующему этапу разработки или тестирования только в том случае, если предыдущий шаг завершен успешно.
  • Методология Agile.
    Методология Agile – это практика, которая способствует непрерывной итерации разработки и тестирования в процессе разработки программного обеспечения. В этой модели действия по разработке и тестированию выполняются одновременно, в отличие от модели водопада. Этот процесс позволяет больше общаться между клиентами, разработчиками, менеджерами и тестировщиками.
  • Водопад против Agile:
    Водопад — это линейная последовательная модель жизненного цикла, тогда как Agile — это непрерывная итерация разработки и тестирования в процессе разработки программного обеспечения.
    — В Agile против Методология Waterfall, Agile, известна своей гибкостью, в то время как Waterfall — это структурированная методология разработки программного обеспечения.
     — Сравнение методологии Waterfall и Agile, которая следует поэтапному подходу, тогда как Waterfall – это последовательный процесс проектирования.
     – Agile выполняет тестирование. одновременно с разработкой программного обеспечения, тогда как в методологии Waterfall тестирование проводится после этапа «Сборка».
     – Agile позволяет вносить изменения в требования к разработке проекта, тогда как Waterfall не имеет возможности изменять требования после начала разработки проекта.
  • Истории пользователей.
    Истории пользователей — это наименьшая единица работы в гибкой структуре. Это конечная цель, а не функция, выраженная с точки зрения пользователя программного обеспечения. Пользовательская история — это неформальное общее объяснение функции программного обеспечения, написанное с точки зрения конечного пользователя или клиента.
  • Обсуждалась важность наличия документации каждого принятого решения.
  • ИНВЕСТИРОВАТЬ в Agile:
    аббревиатура ИНВЕСТИРОВАТЬ помогает запомнить общепринятый набор критериев или контрольный список для оценки качества пользовательской истории. Если история не соответствует одному из этих критериев, команда может захотеть перефразировать ее или даже подумать о переписывании (что часто приводит к физическому разрыву старой карты истории и написанию новой).
    Хороший пользователь. история должна быть:

Янезависим (от всех остальных)
Ндоговорен (не конкретный контракт на функции)
Vдостоин (или по вертикали)
Eстимулируемый (в хорошем приближении)
Sмаленький (чтобы соответствовать итерации)
T estable (в принципе, даже если для него еще нет теста)

День 9: А вот и ввод командной строки

Я думаю, что заголовок довольно понятен, поэтому я просто оставлю это как есть.

Другие инструкции и обсуждения:

  • OCP — принцип открытости/закрытости
    Это принцип, согласно которому мы должны писать код, который является «открытым» для расширения и «закрытым» для модификации.
  • Была дискуссия о важности модуляризации, и нам было дано указание писать все как модули и максимально разбивать код. Что касается приложения CLI, нам сказали разбить его на 4 компонента, а именно:
    - IO
    - Parser
    - Handler
    - Views
  • LSP (принцип замещения Лискова) снова обсуждался.

День 10: Путешествие заканчивается

Что отмечает окончание больше, чем клишированный заголовок?

Другие инструкции и обсуждения:

  • DIP — принцип инверсии зависимостей:
    отключите их, прежде чем вы их имитируете.
    Мы не рекомендовали имитировать пользовательский ввод, если нет абсолютно никакой альтернативы, и вместо этого использовать другие методы.
  • Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба должны зависеть от абстракции.
  • ISP – принцип разделения интерфейсов.
     Клиенты не должны принуждаться к использованию интерфейсов.
  • Закон Деметры:
    Модуль не должен знать внутренних деталей объекта, которым он манипулирует.
  • Было кратко обсуждено, как приложение Uber основано на системе, управляемой событиями.

На этом я считаю, что мы подошли к концу программы обучения bios-00 в ShopUp. Есть пара вещей, которые я забыл или пропустил, а некоторые я помню, но не помню, когда это было сказано.

А вот и обсуждение "неотслеживаемых":

ПЕРВЫЙпринцип:
- F для быстрого.
- Iдля независимого
- Rдля повторения
- Sдля самопроверки
- Tдля полного

Это рекомендации по написанию спецификаций/тестов в TDD/BDD.

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