Что бы вы хотели, чтобы разработчики сделали по-другому? [закрыто]

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

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

1. Подумайте о безопасности и постройте ее с 0 дня.
2. Используйте контроль версий для всего: исходного кода, документации, конфигурации и т. Д.
3. Документация, документация, документация.
4. Чистая установка и удаление, используя встроенную платформу
5. Отдельные данные конфигурации от библиотек и исполняемых файлов
6. Поддержка параллельного запуска различных версий для тестирования и миграции.
7. Надежная, настраиваемая регистрация
8. Легкий, точный, безопасный мониторинг
9. Проверка приложений и резервное копирование
10. Как ваше приложение реагирует на проблемы: нехватка памяти, переполнение файловой системы, отключение сети, отсутствие / повреждение файлов конфигурации, перекос времени?
11. Всегда используйте отдельные среды разработки, тестирования и производства. Со всем бесплатным виртуальным программным обеспечением нет оправдания!

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

• вниз
• инициализация
• восстановление
• до-но-не-акцепторные-работы
• ожидания
• чекпойнтинг
• обработка
• Заканчивать
• Выключение
• вниз

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

Различают «пользователя» из SA.

«Пользователь» должен знать, как использовать ваше программное обеспечение. Пользователи не заботятся о том, как установить ваше программное обеспечение.

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

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

Одно из моих желаний - включение правильных сообщений в исключения и коды ошибок. Это совершенно непрозрачно для того, кто не разработал приложение, что JimmyNotAtHomeException: it's late!значит.

Но такое сообщение Unable to find jimmy - initial manual call_mother procedureочень полезно.

Общение, общение, общение. Любая проблема между системным администратором и разработчиком всегда может быть отслежена в результате отсутствия связи. Если до начала проекта системные администраторы (или их представители) и разработчики собрались вместе и провели приятную дискуссию, SOOOOOOOOOO, то можно избежать многих проблем в будущем. Я не могу сказать вам, сколько вещей запутано, потому что вы разрабатываете все на одном компьютере в процессе разработки, чтобы увидеть, как оно загорается в prod, потому что приложение затем разделяется на сервер приложений + сервер БД + сервер интерфейса и т. Д. Слава за поднятие этой темы.

Вовлеките нас рано в проект. Как очень по-настоящему рано, на стадии функциональной спецификации.

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

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

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

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

Не будь элитарным.

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

Разработчик фактически сказал мне эти слова однажды (1). По электронной почте CC'd большой группе распределения. Смысл был ясен: как разработчик, он был лордом и хозяином всей программной вселенной; и я был просто поденщиком, нанятым для решения задач, слишком тривиальных для него, чтобы тратить его драгоценное время на. Конечно, это пример наихудшего случая, но вы знаете, я слышал сильные и слабые отголоски этого комментария от ряда разработчиков как до, так и после (2).

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

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

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

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

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

(2) Я также работал со многими замечательными разработчиками, которые могут преподавать в случае необходимости и учиться в случае необходимости.

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

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

Обсудите проблемы с производительностью сисадминов. Честно говоря, только системные администраторы способны правильно интерпретировать показатели производительности в системах. Я видел, как разработчики решили, что в Linux всегда происходит утечка памяти, потому что свободная память, сообщаемая «free», всегда уменьшается, даже после 10-го раза объясняется вывод «free».

Не делайте выводов, не обсуждая это с сисадминами. Я видел, как разработчики зацикливались на таких теориях, как «базы данных всегда связаны с дисками» (они не знали, что iostat даже существует), «RAID 5 быстрее для транзакционных рабочих нагрузок» (основываясь на воспоминаниях об одной системе баз данных, которая была перемещена с одной аппаратной платформы на другую - это была интенсивная нагрузка на чтение, в решении RAID5 было больше и более быстрых дисков, распределенных по большему количеству контроллеров. Но они забыли эти детали и только помнили заключение.)

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

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

Либо послушайте, что говорит вам ваш системный администратор, либо пожаловайтесь руководству, что ваши системные администраторы некомпетентны и должны быть уволены. Игнорировать вашего сисадмина не имеет смысла.

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

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

Поймите, что есть разница между «медленно реагировать» и «вообще не отвечать».

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

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

Когда с приложением происходит межсерверная связь, пожалуйста, укажите хотя бы одного системного администратора на этапе проектирования. Кроме того, четко документируйте зависимости от других служб: SQL, SMTP, HTTP и т. Д. Не заставляйте нас угадывать, что вы делаете, или мы не можем помочь вам, когда что-то не работает, как вы ожидали.

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

У Adobe исторически было несколько инсталляторов, с которыми было очень трудно работать ; пожалуйста, цель выше, чем это!

Подумайте о масштабировании с первого дня. Сисадмины могут творить чудеса, бросая деньги / оборудование на проблемы с производительностью, но иногда никакие из них не помогут - в частности, подумайте о блокировке - иногда вы не можете выкупить себя из проблемы блокировки. Спасибо за вопрос, хотя :)

Да, и старайтесь быть 64-битными, где это возможно, и многопоточными тоже :)

Дизайн для операций.

Помимо всего прочего здесь ...

• Запросите смоделированную производственную среду (сервер разработки или виртуальную машину с той же конфигурацией, что и у действующего сервера), а затем используйте ее для тестирования процесса выпуска. Затем предоставьте нам этот процесс выпуска, включая список изменений и порядок, в котором они должны применяться (например, 1. Войдите в режим обслуживания, 2. примените обновление SQL, 3. обновите источник до версии X, 4. выйдите из режима обслуживания, 5. молись)
• Убедитесь, что у вас есть режим обслуживания, который может выгнать пользователей для сохранения целостности данных. Вы не хотите, чтобы мы запускали большое обновление системы на нескольких серверах, когда пользователи входили в систему и выполняли транзакции ... в большинстве случаев это рецепт сбоя.
• Используйте модель разработки, которая несколько стандартизирована. Например, все наши новые приложения на работе (веб-группа) используют Zend Framework.
• Предоставьте нам журналы изменений, которые мы можем прочитать, включая список исправленных ошибок, которые мы можем найти, чтобы получить представление о масштабах изменений. Иногда мы можем определить потенциальные проблемы только потому, что у нас другая точка зрения.

Хотя это и нереально, было бы полезно, если бы разработчики были вынуждены работать в роли производственного sysadmin или dba, прежде чем их выпустили в мир.

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

1) Файл журнала, в котором подробно регистрируются ошибки. или хорошая система отслеживания ошибок, как ELMAH.

2) Подробная документация по установке, внедрению и руководство SA.

3) Плюс материал, упомянутый выше, от других удивительных SA. :)

Это все, что я могу думать прямо сейчас.

Книга Выпусти это! есть хороший выбор страшных историй о том, что может пойти не так в производстве. Чтение этого может дать вдохновение / идеи для проектирования с учетом операций. (Он написан Майклом Найгардом, который работал над разработкой и эксплуатацией).

• Не развивайся без спецификаций
• Документ (или убедитесь, что те, кто делает документ, делают это точно)
• Не бойтесь поддерживать клиента (как более высокий уровень поддержки)

По моему опыту, самое главное, если бы разработчики подумали о развертывании с первого дня. Как только вы начнете задумываться о новой функции в среде производства / заказчика, начните думать о том, как она будет развернута в ней. среда, и как это будет работать.

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

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

Хотелось бы, чтобы у разработчиков было лучшее отделение от задач QA. Я думаю, что это хорошо, когда разработчик может создать несколько тестовых примеров для проекта, над которым он / она работает, но было бы хорошо, если бы эти тесты были переданы в QA. На самом деле, приятно, когда разработчики оказывают небольшую помощь инженерам по обеспечению качества, потому что это в конечном итоге приносит пользу DEV.

Убедитесь, что он поддерживается: в дополнение ко всему остальному, упомянутому здесь, посмотрите на этот пост в SO - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- документация/