Есть ли смысл в создании кода, настолько гибкого, что его не нужно будет обновлять?

Question

В настоящее время я участвую в дискуссии с моими коллегами о том, как мне разработать API, который будет использоваться моим отделом. В частности, мне поручено написать API, который будет служить оболочкой фасадом для доступа к информации Active Directory - с учетом потребностей моей компании / отдела. Мне известно, что упаковщики фасады с открытым исходным кодом уже существуют, но не является сутью этого вопроса и просто используется в качестве примера.

Когда я представил свое проектное предложение моей команде, они сбили меня с толку, потому что API не был достаточно «настраиваемым». Они утверждали, что не хотят, чтобы API устанавливал связь между «номером телефона» и <представлением номера телефона в Obscure Active Directory>. Каждый участник собрания (кроме меня) согласился с тем, что он предпочел бы спросить: «Какое правильное поле в Active Directory использовать для номера телефона пользователя?» И вставить его в свои соответствующие приложения (LOL!).

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

Является ли это действительно правильным отношением при разработке программного обеспечения?!

Answer 1

http://en.wikipedia.org/wiki/Inner_platform_effect

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

Answer 2

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

Answer 3

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

Имена столбцов

Конкретно в вашем случае столбцы в таблицах - это нестатическая переменная. Обычно они меняются по мере изменения ваших потребностей.

Если у вас есть столбец " phonenum ", то они добавляют второй номер телефона, они меняют столбец на " phonenum1 " и " phonenum2 " , Это должно быть изменено в коде. Затем, если они изменят их на « Home_Phone », « Work_Phone », « Cell_Phone », код снова должен быть изменен. Однако, если у вас есть файл сопоставления (файл конфигурации ключ / значение), все эти изменения будут чрезвычайно просты для внесения.

В общем

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

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

Вы должны писать приложения, чтобы внешние (окружающие) изменения НЕ требовали изменений кода. Такие вещи, как

• Смена пароля пользователя базы данных
• Изменение имен столбцов
• Изменение папки «Temp folder»
• Имя целевой машины / изменение IP-адреса
• Приложение должно запускаться два раза в день, а не один раз
• Уровни логирования

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

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

Answer 4

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

Сказав, что в вашем конкретном примере вы описываете API, который обеспечивает фасад поверх службы ActiveDirectory - тот, который, по-видимому, предназначен для использования различными группами и / или проектами в вашей организации.

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

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

Answer 5

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

Answer 6

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

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

Answer 7

Если вы говорите: «Должен ли я все кодировать жестко», то я думаю, что это не очень хорошая идея.

Через 2 года вас не будет, и найдется программист, который потратит много времени на попытки обновить ваш устаревший код, когда обновление файла конфигурации было бы намного проще.

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

Answer 8

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

Однако, если цель API состоит в том, чтобы просто быть набором классов, которые абстрагируют детали доступа к Active Directory, а не от того, какие свойства доступны, то то, что указали ваши коллеги, - это путь.

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