Никогда не получится сделать всё так, как хочется… Это, конечно, немного несправедливо, но это факт — идеальных сайтов не бывает, да и никогда не будет! Постоянно приходится выбирать: оригинальность навигации и дизайна или юзабилити, оптимизированный или интересный читателю контент, небольшие и легкие скрипты или безопасность, устойчивость сайта к взлому. И ведь это далеко не все — этот список можно продолжать до бесконечности!
Вот именно об одной такой дилемме и хочу сегодня порассуждать. Думаю, что многие сайтостроители при разработке своих творений сталкивались с такой вот проблемой: что же предпочесть? Что будет лучше для сайта, посетителей и самого разработчика? Читабельный и лёгкий в понимании код или же небольшой размер страниц и, следовательно, и более высокая скорость загрузки?
Вообще это вопрос вечный! Почему? А потому что всегда придётся чем-то пожертвовать!
Многие, к сожалению, делают однозначный выбор в пользу скорости загрузки и пишут код чуть ли не в одну строчку. Поначалу я тоже так делал, но со временем мой код стал более читабельным. В чисто html страницах можно довольно быстро разобраться с кодом, т.к. легче понять, что куда, нет никаких переменных, циклов
На моем сайте был такой глюк: в Опере и IE всё нормально, а в Мозилле почему-то страницы «прыгали». В частности, правый столбец вытягивался сильно в высоту, а центральный и левый из-за этого находились где-то в середине.
Я почти два дня искал ошибку! Так и не нашёл! Это осложнялось как раз тем, что html код был довольно большим и нагруженным. Потом я плюнул и решил сделать прежде всего-навсего код читабельным, т.к. в своё время много его изменял, добавлял вложенные таблицы, убирал одни, добавлял третьи, переносил из одного места в другое четвёртые
И вот я просто сделал код читабельным! Размер страниц при этом у меня увеличился аж почти на 21 килобайт. При том, что уже почти 75 она весила до этого.
И в результате всего за полчаса нашёл ошибку! Просто в одном месте у меня высота была указана в процентах, а именно в этом месте нужно было в пикселях. Перепутал, думал, что этот tr принадлежит к одной таблице, а оказалось, к другой! Как видите, ошибка была элементарной и её было тяжело найти только лишь из-за нечитабельного кода!
Да, я понимаю, что код постоянно изменяется, что-то дополняется, что-то убирается, но не ленитесь при этом делать код читабельным! Каждый раз, после каждой модификации.
Т.к. мы говорили только про html код — то это были ещё цветочки, а про ягодки смотрите вторую часть.
5!
Мне интересно всё на эту тему - сайтостроение.
Поэтому - спасибо!
И буду все статьи подобные скачивать и внимательно изучать. И комментарии к ним тоже.
Оценка статьи: 5
0 Ответить
Большое спасибо за такой отзыв))) Значит можно ещё что-нибудь на данную тему написать.
0 Ответить
Я всегда выбираю читабельность.
1. Все стоны по поводу больших файлов HTML решаются элементарно: либо хостинг должен поддерживать GZIP (это сжатие страниц перед передачей получателю в браузер, которых их разожмет перед показом), либо воспользуйтесь специальным сервисом для этого.
Поскольку форматирование - это табуляции или пробелы, то сжимается это очень здорово.
2. По поводу PHP вообще зря упомянули, т.к. этот скрипт вообще отрабатывает на веб-сервере, а клиенту летит результат. Поэтому то, как отформатирован скрипт на PHP, вообще никого не волнует.
0 Ответить
Насчёт второго вашего замечания - не могу полностью согласится... Ведь php код исполняется сервером. И если на сервере этот код будет исполняться 5 секунд, то и данные в браузер начнут поступать только через 5 секунд, независимо от качества соединения. А если php код исполняется за 0.1 секунды, то через это же время и данные начнут поступать. Конечно скрипты исполняющиеся 5 секунд это невообразимая редкость, но всё же при больших и длинных скриптах разница может быть довольно существенной. Да, я соглашусь, что в php коде форматирование играет гораздо меньшую роль и довольно слабо влияет на скорость обработки сервером.
А вообще, про php код я упомянул главным образом для начинающих веб-программистов, которые пишут скрипты «а лишь бы как», а потом сидят ночами и разгребают, чего же это они там понаписали…
0 Ответить
За всю мою 20-ю карьеру программиста разработка сайта вызвала второй раз в жизни чувство глубокого неудовлетворения, как-будто меня обманули (первый - когда связался с разработкой баз и оказалось, что для разных СУБД должны быть разные по синтаксису SQL запросы одной версии - что противоречит декларациям о назначении SQL).
По поводу сайтостроительства - я молчу о несовместимости существующих браузеров (это диверсия - разрабатывать несовместимые браузеры и т.Сталин в 32 году поставил бы их к станке как саботажников). Про требуемые ресурсы - тоже ( оптимизация там и рядом не валялась). На этом фоне - экономить что-то на форматировании- просто смешно. И показательно - что действительно в канал можно гнать неформатированную (сжатую, прекомпилированную...) инфу - до этого просто не додумались. Просто стоит вспомнить - кто разработал концепцию HTML (не IT-шник) и для каких целей. К счастью развитие техники и технологий в большинстве перекрывает требования по ресурсам.
В общем - экстенсивный путь развития, господа.
0 Ответить
На этом фоне - экономить что-то на форматировании- просто смешно.
ну может на этом фоне - да, но на фоне страниц, которые должны грузиться как можно быстрее - это нормальный аспект, которому стоит уделить внимание.. к тому же проблема форматирования имеет место не только с точки зрения экономии места, но и как было озвучено выше - с точки зрения читабельности кода, а тут, думаю Вы согласитесь, при больших проектах это может сэкономить много времени и снизить затраты на лекарства от головной боли.. не зря были попытки стантартизировать написание исходного кода (что часто соблюдается в рамках одного проекта/конторы)..
И показательно - что действительно в канал можно гнать неформатированную (сжатую, прекомпилированную...) инфу - до этого просто не додумались.
что Вы подразумеваете под фразой: "до этого просто не додумались", уточните, пожалуйста
0 Ответить
ещё советую почитать про рефакторинг.. например, в книге у Фаулера (на рсдн-е есть описание его книги) или на его официальной странице, посвящённой этому вопросу (но на "буржуйском" языке)
0 Ответить
Читабельность кода хороша только разработчику. Дома можно делать его читабельным, а в инет выкладывать 1ой строчкой. Ведь довольно много идей можно попросту украсть с сайта, при этом особо не вникая.
Что касается простого пользователя ему до фени код. Большинство и не догадывается, что его вообще можно посмотреть.
А еще лучше будет делать несколько версий, у каждой будут свои особенности.
Насчет разных браузеров. Каждый поддерживает как хочет разметку. Есть стандарты, но они порой поразному интерпретируются. Именно поэтому зачастую внизу можно увидеть: оптимизировано под ***
0 Ответить
Делать несколько версий... А нужно ли это? Несколько версий - это более тяжелая БД и дополнительный скрипты определния настроек, браузера пользователя и т.д. . Это на скорости загрузки страниц скажется гораздо хуже, чем просто неотформатированный внутренний код.
0 Ответить
Речь идет о хтмл сайте, если я ничего не путаю. А для его работы никакая БД не нужна! Как мне кажется в описываемом вопросе несколько не разбираетесь.
0 Ответить
В даной статье я говорю именно о читабельности html кода. А он уже может подгружаться на сайт из БД (т.е. скрипт определяет версию, скажем, бразуера и в зависимости от этого подгружает тот или иной код). Вот что я имел ввиду упоминая БД. Ведь согласитесь, делать сайт на одном лишь html - бесперспективная затея.
Но в любом случае - несколько версий html - это не выход. У всех разные браузеры и разные настройки. Самое оптимальное это 2 версии, с поддержкой и без поддержки графики. А если учитывать html стандарты, которые, как вы уже сказали выше, часто по разному интерпритируются, настройки бразуеров, то кол-во html версий будет очень большим.
0 Ответить
В таком случае добавьте строчки дающие более ясно понять что вы говорите лишь о представляемом виде сайта.
В таком случае БД будет грузиться.
Серьезные фирмы делают так чтобы всем было удобно. В идеале
0 Ответить
Вы не поняли, несколько версий локально, а на сервер загружать после тестов только оптимизированную
0 Ответить
А, просто я вас немного не так понял. Бывает)). Ну так делать можно и даже нужно. Я в принципе именно так и делаю. Конечная версия для загрузки на сервер у меня без комментариев и прочих ихлишеств.
0 Ответить
В статье фигурирует НТМЛ, а для его работы никакая БД не нужна.
На сервер грузятся версии(как вариант): без графики, для оперы, для ие. А пользователь сам выбирает через какую ему поглащать контент
0 Ответить
А еще лучше будет делать несколько версий, у каждой будут свои особенности.
согласен, про это я упоминал выше
Ведь довольно много идей можно попросту украсть с сайта, при этом особо не вникая.
вспоминается один разработчик Andy Dufilie.. был скрипт (под mIRC) игры танчики, в оригинале выглядел так (я привожу очень маленькую часть, просто для примера):
alias -l tanks.alias.mkey {
if ($mouse.key & 2) || ($mouse.key & 4) && ($istok(tanks.button.up tanks.button.down tanks.button.left tanks.button.right,$1,32)) return $1 $iif(%tanksinc == 1,5,1)
return $1 %tanksinc
}
но автор закодировал часть исходного скрипта в такой вид:
alias -l O00OOO00 {
if ($mouse.key & 2) || ($mouse.key & 4) && ($istok(O000000O O0000OOO O000O00O O000O0O0,$1,32)) return $1 $iif(%tanksinc == 1,5,1)
return $1 %tanksinc
}
имена функций (альясов), переменных зашифрованы в виде случайного набора букв O и нолей.. увидев такую версию скрипта на почти 4 тысячи строк я был в шоке (бесполезно было думать даже в этом разбираться) и только потом наткнулся на оригинал.. чего только не сделают для шифровки исходного кода, даже если он публично выложен и виден..
0 Ответить
Чтобы это работало, необходимо чтобы программы-обработчики понимали что они делают. Таким образом ничего зашифровать практически нельзя, либо можно расшифровать. Есть великая вещь: дизасемблер
0 Ответить
необходимо чтобы программы-обработчики понимали что они делают
естественно, Вы думаете, хороший разработчик будет натравливать на свой код "левый" транслятор? если не найдёт подходящего, то свой напишет, в большинстве случаев, это не настолько то и сложно, главное синтаксис языка/языков с которого на который транслировать будут знать
даже если вы расшифруете, то результат будет гораздо менее удобночитаем по сравнению в оригиналом.. а несколько тысяч строк трудночитаемого текста это усложняет задачу
Есть великая вещь: дизасемблер
а причём тут он?
речь идёт о скриптах, которые выложены публично в открытом виде, как есть, они не компилируются в исполняемые файлы (которые кое как можно дизасемлировать) и чтобы запутать чтение таких публично выложенных файлов иногда применяются трансляторы, запутывающие код.. либо трансляторы, которые омгут соптимизировать код скрипта. уменьшив его объём, в ущерб читабельности
0 Ответить
Честно говоря, мне как посетителю, на читаемость кода до лампочки. А вот то, что время загрузки увеличилось чуть ли не в полтора раза - вот это существенно. Так что, уважаемые сайтописатели, лучше думайте об удобстве пользователя, а не о собственном.
Путь к удобству сайтописателя лежит через применение программных средств, которые, оставляя исходный текст нетронутым, создают "легкую" рабочую версию.
Оценка статьи: 4
0 Ответить
Да согласен что для посетителя в первую очередь - это быстрота загрузки и пользователю до фени на код. Но вот сколько я лично видел внутренних кодов сайтов, 95% из них имеют нечитабельный и далеко не самый практичный код. Взять даже например страницу моего акка на ШЖ https://www.shkolazhizni.ru/authors/antiKILLER/.
Код очень читабельный. Всё без труда понятно где находится и за что отвечает...но 1568 строк конечного кода (причём последняя строчка пустая) - это слишком. Просто я не разу не видел чтобы кто-то пользовался такими програмками, да и очень многие выбирают что либо одно.
0 Ответить
Путь к удобству сайтописателя лежит через применение программных средств, которые, оставляя исходный текст нетронутым, создают "легкую" рабочую версию.
правильно
если в курсе, может оставите для справки в комментариях ссылки на подобные утилитки (которые позволяют "скормить" файл удобночитаемый и получить трудночитаемый меньшего размера)?
0 Ответить
с одной стороны подмечено правильно.. код должен быть удобночитаемым, а то затраты на исправление недочётов и расширение функциональности будут велики..
но! кто мешает писать полностью отформатированный, удобночитаемый текст, сохранить его, далее прогнать этот текст через специальную программу (я сайтостроительством не занимаюсь, потому не могу посоветовать конкретных приложений, но уверен на 99%, что такие программы уже есть) и получить трудночитаемый текст, но занимающий меньший объём? в итоге будет две версии исходного кода: debug и release (из аналогии с программированием на компилируемых языках).. debug - версия до сжатия, пользуетесь ей, до тех пор пока не получили стабильную версию, как только версия стабильная етсь, можно делать release версию и использовать её.. "и волки сыты, и овцы целы" ©
0 Ответить
Отличная идея!
Я бы сам до такого не додумался!!!! СПС за идею, и комментарий))
0 Ответить
всегда пожалуйста © helpteam bynets.org
0 Ответить
Мдяяяяя... Конечно же читабельность важнее. Краткость - сестра таланта.
PS: а твой вмзар это пирамида, это ж кидалово всегда)))
0 Ответить
Илья, по поводу З.Ы.:
И почему же опять кидалово... Ну назовите мне обьективную причину почему мне выгодно обманывать пользователей.
Да, к сожалению сейчас довольно много мошенников, но у меня всё честно. Иначе обматые давно бы пожаловались в Арбиртраж вебмоней и как минимум мой сайт прикрыли бы.
0 Ответить
Это будет интересно массовому читателю?
0 Ответить
Вполне возможно что да. Сколько сейчас сайтов в сети? И сколкьо каждый день создаётся новых сайтов?
И соответственно очень много пользователей интернета занимаются веб-дизайном и интересуются им.
0 Ответить
Нужно взять на заметку.
0 Ответить
Я тоже люблю читабельный код - с ним легче работать.
Оценка статьи: 5
0 Ответить
Уверен что многие кому хоть раз приходилсоь именно рабоать с кодом предпочтут именно читабельность всему остальному))))
0 Ответить