← All posts tagged разработка

Constantiner

К предыдущему #1136447 Если, например, классов BullShitController я просто боюсь, то за классы BullShitModel я хочу отучить людей с использованием бейсбольной биты. Даже ModelLocator в Cairngorm имеет адекватное название так как предполагает, что остальные классы, относящиеся к букве M триады MVC, и отвечающие за данные и бизнес-логику, не имеют таких глупых шаблонных названий. Но когда в преложении бля BullShitModel, мне хочется встать, приложить руку к сердцу, поднять подбородок и начать петь возвышенный гимн какой-нибудь великой страны.

Constantiner

Вообще, последнее время ненавижу, когда классы, даже в концепции MVC, называют BullShitController, MailController. Ну контроллер, круто. А что конкретно он контролирует? Весь Mail? Не жмет?

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

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

Constantiner

Возвращаясь к #1134962 очень замечательно в таком коде искать нужное. Ну вот не знаешь ты, где в коде находится кнопка. Один путь — курить всю иерархию контроллеров, контейнеров и найти (вполне случайно), где она создается с непонятной целью именно там. Другой способ, конечно, найти кнопку по метке. Но в современных технологиях все настолько усложнено, что и это не помогает. Понятно, что метка локализована, а ее текст получается с сервера, в проекте его нет. Так что сосите, сэр, да. Разгадывайте квесты трудолюбивых архитекторов.

Constantiner

Чем я люблю MXML, да еще с разметкой, основанной на контейнерах, отличных от Canvas или группах с компоновкой, отличной от базовой, так это тем, что все наглядно. Посмотрел теги и все быстро понял. Поэтому, например, жутко не люблю писателей, которые делают скины во Flex 4 для всего, включая компоновки компонент. Они называют это code behind, а я называю их мудаками :)

Но когда начинается архитектура от астронавтов, то пиши-пропало. Тут, по сути, MXML и не нужен. Ибо роль свою выполняет уже весьма слабо.

Constantiner

Текущий проект вызывает смешанные чувства. Много всего написано, навороченно. Но вызывает ощущение, что все написано на AS2 во времена mx-компонент. Потому как по коду иногда даже поиском нельзя понять, что, как и где инжектируется. Описывать в MXML не контейнеры, в которые запуляются конкретные компоненты в дебрях контроллеров с многоэтажным наследованием с единообразными названиями SomethingBase, Something итд, но без единой строчки комментариев, а сами компоненты, это, видимо, не тот путь. Это для слабаков. Надо же иметь конкурентное преимущество над новыми разработчиками в проекте! Пусть пользуются текстовым поиском и тренируют память! :)

Везет мне на талантливых велосипедистов, которые любят писать максимально сложный код :)

Constantiner

Кажется, как-то Ваня Дембицкий (но могу ошибаться) писал, и я с этим согласен, насчет форматирования одинокой строчки кода в блоках типа if-else или в циклах. Типа принято не ставить скобочки если строчка в блоке единственная. Я с этим не согласен по двум причинам:

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

2. Код — это не то, что вырублено раз и навсегда в граните. Его постоянно приходится менять. И что за мудачество приходится совершать если в блоке из нескольких строк надо удалить все, кроме одной? Или если надо добавить еще одну строчку. Приходится совершать глупые и неадекватные движения по простановке или убиранию скобочек. Я называю это мудачеством.

А вообще, формальное отношение к форматированию кода меня пугает. За всеми такими правилами либо лежит сермяжный смысл, либо не лежит. Скажем, перенос { на новую строку или написание на той же, где while, if или for. Полагаю, что в Java правило оставлять на той же связано с тем, чтобы уменьшить число строк чтобы на древних маленьких экранах их вместилось побольше. Резонно. Тогда в эту концепцию вписывается и убирание {} для однострочных выражений.

Но в ActionScript большинство придерживается Адобовских соглашений. Где { идет на новой строке. Ничего страшного. Но тогда довод про экономию строк в однострочных выражениях уже неубедителен.

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

Легко писать, что кто-то формалист и зануда когда сам являешься таковым :) На будущее: меньше формализма в самом себе.

Constantiner

Вы сталкиваетесь с проблемой, которая, как вам кажется, может появиться и в будущем. Находите решение. Как вы поступаете?

1. Забиваю. А вдруг не появится? А если появится, то либо вспомню решение, либо опять решу/нагуглю.
2. Записываю на бумажке.
3. Я помню все, вообще все.
4. Записываю в текстовый файлик. Я помню, где я его храню.
5. Еще как-то. Как?

Constantiner

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

Constantiner

Обычно многие из проблем, описанных в #1082416 фиксятся в текущих ветках разработки. Таким образом ты волей-неволей переключаешься на всякие ночные билды. И имеешь красоту, извините, во всей красе: твою проблему решили, но зато есть куча других. И не говорите, что типа опенсорц, можешь сам помочь. Я могу, но если меня в течение n лет жизни железно интересует одна технология, которой мне интересно помогать, и которая мою помощь благодарно примет. Но если надо немного отсюда, немного оттуда? Всем ведь не поможешь? ХЗ

Constantiner

А еще мне нравятся современные опенсорсные технологии, в которых одни и те же евангелисты на разных конференциях показывают одни и те же демки, которые работают. Эти демки могут включаться в код самого SDK или либы. Но когда ты сам пытаешься потом сделать шаг вправо или влево, вся красота пропадает. Начинается борьба с багами :(

Constantiner

Стал подумывать, что в современных условиях следование правильным agile'овским методикам и сам agile уже несовместимы. А, может, и не были никогда? Потому как настройка проекта со всякой сборкой, модулями, тестированием, артефактами, CI, автоматическим деплоем итд хоть и осуществляется какбе один раз (ню-ню), но занимает столько сил и нервов с этим современным стеком несовместимых опенсорсных технологий, что, кажется, безо всей этой лабуды ты проект быстрее сделаешь. Понятно, что если ты используешь один и тот же набор технологий одних и тех же версий, и съел на них собаку, то это не так болезненно. Но в agile частенько приходится использовать что-то новенькое. Надо найти какой-то срединный путь.

Constantiner

Разумные и четко сформулированные доводы, почему в процессе разработки что-то делать правильно, а что-то — нет, нужны и важны если вам надо кого-то в чем-то убедить. В повседневной жизни достаточно иметь чутье. У вас оно есть? Что бы делаете когда чутье не дает однозначного ответа, есть сомнения?

Constantiner

Какой бы сложной и замороченной ни была внутренняя реализация программной системы, для взаимодействия с внешним миром ей необходим понятный API. Он может страдать своими особенностями, но для успешного взаимодействия эти особенности должны укладываться в рамки привычных концепций, принятых в разработке ПО. Особенности внутренней реализации могут понадобиться при более тесной, низкоуровневой, интеграции с системой. Так и у людей, в обществе. И это в определенных применениях нормально :)