Тэгпрограммирование

Разработка программных систем по ГОСТ

Кажется, мы стали забывать, как должен выглядеть полный цикл разработки ПО. При разборе старых завалов, был обнаружен артефакт — документы ещё советской научно-исследовательской работы конца 70-х по созданию системы управления разработкой проектов программных комплексов. Это уже сложно достоверно установить, но, возможно, именно она легла в основу ГОСТ 19, разработанного примерно в то же время.

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

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

Эта схема описывает полный цикл жизни ПО — от предложений по разработке системы, написания технического задания (конкретно о нём я как-нибудь обязательно расскажу отдельно: как надо и как не надо писать ТЗ) и составления эскизного проекта до внедрения и сопровождения системы. Такой подход к разработке программных комплексов  полностью согласуется с ГОСТ и активно применялся при создании всех бортовых систем военного назначения. Собственно, всё это и было выстрадано именно из большого опыта решения проблем создания такого ПО.

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

Может, даже получится как-то склеить эти куски костылями в единое целое. Но уже в этот момент приходит понимание, что рождённое чудо некромагии не выдержит ещё одной итерации разработки и, конце-концов, его придётся выбрасывать. И делать всё с нуля. Поэтому, лучше сразу придерживаться (или хотя бы стараться) процесса разработки, уже выстраданного набитыми шишками многих инженеров до нас.

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

Это, однако, не означает, что синхронизаций не должно быть вообще.

Засилие текстовых протоколов

Я давно наблюдаю в программировании засилие текстовых протоколов обмена. Мода на представление информации в «читаемом человеком» (human readable) виде пошла с языков группы SGML — HTML и XML. Раздутых и переусложнённых, иногда, до идиотизма. Одно время XML стал настолько мейнстримным, что им пытались представить вообще любую передаваемую информацию где бы то ни было. Этот процесс родил, в том числе, таких чудовищ ума как веб-сервисы и SOAP: архитектуры самоконфигурирующихся служб, которые, по факту, никому на самом деле не нужны. Потому, что они всё равно требуют той же самой ручной конфигурации уровнями ниже и выше (адаптации программной архитектуры).

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

Читать далее

Интерполяция высоты по трём точкам

Недавно возникла необходимость в «реальном времени» увеличивать разрешение карты высот для одной разрабатываемой игры. По существу, задача сводится к трёхмерной линейной интерполяции: берем уравнение плоскости, выражаем высоту (Z), т.е. приводим уравнение к виду z = f(x_1, y_1, z_1, x_2, y_2, z_2, x_3, y_3, z_3, x, y), подставляем туда координаты трёх известных точек и две координаты искомой и получаем результат.

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

\begin{vmatrix}x-x_1&y-y_1&z-z_1\\ x_2-x_1&y_2-y_1&z_2-z_1\\ x_3-x_1&y_3-y_1&z_3-z_1\end{vmatrix}=0

Читать далее

inet_ntop() для Windows одним макросом

inet_ntop() используется для преобразования структуры, содержащий сетевой адрес в строку. Для Windows (WinSock2) зачем-то выдумали мудрёную WSAAddressToString. Собственно.

#ifdef _WIN32
/** @brief inet_ntop for WinSock. */
/** @param af	Address family. */
/** @param src	Pointer on source address struct. */
/** @param dst	Pointer on destination string. */
/** @param cnt	Length of the string. */
#define inet_ntop(af, src, dst, cnt)	WSAAddressToString((struct sockaddr*) src, sizeof(struct sockaddr_in), NULL, dst, (LPDWORD)&cnt)
#endif

Единственный нюанс заключается в том, что необходимо поместить размер строки (cnt) в отдельную переменную, т.к. WSAAddressToString принимает указатель на размер (зачем это было нужно мне решительно непонятно).

Плохой С++

Вот уже некоторое время при разработке ПО я всегда отдаю предпочтение либо С, либо C#/Python, сознательно обходя стороной С++. Почему?

Представьте, что вам нужно забить гвоздь. Но вместо обычного молотка вы используете супер-молоток Х-1000, который разрабатывается на протяжении 30 лет путем консенсуса 100500 забивателей гвоздей со всего мира, большая часть из которых является учеными-математиками и забивала гвозди только в теории, а остальные явно имеют философские наклонности. В итоге, вы в течение трёх суток генерируете на основе супер-молотка 13 специализированных молотков для забивания конкретно вашего гвоздя, но часть из них разваливается при попытке удара, а часть получилась с дыркой в центре. Через пять суток, после того, как вами подробно был описан гвоздь, молоток, фактура стены, были созданы абстракции-связки между всеми этими объектами вы обнаруживаете на супер-молотке Х-1000 кнопку работы в режиме обычного молотка и просто забиваете гвоздь.

Читать далее