Мое становление как программиста началось в 2005 году и продолжается по
сей день. Несомненно, многие читатели смогут похвастаться более обширным
опытом, но речь пойдет о другом. Мой профессиональный рост наложился на
интересный период - повышение культуры программирования в рунете, если это
можно так назвать. Профессионалы были всегда, но сегодня подкованность
среднего программиста(во всяком случае в сфере best pracices) несравнимо
выше, чем тогда.
И само по себе это не плохо, опасения вызывает сам тренд который привел к
подобному результату. При его продолжении мы можем всерьез столкнуться с той
же проблемой, с которой все и началось - а именно с говнокодом, но на сей раз
говнокодом облагороженным, прикрытым множеством абстракций, а порой самими
этими абстракциями и являющимся. Да-да, сегодня опять критикуем
оверинжениринг.
Рубрика «проектирование» - 28
Вне области применения
2013-04-25 в 22:52, admin, рубрики: Анализ и проектирование систем, нытьё, Программирование, проектирование, Совершенный код, трэш-аналитика, Учебный процесс в IT, метки: нытьё, проектирование, совершенный код, трэш-аналитикаСерьезное проектирование серьезных сайтов. Часть 1. Аналитика
2013-04-25 в 11:05, admin, рубрики: secl group, usability, аналитика, Блог компании SECL GROUP, веб-дизайн, идеи, интерфейсы, проектирование, сайтостроение, юзабилити, метки: secl group, аналитика, веб-дизайн, идеи, интерфейсы, проектирование, сайтостроение, юзабилитиСразу скажу, что статья получилось очень большая. В моем духе. Поэтому я решил разбить её на две части: аналитика и визуализация. А после еще будет несколько статей с логическим продолжением. Первая может показаться сухой из-за большого количества текста, но без неё не сможет существовать вторая. Поэтому, если вы действительно интересуетесь проектированием сайтов, читать нужно обе и внимательно, я постарался избавиться от «воды» и рассказать только о полезном.
И еще статья описывает технологию проектирования, однако она не учитывает специфики подходов waterfall и agile. С waterfall данную технологию проектирования можно применять без изменений, а вот для agile придется оптимизировать.
Вступление
Начиная писать эту статью, я сразу вспомнил аналогию с проектированием дома, а если точнее, целого небоскреба с торговыми центрами, офисами и жилыми помещениями. В такой масштабной стройке никто не начнет строительные работы, пока все до мелочей не будет учтено в проекте этого небоскреба. Причем требований огромное множество: помещения должны быть правильно расположены, материалы должны быть долговечные, небоскреб должен быть устойчив к землетрясениям и т.д. Все отлично понимают важность проектирования зданий, потому что от этого зависит не только удобство его использования, но и жизни людей. Я не строитель, я итишник, а если точнее – я концептуальщик, занимаюсь концепциями и проектированием больших сайтов уже много лет. Из опыта могу со стопроцентной уверенностью сказать, что успех любого большого сайта зависит именно от проектирования: все точно также, как в строительстве, только на кону не жизни людей, а успешность сайта. Именно поэтому в этой статье я хочу рассказать, как и почему нужно проектировать большие сайты.
Прежде всего, давайте разберемся, кто именно должен заниматься проектированием сайтов. Существует особая специальность для этого вида работ, а соответствующий человек называется проектировщик. Я сознательно не употребляю модных понятий типа UI (UX), потому что в статье речь будет идти не только об интерфейсах. Данный специалист должен обладать хорошей логикой, аналитическим складом ума, иметь очень богатый пользовательский опыт, мыслить предпринимательскими (экономическими) масштабами, быть внимательным к деталям. Кроме этого, он должен хорошо разбираться в интерфейсах и юзабилити, технологиях веб-разработки, маркетинге и многих других сферах. В процессе работы проектировщик, конечно, может советоваться с разными экспертами: дизайнерами, верстальщиками, программистами и т.д., дабы спроектировать продукт наивысшего качества. Получился довольно широкий образ идеального проектировщика, однако «из песни слов не выкинуть».
Процесс проектирования
В методологии ниже я буду описывать теорию, и сразу практический пример результатов работы по конкретному этапу для одного из наших проектов.
Читать полностью »
Рефакторинг с бубном, или как мы халка усмиряли
2013-04-24 в 7:54, admin, рубрики: .net, usercontrol, Блог компании «Дневник.ру», Веб-разработка, проектирование, Проектирование и рефакторинг, рефакторинг, метки: .net, usercontrol, Веб-разработка, проектирование, рефакторинг 
Думаю, все согласятся, что большинство стартапов изначально сделаны на коленке. Только потом, в случае удачного выстреливания, при грамотном руководстве и понимании стратегических целей владельцы ресурса могут принять решение о рефакторинге существующего продукта. Хорошо, если это произошло раньше превращения Брюса Баннера в Халка. Но что делать, если такой момент был благополучно пропущен, и ресурс представляет собой огромного зеленого плохо-контролируемого гиганта? Как поступить в такой ситуации? Читать полностью »
Как стать настоящим аналитиком требований. Часть 1. Великими аналитиками рождаются или становятся?
2013-04-22 в 19:27, admin, рубрики: human resources, Анализ и проектирование систем, Блог компании Нордавинд, проектирование, метки: проектирование «Великих аналитиков взращивают, а не обучают. Для работы аналитиком требуется множество личностных черт, а не знаний каких-либо технологий. Стандартного обучающего курса или описания обязанностей такого специалиста не существует. В аналитики приходят из разных профессий, и, скорее всего, у всех новичков есть пробелы в знаниях и навыках»
Вигерс Карл «Разработка требований к программному обеспечению», 2004
Карл Вигерс написал свою книгу практически 10 лет назад, но ситуация не изменилась – настоящих аналитиков единицы.
Эта серия статей – для тех, кто собирается стать профессиональным аналитиком требований. Информация собрана из личного опыта, книги Карла И. Вигерс «Разработка требований к программному обеспечению», а так же из опыта других аналитиков из сети Интернет.Читать полностью »
Проектируем по DDD. Часть 1: Domain & Application
2013-03-22 в 11:26, admin, рубрики: .net, DDD, domain-driven design, Программирование, проектирование, Проектирование и рефакторинг, метки: .net, DDD, domain-driven design, проектированиеxxx: там порог вхождения выше
xxx: тебе на asp.net'е hello world настрогать за 10 минут научиться можно (8 минут на запуск студии, 2 на кодинг)
xxx: на java такое не прокатит
xxx: пока скачаешь одну библиотеку, пока другую, пока их xml конфигом на полметра склеишь, пока маппинг для hibernate настроишь, пока базу нарисуешь, пока веб-сервисы поднимешь
xxx: вроде и hello world пишешь, а уже две недели прошло и всем кажется, что это учетная система для малого бизнеса
© ibash.org.ru/quote.php?id=15446
В серии из нескольких статей я хотел бы на простом, но имеющим некоторые нюансы, примере рассказать о том, как имея готовые domain и application слои реализовать под них инфраструктуру для хранения и извлечения данных (infrastructure for persistence) используя две различные популярные технологии – Entity Framework Code First и Fluent NHibernate. Если вы хотя бы слышали про три буквы DDD и у вас нет желания послать меня на тоже три, но другие буквы — прошу под кат.
Где мой робот?
2013-03-12 в 6:59, admin, рубрики: атомная бомба, будущее, История ИТ, компьютеры, космос, Пентагон, персональные компьютеры, проектирование, Процессоры, ретрофутуризм, робототехника, сколково, метки: intel, атомная бомба, будущее, история IT, компьютеры, космос, Пентагон, персональные компьютеры, проектирование, процессоры, ретрофутуризм, робототехника, сколково 
Недели две назад мой младший брат затащил меня на международную конференцию по робототехнике в Сколково. Я тогда так и не сдюжил написать отчет, вот nuzgul своим постом привел меня в такое возмущение, что я наконец-то нашел в себе силы разложить все по- полочкам. У него безосновательно утверждается, что «Судя по всему, наивные мечты фантастов постепенно уходят в прошлое и выясняется, что роботы-андроиды — это не лучшие работники и бал править будут специализированные устройства». Как тот самый наивный фантаст, позволю себе некоторые размышления. Возможно они многих разозлят, по этому под кат заглядывайте на свой страх и риск, я предупредил.
История развития методологий проектирования (программной инженерии)
2013-03-04 в 9:45, admin, рубрики: agile, devops, waterfall model, методологии разработки, Песочница, программная инженерия, проектирование, управление проектами, Управление проектом, метки: agile, DevOps, waterfall model, методологии разработки, программная инженерия, проектирование, Управление проектом .jpg "История развития методологий проектирования (программной инженерии)")
-2.gif "История развития методологий проектирования (программной инженерии)")
При написании статьи у меня возникли большие трудности с поиском информации. Информации просто не было. После долгого копания в страницах гугла обнаружилось, что терминология проектирования в русском языке несколько отличается. В русском языке проектирование это один из этапов разработки программного обеспечения, а дисциплина, изучающая проблематику создания и управления проектами, методологий проектирования и т.д. называется программной инженерией или технологией промышленного программирования(если совсем по русски). Если еще остались те кто этого не знал, то возможно мое замечание, вам, немного поможет.
С чего все начиналось
Как закончить проект в срок?
2013-03-04 в 8:24, admin, рубрики: agile, оценка времени, оценка трудозатрат, проектирование, управление проектами, метки: agile, оценка времени, оценка трудозатрат, проектированиеЭтот пост навеян оценкой большого технологического проекта, в которой мне довелось поучаствовать. Оценка началась катастрофически – после недель совещаний, сборов рабочих групп и размышлений тимлидов разработка представила оценку сроков разработки – с разбросом в 14 месяцев между минимальной и максимальной длительностью проекта.
Сам проект был посвящен большой и объемной фиче в уже существующем продукте, но не являлся r&d проектом, где подобный разброс можно было бы правдоподобно вписать в проектный план.
И в то время, как финансовый отдел уже расчехлил пулемет, наша проектная gang of four собралась на срочное обсуждение того, что делать с такими сроками разработки: можно ли планировать загрузку людей, считать риски, как быть с критическими взаимосвязями с другими компонентами. Но, пожалуй, самым волнующим вопросом был вопрос насколько валидна такая оценка, и можем ли мы помочь разработке оценивать точнее и лучше.
Читать полностью »
Про абстрагирование, слабосвязную архитектуру и проектирование в целом
2013-03-02 в 7:29, admin, рубрики: dfd, Программирование, проектирование, Проектирование и рефакторинг, разработка, рефакторинг, Совершенный код, метки: dfd, Программирование, проектирование, разработка, рефакторингК хорошим постам habrahabr.ru/post/135340/ и habrahabr.ru/post/171261/
- Почему большинство программистов не любят «читать чужой код»?
- Почему рефакторинг и внесение изменений становятся серьезной проблемой?
- Почему так часто случается, что легче переписать с нуля?
- Почему одни программисты называют других хорошими или плохими словами?
Конечно, многие из вас обнаружат, что предлагаемые ниже ответы на эти вопросы весьма знакомы, но возьмите эту статью на заметку, так как кидать линк зачастую все же существенно комфортнее, чем распинаться в объяснениях и доказательствах очевидного.
Читать полностью »
Как мы озвучили храм
2013-03-01 в 6:46, admin, рубрики: Блог компании КРОК, динамики, инженерный расчёт, ит-инфраструктура, коммутация, проектирование, Работа со звуком, метки: динамики, инженерный расчёт, коммутация, проектирование 
Зоны озвучивания, фрагмент схемы
Храмы, синагоги, церкви, костёлы, мечети и прочие крайне специфические с точки зрения акустики объекты озвучиваются весьма нетривиально.
Большое время реверберации, отсутствие возможности изменить архитектурную акустику (и иногда даже установить микрофоны), необходимость учесть культурные и исторические особенности, а еще обучение использованию этой системы персонала без технического образования – неполный перечень причин сложностей такого проекта.
Задача озвучивания собора была для нас не совсем обычной – раньше мы не занимались такого рода проектами. Драматизма ситуации придавал тот факт, что освящение собора должно было состояться через несколько месяцев.
Когда мы пришли на место в первый раз, как раз шла утренняя служба. С амвона служитель читал молитвы. В радиусе 4-5 метров мы разбирали слова, но как только отходили дальше от священника, все звуки сливались в ровный гул из-за нескончаемого переходного процесса. Понятно было, что при большом скоплении людей речь будет совсем не различимой. Читать полностью »