Существует ли парадигма программирования, которая способствует тому, чтобы сделать зависимости чрезвычайно очевидными для других программистов?

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

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

Трудно объяснить преимущества этого моей команде. Они склонны просто принимать вещи такими, какие они есть, и не «мыслить масштабно» с точки зрения того, чтобы увидеть преимущества возможности концептуализировать всю систему по-новому - они на самом деле не видят этого, если вы сможете смоделировать огромную систему чем эффективнее, тем меньше вероятность того, что вы столкнетесь с неэффективностью памяти, остановкой потока уникальных ограничений и дубликатов ключей, бессмысленными данными, потому что намного проще спроектировать их в соответствии с первоначальным видением, и вы не столкнетесь со всеми этими проблемами, которые сейчас мы переживаем то, что, как я знаю, необычно по сравнению с прошлым, но кажется, что оно кажется им неизбежным.

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

Понятность

Его отсутствие мучает многие организации. Где тот инструмент, который Фред построил снова? В репозитории Git, конечно. Где?

Образец программного обеспечения, который приходит на ум, это Model-View-ViewModel. Для непосвященных этот шаблон является полной загадкой. Я объяснил это своей жене как «пять виджетов, плавающих над столом и говорящих друг с другом с помощью какой-то таинственной силы». Понять шаблон, и вы понимаете программное обеспечение.

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

Команда несет ответственность за разработку разумной организационной архитектуры и ее документирование. Это включает в себя такие вещи, как

• Папочная организация
• Ссылки на проекты
• Документация класса (что это такое, что оно делает, почему оно существует, как оно используется)
• Проект, модуль, сборка, любая документация.

Команда несет ответственность за то, чтобы все было организовано и открыто, чтобы команда не постоянно изобретала велосипед.

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

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

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

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

Архитектура.

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

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

В идеале эти правила объединены единством ума.

Небольшая команда, безусловно, может создавать архитектуру совместно. Но, с различными мнениями, это может быстро привести к очень шизофренической архитектуре, которая не служит для поддержания вашего здравомыслия. Самый простой способ убедиться в том, что ваша архитектура, а также множество TLA и шаблонов в ней, служат единодушному успеху команды, состоит в том, чтобы за них отвечал единый разум.

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

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

Добро пожаловать в Software Engineering (в обоих смыслах);) Это хороший вопрос, но на самом деле простых ответов не существует, как я уверен, вы в курсе. Это действительно случай, когда со временем развиваются лучшие практики, обучающие людей быть более умелыми (по определению большинство людей в отрасли обладают посредственной компетенцией) ...

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

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

Идеи, на которых вы могли бы сосредоточиться, - это (со временем, постепенно) изоляция и рефакторинг ключевых частей системы таким образом, чтобы сделать их более модульными и отделенными, удобочитаемыми и обслуживаемыми. Хитрость заключается в том, чтобы работать с существующими бизнес-требованиями, так что сокращение технического долга может быть сделано одновременно с предоставлением видимой ценности для бизнеса. Таким образом, решение состоит в том, чтобы частично улучшить методы и навыки, а частично попытаться продвинуться в направлении долгосрочного архитектурного мышления, как я уже могу сказать.

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

Мне нравится идея @ RobertHarvey о конвенциях и я думаю, что они помогают. Мне также нравится идея @ KarlBielefeldt «документировать по ходу дела» и знаю, что это важно, потому что это единственный способ поддерживать актуальность документации. Но я думаю, что общая идея заключается в том, что документирование того, как найти все части вашего кода, собрать и развернуть их, важно!

Недавно я отправил по электронной почте важный проект с открытым исходным кодом, в котором была некоторая конфигурация XML, в результате чего код был полностью недокументирован. Я спросил сопровождающего: «Где задокументирован этот процесс генерации XML-кода? Где задокументирована настройка тестовой базы данных?» и он сказал: «Это не так». В основном это проект с одним вкладчиком, и теперь я знаю почему.

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

В бизнесе отсутствие документации - это огромная трата времени и энергии. Подобные проекты часто направляются консультантам, которые стоят еще дороже, просто чтобы они могли разобраться в основных вещах, таких как «где все части и как они сочетаются друг с другом».

В заключение

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

Чтобы ответить на вопрос в том виде, в котором он задан (вместо того, чтобы дать вам совет для вашей конкретной ситуации):

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

Каждое хранилище данных отличается, но вы можете многое сделать, чтобы упростить себе задачу.

Для начала, каждая строка в базе данных имела столбцы DATE_ADDED и DATA_UPDATED, чтобы мы могли видеть, когда он был добавлен в базу данных и когда он был изменен. У нас также был столбец SOURCE_CODE, чтобы мы могли отслеживать, где каждый бит данных поступает в систему.

Затем у нас были общие инструменты, которые работали со всеми нашими хранилищами данных, такие как сортировки, сопоставления таблиц, слайсеры и разделители и т. Д.

Сделанный на заказ код был сведен к абсолютному минимуму, и даже тогда он должен был соответствовать различным стилям кодирования и отчетности.

Я предполагаю, что вы уже знакомы с комплектами ETL . В эти дни вы получаете множество функциональных возможностей, которых не было, когда я был в игре около десяти лет назад.

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

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

• Избегайте глобальных переменных, используйте вместо них параметры. Это относится и к кросс-языковым вызовам.
• Избегайте изменения / изменения значений переменных, насколько это возможно. Создайте новую переменную и, если возможно, используйте, когда вам нужно изменить значение.
• Сделайте код модульным. Если невозможно описать, что (не как) часть фактически делает в простом предложении, разбейте его на модули, которые удовлетворяют условию.
• Назовите свои части кода правильно. Когда вы действительно можете описать, что часть кода делает в простых терминах, эти термины становятся названием части. Таким образом, код становится самодокументированным через имена модулей / классов / функций / процедур / методов и т. Д.
• Проверьте свой код. Проверьте, оправдывают ли сущности в вашем коде свои имена, о которых говорилось в предыдущем пункте.
• Журнал событий в коде. По крайней мере поддерживать два уровня журнала. Первый всегда включен (даже в рабочей среде) и регистрирует только критические события. И используйте другой, чтобы регистрировать в основном все, но может быть включен или выключен.
• Найдите и используйте подходящие инструменты для просмотра, поддержки и развития вашей кодовой базы. Даже простая опция «Искать все» в коде Visual Studio значительно упростила мою жизнь.