Программирование
Пишите глупый код
Программист и ученый Мэттью Роклин рассказал о частых ошибках недавних выпускников и о том, к какому коду стоит стремиться опытным программистам.
Лучший способ сделать свой вклад в open source-проект — это убрать из него код. Мы должны стремиться писать код, который легко поймет новичок в программировании без пояснений или который мейнтейнер сможет понять, не тратя на него много времени.
20 Open Source проектов для Android, которые могут научить вас новому
В обучении мы решаем все более сложные проблемы при помощи все более сложных технологий. Мы изучаем циклы, затем функции, затем классы и так далее. Нас хвалят, когда мы продвигаемся по этой иерархии и пишем более длинные программы при помощи более сложных технологий. Мы узнаем, что опытные программисты используют монады, где новые программисты используют циклы.
Затем мы выпускаемся и ищем работу или open source-проект, чтобы работать вместе с другими людьми. Мы ищем, чем мы можем помочь, и гордо внедряем решение, используя все уловки, которым научились.
«Ага! Я могу расширить этот проект при помощи X! И я могу использовать здесь наследование, отлично!»
Мы внедряем эту функцию и чувствуем, что достигли чего-то. Программирование реальных систем — это большое достижение. Я был рад писать код и гордился тем, что могу показать миру все, что знаю. В качестве доказательства моей давней любви к программированию, вот язык линейной алгебры с другим языком мета-программирования. Обратите внимание, что никто не прикасался к этому коду несколько лет.
Однако после более продолжительной работы по поддержанию кода я изменил свое мнение.
- Мы не должны стремиться программировать. Программы — это валюта, которую мы платим за решение проблем, что и является нашей истинной целью. Мы должны стремиться создавать как можно меньше кода, который нам нужен для решения проблем.
- Мы должны использовать как можно более простые технологии, чтобы как можно больше людей могли использовать и развивать их без необходимости разбираться в нашем сложном решении. Нам следует использовать сложные методики только тогда, когда мы недостаточно умны, чтобы использовать более общие техники.
Эти выводы не новы. Многие люди соглашаются с ними в какой-то степени, но почему-то мы забываем об этом, когда работаем над новым проектом. Страсть к созданию и демонстрации часто берет верх.
Программа стоит времени
Каждая строка кода стоит людям времени. Она стоит времени вам, когда вы её пишете, но вы хотите принести эту личную жертву. Однако этот код также стоит времени тем, кто будет потом читать его и разбираться в нем. Он стоит времени будущим мейнтейнерам и разработчикам, когда она будут исправлять и модифицировать ваш код. Они могли бы провести это время на прогулке или с семьей.
Поэтому при добавлении кода в проект вы должны быть скромнее. Это должно быть похоже на ситуацию, когда вы едите со своей семьей, но на тарелке недостаточно еды. Вы должны взять то, что вам нужно, не больше. Люди будут уважать вас за усилия ограничить себя. Решать проблемы меньшим количеством кода труднее, но вы должны взять это на себя, чтобы облегчить труд других.
Сложные технологии сложнее поддерживать
Студенты демонстрируют знания, используя сложные технологии. Нас оценивают по тому, как мы используем функции, классы, функции высшего порядка, затем монады и так далее. Мы хвастаемся решениями перед нашими сверстниками и в зависимости от их сложности чувствуем гордость или стыд.
Однако при работе с командой над решением проблемы ситуация переворачивается. Теперь мы стремимся решать проблемы максимально простым кодом. Простой код усиливает наше влияние и быстрее открывается остальным. Мы показываем свою ценность, решая сложные проблемы базовыми методиками.
«Смотрите! Мне удалось заменить эту рекурсивную функцию циклом и он делает все, что нам нужно. Я знаю, что это не такое уж умное решение, но стажерам было сложно, и это может им помочь».
Если вы хороший программист, вам не нужно демонстрировать, что вы знаете крутые трюки. Вместо этого вы можете показать свою ценность, решая проблему простым путем, который позволит всем в вашей команде внести свой вклад в будущем.
Всё хорошо в меру
Стоит сказать, что излишняя привязанность к этой догме может оказать и обратный эффект. Часто рекурсивное решение гораздо проще цикла, а иногда стоит использовать класс или монаду. Нам стоит осмысленно относиться к использованию этих технологий, когда мы строим систему с людьми, у которых может не быть такого опыта.
