Привет, мир. Надеюсь, у тебя все хорошо. Эта статья не техническая, а больше ориентирована на чтение для удовольствия. Идея состоит в том, чтобы пощекотать ваши мысли, чтобы вы могли принимать важные решения наперед. Ниже приведены некоторые аналогии с примерами из реальной жизни, которые помогут вам подумать о программировании.
Код на сегодня
Вы когда-нибудь представляли, как отправляетесь в путь с закрытыми глазами. Неизвестная тебе дорога. Некоторые могут попытать счастья и рискнуть, но многие не могут. Хотя ходьба и переноска — это наша повседневная деятельность, мы привыкли к этому и практиковались сотни раз. Мы уверены, когда делаем шаг вперед. Но когда мы пытаемся идти по мелкой реке, мы пытаемся найти устойчивую поверхность только тогда, когда ставим ногу.
Это очень похоже на написание нашего кода. Вы можете кодировать только в том случае, если требование ясно в вашей голове. Даже самая маленькая единица должна быть очень четкой, и нужно уметь ее визуализировать. Если вы можете визуализировать это и не найти незавершенных вопросов, то кодирование — это неплохо для начала.
Вы должны кодировать только те требования, которые сегодня ясны. Любое неясное требование должно пройти через сеансы мозгового штурма с заинтересованными сторонами. Помните, если требования трудно объяснить, это свидетельствует о том, что они не определены четко. Одним из подходов может быть разделение требований на подтребования, выявление и устранение нечеткой части.
Программное обеспечение — это постоянно улучшающийся портрет
Вы видели, как художник работает над живым портретом? Удается ли ему/ей сразу создать окончательный результат? Нет, процесс основан на методе итеративного систематического прогресса для достижения желаемой цели.
То же самое и с разработкой программного обеспечения. Программирование — это искусство, и вы должны думать как художник. Сложные проблемы можно решить, только разбив их на более мелкие проблемы, а затем победив каждую из них.
Каждая разработка программного обеспечения начинается с наброска минимальной структуры путем создания абстракций, создания интерфейсов, размышлений о данных и их структуре. Как только это будет сделано, следующая итерация будет включать в себя реализацию этих абстракций путем написания реализаций, все более глубокого погружения в реализации и кодирования для наименьшей возможной единицы. Соединяем их вместе, тестируем и так далее.
Повторная итерация, как набросок, — это путь разработки программного обеспечения, и для этого нужно овладеть искусством рефакторинга.
Рефакторинг просто означает организацию и реорганизацию кода без изменения его поведения. Это может быть что угодно, например Извлечение метода, если код повторяется более одного раза, или извлечение, потому что некоторые строки кода специально выполняют только одну функцию, Идентификацию зависимостей, просто рисуя значение или связь их с сущностями реального мира (например, цикл зависит от шины, а не наоборот) и при этом сохраняется поведение цикла или шины и т. д.
Я бы порекомендовал прочитать книгу по рефакторингу. Вот пара книг, с которых вы можете начать.
1. Рефакторинг: улучшение дизайна существующего кода — Мартин Фаулер.
2: Эффективная работа с устаревшим кодом — Майкл С. Фезерс
Испытательный жгут
По мере роста программного обеспечения с ним будет происходить множество вещей. Тесты помогут вам отслеживать поведение вашего программного обеспечения. Программное обеспечение — это результат действия различных воображаемых правил, решающих конкретную человеческую проблему. Со временем будет очень трудно запомнить их все. Возможно, мы захотим добавить функции и проверить, работает ли остальная часть программного обеспечения должным образом. Это может быть повторяющаяся задача и может происходить ежедневно, поэтому нам нужны некоторые меры, чтобы позаботиться об этом. Тесты и есть эти меры. Компьютеры могут продолжать повторять и запускать тестовые случаи для нашего программного обеспечения каждый день или каждые пару часов, не утомляясь, в отличие от человека.
Как правило, во время нашего обучения очень мало внимания уделялось написанию модульного теста, и большинство из нас знает модульное тестирование только теоретически. Такие понятия, как модульное тестирование, требуют дополнительных усилий, зачем нам управлять двумя кодовыми базами? Если мы допускаем ошибки при написании кода, какова гарантия того, что так называемый «тестовый код» не будет содержать ошибок? Это мой любимый «Мы уже пишем отлично работающий код, зачем нам нужны тесты?». Все эти понятия создают барьеры и еще больше затрудняют понимание важности Тестов.
Признаюсь, мы тоже прошли через все эти неохотные мысли. Один специфический опыт, если вы начинаете изучать тесты очень поздно в своей карьере, заключается в том, что даже если вы читаете статьи, читаете книги, вы как бы понимаете, что автор пытается заставить вас понять, но все же это поначалу не имеет смысла. Концепции будут звучать очень очевидно, но все же это не будет «кликнуть». Это очень похоже на достижение «Внутреннего покоя». Все остальное, чему мы научились, было знанием, но эта часть — Мудрость.
Итак, что мы должны сделать, чтобы впитать эту мудрость? Что ж, ответ на него тоже мудрый.
Сделайте прыжок веры. Сдаться своим испытаниям
Вам придется забыть, что вы идеальный программист. Напишите тест, введите некоторые данные для класса, который вы тестируете, и ожидайте каких-либо результатов. Это должно быть еще до того, как вы напишете что-нибудь в указанном классе. Тест провалится. Затем напишите код только для того, чтобы пройти этот тест, ровно столько, чтобы пройти тест. Оставьте следующее поведение для предстоящего следующего теста. Не думайте дальше этого класса и продолжайте писать тесты и проходить их до тех пор, пока не будет достигнуто желаемое поведение указанного класса. Не прыгайте между другими классами. Могут возникнуть ситуации, когда указанный класс должен будет взаимодействовать с другими классами, но опять же этих классов не существует. Мы все еще можем продолжать писать тесты и проходить их для текущего класса, используя методы Mocking and Fake.
Вы можете узнать об этих вещах в Интернете, там есть множество библиотек для тестирования и насмешек, доступных практически для любой платформы программирования.
Для Java вы можете проверить Junit4, Junit5, Mockito. Аналогично для Kotlin, чтобы назвать некоторые Kotest, Mockk
Не изобретайте заново
Программирование и программисты развиваются с 1960-х годов. Они столкнулись с различными блокпостами и устранили большинство из них. Как и в случае с реальными жизненными проблемами, нет единого решения для каждой проблемы, точно так же были классификации таких решений, которые лежали в сценариях, книгах, опубликованных статьях и т. д. Мы должны учиться на таких документах, это ускорит нас вперед и мы сможем учиться на их ошибках, на их выводах и на их решениях.
Один из способов начать — изучить шаблоны программирования. Существует 3 категории шаблонов программирования.
Творческий
Структурный
Поведенческий
Проверьте все это подробно на примере, сделайте краткую справочную заметку, чтобы вы могли вернуться к ней в любой момент времени.
Кроме того, узнайте об архитектурных шаблонах, таких как MVC, MVVM, MVP, MVI… и т. д.. Описание этих паттернов выходит за рамки этой статьи, так как я обещал вам, что она не будет технической.
Сказав это, поймите цель Architectural Pattern. Эти шаблоны приняты, чтобы упростить общение между разработчиками. Короче говоря, он более или менее определяет, какой код куда будет идти, и если вы что-то ищете, как к нему перейти. При работе в команде это избавит вас от серьезных переделок.
Узнайте о некоторых принципах, таких как DRY (не повторяйтесь) и SOLID. С намерением обрести мудрость так же, как и изучение тестов. Более того, все эти вещи помогут вам писать несвязанный и повторно используемый код. Как только вы овладеете этими вещами, вы уже не будете прежним человеком. Ваш подход к проблемам будет другим. Ваше понимание того, что неважно, резко изменится и в конечном итоге избавит вас от излишней инженерии. Вы поймете разницу между кодом Framework и бизнес-логикой, это различие позволит вам отложить или отложить какое-либо решение до более позднего этапа разработки программного обеспечения.
Все это позволит вам наслаждаться программной инженерией. Как и в случае с эспрессо, вам потребуется некоторое время, чтобы полюбить его. Это стоит того.
Развивайте сочувствие
Как мы узнали, идеально искать решение проблемы, если она уже была решена кем-то раньше, это может уберечь вас от повторного изобретения того же самого. Это означает, что мы вместе в этом, и именно сообщество вносит свой вклад в вашу работу, и именно вы рано или поздно вносите свой вклад в сообщество. Так что будьте эмпатичны. Это самый важный механизм для программиста для продвижения в карьере и жизни.
Как мы каждый раз находимся в переходном состоянии, так и все остальные находятся в своих областях. Важно, чтобы вы просили и ценили каждого. Не стесняйтесь сказать «Спасибо», даже если вы думаете, что это просто формальность. Уважайте время и усилия каждого. Если вы работаете в межфункциональной команде и наделены QA (инженерами по обеспечению качества), даже если они регистрируют ошибки для вас, это как бы помогает вам и пытается спасти вас и компанию от серьезных проблем.
Один из быстрых способов понять обратную связь — попытаться понять ее роль. Проведите дружескую дискуссию и попытайтесь выяснить, с какими повседневными проблемами они сталкиваются и с какими ограничениями работают.
В конце концов ваше сочувствие заведет вокруг вас несколько скромных друзей. Отсюда и хорошая культура труда.
Наконец, я хотел бы попросить вас всегда быть полезным. Будьте активистами. Наше существование всегда должно приносить пользу людям вокруг нас.
Дайте мне знать ваши мысли. Если вы считаете, что в этой статье есть что улучшить, мы всегда можем разместить их здесь.
