>Тесты показали как минимум то, что не нужно обязательно писать тесты вначале – как минимум если работа проходить короткими циклами.
Об этом я и всегда пишу.
Но TDD-проповедники в каких-то книжках читали, что тесты нужно писать перед кодом. :) И непонятно какой размер итерации. Обычно просто говориться, что тесты перед кодом.
Если это использовать как культ карго — то выходит ерунда. :)
Впрочем, как и везде. :)
Так эта. Они, любители решать придуманные собой проблемы, говорят, что используют этот мусор в целях неврот *ских оптимизаций. :)
А на тех, кто этот мусор не использует, смотрят как на г-но.
Какого подхода?
Я не евангелист говнокода. Не втягивайте меня в это болото.
Поищите мой коммент тут.
А вам всем говна на вентилятор набросили и начался срач.
Нужно код упрощать, а не искусственно плодить функции (уменьшать экраны). Купите себе больший монитор.
Как их потом называть такие функции?
doSmth[1-N]()? doOneandTwo()? authAndPrind()? :)
Передавать в них 100500 параметров или использовать ООП, а потом ломать голову, где же еще используется член класса?
> Если программист не соответствует базовым требованиям, то ему рано или поздно укажут на дверь.
Имитация бурной деятельности — наше все. :)
> «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Это последствие пропаганды, в первую очередь ООП, когда оно используется без понимания, ради самого ООП, ибо кто не пишет в ООП, с того будут смеятся. :)
> Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня.
Хм, почему вы тогда дальше доколупывались до интервьюируемых, стоит ли избегать перфекционистов? :)
> «симптомы», связанные с неумением следовать парадигме разработки
А зачем следовать этим парадигмам? Ради того, чтобы следовать? Культ карго? :) PHP, JS — мультипарадигменные.
> и написание оставшейся части программы в императивном/процедурном стиле;
Основа моего кода — продедурный стиль — понятный всем. А не широкопальцевая ИБД.
> Установление индивидуальных значений в императивном коде вместо использования связывания данных
Шойта?
> насколько быстро решает простые задачи
В представлении менеджера — да че ты вые, там всего одну строчку добавить.
А то, что потом все из-за нее падает, то ему пох. :)
Но да, простые задачи нужно решать простыми способами. :)
>Первейший способ быть плохим программистом – искать сложных решений там, где есть простые.
В мире PHP (вебе) (сам из него) заклюют, если не используешь мейнстримовый фреймворк (микроскоп) для создания сайтов (забивания гвоздей). :)
Чем больше проблем ты решишь, тем более высокий у тебя рейт, и плевать, что большинство проблем самопринесенные решением неподходящим образом.
> Хороший программист это тот, кто может поддерживать чужой проект
Любой говнокодер это может :)
> тот кто может после запуска продолжать дописывать свой код
А в чем проблема? :)
> тот, чей код могут поддерживать другие люди.
+1
> Должен ли хороший программист использовать выражения return true или return false в циклах?
А в чем проблема?
> Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов?
Хороший программист старается писать понятный код…
> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Это менеджер оценить не сможет… :)
> Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами.
Вывод: выбор схемы шардинга сильно зависит от характера работы приложения с базой.
Вопрос 1.
Как быть с JOIN-ами?
Размещать связанные данные вместе?
У меня такое ощущение, что большие проекты не особо их используют, так как функционал у соцсетей слишком обрезанный.
Вопрос 2.
Вот я могу видеть список «избранного» / ленту в соцсети. При этом само избранное хранится с большой вероятностью на нескольких серверах.
Выполняется несколько запросов?
Документация бизнес логики.
А то вот у меня (на фирме) примерно одинаковый код с точки зрения бизнес логики выполняется последовательно в 2-ух местах, перетирая изменения.
Но прийти к единому знаменателю не хотят, «требуют» формального выполнения задания. :)
В комментах пишут, что куча статей на этот счет.
Они все одинаковые, как и эта.
А вот о field.setCustomValidity() и :valid и :invalid я впервые узнал тут, правда в комментах :)
Где это явно описано? :)
Об этом я и всегда пишу.
Но TDD-проповедники в каких-то книжках читали, что тесты нужно писать перед кодом. :) И непонятно какой размер итерации. Обычно просто говориться, что тесты перед кодом.
Если это использовать как культ карго — то выходит ерунда. :)
Впрочем, как и везде. :)
А на тех, кто этот мусор не использует, смотрят как на г-но.
У меня доля мобильного доходит до 35-40%.
Поэтому должна быть доступна и обычныя страница.
Ну и плевать на Яндекс, пока он приносит большинство трафика — тупорыло.
Я не евангелист говнокода. Не втягивайте меня в это болото.
Поищите мой коммент тут.
А вам всем говна на вентилятор набросили и начался срач.
Это они — путь в болото.
Это как застрявание в текстурах.
Нормальному разработчику фреймворк не нужен.
Но поддержит же.
Поэтому я и говорю, что разница — в качестве кода после программиста.
>Менеджер, во-первых, иногда сам в прошлом — кодер.
Тогда это не менеджер, а замаскированный программист…
>А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
То есть все же сам менеджер не может этого определить…
>Вы же сказали, что поддерживать любой «говнокодер» может.
Перечитайте, что говорилось в статье и что я цитировал.
Улавливаете разницу:
«поддерживает говнокодер после кого-то»
и
«кто-то поддерживает после говнокодера»
? :)
Или я раскрыл чей-то секрет? :)
Я не говорою, что нужны длинные функции, я говорю, что их упрощать нужно с умом, а не поверхностно.
Поверхностное «упрощение» только усложнит все.
Как их потом называть такие функции?
doSmth[1-N]()? doOneandTwo()? authAndPrind()? :)
Передавать в них 100500 параметров или использовать ООП, а потом ломать голову, где же еще используется член класса?
Имитация бурной деятельности — наше все. :)
> «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Это последствие пропаганды, в первую очередь ООП, когда оно используется без понимания, ради самого ООП, ибо кто не пишет в ООП, с того будут смеятся. :)
> Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня.
Хм, почему вы тогда дальше доколупывались до интервьюируемых, стоит ли избегать перфекционистов? :)
> «симптомы», связанные с неумением следовать парадигме разработки
А зачем следовать этим парадигмам? Ради того, чтобы следовать? Культ карго? :) PHP, JS — мультипарадигменные.
> и написание оставшейся части программы в императивном/процедурном стиле;
Основа моего кода — продедурный стиль — понятный всем. А не широкопальцевая ИБД.
> Установление индивидуальных значений в императивном коде вместо использования связывания данных
Шойта?
> насколько быстро решает простые задачи
В представлении менеджера — да че ты вые, там всего одну строчку добавить.
А то, что потом все из-за нее падает, то ему пох. :)
Но да, простые задачи нужно решать простыми способами. :)
>Первейший способ быть плохим программистом – искать сложных решений там, где есть простые.
В мире PHP (вебе) (сам из него) заклюют, если не используешь мейнстримовый фреймворк (микроскоп) для создания сайтов (забивания гвоздей). :)
Чем больше проблем ты решишь, тем более высокий у тебя рейт, и плевать, что большинство проблем самопринесенные решением неподходящим образом.
> Хороший программист это тот, кто может поддерживать чужой проект
Любой говнокодер это может :)
> тот кто может после запуска продолжать дописывать свой код
А в чем проблема? :)
> тот, чей код могут поддерживать другие люди.
+1
> Должен ли хороший программист использовать выражения return true или return false в циклах?
А в чем проблема?
> Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов?
Хороший программист старается писать понятный код…
> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Это менеджер оценить не сможет… :)
> Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами.
Я человек простой. Вижу дебила, шлю найух. :)
Вопрос 1.
Как быть с JOIN-ами?
Размещать связанные данные вместе?
У меня такое ощущение, что большие проекты не особо их используют, так как функционал у соцсетей слишком обрезанный.
Вопрос 2.
Вот я могу видеть список «избранного» / ленту в соцсети. При этом само избранное хранится с большой вероятностью на нескольких серверах.
Выполняется несколько запросов?
Документация бизнес логики.
А то вот у меня (на фирме) примерно одинаковый код с точки зрения бизнес логики выполняется последовательно в 2-ух местах, перетирая изменения.
Но прийти к единому знаменателю не хотят, «требуют» формального выполнения задания. :)
Если есть смысл, выделить пару микросервисов.
Кто непонятно почему использует XHTML, те вынуждены писать required=«required» :)
Правильно было бы сказать, что это булев тип, не требующий значения, включающийся просто от наличия атрибута.
Я даже о ВО в новых резюме перестал упоминать. :)
Отписал в процессе чтения статьи автору.
Ждем. :)
Они все одинаковые, как и эта.
А вот о field.setCustomValidity() и :valid и :invalid я впервые узнал тут, правда в комментах :)