Уроки, извлечённые из опыта разработки программного обеспечения

Вот список правил по разработке ПО, которые я вывел для себя за годы практики.

Разработка

1. Начинайте с небольших вещей, затем расширяйте их.

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

Мне нравятся эти слова Джона Галла: «Любая достаточно сложная система, которая работает, так или иначе в своё время эволюционировала из простой системы, которая работала».

2. Изменяйте что-то одно за один раз.

Если при разработке программа начинает проваливаться на каком-то тесте или некоторая функция перестаёт работать, то гораздо проще найти причину, если вы поменяли код только в одном месте. Другими словами, лучше использовать небольшие итерации, чем пытаться сделать всё и сразу. Сделайте что-то одно, убедитесь, что это работает, повторите.

Это также применимо и на уровне коммитов в систему контроля версий. Если вам надо провести рефакторинг, то прежде чем добавить какую-то новую фичу, сначала зафиксируйте изменения для рефакторинга, а только потом (отдельным коммитом) добавьте эту фичу.

3. Добавляйте логирование и обработку ошибок на ранних стадиях.

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

Примерно то же самое и с обработкой ошибок — раз уж исключений всё равно не избежать, и они будут кидаться на протяжении всей жизни проекта, то почему бы не начать обрабатывать их систематически уже в самом начале?

4. Каждая новая строчка кода должна быть выполнена хотя бы один раз.

Прежде чем закончить работу по какой-либо функциональной возможности, её нужно протестировать. Ведь иначе как вы поймете, что она делает именно то, что должна? Часто лучший вариант для этого — автоматические тесты, хотя бывают и другие варианты. В целом не важно как, но главное, что управление должна получить каждая написанная вами строчка кода.

Иногда может быть сложно воспроизвести нужные условия, чтобы зайти во все ветки кода. К счастью, у вас есть возможность немного смухлевать, не обязательно стараться воспроизводить полностью боевые условия. К примеру, отлов ошибок базы данных можно проверить специально допустив ошибку в написании названия колонки. Или можно временно инвертировать условие внутри if, тогда случай «ошибка произошла» поменяется местами со «всё прошло корректно». Это полезно для ошибок, которые в принципе происходят очень редко и их сложно сымитировать.

Иногда мне попадаются баги, которые показывают, что определённая строчка кода вообще никогда не должна работать. Она может выглядеть вполне нормально внешне, во время code-review, но всё равно не работать так, как должна. Вы избежите таких ситуаций, если примете за правило всегда выполнять хотя бы один раз каждую новую строку.

5. Тестируйте по частям прежде, чем проверять весь проект на работоспособность.

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

6. Абсолютно всё занимает больше времени, чем вы думаете.

Особенно в программировании. Оценить, сколько времени уйдет на реализацию той или иной задачи, действительно трудно, даже если всё идет гладко. Но когда речь идет о разработке ПО, необходимо брать в расчет тот факт, что могут возникнуть неожиданные проблемы: в самое простое слияние может закрасться баг, обновление фреймворка вызовет необходимость изменить некоторые функции, или вызов API даст непредсказуемый или неверный результат.

Похоже старик Хофштадтер был прав, когда формулировал свой закон: «На любое дело требуется больше времени, чем казалось в начале, даже если вы учитывали при этом закон Хофштадтера».

7. Сначала поймите, что делает данный код.

В большинстве своем программирование подразумевает изменение существующего кода. Даже если вы включили в проект нечто совершенно новое, это новое должно стать частью написанного кода. Более того, необходимо понять найденное решение прежде, чем добавлять его. Иначе вы можете нарушить работоспособность чего-то, что уже было реализовано. Поэтому умение читать код так же важно, как умение его писать. И это еще одна причина, почему вроде бы простая задача по встраиванию кода может занять больше времени, чем кажется: нужно понимать контекст, в котором происходят изменения.

8. Читайте и запускайте код.

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

Отладка

9. Ошибки будут всегда.

Мне не очень нравится подход «Сделать всё с первого раза». Не имеет значения, сколько усилий вы потратите, ошибки будут всё равно («Мы об этом не подумали…»). Гораздо продуктивней запустить приложение и исправлять баги по мере поступления.

10. Реагируйте на отчеты об ошибках.

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

11. Воспроизводите проблему.

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

12. Исправьте известные ошибки и смотрите, что останется.

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

13. Совпадений не бывает.

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

14. Учитывайте временны́е метки.

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

Сотрудничество

15. Самая эффективная коммуникация — лицом к лицу.

Живой диалог не заменят видеоконференции, чат, звонок или электронная почта. Удивительно, насколько лучше становятся идеи и решения, если обсудить их с коллегами.

16. Резиновый утенок.

Если вы столкнулись с затруднениями, вы можете пойти к коллеге и рассказать ему о своей проблеме. Чаще всего, в процессе объяснения, вы сами придете к решению, даже если коллега не сказал ни слова. Звучит как магия, но работает достаточно часто.

17. Спрашивайте.

Чтение и запуск кода — отличный способ понять, как он работает. Но если у вас есть возможность спросить кого-нибудь компетентного (автора программы, к примеру), используйте её. Возможность задать вопрос и получить на него ответ, а затем, исходя из ответа задать дополнительные вопросы, позволит вам получить информацию за несколько минут вместо нескольких дней.

18. Признавайте заслуги других.

Говорите, напимер: «Маркусу пришла в голову замечательная идея …», вместо: «мы попробовали …». Старайтесь упомянуть всех, кто вам помог.

Разное

19. Экспериментируйте.

Если вы не уверены, как работает та или иная особенность языка, вы можете просто написать маленькую программу, которая продемонстрирует это на примере. Тот же самый метод применим и когда вы тестируете сложную систему. Что случится, если я передам -1 в качестве аргумента? А не упадет ли сервис, когда я перезагружу машину? Исследуйте, как что работает — вы наверняка обнаружите какие-то ошибки, и кроме того, глубже поймете систему.

20. Поспите.

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

21. Меняйтесь.

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

22. Учитесь.

Самая лучшая особенность ИТ — всегда есть, куда расти, есть, чему учиться. Пробуйте разные языки и инструменты, читайте книги, проходите онлайн-курсы. Маленькие улучшения, накапливаясь, значительно укрепят ваши навыки.

Перевод статьи «Lessons Learned in Software Development»