Полная Версия: Как правильно делать commit ?
| Цитата (Ron @ 9.11.2015 - 10:05) |
| Какой смысл экономить машинное время? |
Ответ на вопрос зависит от того, что ты хочешь получить в итоге. Если какой-то сайт с небольшой посещаемостью, то да, ты прав. Не надо париться. Можно создать красивый сайт с помощью CMS/фреймворка и пусть он подтормаживает.
Но если ты планируешь, что будет реально большая посещаемость, то тогда надо "экономить машинное время" при любой возможности.
Arh, учу гуглить, дорого
http://metropol-moscow.ru/restaurants
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
| Цитата |
| качество кода обратно пропорционально количеству чертей которых ты произнес во время его чтения |
есть не только паттерны есть и принципы типа единой точки правды (SPOT) и тд, будь оно миллион раз оптимизировано, но если для простого действия мне надо одно и тоже поправить в 10-20 местах одну и туже копипасту то это дерьмокод.
И да мне будет лень читать лапшу из кода, так как по сути любой программист леньтяй, лень - двигатель прогресса, мы пишем программы что бы облегчить чей-то труд и оптимизировать его работу, в каком бы то ни было виде, сайт, CRM и тд
и да оптимизация на спичках это ерунда в случае со скриптовым языком, потратиться 0.0001 или 0.00011 разница не существенна, оптимизация должна быть там где она необходима и где есть известные узкие места
использовал ты filter_val или регулярку нет никакой разницы в плане результата
но есть куча различий для чего ты разрабатываешь и что у тебя за продукт и какие цели ты преследуешь, где-то нужны этапы говнокод рефакторинг чистый код
sergeiss
| Цитата |
| учу гуглить, дорого |
Ну гугл же не скажет "ты чё? это же знаменитый ресторан!" =)
Гугл говорит что это гостиница =)
_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
| Цитата (twin @ 9.11.2015 - 12:18) |
| Хороший программист должен делать хороший продукт. Хороший продукт должен работать хорошо. За хорошо работающий продукт нужно платить хорошие деньги. Это правильная и железная логика. |
От каждого по возможностям каждому - по потребностям. Тоже железная логика. Но не работает ведь! И не может работать, потому как утопия. Вот тоже самое и про хорошего программиста. Это нам всем хочется, чтобы платили деньги за то, что мы лежим на диване и разрабатываем идеальный алгоритм в своей голове. А потом его кодим неспеша через кофеек и дискуссии с коллегами, что же лучше: filter_var() или preg_match().
| Цитата (twin @ 9.11.2015 - 12:18) |
| Если человек хочет быстро и недорого покушать, он идет в Макдональдс. |
Куда же ты дел огромнейшую нишу полуфабрикатов самой различной ценовой категории и различные забегаловки классом выше а-ля сабвей или ильпатио. Образно говоря это и есть фреймворки. Зачем крайности? Или известный ресторан, или макдональдс, который стал, пожалуй, худшим общепитом ever. Даже не знаю с какой CMS-то его сравнить, вот настолько он плохой... =(
| Цитата (twin @ 9.11.2015 - 12:18) |
| Хорошие сайты на фрилансе не делаются и не поддерживаются. |
Смотря что считать фрилансом. Если тематические сайты, где люди хотят за копеечку работы на рубль, то да. А если проекты на заказ через знакомых - то дело совершенно другое. Хотя и то и другое фриланс.
| Цитата (sergeiss @ 9.11.2015 - 13:39) |
| Можно создать красивый сайт с помощью CMS/фреймворка и пусть он подтормаживает. |
Да? Я вот сейчас возьму фреймворк express и создам на нем сайт. Без всяких проблем и очень быстро. А мой конкурент начнет делать на PHP c нуля. У кого получится бОльшая экономия машинного времени? Вопрос. Или возьму тот же Phalcon. Логика ведь какая: если фреймворк, значит тормоза, потому что там паттерны. Вот только поэтому.
Честно говоря странное у нас получается обсуждение. Говнокод это такой код, который вынуждает меня всматриваться, вчитываться и тем самым тормозит и тратит моё время. Причем каждый раз, когда я касаюсь подобного кода. Естественно, пусть лучше нагрузка на сервер будет на 10-15% выше. Мы ведь в погоне за производительностью сейчас договоримся до того, что тру программисты как минимум только "сишники". А вообще-то ассемблеровцы. И что неплохо бы самим написать web сервер, потому что "обычный" под нашу задачу неочень оптимален.
Ron
+1 оптимизация на спичках ведет к говнокоду, оптимизировать нужно действительно узкие места
+1 оптимизация на спичках ведет к говнокоду, оптимизировать нужно действительно узкие места
| Цитата (bestxp @ 10.11.2015 - 06:52) |
| +1 оптимизация на спичках ведет к говнокоду, оптимизировать нужно действительно узкие места |
Всё по кругу.
Смотря что считать говнокодом. Сервер так не считает. Он считает говнокодерами тех, кто грузит его сверх меры, дабы не нагружать мозги.
Ну а вы считаете говнокодерами тех, кто пишет "не как все". А это не показатель вовсе.
Вот допустим я писал всегда переменные с подчеркиванием. Меня убедили, что все пишут в верблюдовой нотации. И вот посыпались косяки. Потому что переменные чувствительны к регистру. Где-то прошло преобразование (массив переработал и из элемента переменную сделал к примеру) в нижний регистр и все посыпалось. Никогда раньше таких проблем не знал.
Так что говнокод говнокоду рознь. Просто вы так привыкли. И своё говно уже не пахнет.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
twin колокольни у нас разные и видения тоже, и спорить мы будем наверно пока солнце не поглотит землю xD и то это будет не повод что бы остановить спор)))
что значит грузить сверх меры?
Скорее всего это будет из темы оптимизации на спичках которые реально ничего не дадут, типа темы геттеры и сеттеры vs публичные свойства, ооп vs императив и тд, но это все несущественные оптимизации, при хорошей архитектуре и правильно выбранными инструментами для решения конкретной задачи экономия будет куда больше, нежели 1-2 мегабайта оперативки и сотая процессорного времени в пике
все эти инструменты считай языки высокого уровня, это тоже самое что сравнивать
машинный код - ассемблер - СИ++ - PHP и тд, если нужна оптимизация как ты говоришь можете тогда стоит писать сразу на машинном коде или ассемблере? Не ну серьезно зачем тогда языки высокого уровня, пойдем сразу на низкий уровень и будем мериться у кого интернет магазин меньше весит и сколько строк ассемблера он занимает
что значит грузить сверх меры?
Скорее всего это будет из темы оптимизации на спичках которые реально ничего не дадут, типа темы геттеры и сеттеры vs публичные свойства, ооп vs императив и тд, но это все несущественные оптимизации, при хорошей архитектуре и правильно выбранными инструментами для решения конкретной задачи экономия будет куда больше, нежели 1-2 мегабайта оперативки и сотая процессорного времени в пике
все эти инструменты считай языки высокого уровня, это тоже самое что сравнивать
машинный код - ассемблер - СИ++ - PHP и тд, если нужна оптимизация как ты говоришь можете тогда стоит писать сразу на машинном коде или ассемблере? Не ну серьезно зачем тогда языки высокого уровня, пойдем сразу на низкий уровень и будем мериться у кого интернет магазин меньше весит и сколько строк ассемблера он занимает
Ты все верно пишешь. Но два момента упускаешь.
1. У всего есть предел. У меня на работе мощнейшие сервера, кластеры, акселераторы и прочая мутота. Но если я перестану, как ты говоришь, экономить на спичках, то все это свалится, потому что работает на пределе. И не могу я себе позволить роскошь писать как все, ставить доктрины, фреймворки, на каждый чих объект создавать и прочее. Потому что тут спичка, там спичка, в итоге получается огроменный сруб. Так что ты смотришь на мой код как на говно, я точно так же смотрю на ваш.
И спорить я не собираюсь. Я просто в очередной раз говорю - смотря с какой стороны рассматривать.
2. Уже несколько раз приводил в пример девиз моего деда. "Стараться нужно делать все хорошо. Плохо - оно само получится."
Если вырабатывается привычка плевать на оптимальность ради лени, это плохо. Это деградация. Как бы не называли это. Бэст практикс, правильная архитектура, качественный код и другие эпитеты. Прожорливый и медленный код - плохой код. Нельзя писать плохой код в надежде, что его исправит акселератор. Тут не в скорости даже дело. А в способности программиста писать оптимально. С привычкой плевать на производительность и получаются такие субъекты, которые плачут, что на работе им не дают применять их любимые паттерны в угоду красоте и самолюбованию.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
1. У всего есть предел. У меня на работе мощнейшие сервера, кластеры, акселераторы и прочая мутота. Но если я перестану, как ты говоришь, экономить на спичках, то все это свалится, потому что работает на пределе. И не могу я себе позволить роскошь писать как все, ставить доктрины, фреймворки, на каждый чих объект создавать и прочее. Потому что тут спичка, там спичка, в итоге получается огроменный сруб. Так что ты смотришь на мой код как на говно, я точно так же смотрю на ваш.
И спорить я не собираюсь. Я просто в очередной раз говорю - смотря с какой стороны рассматривать.
2. Уже несколько раз приводил в пример девиз моего деда. "Стараться нужно делать все хорошо. Плохо - оно само получится."
Если вырабатывается привычка плевать на оптимальность ради лени, это плохо. Это деградация. Как бы не называли это. Бэст практикс, правильная архитектура, качественный код и другие эпитеты. Прожорливый и медленный код - плохой код. Нельзя писать плохой код в надежде, что его исправит акселератор. Тут не в скорости даже дело. А в способности программиста писать оптимально. С привычкой плевать на производительность и получаются такие субъекты, которые плачут, что на работе им не дают применять их любимые паттерны в угоду красоте и самолюбованию.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (Ron @ 9.11.2015 - 22:01) |
| Да? Я вот сейчас возьму фреймворк express и создам на нем сайт. Без всяких проблем и очень быстро. А мой конкурент начнет делать на PHP c нуля. У кого получится бОльшая экономия машинного времени? Вопрос. Или возьму тот же Phalcon. Логика ведь какая: если фреймворк, значит тормоза, потому что там паттерны. Вот только поэтому. |
Тут проблема в том, что у любого фреймворка есть "лишний" код, т.е. тот, который будет загружен и обработан, но который не будет реально использован для данной конкретной страницы. Это, в немалой степени, и приводит к тормозам. Вопрос только в том, как я уже говорил, "что ты хочешь получить в итоге". Насколько эти тормоза напрягают или НЕ напрягают.
Если ты будешь писать аналог одноклассников или контакта, то на симфони (и не только на нем) ты получишь медленного монстра
Да, функционал будет. Но будут и сильнейшие тормоза."Я вот сейчас возьму фреймворк express и создам на нем сайт." - какой сайт ты создашь, под какую посещаемость, с какими фичами????? Не может быть абстрактного сайта, он делается под какие-то определеннные цели. Ты их не озвучил, а просто сказал "создам сайт".
_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL
* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.
* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)
и опять 25 twin ты не прав, оптимизация на спичках это полная ерунда, оптимизировать надо реально узкие места и правильность применения инструментов, и только такая оптимизация приносит результат, нет тут кластеров и тд, есть практика этого всего
какую оптимизацию выбрать?
прирост в скорости в 10мс на самый тяжелый процесс за счет например убрать геттеры и сеттеры
либо рефакторинг этого процесса и ускорение его в 10-20 раз в счет изменения инструментов и способа работы с ним?
первый это оптимизация на спичках второй пример реальной оптимизации, в первом ты ничего не меняешь, а только хуже делаешь, во втором случае ты улучшает или меняет процесс, оптимизируя его узкие места и ускоряешь его медленное место
в первом случае ты ничего не экономишь. во втором случае ты экономишь огромное кол-во денег за счет оптимизации процесса например генерации важного отчета от которого зависит прибыль компании
если тебе нравиться оптимизации на спичках, то тебе прямиком писать все на си++ и цеплять как ext к языку тогда будет заметен прирост оптимизации и будет от нее польза, но такими темпами зачем нужен будет php вообще?
жду контр аргументов
upd---
какую оптимизацию выбрать?
прирост в скорости в 10мс на самый тяжелый процесс за счет например убрать геттеры и сеттеры
либо рефакторинг этого процесса и ускорение его в 10-20 раз в счет изменения инструментов и способа работы с ним?
первый это оптимизация на спичках второй пример реальной оптимизации, в первом ты ничего не меняешь, а только хуже делаешь, во втором случае ты улучшает или меняет процесс, оптимизируя его узкие места и ускоряешь его медленное место
в первом случае ты ничего не экономишь. во втором случае ты экономишь огромное кол-во денег за счет оптимизации процесса например генерации важного отчета от которого зависит прибыль компании
если тебе нравиться оптимизации на спичках, то тебе прямиком писать все на си++ и цеплять как ext к языку тогда будет заметен прирост оптимизации и будет от нее польза, но такими темпами зачем нужен будет php вообще?
жду контр аргументов
upd---
| Цитата |
| Тут проблема в том, что у любого фреймворка есть "лишний" код, т.е. тот, который будет загружен и обработан, но который не будет реально использован для данной конкретной страницы. Это, в немалой степени, и приводит к тормозам. Вопрос только в том, как я уже говорил, "что ты хочешь получить в итоге". Насколько эти тормоза напрягают или НЕ напрягают. |
и пусть будет, если он не будет загружен и работать и ты его не используешь, то какие будут там тормоза? откуда им там взяться или у тебя там старый hdd
Да контр аргументы просты как ясный день. Зачем оптимизировать узкие места, если их можно не делать изначально.
Да, я понимаю, что идеального кода не бывает. Но нужно писать так, чтобы этих мест было как можно меньше. Изначально. А ваши подходы больше чем полностью состоят из узких мест. Ибо вы старетесь все унифицировать, все разложить по паттернам, привести к однообразию, чтобы было легче разбираться.
А любая унификация обратно пропорциональна производительности. Это аксиома. Если мне нужно порезать колбасу, я беру столовый нож. Если нужно порубить тросник - мачете. Вы берете сразу мачете, им же можно и колбасу порезать. Не важно, что его в карман не спрячешь. И что он длинный и тяжелый. Нафиг его оптимизировать, спички это. Сильно захочется, мы ему тележку прикупим возить. Акселератор тобишь.
Вот если рефакторить, приспосабливать к кухне,то нужно либо заменить его, либо перековать.
А можно сразу взять нужный нож. И всё. Никаких оптимизаций.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Да, я понимаю, что идеального кода не бывает. Но нужно писать так, чтобы этих мест было как можно меньше. Изначально. А ваши подходы больше чем полностью состоят из узких мест. Ибо вы старетесь все унифицировать, все разложить по паттернам, привести к однообразию, чтобы было легче разбираться.
А любая унификация обратно пропорциональна производительности. Это аксиома. Если мне нужно порезать колбасу, я беру столовый нож. Если нужно порубить тросник - мачете. Вы берете сразу мачете, им же можно и колбасу порезать. Не важно, что его в карман не спрячешь. И что он длинный и тяжелый. Нафиг его оптимизировать, спички это. Сильно захочется, мы ему тележку прикупим возить.
Акселератор тобишь.Вот если рефакторить, приспосабливать к кухне,то нужно либо заменить его, либо перековать.
А можно сразу взять нужный нож. И всё. Никаких оптимизаций.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Да оба правы по своему, 100500 раз уже нахоливарили целые кучи по углам форума =)
_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2
| Цитата (twin @ 10.11.2015 - 16:11) |
| Да контр аргументы просты как ясный день. Зачем оптимизировать узкие места, если их можно не делать изначально. Да, я понимаю, что идеального кода не бывает. Но нужно писать так, чтобы этих мест было как можно меньше. Изначально. А ваши подходы больше чем полностью состоят из узких мест. Ибо вы старетесь все унифицировать, все разложить по паттернам, привести к однообразию, чтобы было легче разбираться. А любая унификация обратно пропорциональна производительности. Это аксиома. Если мне нужно порезать колбасу, я беру столовый нож. Если нужно порубить тросник - мачете. Вы берете сразу мачете, им же можно и колбасу порезать. Не важно, что его в карман не спрячешь. И что он длинный и тяжелый. Нафиг его оптимизировать, спички это. Сильно захочется, мы ему тележку прикупим возить. Акселератор тобишь.Вот если рефакторить, приспосабливать к кухне,то нужно либо заменить его, либо перековать. А можно сразу взять нужный нож. И всё. Никаких оптимизаций. |
Не всегда у тебя будет время выбрать ножик полегче да понаточеннее
Разработка в конкуретных условиях порой требует хардкода и использования не то что мачете, скорее клеймора двуручного и для рубки голов и для порезать хлебушка, но зато ты уже можешь подать хлеб и делать сендвичи пока твои конкуренты выбирают ножик, к тому времени когда ты поймешь какой ножик нужен у тебя и клиенты есть и прибыль и тд, и ты уже оптимизируешь свой процесс и в этотм момент открываються конкуренты все такие красивые вроде к легкими ножами, а сендвичи то готовить не умеют
на счет экономии на спичках, тут же официант один носит на 10 секунд быстрее второй на 10 секунд дольше, но оба принесут заказ притом что 10 секунд эти не существенны, другое дело если один принесет сразу другой через 10 минут , тут ты уже будешь разбираться почему второй несет 10 минут, путь у него кривой или тарелка тяжелая и нужно было попросить помочь второго официанта и тд
вот тебе и оптимизации
А я во главу угла всегда ставлю не разработку. А обслуживание.
И кроме того, тут не про фреймворки речь, а про структуру кода.
Разницы по времени совершенно никакой, или ты популярными паттернами пишешь, или используешь свои наработки. Но когда проект выходит в свет, начинается гонка, оптимизация, рефакторинг и прочие прелести. А это чаще всего не приводит к желаемму результату, ибо изначально схема построена так, что менять ничего нельзя. Куча зависимостей, шаблоны, унификации. В итоге бабушкин клубок, который распутать невозможно. Вот и придумывают кэши и прочую лабуду, которая ну совершенно не нужна, если сразу писать оптимально.
Я кэширование только на курсах рассказывал. В практике ниразу не понадобилось. Ибо нечего кэшировать, все и так работает как кэш.
Так что все эти домыслы про крутую оптимизацию оставь при себе. Мне нечего оптимизировать. А тебе не поможет.
По этому все при своих. Хочешь писать общепринятыми схемами - твое право. Но это говнокод. На мой взгляд.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
И кроме того, тут не про фреймворки речь, а про структуру кода.
Разницы по времени совершенно никакой, или ты популярными паттернами пишешь, или используешь свои наработки. Но когда проект выходит в свет, начинается гонка, оптимизация, рефакторинг и прочие прелести. А это чаще всего не приводит к желаемму результату, ибо изначально схема построена так, что менять ничего нельзя. Куча зависимостей, шаблоны, унификации. В итоге бабушкин клубок, который распутать невозможно. Вот и придумывают кэши и прочую лабуду, которая ну совершенно не нужна, если сразу писать оптимально.
Я кэширование только на курсах рассказывал. В практике ниразу не понадобилось. Ибо нечего кэшировать, все и так работает как кэш.
Так что все эти домыслы про крутую оптимизацию оставь при себе. Мне нечего оптимизировать. А тебе не поможет.
По этому все при своих. Хочешь писать общепринятыми схемами - твое право. Но это говнокод. На мой взгляд.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Странно но мне тоже кеши практически не разу не понадобились, есть исключительные ситуации, как например сторонний сервис по json отдает данные, тут лучше кешироват его ответы чем в случае его тормозов тормозить свой проект
а причем тут фреймворки?)) я где-то упоминал про них?)
я говорил про то что пока ты пишешь сразу оптимально я уже буду продавать и у меня будут клиенты, к твоему открытию я буду на шаг впереди, а то и на 2, и спорить тут безполезно
я сначала использую готовые решения и стратегии что бы начать, пока ты будешь изучать и оптимизировать, все поменяеться 20 раз и пока ты оптимизиурешь опять я просто беру удачливый паттерн и опять продаю и зарабатываю в итоге пока ты делаешь и переделываешь пройдут годы и может вообще не запустишься , у меня уже построен бизнес
так вот суть в том и есть что все паттерны и тд позволяют быстро построить и потом оптимизировать узкие места если они будут или вообще безболезннено их вырезать и забыть или проосто не использовать не тратя на них ресурсы и развиваться равномерно ,как ты там говорил сам "нет предела совершенству" но оптимизацию нужно делать там где она нужна, а не экономить сначала на спичках
а причем тут фреймворки?)) я где-то упоминал про них?)
я говорил про то что пока ты пишешь сразу оптимально я уже буду продавать и у меня будут клиенты, к твоему открытию я буду на шаг впереди, а то и на 2, и спорить тут безполезно
я сначала использую готовые решения и стратегии что бы начать, пока ты будешь изучать и оптимизировать, все поменяеться 20 раз и пока ты оптимизиурешь опять я просто беру удачливый паттерн и опять продаю и зарабатываю в итоге пока ты делаешь и переделываешь пройдут годы и может вообще не запустишься , у меня уже построен бизнес
так вот суть в том и есть что все паттерны и тд позволяют быстро построить и потом оптимизировать узкие места если они будут или вообще безболезннено их вырезать и забыть или проосто не использовать не тратя на них ресурсы и развиваться равномерно ,как ты там говорил сам "нет предела совершенству" но оптимизацию нужно делать там где она нужна, а не экономить сначала на спичках
Здесь расположена полная версия этой страницы.