Мнение о процессе разработки ПО
Posted: Wed May 20, 2020 10:03 am
https://dev.by/news/20-veschei-kotorye- ... yandex.com
Я программирую с 1999 года, то есть уже больше 20 лет. Начинал с Basic, но вскоре перешёл на Pascal и C, а потом изучал объектно-ориентированное программирование на Delphi и C++. В 2006 взялся за Java, а в 2011-м — за JavaScript. Работал в самых разных сферах от робототехники, финтеха и медтеха до СМИ и телекоммуникаций. Был исследователем, СТО, ТРМ (технический продакт-менеджер), преподавателем, системным архитектором, техлидом, но никогда не переставал кодить.
Некоторыми из продуктов, в разработке которых я поучаствовал, пользовались миллионы людей, а некоторые были похоронены ещё до релиза. Я работал консультантом и даже пробовал вырастить стартап. Кучу времени посвятил проектам с открытым исходным кодом, с закрытым кодом, inner source-проектам (когда методологии open source-разработки используются в создании проприетарного софта сообществом внутри компании). Доводилось работать с крошечными микроконтроллерами, с мобильными и десктопными приложениями, облачными серверами и бессерверными архитектурами.
Подводя черту под 20 годами программирования, я составил список «золотых правил», к которым постепенно пришёл за это время и которыми руковожусь в работе.
Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции. Не пытайтесь прогнуть технологии, но и задачу под них тоже подстраивать не нужно. Выбирайте правильный инструмент для решения конкретной проблемы, или придётся искать «правильную» проблему под те инструменты, которые оказались у вас в руках.
Вы пишете код не для машин. Вы пишете его для своих коллег и для будущего себя (если это какой-нибудь пробный или «расходный» проект). Пишите код для неопытных разработчиков как эталон.
Любой серьёзный и успешный программный продукт — результат совместного труда. Коммуникация должна быть эффективной и открытой. Доверяйте другим и сами заслуживайте доверие. Цените людей больше, чем код. Подавайте пример. Помогайте другим становиться лучше.
«Разделяй и властвуй». Пишите обособленные модули с определённым назначением, которые можно запросто объединить. Тестируйте каждую часть отдельно и вместе с другими. Тесты должны быть приближены к реальности, но и предельные случаи тоже нужно тестировать.
Код не должен зависеть от вас. Не замыкайте код на себе. Оптимизируйте его таким образом, чтобы другие люди могли фиксить баги и добавлять новые фичи. Оставляйте себе возможность свободно перейти к новому проекту или в другую компанию. Не относитесь к коду как к своей собственности, а то никогда не перерастёте его.
Есть разные уровни безопасности. Каждый нужно рассматривать индивидуально, но в контексте целого. Приемлемый уровень риска — это бизнес-решение, которое прямо соотносится с уязвимостью и вероятностью. У каждого продукта/организации этот уровень — готовность идти на тот или иной риск для получения большей выгоды — различный. Часто возникает конфликт между тремя вещами: UX, безопасностью и производительностью.
Поймите, что у любого кода есть жизненный цикл, который когда-нибудь закончится. Иногда код «умирает» в зачаточном состоянии, так и не дотянув до выхода в продакшн. Учитесь отпускать. Помните, что функционал делится на 3 неравнозначные группы:
— ключевой — например, двигатель в автомобиле. Без таких фич продукт бесполезен;
— необходимый — например, запасное колесо. Использовать его выпадает редко, но если час придёт, от него будет зависеть работоспособность всей системы;
— дополнительный — например, подстаканник. Приятно, когда он есть, но можно и обойтись.
Нельзя по коду судить о человеке. Не приравнивайте людей к артефактам, которые они генерируют. Не принимайте на свой счёт, когда кто-то ругает ваш код, но сами будьте крайне деликатны, критикуя код других.
Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
Если когда вы принимаете решение, все следующие факторы имеют одинаковый приоритет, расставьте их в таком порядке:
безопасность > юзабилити (доступность + UX) > сопровождаемость > простота («опыт разработки», developer experience) > краткость (длина кода) > производительность.
Только не нужно строго придерживаться такой последовательности, поскольку всё зависит от сущности продукта. Как и в любой другой профессии, с опытом у вас будет всё лучше получаться найти правильный баланс в каждом конкретном случае. Например, при разработке игрового движка первостепенную важность имеет производительность, а для банковского приложения главным фактором будет безопасность.
Верный способ плодить баги — использовать копипаст. Всегда смотрите, что копируете; всегда проверяйте, что вставляете. Баги кроются в сложностях. Не мудрите с кодом.
Пишите код не только для благоприятных сценариев. Предусмотрите ещё и сообщения об ошибках, из которых понятно, почему они произошли, как были обнаружены и что сделать, чтобы их исправить. Верифицируйте все данные, поступающие в систему извне (в том числе вводимые пользователем): лучше, чтобы ошибки срабатывали как можно раньше и по возможности устранялись. Представьте, что у пользователя в руке пистолет: вложите в сообщение максимум усилий, чтобы стрелять куда угодно, но не вам в голову.
Используйте зависимости только тогда, когда затраты на импорт, сопровождение, устранение крайних случаев/багов и рефакторинг в случае, когда они не отвечают нуждам, оправдывают себя.
Не идите на поводу у хайпа (это называется hype-driven development). Но старайтесь постоянно расширять кругозор. Пилите домашние хобби-проекты.
Выходите из зоны комфорта. Каждый день учитесь чему-то новому. Учите других тому, чему научились сами. Когда человек упирается в потолок, то перестаёт развиваться. Изучайте новые языки, технологии, культуры, будьте любознательны.
Хороший код не требует документации, но отличный код задокументирован по определению. Любой человек со стороны, который не участвовал в его разработке и доведении до текущего состояния, может с ним работать. Если фича не задокументированне, её не существует. Для фичи, которой не существует, не должно быть и кода.
Старайтесь по возможности избегать переопределения, наследования и других усложнений. Пишите чистые функции. Их легче тестировать и анализировать. «Нечистая» функция должна быть классом. У каждой конструкции кода со своей функцией должно быть своё имя.
Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи. Ничего страшного, если уйдёт больше времени на прослушивание и чтение материалов для подготовки, чем на стучание по клавишам. Прежде чем писать код, ознакомьтесь с предметной областью.
Не сражайтесь с ветряными мельницами. Не занимайтесь «спекулятивным программированием». Делайте код расширяемым только в том случае, если уверены, что его точно будут расширять. Может случиться, что к тому времени проблема будет стоять уже не так, как тогда, когда вы начинали писать код.
Софт веселее создавать вместе. Соберите сплочённое сообщество. Слушайте. Вдохновляйте. Учитесь. Делитесь.
Я не претендую на звание эксперта по разработке программного обеспечения. Это просто соображения, которые накопились за годы практики. Уверен, что ещё через 20 лет этот список будет более глубоким.
[!] Выделил в отдельную тему отсюда, dunkaist.
Я программирую с 1999 года, то есть уже больше 20 лет. Начинал с Basic, но вскоре перешёл на Pascal и C, а потом изучал объектно-ориентированное программирование на Delphi и C++. В 2006 взялся за Java, а в 2011-м — за JavaScript. Работал в самых разных сферах от робототехники, финтеха и медтеха до СМИ и телекоммуникаций. Был исследователем, СТО, ТРМ (технический продакт-менеджер), преподавателем, системным архитектором, техлидом, но никогда не переставал кодить.
Некоторыми из продуктов, в разработке которых я поучаствовал, пользовались миллионы людей, а некоторые были похоронены ещё до релиза. Я работал консультантом и даже пробовал вырастить стартап. Кучу времени посвятил проектам с открытым исходным кодом, с закрытым кодом, inner source-проектам (когда методологии open source-разработки используются в создании проприетарного софта сообществом внутри компании). Доводилось работать с крошечными микроконтроллерами, с мобильными и десктопными приложениями, облачными серверами и бессерверными архитектурами.
Подводя черту под 20 годами программирования, я составил список «золотых правил», к которым постепенно пришёл за это время и которыми руковожусь в работе.
Не боритесь с инструментами — библиотеками, языками, платформами — чем бы то ни было. Старайтесь использовать присущие им конструкции. Не пытайтесь прогнуть технологии, но и задачу под них тоже подстраивать не нужно. Выбирайте правильный инструмент для решения конкретной проблемы, или придётся искать «правильную» проблему под те инструменты, которые оказались у вас в руках.
Вы пишете код не для машин. Вы пишете его для своих коллег и для будущего себя (если это какой-нибудь пробный или «расходный» проект). Пишите код для неопытных разработчиков как эталон.
Любой серьёзный и успешный программный продукт — результат совместного труда. Коммуникация должна быть эффективной и открытой. Доверяйте другим и сами заслуживайте доверие. Цените людей больше, чем код. Подавайте пример. Помогайте другим становиться лучше.
«Разделяй и властвуй». Пишите обособленные модули с определённым назначением, которые можно запросто объединить. Тестируйте каждую часть отдельно и вместе с другими. Тесты должны быть приближены к реальности, но и предельные случаи тоже нужно тестировать.
Код не должен зависеть от вас. Не замыкайте код на себе. Оптимизируйте его таким образом, чтобы другие люди могли фиксить баги и добавлять новые фичи. Оставляйте себе возможность свободно перейти к новому проекту или в другую компанию. Не относитесь к коду как к своей собственности, а то никогда не перерастёте его.
Есть разные уровни безопасности. Каждый нужно рассматривать индивидуально, но в контексте целого. Приемлемый уровень риска — это бизнес-решение, которое прямо соотносится с уязвимостью и вероятностью. У каждого продукта/организации этот уровень — готовность идти на тот или иной риск для получения большей выгоды — различный. Часто возникает конфликт между тремя вещами: UX, безопасностью и производительностью.
Поймите, что у любого кода есть жизненный цикл, который когда-нибудь закончится. Иногда код «умирает» в зачаточном состоянии, так и не дотянув до выхода в продакшн. Учитесь отпускать. Помните, что функционал делится на 3 неравнозначные группы:
— ключевой — например, двигатель в автомобиле. Без таких фич продукт бесполезен;
— необходимый — например, запасное колесо. Использовать его выпадает редко, но если час придёт, от него будет зависеть работоспособность всей системы;
— дополнительный — например, подстаканник. Приятно, когда он есть, но можно и обойтись.
Нельзя по коду судить о человеке. Не приравнивайте людей к артефактам, которые они генерируют. Не принимайте на свой счёт, когда кто-то ругает ваш код, но сами будьте крайне деликатны, критикуя код других.
Технический долг как фастфуд: допустим в умеренных количествах, но если войдёт в привычку, не успеете оглянуться, как он убьёт продукт, и это будет больно.
Если когда вы принимаете решение, все следующие факторы имеют одинаковый приоритет, расставьте их в таком порядке:
безопасность > юзабилити (доступность + UX) > сопровождаемость > простота («опыт разработки», developer experience) > краткость (длина кода) > производительность.
Только не нужно строго придерживаться такой последовательности, поскольку всё зависит от сущности продукта. Как и в любой другой профессии, с опытом у вас будет всё лучше получаться найти правильный баланс в каждом конкретном случае. Например, при разработке игрового движка первостепенную важность имеет производительность, а для банковского приложения главным фактором будет безопасность.
Верный способ плодить баги — использовать копипаст. Всегда смотрите, что копируете; всегда проверяйте, что вставляете. Баги кроются в сложностях. Не мудрите с кодом.
Пишите код не только для благоприятных сценариев. Предусмотрите ещё и сообщения об ошибках, из которых понятно, почему они произошли, как были обнаружены и что сделать, чтобы их исправить. Верифицируйте все данные, поступающие в систему извне (в том числе вводимые пользователем): лучше, чтобы ошибки срабатывали как можно раньше и по возможности устранялись. Представьте, что у пользователя в руке пистолет: вложите в сообщение максимум усилий, чтобы стрелять куда угодно, но не вам в голову.
Используйте зависимости только тогда, когда затраты на импорт, сопровождение, устранение крайних случаев/багов и рефакторинг в случае, когда они не отвечают нуждам, оправдывают себя.
Не идите на поводу у хайпа (это называется hype-driven development). Но старайтесь постоянно расширять кругозор. Пилите домашние хобби-проекты.
Выходите из зоны комфорта. Каждый день учитесь чему-то новому. Учите других тому, чему научились сами. Когда человек упирается в потолок, то перестаёт развиваться. Изучайте новые языки, технологии, культуры, будьте любознательны.
Хороший код не требует документации, но отличный код задокументирован по определению. Любой человек со стороны, который не участвовал в его разработке и доведении до текущего состояния, может с ним работать. Если фича не задокументированне, её не существует. Для фичи, которой не существует, не должно быть и кода.
Старайтесь по возможности избегать переопределения, наследования и других усложнений. Пишите чистые функции. Их легче тестировать и анализировать. «Нечистая» функция должна быть классом. У каждой конструкции кода со своей функцией должно быть своё имя.
Никогда не начинайте кодить (разрабатывать какое-то решение), полностью не вникнув в суть задачи. Ничего страшного, если уйдёт больше времени на прослушивание и чтение материалов для подготовки, чем на стучание по клавишам. Прежде чем писать код, ознакомьтесь с предметной областью.
Не сражайтесь с ветряными мельницами. Не занимайтесь «спекулятивным программированием». Делайте код расширяемым только в том случае, если уверены, что его точно будут расширять. Может случиться, что к тому времени проблема будет стоять уже не так, как тогда, когда вы начинали писать код.
Софт веселее создавать вместе. Соберите сплочённое сообщество. Слушайте. Вдохновляйте. Учитесь. Делитесь.
Я не претендую на звание эксперта по разработке программного обеспечения. Это просто соображения, которые накопились за годы практики. Уверен, что ещё через 20 лет этот список будет более глубоким.
[!] Выделил в отдельную тему отсюда, dunkaist.
Хочешь помочь проекту - делай что-либо сам. Конечный результат лучше любых слов.
А потом простым преподом