🖥 Подборка статей как писать свой код лучше

Многие игнорируют качество кода. Говорят это сложно посчитать. Непонятно станет ли лучше кнопка при правильной архитектуре или идеальном коде. Сколько она принесет денег бизнесу или сократит сроки спорами на код-ревью. А написав код разок не факт что к нему еще вернешься. Ресурсов на хороший код требуется много, а пользу сложно понять.

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

Я сам не верю ни в код ревью, ни в формальные договоренности. Верю только в метрики, стандарты и санкции за нарушения. А если для этого нет повода вводить санкции, то так ли это важно? Договоренности всегда нарушают, а метрики и санкции имеют ощутимые последствия.

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

Попытался собрать подборку с хорошими статьями как сделать свой код лучше:
- Как написать чистый код на Swift
- 7 советов для чистого кода
- 10 лучших практик написания чистого и эффективного кода на Swift
- Чистый код на iOS
- Как написать чистый, удобный в сопровождении код Swift для мобильных приложений?
- 10 советов по написанию более чистого и читаемого кода на Swift

🍭 100 платных подписчиков

Для многих очень маленькое число, но для меня большая цифра. Огромное спасибо каждому. За ваш фидбэк и конструктивно-креативную энергию.

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

Перо глубже вонзается в бумагу. Пальцы уверенней бьют по клавиатуре. Шаги к трибуне решительней, а голос смелее.

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

Ты находишь новые силы продолжить приключение и узнать какой же конец у этого пути. У тебя появляются попутчики и даже друзья.

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

Впереди пара интересных анонсов с новым форматом контента. Оставайтесь, присоединяйтесь.

🛸 Подборка визуализаций алгоритмов

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

🌺 Pathfinding Visualizer — сайт визуализирует в действии различные алгоритмы поиска пути и многое другое: поиск в ширину, глубину, жадные алгоритмы и другие. Если вы работаете с расчетом пути, то очень полезно.

🌼 Algorithm visualizer — широкий список разных алгоритмов и визуализаций: рекурсия, динамическое программирование, бэктрекинг и брутфорсинг

🌸 VisuAlgo — простенький и небольшой сайт, но с приятными и простыми анимациями разных алгосов и структур данных

❤️ Подборка ресурсов для эффективного кодревью

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

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

Попробовал собрать хорошие правила практик для эффективного код ревью:

🌄 Официальное руководство по стилю Kodeco Swift. Бывший сайт Рей Вандерлея собрал неплохие практики по многим частым вопросам.

🌄 Swift API design guideline. Нельзя не упомянуть всеми известную доку от разрабов нашего любимого языка.

🌄 Coding Guidelines for Cocoa. Еще один сборник рекомендаций от разрабов инфры Cocoa.

🌄 The Standard of Code Review in Google. Принципы и правила кодревью в гугле. Материал не о том, как писать код, а скорее общие стандарты по эффективному код ревью

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

Прежде чем стандартизировать процесс производства кода, мне кажется, нужно выявить общий компромисс