на главную сниппетов Проработав много лет в IT, я тем не менее имею довольно небольшой опыт работы в компаниях производящих программное обеспечение на продажу. В основном доводилось разрабатывать софт для использования только в своей-же организации. А это создаёт определенную специфику. Программист в этом случае оказывается даже не full stack разработчиком, а вообще всем - аналитиком, постановщиком задачи, менеджером проекта, разработчиком, администратором, поддержкой, писателем инструкций и Бог знает кем ещё. Что позволяет руководствоваться только здравым смыслом и своим пониманием задачи без оглядки на общепринятую практику и стандарты компании. Именно такой опыт отступления от норм и правил я и хочу суммировать в этой статье, потому она и называется "вредные советы". Так что, если Вы собираетесь сдавать экзамен по программированию или устраиваетесь на работу в Microsoft, лучше это не читать.
Кроме очевидного снижения производительности на пересчете внешних индексов они способны попортить много крови при сопровождении проекта. У меня есть такая практика, когда приходилось подолгу возиться с восстановлением работоспособности базы из-за обилия внешних индексов. То есть, удаление битой и на самом деле ненужной записи превращается в целое мероприятие, так как она связана с десятками записей в других таблицах. Я конечно понимаю - ссылочная целостность. Но обеспечивать её внешними индексами имеет смысл, если базу разрабатывает один человек, а клиентскую программу другой. А если Вы "от скуки на все руки", несвязанные данные в базе появятся только, если Вы же их туда поместите. И что особенно актуально для локальных баз и баз работающих в маленьких одноранговых сетях, где сервером является обычный настольный компьютер - в результате сбоя портиться некая запись и факт наличия внешнего ключа начинает приводить к ошибкам. В частности, Firebird плохо переносит аварийное выключение. Так что, стоит ли делать из ссылочной целостности священную корову? Что для Вас хуже - наличие несвязанных записей в базе или непрерывные звонки от пользователей, у которых не работает программа.
Наличие первичного индекса в таблице считается аксиомой, его делают даже в таблицах из нескольких строчек. Но всегда ли он нужен? Если таблица представляет собой некий буфер накапливающий информацию, которая потом целиком сливается в другое место - например, с локальной машины на далёкий сервер в Интернете. При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных. В этом случае никакие индексы не нужны, они будут только зря расходовать ресурсы.
Обычное дело, когда множество строк в одной таблице ссылаются на одну в другой, например - сотрудники в подразделении. В таблицу сотрудников пишется идентификатор подразделения и всё хорошо. Но есть ли гарантия, что это всегда так будет? Через пять лет произвели реорганизацию, и появилась возможность того, что один сотрудник будет числится в нескольких подразделениях. Если нет полной уверенности, что отношения "один-много" будет достаточно для любого случая, лучше делать "много-много" через промежуточную таблицу. На всякий случай.
Общепринято повторяющиеся операции выносить в функции и вызывать эти функции из разных мест кода по необходимости. Это удобно и как-бы правильно. Но, только в том случае если до скончания времен это будут именно повторяющиеся операции. В реальной жизни условия задачи меняются со временем, и запросто может получится, что одинаковые алгоритмы в разных местах перестанут быть одинаковыми. Причем различия могут быть ничтожными, но придется либо переписывать функцию вводя дополнительный параметр, либо создавать еще одну функцию. А в случае повторения одного и того-же кода в нескольких местах, можно подправить пару строчек там, где нужно. И для производительности так лучше - нет накладных расходов на вызов функции.
Речь пойдет о юзабилити и, не побоюсь этого слова, эргономике - вещах давно и прочно забытых. Конечно, если Вы пишите софт на продажу, Вам всё равно, как быстро пользователь разберется в интерфейсе. Вы даже делаете доброе дело, помещая на кнопки вместо надписей непонятные значки без всплывающих подсказок - создаёте рабочие места в службе поддержки. Вам также всё равно, сколько времени нужно пользователю на выполнение тех или иных операций, если это происходит не в Вашей организации. Знаю важность таких вещей по опыту работы на почте. В почтовых отделениях всегда очереди и из-за низкой зарплаты крайне малоквалифицированный персонал. Поэтому пользовательский интерфейс должен быть не просто интуитивно понятным, он должен быть очевидным. И "защиту от дурака" нужно прикручивать везде, где только можно. Если есть возможность сделать выбор из списка вместо ввода с клавиатуры - нужно делать. В случаях вроде вышеупомянутой почты критически важна производительность оператора, поэтому совершенно необходимо, чтобы любое действие можно было осуществить только клавиатурой, без мыши - это намного быстрее. Но и мышью тоже - персонал малоквалифицирован. В общем, лучше один раз не полениться - всё тщательно продумать, протестировать, чем потом постоянно объяснять пользователям, где нужная кнопка, и как туда быстрее добраться.
Широко распространено мнение, что инструкции должны быть максимально подробны и богато иллюстрированы скриншотами. Почему-то мало кто задумывается о том, что большое количество картинок разрывает текст на множество мелких фрагментов разбросанных по огромному объёму этого графического романа. Это делает очень трудным поиск нужного места. Да и общее понимание прочитанного затрудненно, если текст представляет собой разрозненные фразы по две штуки на страницу. Эффективнее указать в тексте последовательность пунктов меню или кнопок. Можно с картинками кнопок, но непосредственно в тексте, а не на общем скриншоте всего окна, который занимает полстраницы. А инструкции предназначенные для IT специалистов - администраторов, сервис-инженеров, сотрудников поддержки, вообще не должны содержать никаких скриншотов. Они должны быть максимально краткими, в идеале умещаться на одну страницу. Такую инструкцию скорее нужно называть памяткой. Предполагается, что специалист понимает смысл того, что делает, так как, если не понимает, то "медицина здесь бессильна"
Если Вы пишите софт для внутреннего использования в своей организации и являетесь единственным его разработчиком, у Вас как правило есть полная свобода в выборе используемых технологий. И Вы размышляете, на чём писать, на чём хранить данные. Конечно, если Вы собираетесь менять работу, то Вы заинтересованы в опыте применения наиболее модных в данный момент технологий. Но если не собираетесь, то следование мировым тенденциям, конъюнктуре на рынке труда и собственному желанию выглядеть невероятно крутым контрпродуктивно. Нужно исходить из особенностей задачи и имеющихся ресурсов. Мне довелось наблюдать душераздирающее зрелище - на очень слабую машину поставили Oracle, несчастный компьютер стал загружаться сорок минут. Зато, Oracle! Нет никаких причин, кроме больного самолюбия, использовать платформы для крупных корпоративных решений там, где можно обойтись чем-то очень простым и не требующим огромных вычислительных мощностей. Может быть, Вам вообще не нужен SQL сервер, можно обойтись файловой СУБД. А может быть, вообще никакой СУБД не понадобиться, всё можно хранить в текстовых файлах. Тоже самое относится к клиентскому программному обеспечению - например, если у будущих рабочих станций Вашей системы нет переизбытка памяти, следует забыть про Java - Delphi Ваше всё! К тому же, уже давно есть бесплатная лицензия. Да что там - огромный спектр задач решается с помощью Excel и VBA. И не смотря на то, что я этот VBA терпеть не могу, вынужден признать, что это очень часто вполне эффективно, хоть и совсем не круто. При выборе средств решения задачи нужно исходить из объективно существующих условий, а не пресс-релизов Microsoft, Google и Oracle.
Больше двадцати лет назад, когда я только начинал работать программистом и почти не знал SQL, столкнулся с необходимость найти и исправить ошибку в запросе, написанным до меня. Там, видимо, была ошибка где-то в условиях join или использовался необоснованно left join. Я этого никогда не узнаю, потому как, имея очень смутное представление о том, как работает join, я выкинул их все, переписал как понимаю. Получилось явное соединение таблиц с перечислением таблиц в from и условиями соединение в where. И всё заработало как надо. А теперь бывает, что ловлю себя на том, что описываю курсор, обобщенное табличное выражение, использую оконные функции и т. д. не потому, что это нужно, а потому, что умею. Особенно курсоров касается, от них один вред - очень сажают производительность. Зато выглядит круто! Нужно эффективно решать поставленную задачу, а не рисовать код неземной красоты.
В заключение повторюсь - не использовать для учёбы и корпоративного трудоустройства. Если Вы на экзамене скажете, что первичный ключ не нужен - будете пересдавать. А если в Microsoft узнают, что Вы задумали сложить в текстовые файлы то, что раньше лежало на MS SQL Server, Вам придётся перейти на нелегальное положение...
на главную сниппетов
