[work.process] Процессы: сплоченная команда vs отлаженный формализм

Возвращаю долг, образовавшийся в обсуждениях двух недавних заметок (#1, #2). Речь в очередной раз пойдет о том, как организуется процесс разработки ПО: должен ли процесс быть тщательно выстроенным формализованным Процессом с большой буквы "Пы" или это должна быть неформальная тусовка постоянно грызущихся между собой пауков в банке никому не подчиняющихся индивидов-"творцов".

[life.wisdom] Очень точно подметил Терри Пратчетт про людей

Тот, кто создавал людей, кем бы он ни был, допустил в своих разработках одну большую ошибку. Люди так и норовят встать на колени.

Источник: http://www.adme.ru/tvorchestvo-pisateli/chertovski-tochnyj-yumor-terri-pratchetta-722660 © AdMe.ru

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

[prog.sobjectizer] Низкоуровневый мониторинг: делать или не делать?

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

[prog.doc] В минутку передыха при написании документации...

Одна из самых тяжких работ в программировании -- это написание документации. Особенно на языке потенциального противника. Особенно, когда знание этого языка где-то на уровне "Do you speak English?" -- "Nicht Verstehen" ;)))

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

Причем фиг знает, с чем именно это связано. Может быть с тем, что документация идет вслед за работающим проектом (или его фрагментом), когда сил и нервов остается не так уж и много. Помню один проект, в котором уже после основных ПСИ документацию приходилось писать буквально "на характере".

При этом, как бы ни было тяжело, написание документации -- это важно. Зачастую именно при написании документации находишь пути для улучшения того, что было сделано. А иногда обнаруживались несоответствия с тем, что именно требовалось сделать. Бывали и случаи, когда описывая поведение того или иного класса/метода всплывали серьезные ошибки в реализации. Да и вообще, в условиях, когда приходится работать "многостаночником", навык документирования оказывается крайне полезен.

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

Однако, как бы то ни было, раздел под названием "Some Technical Details" настоятельно просит быть написанным. Хотя бы в черновом варианте :))) Так что возвращаюсь к своим баранам :)

[prog.c++] Пример устранения многословности кода

Код на C++ имеет репутацию многословного. Хотя здесь далеко не все так однозначно. И если в C++98/03 было больше объективных предпосылок к многословности, то в C++11/14 таковых остается все меньше и меньше. Поэтому в современном C++ объемный прикладной код, как мне представляется, проистекает из-за недостаточной проработанности задействованных в коде библиотек. И, если посмотреть на то, что ты делаешь, более критично, то выяснится, что возможности для уменьшения объема кода имеются. Нужно только победить свою лень и поэкспериментировать.

[prog.c++] Состоялся релиз SObjectizer-5.5.3.1

В процессе работы над следующей версией был найден и исправлен баг. Версия 5.5.3.1 содержит исправление этого бага. Больше ничего не изменялось/добавлялось/удалялось.