Этика и качество программирования

Периодически приходится править чужие исходники. Как правило, это работы людей, которые либо уже уволились, либо заняты в данный момент какой-то приоритетной работой. Хочется поделиться с читателями накипевшим – такого насмотришься, зла не хватает.

Ладно, черт бы с ними комментариями в коде. Сам пишу без комментариев, лишь потом, позже проставляю краткие комментарии о назначении того или иного куска кода. Я готов даже простить коллегам кривое форматирование кода – не у всех есть чувство эстетики программирования, когда код приятно читать.
Что бесит меня больше всего, так это абсолютно безымянные переменные и контролы. За что отвечает Edit19, кто-нибудь  может сходу сказать? Правильно, надо отвлекаться, лезть на форму, читать подпись к едиту. А подписи еще не всегда бывают информативны в плане функционала, ибо их часто придумывают пользователи. Это очень неприятно, неудобно, некрасиво. Ну неужели самому не приятно назвать переменную или переименовать контрол во что-нибудь осмысленное? И самому потом же проще будет вспоминать, чего понаписал.

И еще один момент, который пострашнее всякого неэтичного программирования. Отношение к разработке, как к халтуре. Халтурное проектирование БД. Халтурное программирование. Входные данные нигде и никак не проверяются. Просто берется текст из едита и пихается в базу – пофигу, текстовое поле в базе или числовое. В итоге процесс вода данных сопровождается букетом исключений. Но самый прикол начинается, когда я беру такую разработку и начинаю прикручивать к ней отчет. Я то предполагаю, что в базе лежат уже валидные данные.А потом юзер звонит и говорит что мой отчет неправильно работает,. и мы начинаем сидеть вместе с юзером по уши в отладчике и в SQL, ищем косяки в данных.

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

Обидно за себя, за отдел, за профессию.

Подвижки в проекте АРМ

Наконец все сдивнулось с мертвой точки в проекте “АРМ руководителя”. Как уже писалось, мне поручили развитие и поддержку этого проекта. И задача номер один – разработать отчет “Суточный рапорт”. Этот отчет уже работает – разработан и функционирует внутри КИС “Галактика” (на языке Атлантис или VIP). Для его формирования нужно произвести достаточно много настроечных телодвижений – отчет достаточно нетривиальный и одним селектом его не сформировать. Суть отчета вот в чем. Собираются все накладные за заданный период времени (как правило, за прошедшие сутки). Строчки из этих накладных по большому количеству правил разбираются и раскидываются по дереву аналитик. Отчет показывает, как отработал завод по отдельным характеристикам относительно плана. Это вкратце.

Полезность отчета для топ-менеджера очевидна. Но существующая разработка совсем не годится для использования руководителями.
Во-первых, топ-менеджер не хочет заморачиваться с изучением КИС. Ему нужно нажать на кнопку и получить информацию. Это правильно.
Во-вторых, по той же причине нужно переработать интерфейс. Руководителю не интересны десятки настроек отчета. Максимум – период времени.
В-третьих, нужна интеграция с уже существующим АРМом, а это Java EE. Атлантис нам совершенно не подходит.

Итак, я начал разрабатывать отчет практически с нуля. Самое неудобное заключается в том, что никто на заводе не в состоянии дать более-менее детальное и точное опеределение, что требуется от отчета. Разработкой под КИС занимался человек, который сейчас пытается меня консультировать. Поскольку в перспективе есть вероятность перехода на новую версию КИС, где можно будет пользоваться процедурами на PL/SQL, решили сделать общий пакет процедур, который в будущем можно будет использовать и из КИС. Но сказывается разница в подходах. У его разработки нет интерактивности. Настроил отчет, нажал на кнопку, получил на выходе отчет и система забывает о том, что формировала его. У меня ситуация иная. Руководитель должен иметь возможность по щелчку мыши углубляться в данные, все больше увеличивая детализацию отчета. Это означает, что система должна сохранять свое состояние  между запросами. При этом стоит учесть, что системой сможет воспользоваться несколько человек одновременно.

Как все это увязать – думаем сейчас напару. Радует, что работа сдвинулась с мертвой точки.

Локальная база знаний

Давно назревала идея поднять в отделе сервис для сохранения наработок по разнообразным вопросам, например решению проблем с софтом. Часто бывает так: возникает проблема, ты теряешь пол дня на поиск решения, а потом оказывается что кто-то из сослуживцев уже сталкивался с ней и знает простое решение.
В качестве движка для такого сервиса неплохо подходит wiki- движок от Wikimedia. Есть конечно ряд особенностей, специфичных для википедии. Например, создали разделы: Софт, Железо, Сети. В разделе Софт еще разделы, в частности ОС и КИС. В этих разделах свои подразделы, среди которых есть совпадающие имена, например Администрирование. Википедия так устроена, что ссылка на раздел Администрирование ведет на одну и ту же страницу, не зависимо от того, из какого родительского раздела пришел юзер. В качестве обходного маневра приняли такой: ссылка пишется как

Windows:Администрирование|Администрирование

Что в итоге делает ссылку с надписью “Администрирование” и ведущую на “Wndows:Администрирование”. Получается некое подобие иерархии. Во всем остальном движок очень удобен, правда вики-форматированиек еще не все освоили.