Блог

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

Достаточно завести какое-то свойство, которое будет хранить ID текущей записи. если свойство равно нулю или NULL, то это форма добавления и можете спрятать какие-то поля, которые не имеет смысла или нельзя изменять при добавлении. Если поле не нулевое, то это редактирование. При сохранении достаточно проверить это свойство/параметр формы и заменять Insert на Update. 

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

В прошлой заметке мы рассмотрели теоретический пример, а теперь перейдем к практическому. У меня на сайте клиента есть система подсчета профиля, чтобы узнать, что больше любит посетитель. Например, на ozon это может выглядеть как - просмотрел страничку с книжкой, получи один поинт в пользу книголюба. Просмотрел косметику, получи один поинт в пользу гламурного падонка.

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

Но разные действия стоят разных поинтов. Например, если я просто посмотрел товар на сайте, то можно дать 1 поинт, а если я его положил в карзину, то 5, а если еще и купил, то 10.

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

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

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

Сегодня хочу поговорить о дизайне кода. То, что он должен быть красивым - это понятно, но для этого не обязательно звать Артемия Лебедева, потому что в случае с кодом он просто не поможет. Когда начинаете новый проект и начинаете задумываться о том, какие классы вам нужны и как все должно работать, нужно всегда держать в голове мысль о том, что код и требования к нему могут меняться.

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

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

У меня на работе сервер базы данных занят в нормальные часы не более чем на 20%, а в пики нагрузки не более 50%. Это такие редкие дни и часы, когда процессор напрягается так сильно, что я уже и не помню, когда последний раз это было. 

В пятницу перед уходом с работы проверяю нагрузку сервера, а у меня там от 30% до 50%, причем большую часть времени под 50%. Ну я оставил сервак в покое, не хотел напрягать мозг на выходных. Сегодня пришел на работу, проверил индексы, изменил один индекс, чтобы он включал в себя все необходимое, и нагрузка снова упала до 20%. 

Один запрос с одним неоптимизированным индексом смог поднять нагрузку на процессор в два раза. 

Интересный вопрос поступил в студию:

в методе класса лучше обращаться к полям этого класса или к свойствам(инкапсулирующим эти поля)? Или зависит от ситуации, допустим в свойстве есть какая-то проверка, тогда через свойство. Если нет проверок, то через поле по идее будет работать быстрее.

Был как-то почти такой вопрос - почему, я против прямого доступа к переменным объекта и я отвечал в комментариях. Сегодня решил ответить в отдельной заметке, чтобы потом проще было находить и ссылаться. В вопросе кроется и ответ - доступ к переменным должен осуществляться ТОЛЬКО через свойства. Никогда не должно быть прямого доступа, даже если вы не делаете никаких проверок. Я понимаю, что впадлу писать get/set и для таких случаев в C# есть офигенная конструкция:

Я уже однажды восхищался именованием переменных индусами в заметке ERP система глазами программиста. Сейчас по работе расширяю один Web сервис, который позволяет обмениваться данными со сторонней конторой. Два года назад мы написали им спецификацию и в ней имена переменных были вполне нормальными: AddressLine1, City, Province, PostalCode... Клиенту понадобилось расширить сервис и передавать еще и данные о пользователе. 

Не знаю почему, но на этот раз отдали работу над сервисом индусам. Казалось бы. всего лишь добавить несколько полей не такая проблема. Но эти красавцы умудрились назвать поля LastNm, FrstNm, BrthDt, EMailAdrTxt. Блин, ну неужели так сложно назвать нормально имена полей - LastName, FirstName... Удивило поле EMailAdrTxt своим Txt на конце. У них email адрес может быть не Txt? Нехило обрадовало поле BrthDt, потому что его передают в виде текста. В Индии наверно не знают, что существует такой тип данных как DateTime и он позволяет решить проблемы с ошибками неправильного ввода даты. 

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

Лично я ничего не воспринимаю на веру и для меня нет авторитетов, я человек мыслящий и сам анализирую все и вам советую. Уж много раз говорил вам, не творите себе авторитетов и в том числе мои слова не воспринимайте на безоговорочную веру. Я очень часто анализирую что-то и предполагаю, что может случиться. На пример, я часто пишу, что к концу года будет PS4, но это просто мои мысли, а не факт.

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

Тип данных uniqueidentifier в Transact-SQL достаточно противный. Если указать некорректное значение, то запрос генерирует ошибку, поэтому прежде чем передавать что-то в запрос, желательно убедиться, что значение верное. Приятней было бы, если бы запрос ничего не возвращал, но это мое желание, которое не совпадает с тем, что сделали в Microsoft. Уверен, что у них были причины, чтобы генерировать ошибку и неплохие.

Короче, все это неважно и я бы не написал об этом, если бы не выполнил вот такой запрос:

select * from session where ID = '1756cb52-5b9e-4c95-8de4-b1ae7e5c2b81test'

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

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

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