[Habr, Программирование, Анализ и проектирование систем, Управление разработкой] Хабр — ума палата
Автор
Сообщение
news_bot ®
Стаж: 6 лет 7 месяцев
Сообщений: 27286
При создании нового или не стандартного решения архитектор/разработчик обычно ищет компромисс между тем что хочется и тем, что нужно с учетом заданных ограничений. И всегда существует возможность в конечном итоге сделать не то, что ожидалось или получить далеко не оптимальное решение.
И если «хотели как лучше, а получилось как всегда» случается из-за неучтенных или изменившихся требований, то это хотя бы можно объяснить. Но порой и на старуху бывает проруха и становится досадно пропустить детскую ошибку просто из-за замылившихся глаз или из-за подводных камней реального использования модной технологии.
И чтобы минимизировать возможность таких ошибок, во многих компаниях существует практика защиты архитектурного решения перед началом непосредственной разработки нового крупного проекта. Это может быть организовано в виде собрания, проведения архитектурного ревью или просто обсуждения в курилке. Тут все зависит от штатной структуры и размера компании, а так же от поставленных процессов разработки.
А что делать, если разработчиков в компании раз-два и обчелся, либо их опыта недостаточно для экспертной оценки всего решения? Или у них просто отсутствует время или желание вникать в чужие трудности?
Наверно, вы уже догадались, что речь идет об использовании Хабра в качестве площадки, где можно получить реальную помощь от знающий людей.
И действительно, путем публичного обсуждения, можно получить замечательную обратную связь. Причем, написание статьи для Хабра значительно проще и удобнее, чем готовится к защите на архитектурном комитете. Не нужно согласовывать дату и время, когда можно оторвать людей от основного процесса. А им в свою очередь, не нужно сразу включаться в контекст, чтобы иметь возможность участвовать в обсуждении деталей.
«В свое время» мне довелось участвовать работе архитектурного комитета крупной компании. И ощущение после завершения каждой встречи всегда было двоякое. С одной стороны, очень здорово получить новый опыт и зачастую реальную помощь. Но бывало и так, что обычное обсуждение, казалось бы мелкого вопроса, превращалась в словесную баталию, отголоски которой долетали по прошествии нескольких дней.
Особенно мне запомнился опыт участия в процессе унификации используемых компонентов. Согласование интерфейса и реализации одного малюсенькой библиотеки заняло более полутора лет и потребовало нескольких полных переделок всей реализации. В результате куча убитого времени на приведение кода в юзабельное состояние, которое бы удовлетворило всех потребителей и полностью выгоревшее желание, делать еще раз, что либо подобное.
С этой стороны, статья на Хабре становится просто идеальным вариантом, когда в компании недостаточно компетенции для организации обсуждения сложного вопроса. И что самое главное, какое бы решение и советы вы не получили в процессе обсуждения статьи, вас никто не заставляет им следовать! :-)
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление персоналом, Карьера в IT-индустрии] Дайджест событий для эйчаров и рекрутеров в IT на февраль 2021
- [Программирование, Разработка мобильных приложений, Конференции, Flutter] Анонс вебинара «Почему компании всё чаще выбирают Flutter и что это значит для разработчиков»
- [Программирование, C#, Учебный процесс в IT] Как избавиться от if-else при помощи команд и обработчиков (перевод)
- [Управление разработкой, Бизнес-модели, Микросервисы] Моделирование микросервисов с помощью Event storming
- [Программирование, Алгоритмы, Компиляторы, Математика] Тактическая оптимизация или результаты одного тестирования
- [Ruby, Программирование, Ruby on Rails, Функциональное программирование] Метапрограммирование в реальной задаче
- [Программирование, Java, API, Хакатоны] Тривиальная и неправильная «облачная» компиляция
- [Информационная безопасность, Анализ и проектирование систем, API, Исследования и прогнозы в IT] OAuth 2.0 -> OAuth 2.1. Что дальше?
- [Программирование микроконтроллеров, Производство и разработка электроники, DIY или Сделай сам, Игры и игровые приставки, Электроника для начинающих] STM32F429 + IL9341 = LVGL, DOOM1
- [C++, Системное программирование, Программирование микроконтроллеров] Запуск сложных C++ приложений на микроконтроллерах
Теги для поиска: #_habr, #_programmirovanie (Программирование), #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_upravlenie_razrabotkoj (Управление разработкой), #_habr (хабр), #_arhitektura (архитектура), #_arhitekturnyj_komitet (архитектурный комитет), #_razrabotka_prototipa (разработка прототипа), #_habr, #_programmirovanie (
Программирование
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 05-Окт 20:28
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 7 месяцев |
|
|
При создании нового или не стандартного решения архитектор/разработчик обычно ищет компромисс между тем что хочется и тем, что нужно с учетом заданных ограничений. И всегда существует возможность в конечном итоге сделать не то, что ожидалось или получить далеко не оптимальное решение. И если «хотели как лучше, а получилось как всегда» случается из-за неучтенных или изменившихся требований, то это хотя бы можно объяснить. Но порой и на старуху бывает проруха и становится досадно пропустить детскую ошибку просто из-за замылившихся глаз или из-за подводных камней реального использования модной технологии. И чтобы минимизировать возможность таких ошибок, во многих компаниях существует практика защиты архитектурного решения перед началом непосредственной разработки нового крупного проекта. Это может быть организовано в виде собрания, проведения архитектурного ревью или просто обсуждения в курилке. Тут все зависит от штатной структуры и размера компании, а так же от поставленных процессов разработки. А что делать, если разработчиков в компании раз-два и обчелся, либо их опыта недостаточно для экспертной оценки всего решения? Или у них просто отсутствует время или желание вникать в чужие трудности? Наверно, вы уже догадались, что речь идет об использовании Хабра в качестве площадки, где можно получить реальную помощь от знающий людей. И действительно, путем публичного обсуждения, можно получить замечательную обратную связь. Причем, написание статьи для Хабра значительно проще и удобнее, чем готовится к защите на архитектурном комитете. Не нужно согласовывать дату и время, когда можно оторвать людей от основного процесса. А им в свою очередь, не нужно сразу включаться в контекст, чтобы иметь возможность участвовать в обсуждении деталей. «В свое время» мне довелось участвовать работе архитектурного комитета крупной компании. И ощущение после завершения каждой встречи всегда было двоякое. С одной стороны, очень здорово получить новый опыт и зачастую реальную помощь. Но бывало и так, что обычное обсуждение, казалось бы мелкого вопроса, превращалась в словесную баталию, отголоски которой долетали по прошествии нескольких дней. Особенно мне запомнился опыт участия в процессе унификации используемых компонентов. Согласование интерфейса и реализации одного малюсенькой библиотеки заняло более полутора лет и потребовало нескольких полных переделок всей реализации. В результате куча убитого времени на приведение кода в юзабельное состояние, которое бы удовлетворило всех потребителей и полностью выгоревшее желание, делать еще раз, что либо подобное. С этой стороны, статья на Хабре становится просто идеальным вариантом, когда в компании недостаточно компетенции для организации обсуждения сложного вопроса. И что самое главное, какое бы решение и советы вы не получили в процессе обсуждения статьи, вас никто не заставляет им следовать! :-) =========== Источник: habr.com =========== Похожие новости:
Программирование ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_upravlenie_razrabotkoj ( Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 05-Окт 20:28
Часовой пояс: UTC + 5