Рубрика «проектирование по»

Разработка (dev) и data science в enterprise — битва за ресурсы или эффективное сотрудничество? - 1


В подавляющем большинстве случаев, когда речь заходит о «настоящей» разработке продукта или решения enterprise уровня, сразу появляются корпоративные архитекторы и глобальные архитектуры и шаблоны, высокоуровневые модели данных и концепты, попытки охватить всё и вся. Формируется шорт лист из языков и фреймворков, в рамках которых идет вся последующая разработка. Все «только на Java» или «только на C#» или… (впишите на свое усмотрение).
Несомненно, это является отражением предыдущего проектного опыта, лучших мировых практик, готовности подхватить новые запросы бизнеса и в общем случае такой подход оправдан. Но в каждом частном случае подобный глобализм на этапе взлета продукта, в тот момент, когда многое еще находится в состоянии неопределенности, может просто погрести под собой начинание и превратить проект в очередную неудачу. Можно ли что-то изменить, упростить и улучшить не теряя при этом в качестве?
Оказывается что это вполне возможно за счет объединения классической разработки ПО с инструментами и подходами data science (далее просто DS). Как этого можно достичь — разберем по шагам.

Материал является продолжением серии предыдущих публикаций.
Читать полностью »

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

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

Как победить дракона: переписываем вашу программу на Golang - 1Читать полностью »

Разработка… она как наркотик — систему пишут, пишут, ведь «прет» же. А потом, вдруг оказывается — «алименты» нужно платить. А любое изменение системы влечет гору ошибок. А ведь еще в начале прошлого века великий Курт Гёдель предвидел это и строго доказал, что даже в арифметике у нас не хватает ума, чтобы выразить все ее законы без противоречий. А в программировании и подавно — мы начнем наступать себе на ноги и запутываться. Что, в общем-то, и происходит: то ноутбук ночью включается и перезагружается, то мобильные приложения сыпят ошибками так, что они из кармана начинают выпадать и разбегаться, бранясь и попискивая, по полу.

А как вам модные нынче бета-версии всего и вся? Cкоро самолеты начнут выходить в альфа-бета версиях, похоже.

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

Сбор требований к программному проекту — без купюр - 1

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

Microsoft предлагает альтернативу пользовательским персонажам - 1

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

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

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

У программы есть цель, о которой иногда забывают

Цель важнее кода - 1
Изображение молотка, лежащего на доске. В доске застрял шуруп, который туда усиленно забивали

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

50 лет назад, в 1968 году, прошла Рабочая конференция по инжинирингу ПО, организованная Комитетом по науке НАТО. Тогда стали замечать, что программное обеспечение становится фундаментальной частью общества. И одновременно его становится труднее понять. После этой конференции программирование начало превращаться в настоящую индустрию. Оно начало уходить из-под контроля бизнеса.
Читать полностью »

С частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »

История первая

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

image

Игровая компания немца разрабатывала 3 вида игр:

  1. Флэш-игры для мобильных телефонов с поддержкой технологии J2ME.
  2. Обучающие игры для портативной игровой приставки Nintendo DS. Заказчиками этих игр были европейские издатели, а покупателями — родители, чьи чада имели проблемы с обучением по математике, английскому или немецкому языкам. Подразделение игр для Nintendo DS выпустило много игр. Хотя они и не стали AAA-тайтлами, но окупили свою разработку и принесли небольшую прибыль.
  3. Игры для платформы Nintendo Wii.

В последней команде был я. Команда должна была разработать игру для маленьких девочек по детскому бренду. Бренд был достаточно известен в Германии (это был основной рынок) и в ряде других европейских стран: во Франции и в Великобритании.

Читать полностью »

image

От переводчика:

На этого интересного автора, Адама Торнхила, я набрел при поиске видео с конференции GOTO. Кому данная статья покажется интересной, советую посмотреть его выступление. Я немного заморочился с переводом (благодарен Тане за помощь!), потому что тематика показалась очень своеобразной, не встречал ранее аналогичные работы (буду рад ссылкам в комментариях!). Статья свежая, августа 2016, в оригинале называется Software ®Evolution — Part 1. В тексте идет повествования от первого лица, но имеется в виду автор оригинальной статьи.

Как эволюция кода позволяет понимать большие кодовые базы

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

Читать полностью »

Прочитал статью коллеги Andrey2008 о добавлении, а точнее сопротивлении добавлению в проект библиотек и решил описать «чек-лист» который я использую в работе со сторонними компонентами. Пока соотношение решений в пользу готовых/написанных с нуля за последние лет 10 примерно укладывается в пресловутые 80/20, может это мне просто везет.
Читать полностью »

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

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js