Сложно ли поддерживать ваше программное обеспечение?
Опытные инженеры-программисты учатся хорошему дизайну программного обеспечения после многих лет работы.
Вы узнаете, что искать в хорошем дизайне, когда вам приходилось добавлять десятки функций в существующую кодовую базу в течение нескольких лет. Еще лучше, когда вы полностью отказываетесь от старого решения и заменяете его чем-то новым. Ключ к отличному дизайну заключается в том, выдержит ли он испытание временем.
Отличные проекты должны быть расширяемыми, ремонтопригодными и удобными в использовании.
1. Расширяемость. Насколько легко поддерживать больше типов вещей, которые могут быть добавлены?
Выясните, что, вероятно, вам нужно будет расширить, и запланируйте это в дизайне.
Проекты обычно похожи на общие функции. Будет несколько мест, где вам нужно будет поддерживать больше типов подобных вещей.
Например, я построил конвейер обработки изображений, и нам нужно было поддерживать кодирование изображений для разных продуктов в приложении и кодирование их до разных размеров для каждого варианта использования.
У нас было две оси свободы, которые должны были быть универсальными: изображения для разных вариантов использования и изображения разных размеров. Нам постоянно приходилось добавлять новые варианты использования и размеры. Таким образом, дизайн должен был максимально упростить размещение большего количества вещей. Мы сделали это, сделав этот слой настраиваемым.
Выясните, какие части вашего проекта, скорее всего, потребуются для поддержки новых вариантов использования в будущем. Затем сделайте эту часть настраиваемой.
Есть один антишаблон, которого следует избегать: не переоптимизируйте слой конфигурации преждевременно.
Я думаю, что слишком часто инженеры имеют тенденцию оживлять свою конфигурацию на каком-то языке конфигурации, таком как yaml или thrift. Но происходит то, что они определяют эту огромную спецификацию, в которой на самом деле настроена только половина исходных свойств — остальные обычно остаются прежними.
Я выступаю за то, чтобы сначала сохранить конфигурацию в коде (вы все равно разбираете файл YAML в код, верно?), а затем, после полдюжины вариантов использования, превратить его в правильный файл конфигурации — не забудьте документация!
Хороший дизайн гарантирует будущее в тех областях, где вы, вероятно, собираетесь добавить больше.
2. Ремонтопригодность: насколько легко устранять проблемы при их возникновении?
Готов поспорить, что за время существования системы больше времени тратится на ее отладку, чем на ее создание.
Отличный дизайн упрощает отладку. Отладка должна быть доступна любому члену команды.
После того, как система построена, у вас, вероятно, будет дежурный человек, который позаботится о ней, если что-то пойдет не так. Старшие инженеры также знают, что они, скорее всего, довольно быстро перейдут к другим проектам и не всегда будут рядом, чтобы помочь.
Как упростить обслуживание системы?
Он должен использовать простой дизайн. Чем неожиданнее ваш дизайн, тем сложнее людям понять, что происходит. Вы должны использовать дизайн, который наиболее распространен там, где вы работаете. Если вы попытаетесь противостоять тренду, это часто приведет к путанице. (Я худший виновник)
Повторно используйте компоненты, которые хорошо используются в вашей компании — не пытайтесь использовать новую технологию, вам лучше использовать то, что поддерживает остальная часть компании.
Если вы используете технологии, которые поддерживают другие команды, вам нужно заботиться об одном компоненте меньше.
3. Удобство использования: насколько легко вашим клиентам, другим командам или проектам интегрировать ваш дизайн?
Ваш проект не существует в вакууме — его должны использовать другие люди.
Как только ваша система заработает, вы будете тратить столько же или даже больше времени, помогая другим людям использовать ее, как и ее отладку. Сокращение времени, которое вы тратите на объяснение того, как оно работает и как его использовать, — это самый простой способ вернуть время для других дел.
Как вы проектируете юзабилити?
Очень похоже на ремонтопригодность, оно должно следовать соглашениям о том, как люди склонны создавать вещи в вашей компании. Принимают ли ваши API обычные объекты? Используете ли вы те же фреймворки, что и все остальные?
Оцените свой дизайн по тому, сколько работы придется сделать кому-то из другой команды, чтобы интегрироваться. Могут ли они вызвать ваш API тем, что у них есть? Сколько шагов нужно, чтобы что-то настроить?
Одна из самых важных вещей, когда ваш проект созреет, это: насколько активно ваша команда должна привлечь нового клиента?
В 2002 году Джефф Безос издал свой печально известный Мандат API, который требовал, чтобы все сервисы были самообслуживаемыми: команды должны общаться друг с другом через API.
Если у вас много клиентов, вам нужно убедиться, что им будет очень легко подключиться.
Следствием этого является то, что чем меньше у вас клиентов, тем меньше времени вам нужно тратить на то, чтобы сделать свой дизайн самообслуживающим.
