Почему современный программный комплекс?
И кто виноват
Почему большинство современных программ настолько сложны, что несколько уровней абстракции накладываются друг на друга? Почему они не делают простые и эффективные программы, как раньше?
Несколько основных причин:
1. Обслуживание кода
В сети уже много лет циркулирует старая юмористическая статья под названием «Если бы архитекторам приходилось работать как программисты». Оно написано так, как будто это письмо от покупателя жилья, который хочет, чтобы архитектор построил дом. Вот выдержка:
«Пожалуйста, спроектируйте и постройте мне дом. Я не уверен, что мне нужно, вы должны действовать по своему усмотрению. В моем доме должно быть от двух до сорока пяти спален. Просто убедитесь, что планы такие, чтобы спальни можно было легко добавить или удалить. Когда вы принесете мне чертежи, я приму окончательное решение о том, чего хочу. Также принесите мне разбивку по стоимости для каждой конфигурации, чтобы я мог выбрать одну произвольно ».
Это смешно, потому что похоже на то, как программисты задаются своими требованиями к программному обеспечению. Поскольку программное обеспечение может быть изменено после его создания, работодатель предполагает, что это легко сделать и что им не нужно четко указывать, чего они хотят.
Люди в области разработки программного обеспечения на протяжении многих лет изо всех сил старались приспособиться к этому, создавая все больше и больше абстракций, чтобы части программного обеспечения можно было легко изменять, комбинировать, обновлять или заменять.
Работодатель хочет этого, потому что это позволяет им получать программное обеспечение по доступному графику, без принуждения работодателя к написанию подробных спецификаций, о которых они, вероятно, не знают заранее.
Программист хочет этого, потому что хочет остаться на работе.
2. Возможность повторного использования кода
Хороший способ повысить качество кода без увеличения расписания - писать меньше индивидуального кода, а вместо этого использовать больше кода, который был написан и протестирован задолго до вашего проекта. Мы называем эти библиотеки, фреймворки, шаблоны или генераторы кода.
Вы, наверное, использовали игрушки Lego, из которых вы можете создавать сложные модели, используя простые многоразовые кирпичи или другие специальные детали. Вы можете построить практически что угодно, используя достаточно кирпичей. Также есть несколько специализированных форм и множество руководств, показывающих, как их комбинировать для создания желаемых моделей.
Это похоже на повторное использование кода. Затем разработка программного обеспечения превращается в деятельность по изучению всех различных частей и способов их совместного использования.
Код можно использовать повторно из-за абстракций. Например, детали Lego, которые имеют стандартные размеры и соединительные кнопки, чтобы их можно было прикрепить к другим деталям.
3. Особенности, особенности, особенности
Однажды я разработал приложение для менеджера, которому очень сложно принимать решения. Каждый раз я спрашивал его: «Вы хотите, чтобы приложение вело себя так или иначе?» Я часто спрашивал о двух исключающих друг друга альтернативах. Например, вы хотите, чтобы в отчете категории данных располагались в строках или столбцах?
Он всегда отвечал «и то и другое». Он не знал, как выбирать, и боялся сделать неправильный выбор. Поэтому он попросил меня реализовать обе альтернативы и сделать программное обеспечение настраиваемым. Он хотел, чтобы у него была возможность менять свое мнение позже так часто, как он хотел.
Это как минимум удвоило работу по реализации кода и удвоило тестирование, необходимое, чтобы убедиться, что он работает.
Но было хуже - каждый раз, когда он говорил «оба», это удваивало количество тестовых примеров, потому что я должен был гарантировать, что новая функция работает с каждой комбинацией альтернатив для прошлых функций.
Программисты не могут сказать «нет», когда их работодатели хотят некоторых функций. Они могут сказать: «Хорошо, но вот сколько это будет стоить времени и денег, вы все еще хотите?»
Была ли эта статья вам полезна? Мы будем рады услышать ваши отзывы! Подпишитесь на нас в Твиттере и следите за новостями в этом блоге, чтобы получать больше интересных новостей, идей и ресурсов из захватывающего мира микросервисов.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Microservice Geeks не нанимает, не заключает контракты или иным образом не поддерживает какие-либо коммерческие связи со своими авторами и участниками. Мнения, выраженные в этой статье, принадлежат ее авторам и не отражают точку зрения компьютерных фанатов.
