Pull to refresh
15
0
bormotov @bormotov

User

Send message
вопрос то не в том, повезло или нет.

Довольно давно автопром ориентируется на то, что обслуживанием занимаются специальные люди. Даже самым небольшим вопросами, типа заменить лампочку или воздушный фильтр салона. И в этих условиях «калькулятор затрат», начинает работать по-другому.
пор Барселону вспомнил сугубо на словах «заменить на квадраты», в контексте статьи да и самого и эксперимента моделирования.

Когда проектировали Барселону? Сколько у них сотен лет моделирования?
Да, сейчас урбанистика считает, что нужно больше общественных пространств, например. Но сколько это «сейчас» от всей истории той же Барселоны.

Кстати, вот только сейчас задумался — как «хорошо лёг» ведь текущий проект по укрупнению кварталов. Поменялись требования, и текущая структура позволяет провести «модернизацию», под новые требования, не ломая всё в ноль. В этом отношении, шестигранные соты не такие гибкие.
https://en.wikipedia.org/wiki/Avinguda_Diagonal
современные урбанисты будут смеяться читая эти строки :)

Если совсем коротко — светофоры не так сильно влияют на пробки, как кажется «интуитивно». Пробки — это результат дисбаланса между:
* количества автотранспорта
* пропускной способности дорожной сети
* эфективности использования дорожной сети

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

про Барселону вспомнил потому, что это хороший пример города, где квадратные кварталы. И такая концепция (да, с небольшими кварталами) прошла испытание временем, и уже много что известно из реальной практики. Например, «диагональный проспект», появился не сразу.
надеюсь, вы знакомы с планировкой Барселоны?
про оракловый оптимизатор вообще никаких интриг:

Дж. Льюис, ORACLE: Основы стоимостной оптимизации.

На русском издавали, например «Питер», аккурат десять лет назад.
Планировщик запроса — это просто алгоритм. Он может быть плохим, конечно. Книжка которую я читал про оракловый, охватывала версии оракла 8, 9, 10, и автор прям наглядно показывал, как планировщику от версии к версии добавляют мозгов, и ситуации, когда эти «более умные» мозги принимают решения хуже, чем было.

Меня удивляет отношение человека, с опытом 10 лет.

В моём понимании, «планировщик запроса» — это такая данность, как восход Солнца. И довольно глупо ругать Солнце, что оно утром светит в окно и мешает спать. Самое простое — добавить к «окно на восток», хорошие светонепроницаемые шторы.

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




Кстати, отдельный вопрос — когда вообще нужно собирать результаты из 20-ти таблиц? Можно хотя0бы намекнуть на прикладную область, и что за данные такого рода запросом вытаскивали?

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

После чтения такой книги, очень странно слышать слова «негативные отзывы от специалиста с 10 лет работы».
Решил авторизоваться через fb



Это прекрасно.
им не нужно повышать вот так свой уровень.

Сейчас «развлекаюсь» тем, что у новым задачам линкую писанные мною несколько лет назад, на эту же тему.
У нас в рамках компании один стиль. Сколько бы проектов не было.

не обращая внимания на несущественные особенности

Вы считаете, что мои слова «стиль затрагивает не только форматирвание» — это несущественные особенности, и не обращаете на них внимание?

Есть еще интересный факт — умение читать разные стили, совсем не избавляет от требования писать в рамках одного проекта в одном стиле (который принят в этом проекте). Даже не касаясь производительности и бизнес-показателей — это элементарное уважение к коллегам.

Точки с запятой в конце строк — смешно, а вот, скажем, алиасы таблиц в sql-запросах, единый подход к выбору имен идентификаторов — тоже смешно? Идем дальше — единый порядок аргументов функций для API?

Вот, из недавного, что меня удивляло: модуль, который дает удобные методы работы с целым пластом данных. Среди них всякие выборки/срезы. Среди них — есть срезы по времени. Для меня очевидно, что если функция принимает аргументы date_start, date_end, то у всех функций с аналогичной семантикой в этом модуле (а лучше, во всём проекте), если есть два таких аргумента, они как минимум должны называться одинаково.
А еще, например, в Oracle PL/SQL, нет удобного способа вернуть курсор с данными поэтому у процедур из которых нужно возвращать данные, последний аргумент что-то типа P_RC IN OUT REF_CURSOR.
Хорошее требование, всегда этому аргументу давать одинаковое имя? Или RC, RC1, P_RC, P_RC1, P_CURS, CUR — нормально, все ведь прочтут, все натренировали толерантность и не испытывают боль?

Пример с RC/итд из реального исходника -
 grep "OPEN .* FOR" some_source.pkg
— 91 штука всего, 6 разных вариантов, преобладает P_RC.
Конечно художник в единицу времени приносит больше ценности бизнесу. Но если он за дополнительные 25 минут сможет заменить 250 часов работы маляров — зачем тогда маляры?

О какой толерантности может идти речь, если яркие личности со своим стилем становятся счастливее и работают эффективнее? (на минутку стал на другую сторону)

На мой взгляд, единый стиль — это и есть та самая середина, которая не вызывает боль и страдания ни у кого в команде, к которой все как минимум толерантны, и соблюдение которой не снижает персональную эффективность.

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

Посмотрите по ссылкам, везде разговор о стиле начинается со слов «общий стиль облегчает общение». Чем больше людей, тем важность «двигались в одну сторону» сильнее перевешивает важность личного счастья каждого, потому что количество общения внутри коллектива растет экспоненциально. И явного, и неявного — через написание-чтение кода.

Нет, я не верю, в сферических коней в вакууме, и в то, что солнце встает на западе.

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

Для бизнеса выгоднее подавлять «собственный стиль» даже выраженный в алгоритмах и архитектуре. Единственный практический способ не подавлять — «взваливать» на такого человека «всех остальных», что бы он всех тянул. Но это равнозначно тому, что у всем остальным насаждать его стиль. Иначе, если код понятен только одному человеку, то фактически один человек работает. А нужно, что бы десяток или несколько десятков.

Это же простая арифметика: если написать код красиво у «художника» занимает 5 минут, а потом у десятка «маляров», чтение кода вместо 5 минут занимает 30, то бизнес теряет 250 минут. Если «художник» потратит 30 минут на написание кода, который «маляр» поймет за 5 минут, то потери будут всего 25 минут (плюс, конечно, личное несчастье, и неудовлетворенность «художника»). А что бы бизнес ничего не терял — разрыв нужно сокращать.

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

Первое, что я сделал — погуглил «why styleguide matter». Но из более-менее общего сходу вылезла только статья https://www.smashingmagazine.com/2012/10/why-coding-style-matters/
на какое-то исследование не тянет совсем. Еще вылезли пачки готовых style guide, на очень много какие вещи.
Но самоеудивтельное для меня оказалось статья в википедии https://en.wikipedia.org/wiki/Style_guide
если точнее, кот этот абзац:
A style guide establishes and enforces style to improve communication. To do that, it ensures consistency within a document and across multiple documents and enforces best practice in usage and in language composition, visual composition, orthography and typography. For academic and technical documents, a guide may also enforce the best practice in ethics (such as authorship, research ethics, and disclosure), pedagogy (such as exposition and clarity), and compliance (technical and regulatory).


еще интерсная цитата нашлась в PEP-8 питоновском:
Donald Knuth explains the traditional rule in his Computers and Typesetting series: «Although formulas within a paragraph always break after binary operations and relations, displayed formulas always break before binary operations»
со ссылкой Donald Knuth's The TeXBook, pages 195 and 196.

Дальше — больше! нашелся документ 1995 года, с такими словами
The classic text on programming style remains Kernighan and Plauger The Elements of Programing Style (1974)

И к этой книге нашлась интересная аннотация (и небольшой обзор), которая начинается со слов
This book written by Brian W. Kernighan and P. J. Plauger is one of the first studies of programming style. It advocates the notion that computer programs should be written not so much to satisfy the compiler or personal programming «style», but also should strive for general «readability» and «understandability» by humans with the specific goal to make software maintenance easier.


вот еще статья, но опять-таки, не научная, без цифр
http://www.perlmonks.org/?node_id=776607

А еще нашлась ссылка на McConnel, «Code Complete», которая тоже просто книга, а не научный труд. Но там в PDF'е 897 страниц, из них последние 30 — ссылки на источники. Есть ссылка в том числе и на «The Elements of Programming Style», и например, на

Woodfield, S. N., H. E. Dunsmore, and V. Y. Shen. 1981. «The Effect of
Modularization and Comments on Program Comprehension.» Proceedings of the Fifth
International Conference on Software Engineering, March 1981, 215–23

туда ссылается вот такой текст:

Woodfield, Dunsmore, and Shen conducted a study in which
graduate and senior undergraduate computer-science students
answered questions about two programs: one that was divided into
eight routines along functional lines, and one that was divided into
eight abstract-data-type routines (1981). Students using the
abstract-data-type program scored over 30 percent higher than
students using the functional version.

Конечно, это не только про форматирование текста исходника…

Думаю, коллег, которым именно нужен пруфлинк, можно смело отсылать в «Code Complete», и далее по ссылкам.

p.s. Нет, я не знаю как научно обосновать, что солнце встает на востоке
читая ваш комментарий вспомнил, что на pastebin наверняка не одна копия списка всех pin-кодов к пластиковым карточкам
Потому, что заранее обозначенные условия мало совпадают с реалиями комментирующих.
А видимо, такую штуковину им было бы интересно прикупить.
вот, кстати, да!
вопрос с таблетками от домофона совершенно не раскрыт.
а потом они подумали, что всё равно фигня получается, дали SDK для Objective C, а теперь вообще продвигают Swift. Я по времени не путаю?

Тогда еще вопрос — ну вот, Apple «отпустило», но получается пинок JS'у дали настолько хороший, что он уже сам дальше полетел?

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity