Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 348
Вот! Вот, наконец, статья от нормального программиста.
И эпилог шикарный. Я буду творить, и мне насрать на тех, кто учит меня, как это делать правильно. Вспомним знаменитую притчу про Моцарта и симфонии, кстати.
И эпилог шикарный. Я буду творить, и мне насрать на тех, кто учит меня, как это делать правильно. Вспомним знаменитую притчу про Моцарта и симфонии, кстати.
А расскажите притчу?
Я нашел сходу две, если что
Первая
Отсюда: pritchi.omkara.ru/pritcha816.htm
Вторая
Отсюда: krendelek.ru/content/doc/parable/anthony-de-mello/page4
Первая
Как-то раз Верди, уже убеленный сединами и знаменитый на весь мир, беседовал с одним начинающим композитором. Его собеседнику было восемнадцать лет. Он был совершенно убежден в собственной гениальности и все время говорил только о себе и своей музыке.
Верди долго и внимательно слушал молодое дарование, а потом с улыбкой сказал:
— Мой дорогой юный друг! Когда мне было восемнадцать лет, я тоже считал себя великим музыкантом и говорил: «Я». Когда мне было двадцать пять лет, я говорил: «Я и Моцарт». Когда мне было сорок лет, я уже говорил: «Моцарт и я». А сейчас я говорю просто: «Моцарт!».
Отсюда: pritchi.omkara.ru/pritcha816.htm
Вторая
Однажды молодой композитор пришел к Моцарту. Он хотел знать, как развить свой талант.
— Думаю, нужно начать с простых композиций, — посоветовал Моцарт. — Песен, например.
— Но вы ведь сочиняли симфонии еще будучи ребенком! — запротестовал молодой человек.
— Да, это так. Но я ведь не ходил к кому-либо за советом о том, как развить свой талант.
Отсюда: krendelek.ru/content/doc/parable/anthony-de-mello/page4
Шикарно, особенно вторая притча, и жизненно спустя N веков!
Я имел в виду вторую, правда читал ее чуть в других словах:
«Какой-то юноша спросил Моцарта, как писать симфонию.
— Вы еще слишком молоды. Почему бы вам не начать с баллад? -сказал Моцарт.
Юноша возразил:
— Но ведь вы начали писать симфонии, когда вам не было еще и десяти.
— Да, — ответил Моцарт, — но я ведь ни у кого не спрашивал, как их нужно писать.»
«Какой-то юноша спросил Моцарта, как писать симфонию.
— Вы еще слишком молоды. Почему бы вам не начать с баллад? -сказал Моцарт.
Юноша возразил:
— Но ведь вы начали писать симфонии, когда вам не было еще и десяти.
— Да, — ответил Моцарт, — но я ведь ни у кого не спрашивал, как их нужно писать.»
… И когда я сотворю что задумал, даже боги ужаснутся, не то что работодатель!!! )
Сильно
Особенно нравится это:
О тренингах — напоминает книги о том, как заработать. Чего ж эти бараны сами не воспользуются знаниями?
А вот насчет разницы в сорок раз структур мозга — совсем не понятно. Разве структура не может отличаться на проценты? Куда уж выше 100% (т.е. полностью)?
А вот насчет разницы в сорок раз структур мозга — совсем не понятно. Разве структура не может отличаться на проценты? Куда уж выше 100% (т.е. полностью)?
У мозга много структур, 40 по 100% получается 4000 % :)
Они и зарабатывают. На тех, кто покупает книги.
1 мм против 5 см, к примеру.
один будет без музыкального слуха, а второй — великим композитором. потому что специальные отделы в мозге развиты от природы.
один будет без музыкального слуха, а второй — великим композитором. потому что специальные отделы в мозге развиты от природы.
Я не верю в это (до конца). Сам учился в музыкальной школе. До нее — даже петь не выходило. После хора и вокала научился (вроде). :)
способности могут быть в зачатке.
но если их __физически__ нет, то развить нельзя
но если их __физически__ нет, то развить нельзя
Всё правильно кроме вот этого:
«Возможно, после N итераций разработчики начинают говорить вам — все, дальше проект делать нельзя, надо рефакторить. А еще лучше — переписать с нуля, иначе он будет падать с каждым новым изменением. И если вы послушаетесь их бесконтрольно — два месяца будут рефакторить, через два месяца решат переписать с нуля. А через полгода, когда ничего еще не будет готово, либо бросят бесполезную затею, либо вы их уволите — рынок ушел вперед, и попасть на уже ушедший поезд не получится.»
тема раскрыта в «Peopleware».
Если те самые гениальные разработчики, которые в 10 раз продуктивнее среднего говорят вам такое, их тоже не нужно «слушаться»?
«Возможно, после N итераций разработчики начинают говорить вам — все, дальше проект делать нельзя, надо рефакторить. А еще лучше — переписать с нуля, иначе он будет падать с каждым новым изменением. И если вы послушаетесь их бесконтрольно — два месяца будут рефакторить, через два месяца решат переписать с нуля. А через полгода, когда ничего еще не будет готово, либо бросят бесполезную затею, либо вы их уволите — рынок ушел вперед, и попасть на уже ушедший поезд не получится.»
тема раскрыта в «Peopleware».
Если те самые гениальные разработчики, которые в 10 раз продуктивнее среднего говорят вам такое, их тоже не нужно «слушаться»?
> И если вы послушаетесь их бесконтрольно
это значит, что пустите дело на самотек, не будете применять никаких Метрик и т.д.
я только это имел в виду.
это значит, что пустите дело на самотек, не будете применять никаких Метрик и т.д.
я только это имел в виду.
Добавлю, что я выделяю от недели до нескольких месяцев на рефакторинг. Но все обычно по определенному вектору
Как вам точка зрения о том, что рефакторинг необходим только как часть решения очередной задачи, не чтобы все исправить, а исправить только части имеющие отношение к конкретной задаче. Задача может относиться как к багу, так и к новой фиче.
Я давненько забросил заниматься рефакторингом ради рефакторинга. Т.о. и рефакторинг как бы есть, и месяцы на него тратить не нужно.
Я давненько забросил заниматься рефакторингом ради рефакторинга. Т.о. и рефакторинг как бы есть, и месяцы на него тратить не нужно.
Вроде небольшая (для заказчика :) ) фича может потребовать либо переделки всего с нуля, либо нагромождения костылей во всех слоях.
Заказчик — вообще основной источник рисков для проекта. Было такое на последней работе. «Field in form should be calculated and editable» — как-то пропустили. А поле вычислялось по сумме по БД. Пришлось для «editable» сумм городить отдельные таблицы.
Ну, тут явно ваш фэйл, заказчик не в конце разработки же вставил «and editable» :)
Ум, как сумма осознанного опыта, даден разработчикам и проектировщикам, как раз, чтобы максимально избежать подобных эксцессов :)
Ошибки такого рода допускаются в основном на более ранних этапах разработки чем проектирование: анализ и постановка задачи, сбор требований и т. п. Да, некоторые вещи опытные разработчики делают на автомате, заботясь, зачастую даже неосознанно, о будущем поддерживании системы, но всех возможных сценариев развития системы не предусмотришь.
Действительно случаются ситуации, и то что эти ситуации случаются не часто, я считаю нормой, когда тот или иной модуль приходится переписывать, однако давненько я не встречал «переделок всего с нуля» и «нагромождения костылей во всех слоях».
С другой стороны, если заказчик требует некий юзер стори которого не было на этапе постановки задачи, то в лучшем случае заказчику светит компромис.
С другой стороны, если заказчик требует некий юзер стори которого не было на этапе постановки задачи, то в лучшем случае заказчику светит компромис.
Недавний пример — внезапно всплывает требование, что незашифрованные персональные данные не должны покидать клиент в принципе, то есть даже имея полный доступ к серверу персональные данные должно быть невозможно (в терминах криптографии) получить, ключа расшифровки на сервере быть не должно.
Вся логика перемещается на клиента? Нецензурная лексика? :)
Слава богу не вся, большинство логики работает с id клиента, но вот чисто интерфейсные штуки типа автодополнения фамилии тоже нецензурную лексику вызывают.
Фамилии можно и в словаре на сервере хранить. Они не являются идентифицирующим личность данными, потому что людей с одинаковыми фамилиями немало. Даже связка ФИО не идентифицирует личность.
Номер паспорта точно идентифицирующая.
Это да. Добавление даты рождения к ФИО сразу делает данные идентифицирующими, хотя это все еще не на 100% подтверждает личность.
В любом случае, это исключительная ситуация. Во вторых, если работа ведется с персональными данными… я бы плохо спал, если честно, потому, как контролирующие органы в разных регионах со своими тараканами, и ГОСТовским шифрованием их не всегда можно уговорить. Хотя, с хорошим юристом можно все.
Не согласен. Изменения в архитектуре сложны, и учитывают динамику роста определенных векторов/осей ответственностей.
И потом, это просто вкайф — сделать проект лучше :) Когда результаты визуальные в порядке )
И потом, это просто вкайф — сделать проект лучше :) Когда результаты визуальные в порядке )
Не согласен, т.к. фраза «динамика роста определенных векторов/осей ответственности» имеет слишком широкую смысловую расплывчатость и не может быть мною корректно формализована.
И потом, это неизбежно, да, ведь разработчик с каждым днем становится профессиональнее, однако рефакторинг ради фана экономически неэффективен. Лучше по-моему поставить задачу так, чтобы рефакторинг понадобился, и фан и польза :) Я совсем не против, рефакторинга, я обожаю удалять код, и если в начала проекта рост строк кода 1-2к в неделю, то к концу проекта добавление функционала, каким-то магическим образом не приводит к увеличению количества кода, напротив, иногда, кода становится меньше.
Золотая середина, я наверное постиг дзен? :)
И потом, это неизбежно, да, ведь разработчик с каждым днем становится профессиональнее, однако рефакторинг ради фана экономически неэффективен. Лучше по-моему поставить задачу так, чтобы рефакторинг понадобился, и фан и польза :) Я совсем не против, рефакторинга, я обожаю удалять код, и если в начала проекта рост строк кода 1-2к в неделю, то к концу проекта добавление функционала, каким-то магическим образом не приводит к увеличению количества кода, напротив, иногда, кода становится меньше.
Золотая середина, я наверное постиг дзен? :)
Те самые «гениальные» тихо отрефакторят всё за ночь без вашего ведома на свой страх и риск, а на утро будут счастливые, как младенцы, спать перед монитором
Говорю вам как программист повидавший виды в разных компаниях мира. Альтруизм — дело неблагодарное, неприбыльное, изматывающее и, наконец, несуществующее. Сегодня он «без вашего ведома на свой страх и риск» «отрефакторил все за ночь», а завтра пойдет искать другую контору, потому что на этой его не ценят и в нем не нуждаются.
Совершенно верно, так и будет.
Но код останется отрефакторенным :) Но вообще говоря такой альтруист может очень долго менять компании. В вакансиях очень редко встречаешь рефакторинг в перечне основных обязанностей разработчика, что означает, что менджмент не считает его важным элементом процессов разработки и/или поддержки и с большой вероятностью рабочее время на это выделяться не будет. Увы :(
Думали, альтруист, а чувак скиллы прокачивал…
А наутро будут с красными глазами дебажить :)
Слушаться.
Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.
Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.
Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
«Я могу творить, и я буду творить, хотите вы этого или нет».
Вот оно!
ps Хотите вы этого или нет, а я это себе в профиль поставлю.
Вот оно!
ps Хотите вы этого или нет, а я это себе в профиль поставлю.
Полностью согласен с автором, а еще не малое влияние на процесс и как следствие — результат оказывают социально-психологические взаимосвязи. Например, если в команде все крутые специалисты, которые начинают «выеживаться» и т.п. друг перед другом, то процесс будет приторможен и малопродуктивен, а результат будет хуже чем у менее профессиональной, но более дружной команды…
Чаще идет конфликт между тимлидом (как правило знающим компромисс между качеством и сроками) и «гением», утверждающим что в калькулятор следует заранее заложить возможности расчета орбит небесных тел с учетом релятивистских эффектов.
Основное и самое интересное слово, которое я у вас тут увидел — «заранее». Почему «заранее»? Потому, что нет уверенности, что получится незаранее — тогда, когда реально будет надо. Поэтому делаем не тогда, когда надо, а тогда, когда можно. Что, в общем, есть признак слабости. Всякое «заранее», как и прочие разновидности ориентации на то, что можешь, а не на то, что хочешь, есть признак слабости.
Но, с другой стороны, физически можем мы обычно больше, чем хотим;-)
Но, с другой стороны, физически можем мы обычно больше, чем хотим;-)
Если говорить не о реализации фичи заранее, а о создании архитектуры, способной без проблем эту фичу подключить, то «заранее» вряд ли можно назвать слабостью. Другое дело, что нужно выбрать из всех возможных фич те, которые будут почти гарантированно.
с помощью рефакторинга архитектуру можно скорректировать, в некоторых пределах.
Чтобы с помощью рефакторинга архитектуру можно было легко скорректировать (на самом деле в достаточно широких пределах) она должна быть покрыта тестами как можно полнее (на крайний случай должна легко покрываться тестами). Для этого архитектура должна быть тестируемой. По-моему, проектировании заранее заведомо легко тестируемой архитектуры, пускай без (пока) намерения писать тесты, как раз тот случай, когда «заранее» не слабость, а сила. Вернее даже превращение слабости, невозможности (объективной или субъективной — не суть) предсказания путей развития проекта, в силу, возможность на этой невозможности не зацикливаться.
Слабость причем? Обычно люди рассуждают о том, что им не хватает. О силе-слабости?
«Ты кричишь как бездомная
— Да здравствует дом!
Я кричу как безумный
— Да здравствует лужа!»
Заранее — это может быть синонимом констатации факта — преждевременно. Всему свое время. Делать то, что хочу (или желать делать только то, что хочу) — может быть признаком детской капризности, которая идет вразрез с логикой и эффективностью.
Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
«Ты кричишь как бездомная
— Да здравствует дом!
Я кричу как безумный
— Да здравствует лужа!»
Заранее — это может быть синонимом констатации факта — преждевременно. Всему свое время. Делать то, что хочу (или желать делать только то, что хочу) — может быть признаком детской капризности, которая идет вразрез с логикой и эффективностью.
Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
Подпишусь под каждым словом!
Очень интересно, но совершенно не практично.
Обычно быстро говнокодом невозможно написать (имхо).
Юра Малинов хорошо об этом сказал.
Юра Малинов хорошо об этом сказал.
Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.
На первых стадиях — легко. Что проще — сделать один God Object или сделать 15 интерфейсов и 2 слоя абстракции, чтобы потом их удалить, когда узнаешь, что предметная область-то совсем иная? Я против God Object и любитель DI, SOLID, IoC TDD etc, но если ты прорабатываешь задачи, делая скелет на скорую руку, ты всегда будешь быстрее.
Грубо говоря, есть миллион вещей, на которых можно сэкономить время — от простого отказа не делать что-то с нуля, а взять готовое, и простого отказал от функционала, до миллиона приемов.
Просто «правильно» писать умеют многие, а быстро — единицы. Быстро и правильно — я таких пока не встречал, но они где-то есть, я точно знаю.
На первых стадиях — легко. Что проще — сделать один God Object или сделать 15 интерфейсов и 2 слоя абстракции, чтобы потом их удалить, когда узнаешь, что предметная область-то совсем иная? Я против God Object и любитель DI, SOLID, IoC TDD etc, но если ты прорабатываешь задачи, делая скелет на скорую руку, ты всегда будешь быстрее.
Грубо говоря, есть миллион вещей, на которых можно сэкономить время — от простого отказа не делать что-то с нуля, а взять готовое, и простого отказал от функционала, до миллиона приемов.
Просто «правильно» писать умеют многие, а быстро — единицы. Быстро и правильно — я таких пока не встречал, но они где-то есть, я точно знаю.
Но если можно написать достаточно хорошо и быстро — почему бы и нет?
Хардкод не самоцель, но обычно именно нежелание написать «неправильно», чтобы было не жалко переделать, и ограничивает скорость разработки людей.
Я не стесняюсь написать числа прямо в коде, текстовые строки и тд; потому что знаю — рано или поздно я заменю это на константы. И таких вещей очень много.
Хардкод не самоцель, но обычно именно нежелание написать «неправильно», чтобы было не жалко переделать, и ограничивает скорость разработки людей.
Я не стесняюсь написать числа прямо в коде, текстовые строки и тд; потому что знаю — рано или поздно я заменю это на константы. И таких вещей очень много.
Тут есть один тонкий момент. Когда пишешь один, можно особо и не стесняться, но когда в команде, это уже накладывает определенные рамки. Помня о том, сколь часто самому приходится вскрикивать: «Да твою мать!», пугая окружающих, когда натыкаешься на очередной «шедевр», подложенный тебе заботливым другом, сам стараешься не подводить товарищей подобным образом, даже если сильно торопишься.
Слава Богу, в Java/Eclipse есть такие вещи, как чекстайл и рефакторинг. Хардкоры можно побороть потом, с минимальными усилиями. И архитектуру выправить.
Быстро и правильно — я таких пока не встречал, но они где-то есть, я точно знаю.
Не знаю, из таких я встречал только кодогенераторы. Обычным смертным, сколь бы гениальны они не были, всегда приходится балансировать между быстро и правильно в зависимости от конкретной ситуации.
Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.
За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно.
Ну почему невозможно? Возможно, просто параллельно работает код разного качества с костылями на стороне старого для связи с новым.
При этом, если вы переписываете говно-ядро, то вам необходимо обеспечить обратную совместимость — задача не очень тривиальная и иногда не позволяет полностью избавится от говнокода (если интерфейс говяный, то его придётся оставить). Либо вместе с ядром вам придётся переписывать клиентский код — т.е. почти всю систему, даже если отдельные части написаны хорошо, но используют говяный интерфейс/API.
Кроме того, есть ещё один нюанс.
По своему опыту я могу сказать что программисты делятся на две кадегории: говнокодеры и чистокодеры. Невозможно заставить чистокодера написать говнокод так же и наоборот. По этому, что бы сначала написать говноядро, а потом переписать его, вам придётся поменять команду разработчиков. А это вообще жесть.
Кроме того, есть ещё один нюанс.
По своему опыту я могу сказать что программисты делятся на две кадегории: говнокодеры и чистокодеры. Невозможно заставить чистокодера написать говнокод так же и наоборот. По этому, что бы сначала написать говноядро, а потом переписать его, вам придётся поменять команду разработчиков. А это вообще жесть.
Прокси, адаптеры и прочие подобные решения позволяют решить проблему совместимости, изолируя чистый код от говна. Вот пример, с которым работаю прямо сейчас. Было:
Стало:
где UserAdapter::updateState($user_id, $state) проделывает всю работу получая объекты User по user_id и изменяя их состояние, пересекаясь со старым кодом только на уровне данных в MySQL. Сначала UserAdapter стремительно разрастался, но теперь стал потихоньку сокращаться.
function updateState($state)
{
global $USER;
//...
mysql_query("UPDATE users SET state = {$state} ... WHERE id = {$USER['id']}";
}
Стало:
function updateState($state)
{
global $USER;
$user_id = $USER['id'];
UserAdapter::updateState($user_id, $state);
}
где UserAdapter::updateState($user_id, $state) проделывает всю работу получая объекты User по user_id и изменяя их состояние, пересекаясь со старым кодом только на уровне данных в MySQL. Сначала UserAdapter стремительно разрастался, но теперь стал потихоньку сокращаться.
При этом, вы не избавились от глобальной переменно $USER и не избавились от лишней функции updateState(). Вы просто написали новую чистокодерскую функцию UserAdapter::updateState();
Где профит?
Где профит?
Профит в обратной совместимости. Старый код вызывает новую updateState не замечая разницы, новый работает непосредственно с User, а UserAdapter просто временный «мост» между старым и новым.
Когда все функции с
Когда все функции с
global $USER будут переписаны на UserAdapter, то от $USER можно будет избавиться, а в последствии и от UserAdapter. Я не отрицаю, что всё можно переписать и избавиться от говнокода. Но что бы избавится от глобальной переменной $USER вам потребуется переписать ядро + клиентский код. Т.е. почти всю систему.
Именно это я имел ввиду когда опровергал утверждение:
Вы же сами пишете, что придётся избавится от уже сделанного инструментария (выпилить функцию updateState). И конечно же всё это будет происходить не быстро так как вам придётся найти все места использующие updateState() и, ни дай бог, вы пропустите говнокод в виде:
TDD-тестов у вас нет и придётся тестировать ВСЁ приложение что бы убедиться в работоспособности. А это очень долго.
Кстати, я очень сильно сомневаюсь, что программисты знакомые с паттернами (прокси, адаптеры и прочие подобные решения) могут начать использовать глобальную переменную $USER. Здаётся мне, вы за кем то переписываете чужой говнокод. Т.е. менеджер сменил команду разработчиков?
Именно это я имел ввиду когда опровергал утверждение:
На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.
Вы же сами пишете, что придётся избавится от уже сделанного инструментария (выпилить функцию updateState). И конечно же всё это будет происходить не быстро так как вам придётся найти все места использующие updateState() и, ни дай бог, вы пропустите говнокод в виде:
$action = 'update';
$what = 'State';
$funcName = $action . $what;
$funcName(23);
TDD-тестов у вас нет и придётся тестировать ВСЁ приложение что бы убедиться в работоспособности. А это очень долго.
Кстати, я очень сильно сомневаюсь, что программисты знакомые с паттернами (прокси, адаптеры и прочие подобные решения) могут начать использовать глобальную переменную $USER. Здаётся мне, вы за кем то переписываете чужой говнокод. Т.е. менеджер сменил команду разработчиков?
Ну, я опровергал тезис «За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно» вне контекста использования инструментария. С другой стороны часть старого кода копипащу в новый, особо в него не вникая, лишь убедившись визуально в отсутствии зависимостей или хардкода или как можно безопасней разрывая зависимости и вынося хардкод в константы и т. п.
Не то чтобы переписываю, а должен внедрять новые фичи, править старые баги и т. п. Просто для себя решил, что лучше это делать параллельно с «сильным» рефакторингом существующего кода, чем вставлять костыли в существующем стиле. Заодно и тестами покрываю. С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы :)
Не то чтобы переписываю, а должен внедрять новые фичи, править старые баги и т. п. Просто для себя решил, что лучше это делать параллельно с «сильным» рефакторингом существующего кода, чем вставлять костыли в существующем стиле. Заодно и тестами покрываю. С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы :)
За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно
… используя готовый говно-инструментарий.
Просто эта фраза вырвана из контекста.
С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы
Вы начинаете писать правильно не за счёт говнокода, а за счёт своего большого опыта. И вряд ли вы сможете наговнокодить глобальную переменную $USER, потому что прекрасно понимаете: чистокод пишется быстрее чем говнокод. Здесь можно поспорить только с TDD, которое даёт результат в переспективе, но может немного замедлить текущие задачи.
Второй ваш абзац подтверждает мою догадку о смене команды. Соответственно, подтверждает утверждение о том что нельзя сначала скомандовать: «пишите говнокод блеать!!! »; а потом на поздних стадиях дать команду: «пишите чистокод с проектированием и tdd используя готовые говно-инструменты, йопт !!!».
Скорее не опыт, а знания, почерпнутые из сторонних источников. Читаешь какую-нибудь книгу или статью, видишь, что сталкивался с озвученной проблемой и видишь элегантное решение. Или просто в чужом коде натыкаешься.
Не то, что смена команды. Просто менеджер решил форкнуть существующий проект, а разработчик апстрима о рефакторинге слышать не хочет («всё работает»). Багфиксами обмениваемся, но не более. Если предлагаю багфикс с рефакторингом, то воспринимает его просто как багрепорт.
Не то, что смена команды. Просто менеджер решил форкнуть существующий проект, а разработчик апстрима о рефакторинге слышать не хочет («всё работает»). Багфиксами обмениваемся, но не более. Если предлагаю багфикс с рефакторингом, то воспринимает его просто как багрепорт.
видишь, что сталкивался с озвученной проблемой
Это опыт.
Читать описания паттернов без понимания проблемы — бессмысленно. В голове будет каша.
а разработчик апстрима о рефакторинге слышать не хочет
ну да, ну да. Как это знкакомо… К сожалению, говнокодера нельзя заставить чистокодить.
Дайте ему в руки фреймворк, качество кода вынужденно станет выше.
Как раз вчера разбирался с сайтом который генерирует страницы по 7-8 секунд. Сайт написан на ZendFramework. Я очень сильно удивился когда на не очень сложных страницах увидел в логах по 1000-1800 SQL-запросов!!! Все они очень простые и лёгкие и выполняются в среднем по 0.6мс и БД совсем маленькая. Но 1800 запросов к БД на одной странице это жесть. ZandFramework не вставил мозги разработчику.
Красной таблетки не существует. (с)
Красной таблетки не существует. (с)
Да, в корне верно! Стив Макконел в своей книге «Совершенный код» писал примерно о том же. Он говорил, что чем меньше связность элементов в системе (классов) и т.п., тем проще их использовать в других проектах. Таким образом проект действительно будет собираться как из кубиков.
Вспомнил «Жизнь внутри пузыря» Ашманова, особенно идею об «общей шине» ( www.ashmanov.com/pap/bubble/#p4.9.2).
О да, общая шина это пять!
В далёком 2007м бумажная тогда ещё Компьютерра брала интервью у Ашманова, по общей шине там тоже проехались. «Общая шина… потому что Общая шина!», хе-хе.
Способствует возвращению с небес на землю некоторых не в меру ретивых проектантов и снижению ЧСВ у них же.
В далёком 2007м бумажная тогда ещё Компьютерра брала интервью у Ашманова, по общей шине там тоже проехались. «Общая шина… потому что Общая шина!», хе-хе.
Способствует возвращению с небес на землю некоторых не в меру ретивых проектантов и снижению ЧСВ у них же.
Вы бы хоть продемонстрировали:
Действительно, доставляет. :)
Действительно, доставляет. :)
Вы бы хоть продемонстрировали
Да, действительно надо было. Исправлюсь, продемонстрирую другую картинку оттуда, которая тоже божественна и связана с данной статьей:
P.S. А вообще «Жизнь внутри пузыря» это конечно классика из разряда «Читать всем!», кто хоть как-то связан с IT.
Только надо учитывать, что рассказанная история, пропущена через фильтр сознания Ашманова
Конечно. Он и сам это признает в «Эпилог 2.0», отвечая на вопрос:
2) А чего это автор получается весь в белом, а все остальные известно в чём? Или, словами из другого блога, почему автор выходит д'Артаньян, а все остальные персонажи — козлы?
Класс!
Огромное спасибо за ссылку. С удовольствием прочитал.
Савельев — фрик, если не ошибаюсь.
Его теории отлично описывают реальность и дают ее предсказуемость.
И доктора наук в СССР фрикам не дают вроде, не? :)
И доктора наук в СССР фрикам не дают вроде, не? :)
Его теории отлично описывают реальность и дают ее предсказуемость.
Какую-такую реальность? Его гипотезы довольно часто идут вразрез с мнением современной науки.
И доктора наук в СССР фрикам не дают вроде, не? :)
Только академика. СССР, если что, уже 20 лет не существует, а наука на месте не сидит…
P.S. Про Савельева.
Брукс, перелогиньтесь!
Вы выросли. :) Это проходит каждый в своей области, ну разве кроме 5-10% клинических инфантилов, просто не каждый после этого пишет пост на Хабре :)
Согласен на все 100%!
Только мое мнение, что иногда надо переписывать с нуля даже на поздних стадиях. Лучше уж сделать еще одну итерацию и учесть имеющийся опыт, чем долго думать, а надо оно или не надо, тратя при этом время. Все равно время переписывание потом покроется меньшим количеством багов и более простой поддержкой.
Только мое мнение, что иногда надо переписывать с нуля даже на поздних стадиях. Лучше уж сделать еще одну итерацию и учесть имеющийся опыт, чем долго думать, а надо оно или не надо, тратя при этом время. Все равно время переписывание потом покроется меньшим количеством багов и более простой поддержкой.
Согласен. Вопрос планирования, чтобы это шло не бесконтрольно, а был какой-то вектор.
А так, я даже писал с нуля MVC фреймворк однажды. Думал написать второй, но, побродив по зарубежным open source вариантам, нашел пару по душе и решил — что лучше помогать коллегам, чем думать, что ты умнее всех :)
А так, я даже писал с нуля MVC фреймворк однажды. Думал написать второй, но, побродив по зарубежным open source вариантам, нашел пару по душе и решил — что лучше помогать коллегам, чем думать, что ты умнее всех :)
>> иногда надо переписывать с нуля даже на поздних стадиях
Если сроки позволяют. Надо очень-очень хорошо все считать. А потом умножать на два и прибавлять месяц. И с этим идти к руководству, заранее зная ответ.
Если сроки позволяют. Надо очень-очень хорошо все считать. А потом умножать на два и прибавлять месяц. И с этим идти к руководству, заранее зная ответ.
вы все еще не читали «Мифический человеко-месяц»?
Никак не мог добраться. Но Peopleware, написанный много лет назад, убедил меня подвинуть Брукса в списке 2read выше.
А вот недавно, обобщая свои выводы, увидел схожие тезисы у Брукса. Воистину, «все украдено до нас» (С)
А вот недавно, обобщая свои выводы, увидел схожие тезисы у Брукса. Воистину, «все украдено до нас» (С)
Доберитесь. Эту книгу стоит прочитать еще до того как берешься за свой первый проект. В издании 1995 года говорил сам Брукс — я удивлен что эта книга все еще актуальна. При этом первое издание вышло еще в 75 году. А в издании 1995 года добавилось эссе «Серебряной пули нет». Которое в целом перекликается с вашим топиком.
Все верно, и это применимо к любой области.
Работают люди, а не методики. А качество работы людей зависит от того любят ли они свою работу или нет.
Вот и весь секрет.
Работают люди, а не методики. А качество работы людей зависит от того любят ли они свою работу или нет.
Вот и весь секрет.
Если в туристическом походе вам приходится периодически менять планы из-за неожиданного ландшанфта или изменения погоды, значит ли это, что не следует прокладывать маршрут?
Если разные дома требует от прораба разных подходов к процессу строительства, значит ли это, что он должен отказаться от любых графиков и просто говорить своим строителям «кладите-кирпичи-блеать»?
И если у вас есть возможность нанять лучших игроков мира в сборную России по футболу, значит ли это, что они сами по себе, без менеджера и тренера, выйграют следующий чемпионат мира?
У вас изначально была неправильная позиция, мол, проектирование — это раз и на весь проект (хотя «водопад» вроде никто уже всьерёз не использует), а методологии разработки важней самого кода (хотя единственная цель методологий — сделать процесс написания кода более эффективным). Сейчас вы поняли ошибочность этих суждений, но при этом впали в другую крайность — проектирования вообще нету, методологий тоже нету,и гитары тоже нету, и татары тоже нету (с).
Другими словами, и проектирования, и методологии есть, и это хорошо. Но чтобы не возникло конфузов, все эти вещи нужно уметь правильно готовить, а не бездумно лепить agile потому что это круто и не заниматься оверинженирингом там, где ещё ничего не понятно.
Если разные дома требует от прораба разных подходов к процессу строительства, значит ли это, что он должен отказаться от любых графиков и просто говорить своим строителям «кладите-кирпичи-блеать»?
И если у вас есть возможность нанять лучших игроков мира в сборную России по футболу, значит ли это, что они сами по себе, без менеджера и тренера, выйграют следующий чемпионат мира?
У вас изначально была неправильная позиция, мол, проектирование — это раз и на весь проект (хотя «водопад» вроде никто уже всьерёз не использует), а методологии разработки важней самого кода (хотя единственная цель методологий — сделать процесс написания кода более эффективным). Сейчас вы поняли ошибочность этих суждений, но при этом впали в другую крайность — проектирования вообще нету, методологий тоже нету,
Другими словами, и проектирования, и методологии есть, и это хорошо. Но чтобы не возникло конфузов, все эти вещи нужно уметь правильно готовить, а не бездумно лепить agile потому что это круто и не заниматься оверинженирингом там, где ещё ничего не понятно.
Все это не работает без людей. В вашем посте любой пример это подтверждает. Прораб рулит рабочими, без него сами работают роботы и немцы. Здание рассчитывает умный архиетектор, и именно его косяк при самой крутой методе фатален
И тд
Методики и проектирование суть инструменты. Сегодня я пилю руками, завтра держу бензопилу.
Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
И тд
Методики и проектирование суть инструменты. Сегодня я пилю руками, завтра держу бензопилу.
Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
Одно не исключает другого, любым людям (в том числе талантливым) нужна организация совместной работы.
Талантливый организатор
Спасибо, кэп!
Теперь понятно! Нужно было всего лишь устраивать на работу талантливых людей!
Пойду найму 10 талантливых программистов и пару талантливых проджект менеджеров… Всего-то делов!
Теперь понятно! Нужно было всего лишь устраивать на работу талантливых людей!
Пойду найму 10 талантливых программистов и пару талантливых проджект менеджеров… Всего-то делов!
Если у вас есть всего лишь месяц, то лучше потратить на эту благородную задачу,
чем на поиск методики, которая решит все сразу, или проектирования на бумаге всего и вся, вместо пяти итераций с релизами говнокода каждый день.
чем на поиск методики, которая решит все сразу, или проектирования на бумаге всего и вся, вместо пяти итераций с релизами говнокода каждый день.
Уже год ищем, пока нашли только двоих талантливых. Что мы делаем не так?
Может быть вы нам подскажете место, где тусуются талантливые программисты?
Поиск методики — дело неблагодарное. Всегда выбираешь из того, что знаешь по опыту, а дальше — по обстоятельствам, проекты то все разные.
Да что это я, вам тут все в этой ветке про это пишут, а вы дальше гнёте)
Предлагаю на этом остановиться)
Может быть вы нам подскажете место, где тусуются талантливые программисты?
Поиск методики — дело неблагодарное. Всегда выбираешь из того, что знаешь по опыту, а дальше — по обстоятельствам, проекты то все разные.
Да что это я, вам тут все в этой ветке про это пишут, а вы дальше гнёте)
Предлагаю на этом остановиться)
Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходовМне показалось, или вы обходными путями всё-таки дошли до первого тезиса Agile манифеста?
«Individuals and interactions over processes and tools» © agilemanifesto.org
А в начале статьи говорили, что это фуфло… :-)
> Методики и проектирование суть инструменты
Естественно! И у каждого инструмента своя область применения. Так же как нельзя отверткой забить гвоздь, так и проектирование не решит всех проблем проекта. Но это не означает, что «проектирования нет». И так же естественно, что инструментом нужно уметь пользоваться (необходимы профессиональные люди).
Естественно! И у каждого инструмента своя область применения. Так же как нельзя отверткой забить гвоздь, так и проектирование не решит всех проблем проекта. Но это не означает, что «проектирования нет». И так же естественно, что инструментом нужно уметь пользоваться (необходимы профессиональные люди).
оно эволюционное. в обычном виде я считаю, для 99% проектов оно нахер не нужен, тк будет 100% оверинжиниринг и время на рынке пропущено.
Для мелких 3-х месячных проектов (почти все мобильные приложения) — не нужно. Да и все веб приложения по MVC шаблону строятся, для них тоже не особо нужно проектирование. Нынче веб+мобильные — это порядка 80%, так что вы не далеки от правды. Но это частный случай (хоть и массовый). А в общем случае без проектирования в большом проекте сложно.
Никто не спорит, что всё упирается в людей, а проектирование, методологии и т.п. — это всего лишь инструменты. Вопрос в том, нужны ли эти инструменты, или же люди и гвозди забивать, и брёвна пилить должны голыми руками.
Когда художник пишет картину, он её делает по линиям, сразу конечный вариант? Нет, сначала много набросков, общие элементы, а потом детали, детали, детали.
Отлично сказано!
Мне вспомнилась фраза Дуайта Эйзенхауэра: Когда готовишься к сражению, планы бессмысленны, но планирование необходимо.
Также вспоминается фраза, которая есть практически в любой книге по гибким методологиям: Серебряной пули не существует, каждая методология имеет свою область применимости.
Читая статьи подобные этой, постоянно сталкиваюсь с одной и той же ошибкой в понимании гибких методологий. Почему-то считается, что гибкие методологии устраняют типичные проблемы разработки — и это не верно! Наоборот, в них признается факт, что от этих проблем не избавиться и в процессе разработки мы должны учитывать. Даже самые опытные программисты делают глупые ошибки — поэтому надо писать тесты и вообще лучше работать в паре, нельзя сразу учесть все требования — поэтому пишется сразу код выполняющий только текущую задачу, а дальше короткие итерации и рефакторинг в помощь, и так далее. Не находите, данные рекомендации совпадают с выводами автора, основанными на практике?
Безусловно, на одной только методологии проект не напишешь — нужны люди. Но хорошие практики разработки, применяемые с пониманием того, какую выгоду они несут в конкретной ситуации, сильно увеличат КПД разработчиков.
Ну а хвалебные отзывы о сверхневероятной эффективности каких-то методик оставим на совести консультантов — им же надо как-то продавать свои услуги.
Мне вспомнилась фраза Дуайта Эйзенхауэра: Когда готовишься к сражению, планы бессмысленны, но планирование необходимо.
Также вспоминается фраза, которая есть практически в любой книге по гибким методологиям: Серебряной пули не существует, каждая методология имеет свою область применимости.
Читая статьи подобные этой, постоянно сталкиваюсь с одной и той же ошибкой в понимании гибких методологий. Почему-то считается, что гибкие методологии устраняют типичные проблемы разработки — и это не верно! Наоборот, в них признается факт, что от этих проблем не избавиться и в процессе разработки мы должны учитывать. Даже самые опытные программисты делают глупые ошибки — поэтому надо писать тесты и вообще лучше работать в паре, нельзя сразу учесть все требования — поэтому пишется сразу код выполняющий только текущую задачу, а дальше короткие итерации и рефакторинг в помощь, и так далее. Не находите, данные рекомендации совпадают с выводами автора, основанными на практике?
Безусловно, на одной только методологии проект не напишешь — нужны люди. Но хорошие практики разработки, применяемые с пониманием того, какую выгоду они несут в конкретной ситуации, сильно увеличат КПД разработчиков.
Ну а хвалебные отзывы о сверхневероятной эффективности каких-то методик оставим на совести консультантов — им же надо как-то продавать свои услуги.
Мне кажется истина как всегда где то посредине. Хорошим программистам любящим свою работу так же нужны какие-то общие рамки и ориентиры, просто для того чтобы эффективно работать вместе. От того что перед написанием проекта будет составлена общая архитектура, хотя бы в виде: «Это мы пишем модулями, а этот функционал будем использовать во многих проектах поэтому выносим на api», а более детальное проектирование можно отложить на момент реализации конкретного блока приложения.
Методологии же позволяют структурировать процесс разработки, наладить общение в командах. Просто некоторые менеджеры за формой не видят содержания, и догматичное следование принципам выбранной методологии начинает мешать а не помогать.
Методологии же позволяют структурировать процесс разработки, наладить общение в командах. Просто некоторые менеджеры за формой не видят содержания, и догматичное следование принципам выбранной методологии начинает мешать а не помогать.
Надеюсь, этот пост прочитает как можно большее число манагеров и они наконец поймут, что можно хоть каждый день придумывать различные методологии, часами обсуждать новые фичи и в течении нескольких месяцев заниматься проектированием, но если у вас нет людей, которые могут «писать код, блять», то это пустая трата времени и денег.
Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.
Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».
Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».
Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
Люди разбегутся, пока будут выстраиваться процессы и болтовня по 100 часов в неделю.
ИМХО!!!
ИМХО!!!
Вам не повезло, если у вас сложилось мнение, что «процессы» — это «болтовня 100 часов в неделю».
Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.
А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.
Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.
А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.
Самое-то главное просмотрели: когда Нео выбирает и съедает одну таблетку, Морфеус ест _другую_.
Я как PM тоже пришел к Вашим выводам примерно год назад. До этого страдал привязыванием методологий к разработке проектов. Лишь в нескольких случаях получалось создать нечто работоспособное, в иных случаях 90% процессов были просто не нужны в проекте.
Скажу только одно — методологии (лучшие практики) знать необходимо, но слепо использовать их нельзя.
Даю гарантию, что любому из ваших проектов пригодится только 1-5% процессов, описанных в методологиях, возможно даже вы возьмете по одному процессу из Kanban и PMBoK и этого будет достаточно.
Не тратьте время на фигню в виде утренних скрамов, пленинг покеров и будет Вам счастье ;)
Скажу только одно — методологии (лучшие практики) знать необходимо, но слепо использовать их нельзя.
Даю гарантию, что любому из ваших проектов пригодится только 1-5% процессов, описанных в методологиях, возможно даже вы возьмете по одному процессу из Kanban и PMBoK и этого будет достаточно.
Не тратьте время на фигню в виде утренних скрамов, пленинг покеров и будет Вам счастье ;)
Или же, если разработчики уже имели опыт рефакторинга в другой компании, они сходу предложат вам проектировать сразу. UML, использование сложнейших инструментов и так далее — давайте сразу сделаем все правильно, чтобы не переписывать. Это может касаться не только программистов — дизайнер будет стараться нарисовать сразу конечный макет, дабы сдать его без переделок.
Знакомо — было на прошлой работе. В результате неделю просидел просто-так, думая, «а чтоб ещё добавить?». В результате, все изменения пошли уже после того, как я начал делать хоть что-то, помимо проектирования.
Спасибо, это лучшее вдохновение перед работой!
С такими как вы, хочется работать и получать тот кайф от кода (некоторые это не понимают).
Видно, накипело, как и у многих… Спасибо!
С такими как вы, хочется работать и получать тот кайф от кода (некоторые это не понимают).
Видно, накипело, как и у многих… Спасибо!
Восхитительно, спасибо. Данная статья сильно укрепила мои взгляды.
Любой дизайнер, программист, специалист, глядя на свои работы годичной давности, найдет много ошибок — ибо вырос профессионально.
Кто-то даже сказал, что если через полгода ваш старый код не кажется вам убожеством, то вы ничему не научились за эти полгода.
Вы всё совершенно правильно подметили для продуктовых компаний или технологичных стартапов.
Но есть ещё одна разновидность, самая многочисленная в СНГ — аутсорсинг, особенно оффшорный. Чтобы заработать много денег, руководству приходится нанимать много студентов, программистов-неудачников и т.п. тупо потому, что даже их уровня разработчика хватает на средний проект. И по-другому никак — не всем в жизни предписано делать свои проекты, свершения и прошивку андронного коллайдера.
А для таких людей нужна жёсткая система с жёсткими правилами. Они просто по-другому не могут работать хотя бы с 10% от продуктивности программистов по рождению.
Но в целом согласен — нужно брать хорошее из методологий только тогда, когда этого потребует проект, а не подстраивать каждый проект под канбан или agile.
Но есть ещё одна разновидность, самая многочисленная в СНГ — аутсорсинг, особенно оффшорный. Чтобы заработать много денег, руководству приходится нанимать много студентов, программистов-неудачников и т.п. тупо потому, что даже их уровня разработчика хватает на средний проект. И по-другому никак — не всем в жизни предписано делать свои проекты, свершения и прошивку андронного коллайдера.
А для таких людей нужна жёсткая система с жёсткими правилами. Они просто по-другому не могут работать хотя бы с 10% от продуктивности программистов по рождению.
Но в целом согласен — нужно брать хорошее из методологий только тогда, когда этого потребует проект, а не подстраивать каждый проект под канбан или agile.
да, есть такая тема.
но я устал от проектов в одну строчку в свое время, а также говносайтов и жадных клиентов, и поэтому забил на свою студию и пошел на наемную работу программистов. потом вырос до ведущего и PM в итоге.
управлять разрабами сайтов, такими, как студенты, нужно уметь, и тут действительно нужна ИМХО система, согласен.
но сколько умных, читающих эту статью программистов пойдут на ЗП x2 работать Битрикс программистами? Или тем более ЖУМЛА (старой, нерефакторенной)? нафиг нафиг
но я устал от проектов в одну строчку в свое время, а также говносайтов и жадных клиентов, и поэтому забил на свою студию и пошел на наемную работу программистов. потом вырос до ведущего и PM в итоге.
управлять разрабами сайтов, такими, как студенты, нужно уметь, и тут действительно нужна ИМХО система, согласен.
но сколько умных, читающих эту статью программистов пойдут на ЗП x2 работать Битрикс программистами? Или тем более ЖУМЛА (старой, нерефакторенной)? нафиг нафиг
Ну что сказать?.. Очевидно где то в своей сфере и со своим опытом вы правы, но подходы «пиши-код-блять», «давай быстро заговнокодим» и т.д. ничего хорошего никому не дал.
И что самое удивительное, если для компаниям такой подход даёт прозрачную надежду на быстрый выход продукта и, иногда, эта надежда сбывается, то программиста которые так работают ВСЕГДА оказываются в жопе. Потому что даже если продукт выходит он оказывается настолько плохим, дырявым и с точки зрения кода не поддерживаемым, что у всех консультантов, которых компания ВЫНУЖДЕНА приглашать, поскольку непонятно ведь отчего вся система падает или не держит нагрузку, возникает вполне логичный вопрос — «а как вообще такое можно было написать?». После чего возникает другой вопрос — «кто конкретно делал этот проект и почему в нем сплошной говнокод и нет никакой структуры?». А самое печальное, что ответы на этот вопрос все знают и та команда которая делала этот проект заменяется на более профессиональную. Так что мой вам совет, не пытайтесь скрыть свою некомпетентность за фразами «это не работает», «главное это писать-блять-код», «не надо лишних действий» и прочими мантрами типа «красной таблетки не существует».
И что самое удивительное, если для компаниям такой подход даёт прозрачную надежду на быстрый выход продукта и, иногда, эта надежда сбывается, то программиста которые так работают ВСЕГДА оказываются в жопе. Потому что даже если продукт выходит он оказывается настолько плохим, дырявым и с точки зрения кода не поддерживаемым, что у всех консультантов, которых компания ВЫНУЖДЕНА приглашать, поскольку непонятно ведь отчего вся система падает или не держит нагрузку, возникает вполне логичный вопрос — «а как вообще такое можно было написать?». После чего возникает другой вопрос — «кто конкретно делал этот проект и почему в нем сплошной говнокод и нет никакой структуры?». А самое печальное, что ответы на этот вопрос все знают и та команда которая делала этот проект заменяется на более профессиональную. Так что мой вам совет, не пытайтесь скрыть свою некомпетентность за фразами «это не работает», «главное это писать-блять-код», «не надо лишних действий» и прочими мантрами типа «красной таблетки не существует».
Если код работает, его всегда можно улучшать. Особенно при закладывании основ во время быстрых фаз. У нас есть опыт 8х больших версий проекта, все масштабируется
Если же делать идеально — ну мы как-то 9 месяцев делали очень давно календарь учета рабочего времени
И он был на смарку. Увы, тогда техник, описанных в статье, я и близко не знал.
Так что структура и тд — вопрос правильной эволюции. Что труднее и интереснее проектирования сразу — ибо даже в неплохих проектах развитие всегд сложнее масштабировать, чем первую стадию
Имхо разумеется, все имхо…
Если же делать идеально — ну мы как-то 9 месяцев делали очень давно календарь учета рабочего времени
И он был на смарку. Увы, тогда техник, описанных в статье, я и близко не знал.
Так что структура и тд — вопрос правильной эволюции. Что труднее и интереснее проектирования сразу — ибо даже в неплохих проектах развитие всегд сложнее масштабировать, чем первую стадию
Имхо разумеется, все имхо…
Сильная статья :) В некоторых деталях я не соглашусь, но такое несогласие вполне нормальное явление.
С удовольствием бы плюсанул, но, увы, кармы не хватает…
С удовольствием бы плюсанул, но, увы, кармы не хватает…
Как здорово, что я не одинок :)
Статья чем то напоминает «Я научился программировать на python за 21 день».
«Мы использовали всякие способы разработки и поняли что они не эффективны».
Звучит примерно так же. По крайней мере для меня. Я не говорю что не надо писать код. Весь вопрос какой код и кому писать.
«Мы использовали всякие способы разработки и поняли что они не эффективны».
Звучит примерно так же. По крайней мере для меня. Я не говорю что не надо писать код. Весь вопрос какой код и кому писать.
Вот так бывает: загорается человек, делает проект с радостью. Все у него получается, совершенствуется в своем мастерстве.
Потом доходит до книжек по архитектуре, о проектированию, UML и пр. С глубокой верой (ага, а как же иначе — умные люди ведь писали) тратит время на изучение, читает умные книжки, пытается понять. И все… Дальше одно переливание из пустого в порожнее и потеря времени.
Потом доходит до книжек по архитектуре, о проектированию, UML и пр. С глубокой верой (ага, а как же иначе — умные люди ведь писали) тратит время на изучение, читает умные книжки, пытается понять. И все… Дальше одно переливание из пустого в порожнее и потеря времени.
Вы почти пересказали книгу «Факты и заблужнения» профессионального программирования,
так что умные книги читать надо и делать из них выводы тоже полезно.
Спасибо Вам за ваш опыт… сам имею похожее мнение, но не решаюсь на озвучку из-за помидоров и попкорна.
так что умные книги читать надо и делать из них выводы тоже полезно.
Спасибо Вам за ваш опыт… сам имею похожее мнение, но не решаюсь на озвучку из-за помидоров и попкорна.
Я правильно понял, что вы пришли к канбану?
>первые три-пять итераций системы должны быть обязательны сделаны быстро (как правило, хардкодом и говнокодом).
это чтоб проект получил пинок в жизнь и хоть как-то существовал… можно утонуть в архитектуре и рефакторинге… и проект утонет. У меня был опыт разработки «мертвворожденных» проектов. Чисто банально — кончилось финансирование, изменились тенденции рынка и т.д…
это чтоб проект получил пинок в жизнь и хоть как-то существовал… можно утонуть в архитектуре и рефакторинге… и проект утонет. У меня был опыт разработки «мертвворожденных» проектов. Чисто банально — кончилось финансирование, изменились тенденции рынка и т.д…
Конечно, всё держится на людях. Если вам повезло с командой — всё получится, что с методологией и планированием, что без них. Если не повезло — не получится, опять-таки, независимо от методологий. Меня лично бесит, когда начинают рассказывать, что «у нас всё вышло, потому что у нас Agile!». У вас всё вышло, потому что программисты были хорошие.
Поэтому я все усилия, по возможности, прилагаю на поиск и на удержание людей. Не верю в методологии — если нет проджекта, верящего в проект, и команды умных людей, все остальное не имеет значения. И не верю в умение сделать сразу хорошо, а верю в эволюцию
хорошие слова… есль люди способные довести проект до финиша — есть и проект…
хорошие слова… есль люди способные довести проект до финиша — есть и проект…
У вас все вышло, потому что вы, к счастью, заебали своим аджайлом своих программистов недостаточно, чтобы окончательно выбить из них инженерный подход и хакерский дух, и они таки сделали вам софт.
Нельзя делить на черное и белое. Главное, конечно, люди. Без них и аджайла и не аджайла не будет. Так же от людей самих зависит, как они лучше работать будут, как понимают методику, по которой работают в проекте.
Но всё же хорошие программисты в разных условиях по разному будут эффективны. Если приходит менеджер, который узколобо верит только в водопад и планирование и появляется некий комитет «более умных» которые будут утверждать каждый шаг и не давать «умным программистам» вести проект и общаться (разведение грибов), то любой проект можно тормознуть на года и скорость разработки будет одинакова, что при таком же штате индусов/студентов.
Но всё же хорошие программисты в разных условиях по разному будут эффективны. Если приходит менеджер, который узколобо верит только в водопад и планирование и появляется некий комитет «более умных» которые будут утверждать каждый шаг и не давать «умным программистам» вести проект и общаться (разведение грибов), то любой проект можно тормознуть на года и скорость разработки будет одинакова, что при таком же штате индусов/студентов.
простите, креационисты, переходные формы все-таки нашли
Ого, я что-то пропустил?
Надеюсь, что имелись в виду звенья между нами и нашими предками, а не между уткой и крокодилом…
Что самое интересное, что поскольку теория не подтверждена фактологическими данными (а их на самом деле собрано за сотню лет огромное количество), то опираться на неё для выбора стратегии разработки несколько эмм… Рискованно, что ли. Ведь если нам нужно спроектировать не «изменённый клюв вьюрка», а самого вьюрка с нуля, то отнюдь не факт, что такой подход сработает.
И тут есть небольшое отличие. В то время как эволюция не предполагает изначального замысла, или конечной цели к которой нужно придти, у разработчика ситуация прямо противоположная — он знает, чего хочет добиться, и какое-то видение конечного продукта у него есть. Ну и да, эволюция не подразумевает участия разума.
Ну да ладно, это я так, придираюсь. Понятно, что методология, предлагаемая автором (камбан) подтверждена опытом (не только автора, но и крупных корпораций). Просто непроверенная теория, с принципиальными отличиями от разработки софта тут несколько, кхм… Некстати, что ли.
И тут есть небольшое отличие. В то время как эволюция не предполагает изначального замысла, или конечной цели к которой нужно придти, у разработчика ситуация прямо противоположная — он знает, чего хочет добиться, и какое-то видение конечного продукта у него есть. Ну и да, эволюция не подразумевает участия разума.
Ну да ладно, это я так, придираюсь. Понятно, что методология, предлагаемая автором (камбан) подтверждена опытом (не только автора, но и крупных корпораций). Просто непроверенная теория, с принципиальными отличиями от разработки софта тут несколько, кхм… Некстати, что ли.
Статья супер, спасибо за нее.
и прочитав кучу умных книг про Методологии программирования я понял, что большинство из них ориентированы на большие компании типа Ms, Oracle и создании грандиозных продуктов… В малешьких компаниях с 5-10 чел. с персональной зоной ответственности половина методик просто не кактит. Скрум я пробовал в трех компаниях и он ни где не прижился.
Интересно, что о прославленной ценности людей и потребности нанимать на работу максимально одарённых думает Рей Крок. Почему-то мне кажется, что он бы с вами не согласился. Точнее сказать, согласился бы не во всём.
Хватит нести чепуху: «писать надо говнокодом, хардкодить всё подряд, рефакторинг и проектирование не нужно вообще»
Вы просто не понимают и не умеют пользоваться этими инструментами. Очень похоже, что архитектор у вас фиговый.
Лично я пользуюсь постулатами:
1. Если для разработки нового функционала, необходимо переделывать базис — значит базис изначально был запроектирована не правильно. (у вас именно такая ситуация).
2. Если нужно изменить существующий фунционал, то менять базис в любом случае придётся, но чем больше говнокода, тем больше изменений и дальнейших багов.
Например, jQuery изначально хорошо запроектирована, написана без говнокода, через tdd. Это базис на котором разработано сотни тысяч плагинов, который используют на миллионах сайтов и который можно расширять до бесконечности. Как вы думаете, можно ли было реализовать jQuery без проектирования, без tdd и собрать говнокодом?
Нет!
Вы просто не понимают и не умеют пользоваться этими инструментами. Очень похоже, что архитектор у вас фиговый.
Лично я пользуюсь постулатами:
1. Если для разработки нового функционала, необходимо переделывать базис — значит базис изначально был запроектирована не правильно. (у вас именно такая ситуация).
2. Если нужно изменить существующий фунционал, то менять базис в любом случае придётся, но чем больше говнокода, тем больше изменений и дальнейших багов.
Например, jQuery изначально хорошо запроектирована, написана без говнокода, через tdd. Это базис на котором разработано сотни тысяч плагинов, который используют на миллионах сайтов и который можно расширять до бесконечности. Как вы думаете, можно ли было реализовать jQuery без проектирования, без tdd и собрать говнокодом?
Нет!
Я чуть позже напишу статью, возможно
А пока банальный пример. Любой сказочный архитектор может с пеной у рта говорить про проектирование сразу. НО! реальную проверку система пройдет ТОЛЬКО С ЖИВЫМИ ДАННЫМИ
без живых данные любые макеты есть херня.
А дальше — экономика. Чем больше итераций в единицу времени — тем быстрее все поймете. Отсюда говнокод для быстрых первы версий.
Итак, пример — убийца. Как бы не проектировали самолеты, они все равно падают. Потому что только атмосфера, увы, все выявляет. На чертежах все идеально.
То же самое стартап. Бизнес планы ничего не решают, будучи хоть трижды крутыми. Все решает реальный клиент
А дальше — см. Выше про скорость эволюционирования. Кто быстрее, тот и победил
А пока банальный пример. Любой сказочный архитектор может с пеной у рта говорить про проектирование сразу. НО! реальную проверку система пройдет ТОЛЬКО С ЖИВЫМИ ДАННЫМИ
без живых данные любые макеты есть херня.
А дальше — экономика. Чем больше итераций в единицу времени — тем быстрее все поймете. Отсюда говнокод для быстрых первы версий.
Итак, пример — убийца. Как бы не проектировали самолеты, они все равно падают. Потому что только атмосфера, увы, все выявляет. На чертежах все идеально.
То же самое стартап. Бизнес планы ничего не решают, будучи хоть трижды крутыми. Все решает реальный клиент
А дальше — см. Выше про скорость эволюционирования. Кто быстрее, тот и победил
Я учился в вузе расчёту самолётов. Там первый просто ломают на стенде при помощи имитации эксплуатационной нагрузки специальными машинами. Так вот если самолёи ломается при нагрузке, более чем на 20% превышающей расчётную, то считается, что он «перетяжелён» и его надо перепроектировать с целью снижения массы. Поэтому, кстати, пассажирский самолёт и должен ломаться при попытке сделать на нём мёртвую петлю. Ну а в очень нештатных погодных условиях типа урагана, при сильных порывах ветра словить на крыло нагрузку более чем на 20% превышающую максимальную расчётную — проще простого: при полёте на максимальной (для планера) скорости порыв ветра со скоростью более 10% от этой максималки и всё…
Так что атмосфера там почти ничего не выявляет.
Так что атмосфера там почти ничего не выявляет.
Спасибо за уточнение.
Но суть та же.
>Там первый просто ломают на стенде при помощи имитации эксплуатационной нагрузки специальными машинами.
То есть не нарисовали, сразу построили по чертежам и сдали в эксплуатацию.
Всегда проверяют живыми нагрузками. Либо их аналогом.
А в ПО нередко могут часами UMLки рисовать, не применяя реальных нагрузок и данных. Потому что в голове моделирование ненадежно, увы. Нужно делать живые прототипы, а ля промышленный образец и тд — а законы бизнеса понуждают сделать как можно раньше и быстрее.
Все просто и очень сложно одновременно :)
Но суть та же.
>Там первый просто ломают на стенде при помощи имитации эксплуатационной нагрузки специальными машинами.
То есть не нарисовали, сразу построили по чертежам и сдали в эксплуатацию.
Всегда проверяют живыми нагрузками. Либо их аналогом.
А в ПО нередко могут часами UMLки рисовать, не применяя реальных нагрузок и данных. Потому что в голове моделирование ненадежно, увы. Нужно делать живые прототипы, а ля промышленный образец и тд — а законы бизнеса понуждают сделать как можно раньше и быстрее.
Все просто и очень сложно одновременно :)
>То есть не нарисовали, сразу построили по чертежам и сдали в эксплуатацию.
Самолетной индустрии более 100 лет. Первые самолеты делали без проектировки, в современном понимании этого слова. Современные самолеты это то, что мы получили эволюционным путем за более чем 100 лет развития.
Индустрия ПО несколько отличается от строительства зданий и самолетов.
Самолетной индустрии более 100 лет. Первые самолеты делали без проектировки, в современном понимании этого слова. Современные самолеты это то, что мы получили эволюционным путем за более чем 100 лет развития.
Индустрия ПО несколько отличается от строительства зданий и самолетов.
Я проектировал самолеты и могу сказать как этот процесс происходит.
1. Проектирование общей компоновки.
2. Расчет массово-габаритный (итерационный)
3. Проектирование аэродинамики: расчеты в первом приближении, программное моделирование, корректировки…
4. Создание модели, продувка. Корректировки, продувки и т.д. Возврат к п.2. и к п.3.
Когда все более менее устраивает аэродинамиков и компоновщиков то
5. расчет на прочность планера и узлов, корректировка массы с учетом реальных узлов. Скорее всего возврат к п.п. 1,2,3
6. создание массо-габаритного макета, продувка.
7. Создание узлов в натуральную величину и испытание их на прочность.
8. Создание лидерного экземпляра и его испытания.
Т.е. никто не строит самолет только для того, чтобы его сломать :)
Перед постройкой очень длительное проектирование.
1. Проектирование общей компоновки.
2. Расчет массово-габаритный (итерационный)
3. Проектирование аэродинамики: расчеты в первом приближении, программное моделирование, корректировки…
4. Создание модели, продувка. Корректировки, продувки и т.д. Возврат к п.2. и к п.3.
Когда все более менее устраивает аэродинамиков и компоновщиков то
5. расчет на прочность планера и узлов, корректировка массы с учетом реальных узлов. Скорее всего возврат к п.п. 1,2,3
6. создание массо-габаритного макета, продувка.
7. Создание узлов в натуральную величину и испытание их на прочность.
8. Создание лидерного экземпляра и его испытания.
Т.е. никто не строит самолет только для того, чтобы его сломать :)
Перед постройкой очень длительное проектирование.
Первый экземпляр всё равно ломают на нагрузочном стенде, по крайней мере раньше было так. Нужна уверенность, что крылья не отломаются при взлёте в начале лётных испытаний;-). С учётом возможной итеративности проектирования вероятность перетяжелённости стремится к нулю…
Смысл моего коммента был в том, что атмосфера, на самом деле, практически ничего не «показыает», а самолёты ломают обычно не от плохого проектирования, а от попадания туда, где они и должны ломаться.
Смысл моего коммента был в том, что атмосфера, на самом деле, практически ничего не «показыает», а самолёты ломают обычно не от плохого проектирования, а от попадания туда, где они и должны ломаться.
Сколько итераций надо сделать что бы без проектирования слепить самолёт? Сколько денег на это будет потрачено?
одну-полторы
На самом деле природа делает миллионы итераций что бы изобрести белку, а потом ещё миллионы итераций что бы изобрести птицу. Всё это она делает вслепую не зная конечной цели и без проектирования. Просто что-то делает, а в результате через милионы лет появляется птица.
Вы сможете без проектирования, без чертежей, без каких либо расчётов собрать самолёт за полторы попытки? И он будет летать??? (речь конечно же не о бумажном самолётике)
Извините, не заметил фразу «без проектирования», думал, вопросы был сколько раз самолёт обычно перепроектируют.
Не все аналогии подходят.
И хреново в нашей отрасли то, что некоторые аналогии приходят извне из общих рассуждений, прямо со студентами. Просто из языка, перевода или созвучности. Т.е. эти аналогии вроде даже насильно специально не навязывают, но как только появляется снова неопытный программист, он повторяет одно и то же.
Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…
Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.
Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).
Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.
А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.
Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.
И хреново в нашей отрасли то, что некоторые аналогии приходят извне из общих рассуждений, прямо со студентами. Просто из языка, перевода или созвучности. Т.е. эти аналогии вроде даже насильно специально не навязывают, но как только появляется снова неопытный программист, он повторяет одно и то же.
Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…
Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.
Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).
Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.
А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.
Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.
>Программист == переводчик.
+pow(10,10)
+pow(10,10)
Интересно как же вы будете выделять уровни абстракции без проектирования. Точнее я знаю как пейсать код блеать! Про количество итераций для одного и того же скромно умолчим?
Маконнела читать до просветления.
Маконнела читать до просветления.
«Интересно как же вы будете выделять уровни абстракции без проектирования»
Фаулера и Бека Кента читать до просветления :)
Отчего такая любовь к Макконелу? Да, нужен, да, хорош. Но воспринимать надо критически. Не всё подходит для любых языков. Некоторые советы для некоторых языков просто вредны. Макконел С++сник.
Фаулера и Бека Кента читать до просветления :)
Отчего такая любовь к Макконелу? Да, нужен, да, хорош. Но воспринимать надо критически. Не всё подходит для любых языков. Некоторые советы для некоторых языков просто вредны. Макконел С++сник.
могу кратко пояснить, как выделяются уровни абстракции на ходу. Отлично выделяются и лучше, чем предугадывать.
Если вы знакомы с реляционными БД, то сначала на таблицах, так очевиднее.
У вас есть пока небольшая бухгалтерская программа. И есть одна из таблиц — Orders (заказы). Колонки, помимо денег, хранят атрибуты заказчика — имя, телефон. Вы это так писали, такие были на данный момент требования. Внезапно обнаруживаете, что связки имен и телефонов повторяются. Что надо делать? Выносить в отдельную таблицу.
Точно так же в ООП. У вас на текущий момент класс Order, у которого есть поля — имя и телефон. Выделить абстракцию? Не вопрос. Создаете класс OrderingCustomer. Туда выносите атрибуты — имя и телефон. Здесь, побольше возможностей, поэтому и смотрите, этот класс выносить за пределы класса или внутри класса оставить. Смотрите на текущие требования и выбираете наиболее ограниченный вариант. Проблемы?
Второй пример. У вас уже есть таблица OrderingCustomers. Кроме того в процессе разработки при постепенном поступлении требований появилась таблица Employers. И вы видите, что часть колонок пересекается. Имя и телефон. Пора выделить новую сущность — Persons. Вынести эти колонки туда и в таблицах OrderingCustomer и Employers установить ключи. Это простая по сути операция поиска общего и частностей. Частности в исходных таблицах, общее в новой.
В ООП. Ровно точно так же. Только еще и поведение выделяете, общее и частное. Уже появляются абстракции. Проблемы?
Вдруг вам понадобилось обрабатывать одинаково эти разные объекты. Создаете фабрику, тогда вас перестает волновать, что за объекты. Еще больше понадобилось абстрагирование — создаете интерфейсы, наследуете объекты.
Нет никаких проблем создавать абстракции исходя из нужд «здесь и сейчас». И нет никаких проблем делать это постепенно и менять по мере надобности.
Заметьте, я примеры дал, почти механические. Вы, теоретически, могли бы сразу увидеть, что имя и телефон относятся к человеку и смоделировать и это. Но а если это не потребуется? Может вы хотите вообще вселенную смоделировать включая атомы? Это не возможно, т.к. объективной истины нет, а модели субъективны )))
Заказчик, который дает требования к проекту, мог повернуть не в ту сторону, куда вы предугадываете и с объектами вышла бы незадача. Архитектура в конце концов при постоянном предугадывании становится деревянной, не позволяющей вносить дальнейшие изменения. А потом, появляются мысли и желания о полном переписывании системы. Корни этих желаний — неумении проводить рефакторинг и непонимание, как разрабатывать исходя из текущих требованих по принципу YAGNI.
Если вы знакомы с реляционными БД, то сначала на таблицах, так очевиднее.
У вас есть пока небольшая бухгалтерская программа. И есть одна из таблиц — Orders (заказы). Колонки, помимо денег, хранят атрибуты заказчика — имя, телефон. Вы это так писали, такие были на данный момент требования. Внезапно обнаруживаете, что связки имен и телефонов повторяются. Что надо делать? Выносить в отдельную таблицу.
Точно так же в ООП. У вас на текущий момент класс Order, у которого есть поля — имя и телефон. Выделить абстракцию? Не вопрос. Создаете класс OrderingCustomer. Туда выносите атрибуты — имя и телефон. Здесь, побольше возможностей, поэтому и смотрите, этот класс выносить за пределы класса или внутри класса оставить. Смотрите на текущие требования и выбираете наиболее ограниченный вариант. Проблемы?
Второй пример. У вас уже есть таблица OrderingCustomers. Кроме того в процессе разработки при постепенном поступлении требований появилась таблица Employers. И вы видите, что часть колонок пересекается. Имя и телефон. Пора выделить новую сущность — Persons. Вынести эти колонки туда и в таблицах OrderingCustomer и Employers установить ключи. Это простая по сути операция поиска общего и частностей. Частности в исходных таблицах, общее в новой.
В ООП. Ровно точно так же. Только еще и поведение выделяете, общее и частное. Уже появляются абстракции. Проблемы?
Вдруг вам понадобилось обрабатывать одинаково эти разные объекты. Создаете фабрику, тогда вас перестает волновать, что за объекты. Еще больше понадобилось абстрагирование — создаете интерфейсы, наследуете объекты.
Нет никаких проблем создавать абстракции исходя из нужд «здесь и сейчас». И нет никаких проблем делать это постепенно и менять по мере надобности.
Заметьте, я примеры дал, почти механические. Вы, теоретически, могли бы сразу увидеть, что имя и телефон относятся к человеку и смоделировать и это. Но а если это не потребуется? Может вы хотите вообще вселенную смоделировать включая атомы? Это не возможно, т.к. объективной истины нет, а модели субъективны )))
Заказчик, который дает требования к проекту, мог повернуть не в ту сторону, куда вы предугадываете и с объектами вышла бы незадача. Архитектура в конце концов при постоянном предугадывании становится деревянной, не позволяющей вносить дальнейшие изменения. А потом, появляются мысли и желания о полном переписывании системы. Корни этих желаний — неумении проводить рефакторинг и непонимание, как разрабатывать исходя из текущих требованих по принципу YAGNI.
А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные? Ошибка проектирования, а точнее его отсуствия.
Я уже сказал весь вопрос в количестве итераций. Проектирование позволяет их уменьшить.
В качестве примера могу привести пример разработки бухгалтерского пакета (про частные изменения законодательства в этой сфере я надеюсь вы в курсе.) Так вот. Проект уже 7 месяцев ТОЛЬКО расширяется. При этом требовалось ввести новую форму бухгалтерского учета! (помимо УСН добавить ОСНО) и новый функционал успешно был внедрен без переписывания всего и вся и без рефакторинга, просто еще одна система встала рядом. А по сути система позволяет работать одной компании сразу под несколькими юридическими лицами и для каждого можно указать форму бух учета. Более того я могу точно сказать что переписываться кардинально он не будет никогда. Расширятся изменятся, какие то части будут становится устаревшими, но так что «Аааа тут у нас говнокод поэтому надо переписать» не будет никогда.
Я когда набираю программистов мне по сути не важно знает человек ЯП или нет. Главное чтобы он владел абстрактным мышлением. Это можеть быть студент краснодипломник с опытом или пацан после школы без опыта вообще. Но эффективности их работы в целом критично отличатся не будет.
Часто на собеседованиях задаю простой вопрос: Какие уровни абстракции вы видите в web-приложении. На что мне люди начинают с умным видом (с опытом разработки от 5+ лет) что то нести про MVC, про что угодно но только не о том что есть страницы есть лейауты, есть сам по себе в конце концев Запрос на сервер и Ответ с него же. Люди пользуют Yii/CodeInteger/Symphony где все это реализовано. Самый кошмар начинается что когда они рассуждают о приложении они абстрагируются от взятого фреймворка и начинают рисовать ТОЛЬКО модели которые сами создали. Остальное для них архитектурой проекта не является.
Я уже сказал весь вопрос в количестве итераций. Проектирование позволяет их уменьшить.
В качестве примера могу привести пример разработки бухгалтерского пакета (про частные изменения законодательства в этой сфере я надеюсь вы в курсе.) Так вот. Проект уже 7 месяцев ТОЛЬКО расширяется. При этом требовалось ввести новую форму бухгалтерского учета! (помимо УСН добавить ОСНО) и новый функционал успешно был внедрен без переписывания всего и вся и без рефакторинга, просто еще одна система встала рядом. А по сути система позволяет работать одной компании сразу под несколькими юридическими лицами и для каждого можно указать форму бух учета. Более того я могу точно сказать что переписываться кардинально он не будет никогда. Расширятся изменятся, какие то части будут становится устаревшими, но так что «Аааа тут у нас говнокод поэтому надо переписать» не будет никогда.
Я когда набираю программистов мне по сути не важно знает человек ЯП или нет. Главное чтобы он владел абстрактным мышлением. Это можеть быть студент краснодипломник с опытом или пацан после школы без опыта вообще. Но эффективности их работы в целом критично отличатся не будет.
Часто на собеседованиях задаю простой вопрос: Какие уровни абстракции вы видите в web-приложении. На что мне люди начинают с умным видом (с опытом разработки от 5+ лет) что то нести про MVC, про что угодно но только не о том что есть страницы есть лейауты, есть сам по себе в конце концев Запрос на сервер и Ответ с него же. Люди пользуют Yii/CodeInteger/Symphony где все это реализовано. Самый кошмар начинается что когда они рассуждают о приложении они абстрагируются от взятого фреймворка и начинают рисовать ТОЛЬКО модели которые сами создали. Остальное для них архитектурой проекта не является.
Проектировать или нет, зависит от способа разработки и архитектуры проекта. Первое, что мы сделали, это разработали API передачи данных с клиента на сервер, и наоборот. К этому добавили особый способ организации кода, и получили простой как двери фреймворк. Его то и фреймворком язык не особо поворачивается назвать. После этого любое проектирование сводится к созданию практически полнофункционального прототипа, и дальнейшему его оживлению. Это очень легко итерируется. Мало того, мы заменили проектирование такой абстракцией как «карта проблем», это примерные требования к разрабатываемой функциональности. Такой себе вектор движения в разработке. Это работает еще и потому, что архитектура слабосвязанная.
Как раз в здравом уме так и делают — исходят из требований. Я показал механику на этом примере. Программист, создавая объекты, таблицы или колонки всегда сам себе задает вопрос:
— Ровно на этот момент что необходимо и достаточно?
Пример вымышленный, возможно, не делают прямо таких мелких шагов, как здесь. Но суть приблизительно такая.
Таблицы БД я привел для примера, потому что они более строгие, чем ООП, но вместе с тем похожи на объекты ООП. На таблицах очевиднее, как разделять общее и частности. В ООП — то же самое — выделение базового класса.
Но с БД немного другая ситуация, если у вас уже внедрен проект, а вы его дописываете, а не разрабатываете с нуля. Могут быть проблемы с данными. Но в общем, если мы говорим об этапе разработки, то такая техника корректна.
Именно так и должно быть, потому что программирование — раздел математики. Это точная наука. Поэтому надо использовать «объективные техники». Т.е. делать как можно меньше предположений, а использовать правила. Информация к нам поступает от заказчика. Поэтому надо опираться только на нее. Если требование не прозвучало, то его не было. А прозвучит, только тогда будем кодить. Кодирование — это требования на языке программирования. И есть различные способы оценки качества кода. Один из них — объем кода. Даже так можно анализировать. Вы выделяете абстракцию (базовые классы) и это сокращает описание. Сокращение описания — это не что иное, как выделение существенной информации. Т.е. знаний.
— Ровно на этот момент что необходимо и достаточно?
Пример вымышленный, возможно, не делают прямо таких мелких шагов, как здесь. Но суть приблизительно такая.
Таблицы БД я привел для примера, потому что они более строгие, чем ООП, но вместе с тем похожи на объекты ООП. На таблицах очевиднее, как разделять общее и частности. В ООП — то же самое — выделение базового класса.
Но с БД немного другая ситуация, если у вас уже внедрен проект, а вы его дописываете, а не разрабатываете с нуля. Могут быть проблемы с данными. Но в общем, если мы говорим об этапе разработки, то такая техника корректна.
Именно так и должно быть, потому что программирование — раздел математики. Это точная наука. Поэтому надо использовать «объективные техники». Т.е. делать как можно меньше предположений, а использовать правила. Информация к нам поступает от заказчика. Поэтому надо опираться только на нее. Если требование не прозвучало, то его не было. А прозвучит, только тогда будем кодить. Кодирование — это требования на языке программирования. И есть различные способы оценки качества кода. Один из них — объем кода. Даже так можно анализировать. Вы выделяете абстракцию (базовые классы) и это сокращает описание. Сокращение описания — это не что иное, как выделение существенной информации. Т.е. знаний.
Да да.
И получается… высоконагруженный проект (10-15к пользователей ежесекундно в пике и по 5-6к пользователей минимум это надеюсь хайлоад? общий объем базы более 200Гб) В нем «исходя из требований заказчика» делают в славном MySQL поле типа ENUM с ТРЕМЯ ролями пользователей. (НУ БОЛЬШЕ ЖЕ СЕЙЧАС НЕ ТРЕБУЕТСЯ ?!). Потом заказчику вдруг по требовалось внедрить еще пару ролей. А теперь начинается финиш. Изменить структуру нельзя. Ибо простой в несколько часов(миграция с версии на версию, переиндексация базы в связи с изменением струкутуры.) будет стоить 200-300 тысяч рублей. Начинается хардкодинг. Проверка «а какая же у нас роль» превращается в развесистый куст. причем так как уже написанное не предполагало что такое может случится, следовательно пишется развесистый куст SQL/проверок у конкретного пользователя. И хрен с ним что на это уйдет месяц. Месяц работы программиста стоит 30 тысяч рублей. Затраты на простой в 10 раз больше. О качестве кода скромно промолчим.
Соболезную вашим заказчикам, если вы считаете подобный подход за здравый ум.
Кстати у меня были такие конкуренты. Почитают ТЗ скажут «на данном этапе надо только вот это поэтому мы сделаем это за 150 тысяч рублей! за 2 месяца». Мы со своей группой разработки настаивали что это будет стоить 600 тысяч (цифры не с потолка) и длительность разработки будет 5 месяцев. Прошел год, заказчик звонит нам. Ругается. Извиняется.
С него вытащили порядка 1.2 млн рублей, при этом поставленная задача была не выполнена и на 50%. А ему мозг весь проели фразой «Ну вы же хотели получить первую версию за 2 месяца, поэтому писали строго исходя из того что надо было в первую очередь (около 10% от всего что надо)».
Ребята может и заработали, но я называю такой подход обманом и мошенничеством.
И получается… высоконагруженный проект (10-15к пользователей ежесекундно в пике и по 5-6к пользователей минимум это надеюсь хайлоад? общий объем базы более 200Гб) В нем «исходя из требований заказчика» делают в славном MySQL поле типа ENUM с ТРЕМЯ ролями пользователей. (НУ БОЛЬШЕ ЖЕ СЕЙЧАС НЕ ТРЕБУЕТСЯ ?!). Потом заказчику вдруг по требовалось внедрить еще пару ролей. А теперь начинается финиш. Изменить структуру нельзя. Ибо простой в несколько часов(миграция с версии на версию, переиндексация базы в связи с изменением струкутуры.) будет стоить 200-300 тысяч рублей. Начинается хардкодинг. Проверка «а какая же у нас роль» превращается в развесистый куст. причем так как уже написанное не предполагало что такое может случится, следовательно пишется развесистый куст SQL/проверок у конкретного пользователя. И хрен с ним что на это уйдет месяц. Месяц работы программиста стоит 30 тысяч рублей. Затраты на простой в 10 раз больше. О качестве кода скромно промолчим.
Соболезную вашим заказчикам, если вы считаете подобный подход за здравый ум.
Кстати у меня были такие конкуренты. Почитают ТЗ скажут «на данном этапе надо только вот это поэтому мы сделаем это за 150 тысяч рублей! за 2 месяца». Мы со своей группой разработки настаивали что это будет стоить 600 тысяч (цифры не с потолка) и длительность разработки будет 5 месяцев. Прошел год, заказчик звонит нам. Ругается. Извиняется.
С него вытащили порядка 1.2 млн рублей, при этом поставленная задача была не выполнена и на 50%. А ему мозг весь проели фразой «Ну вы же хотели получить первую версию за 2 месяца, поэтому писали строго исходя из того что надо было в первую очередь (около 10% от всего что надо)».
Ребята может и заработали, но я называю такой подход обманом и мошенничеством.
Потом заказчику вдруг по требовалось внедрить еще пару ролей.
А если не ролей, а чего-то такого, что и предположить изначально было нельзя. Такое бывает сплошь и рядом, «никогда не знаешь, что придет в голову этим пчелам (с)». Все и сразу, особенно в сложных проектах, предусмотреть невозможно в принципе. Да конечно нужно попробовать предусмотреть максимально, если того позволяют обстоятельства, а они позволяют далеко не всегда. Хорошо, что в приведенном Вами примере заказчик к вам вернулся, а ведь «те» могли бы запросто с него еще пару миллионов вытянуть и на костылях проект выкатить, такое тоже довольно нередко.
Запроектировать все нельзя, но запроектировать так чтобы потом не переписывать все с нуля вполне возможно. Понятно что могут изменятся требования. Может изменяться много что. Но если для внедрения новых изменений требуется переписать всю систему… это клиника. Если система не может гибко изменятся — это косяк исключительно этапа проектирования. Которого типа и не надо.
Вы еще предложите от ТЗ отказаться.
Вы еще предложите от ТЗ отказаться.
косяк исключительно этапа проектирования. Которого типа и не надо
Насколько я понял автора, он не предлагает в принципе отказаться от проектирования. Он говорит о том (насколько я понял), что раз во многих случаях нельзя запроектировать все и сразу, то по сему в этих ситуациях более целесообразно использовать проектирование не предварительное, а эволюционное.
>Но если для внедрения новых изменений требуется переписать всю систему… это клиника.
Требовался сайт-визитка, постепенно пришедшая к ERM системе. Вы действительно считаете, что при заказе на визитку нужно проектировать сразу ERM-систему?
Ну и плюс речь больше, по-моему, о ситуациях когда заказчик не знает, что ему понадобится через два месяца и понадобится ли вообще, чем когда он знает планы на несколько лет, но на первом этапе хочет 10% от возможностей предполагаемой системы. Тут да, для реализации первых 10% нужно сразу учитывать остальные 90. Но не стоит предугадывать за заказчика что его 100% превратятся в 10% и проектировать систему исходя из своих предположений каковы будут 90%. Слишком велика вероятность ошибиться и предусмотреть расширяемость там, где она не потребуется, а там где потребуется не предусмотреть.
Требовался сайт-визитка, постепенно пришедшая к ERM системе. Вы действительно считаете, что при заказе на визитку нужно проектировать сразу ERM-систему?
Ну и плюс речь больше, по-моему, о ситуациях когда заказчик не знает, что ему понадобится через два месяца и понадобится ли вообще, чем когда он знает планы на несколько лет, но на первом этапе хочет 10% от возможностей предполагаемой системы. Тут да, для реализации первых 10% нужно сразу учитывать остальные 90. Но не стоит предугадывать за заказчика что его 100% превратятся в 10% и проектировать систему исходя из своих предположений каковы будут 90%. Слишком велика вероятность ошибиться и предусмотреть расширяемость там, где она не потребуется, а там где потребуется не предусмотреть.
Вы спросили как можно эволюционно выделять абстракции — и я вам показал как.
Подход этот очень здравый. Называется YAGNI. В паре с KISS дает хороший эффект. Подход надо попробовать и прочувствовать, тогда поймете, почему таким образом г… нокод не получается. Никаких костылей не будет. Вы, видимо, забываете о рефакторинге. Именно рефакторинг делает из кода то, что нужно. Архитектура будет не идеальной, возможно, но достаточно хорошей и поддающейся изменениям.
Про энам с тремя полями, что-то не понял. Где вы увидели проблему? Есть энам с тремя ролями. Нет никакой сущности, которая описывает роли. Заказчику потребовались новые роли. И что? Заводите таблицу, добавляете роли, сколько хотите. С поля выкашиваете энам, предварительно замапив на новую таблицу. Потом устанавливаете ключ. Работы минут на 15. (тесты также поправить, но всё это не сверхзатратно).
Правда, зачем сразу делали энам — загадка. Это не относится к эволюционному программированию. Достаточно на данный момент — это не значит «не использовать реляционную модель».
По ТДД всё делается маленькими циклами: тест -> кодирование самым простым и очевидным способом, чтобы тест прошел -> рефакторинг, направленный на приведение кода в нормальный вид.
Последний шаг как раз и гарантирует, что не будет г… нокода. То, что нужно на данный момент, не относится к рефакторингу. Рефакторинг — обязательная часть процесса. Нельзя рассуждать так: оно на данный момент работает и этого достаточно, поэтому не будем рефакторить. Достаточность относится ко всему, кроме тестов и рефакторинга — это часть процесса. В какой-то момент и энамы исчезнут.
На счет скорости разработки, могу поспорить. Такой подход по моему мнению значительно ускоряет разработку. Если у вас совсем маленький проект, однодневный, то может быть без тестов напишете быстрее. А в любом достаточно большом проекте через некоторое время после начала более важным критерием становится возможность расширений и изменений, с одновременными проверками — не сломалось ли что-то.
Вот здесь и помогают тесты. А рефакторинг помогает быть «коду в форме» и готовым к любым изменениям. Гибкость — это не всегда гибкость. Если вы что-то предугадываете, закладывая гибкость, то это означает жесткость изменений в других направлениях. Постоянный рефакторинг и соответствие текущим требованиям позволяют быть проекту достаточно гибким в любом направлении.
Подход этот очень здравый. Называется YAGNI. В паре с KISS дает хороший эффект. Подход надо попробовать и прочувствовать, тогда поймете, почему таким образом г… нокод не получается. Никаких костылей не будет. Вы, видимо, забываете о рефакторинге. Именно рефакторинг делает из кода то, что нужно. Архитектура будет не идеальной, возможно, но достаточно хорошей и поддающейся изменениям.
Про энам с тремя полями, что-то не понял. Где вы увидели проблему? Есть энам с тремя ролями. Нет никакой сущности, которая описывает роли. Заказчику потребовались новые роли. И что? Заводите таблицу, добавляете роли, сколько хотите. С поля выкашиваете энам, предварительно замапив на новую таблицу. Потом устанавливаете ключ. Работы минут на 15. (тесты также поправить, но всё это не сверхзатратно).
Правда, зачем сразу делали энам — загадка. Это не относится к эволюционному программированию. Достаточно на данный момент — это не значит «не использовать реляционную модель».
По ТДД всё делается маленькими циклами: тест -> кодирование самым простым и очевидным способом, чтобы тест прошел -> рефакторинг, направленный на приведение кода в нормальный вид.
Последний шаг как раз и гарантирует, что не будет г… нокода. То, что нужно на данный момент, не относится к рефакторингу. Рефакторинг — обязательная часть процесса. Нельзя рассуждать так: оно на данный момент работает и этого достаточно, поэтому не будем рефакторить. Достаточность относится ко всему, кроме тестов и рефакторинга — это часть процесса. В какой-то момент и энамы исчезнут.
На счет скорости разработки, могу поспорить. Такой подход по моему мнению значительно ускоряет разработку. Если у вас совсем маленький проект, однодневный, то может быть без тестов напишете быстрее. А в любом достаточно большом проекте через некоторое время после начала более важным критерием становится возможность расширений и изменений, с одновременными проверками — не сломалось ли что-то.
Вот здесь и помогают тесты. А рефакторинг помогает быть «коду в форме» и готовым к любым изменениям. Гибкость — это не всегда гибкость. Если вы что-то предугадываете, закладывая гибкость, то это означает жесткость изменений в других направлениях. Постоянный рефакторинг и соответствие текущим требованиям позволяют быть проекту достаточно гибким в любом направлении.
Я где то написал что я против TDD? Это хорошо, и правильно.
Нет гибкость это именно гибкость. Как угодно и куда угодно. От широкого к узкому. Понятно что могут возникать вещи и некоторые вещи будут вынесены в более высокие слои абстракции. Но в целом…
Я примеров могу привести массу. Обратных примеров тоже. =) И еще я не спорю. Бывает действительно собирается команда, у меня получилось раз такую собрать. Не было не методологий ни TDD толком, НО! каждый делал только свое и только в своей нише. Скорость разработки была неожиданна для всех. Синергия в чистом виде. Бешенные темпы. Ошибки конечно были, но они вылизывались быстро и эффективно. Больше я такой команды не смог собрать, хотя сейчас и пытаюсь сделать что-то подобное.
Я еще раз говорю то что вы говорите, что это займет 15 минут, это исключительно в ваших фантазиях. В реальности, заняло месяц. Без TDD и без ООП правда писалось все.
Нет гибкость это именно гибкость. Как угодно и куда угодно. От широкого к узкому. Понятно что могут возникать вещи и некоторые вещи будут вынесены в более высокие слои абстракции. Но в целом…
Я примеров могу привести массу. Обратных примеров тоже. =) И еще я не спорю. Бывает действительно собирается команда, у меня получилось раз такую собрать. Не было не методологий ни TDD толком, НО! каждый делал только свое и только в своей нише. Скорость разработки была неожиданна для всех. Синергия в чистом виде. Бешенные темпы. Ошибки конечно были, но они вылизывались быстро и эффективно. Больше я такой команды не смог собрать, хотя сейчас и пытаюсь сделать что-то подобное.
Я еще раз говорю то что вы говорите, что это займет 15 минут, это исключительно в ваших фантазиях. В реальности, заняло месяц. Без TDD и без ООП правда писалось все.
Гибкости куда угодно и как угодно не бывает. Гибкость обычно в каком-то направлении (степени свободы), а в других жесткость.
Кстати, жесткость — это самое важное, намного важнее гибкости. Жесткость — это строгая типизация. Жесткость — это выражение того, что вы хотите и способность программы от этого не отклоняться.
Самое гибкое в разных направлениях — не пользоваться даже типами, а память сырую выделять. «просто объект». Вот это будет очень гибкая вещь.
Но нормально, когда пишут, все таки устанавливают некоторые жесткие ограничения. И иногда закладывают гибкость (иногда лишнюю, см. выше). И предугадывание ведет к проблемам.
Какой-то простой пример. Моделируете предметную область. Объекты: яблоко, груша, арбуз.
По YAGNI: не делаете общего предка. Понадобилось, уточнились требования — сделали. Но еще не знаете, как сделать иерархию, заказчик всё еще молчит. Но и не страшно, потом расширите.
По предугадывание. Закладываете гибкость и пишете базовый «фрукт», «овощь», «еда». Можете потом расширять иерархию, если угадали, добавлять новые фрукты, овощи. Всё для этого готово. Но проблема, если заказчика будет интересовать совсем не это, а: «форма» или «цвет» или даже «полосатость». Что в этом случае делать? Выпиливать старый предугаданный код. Может случиться, что ваша иерархия не только бесполезна, а очень мешает.
1. Вы потратили время на написание кода. Вы могли бы почти такое же время потратить и потом, но вы делали заранее.
2.1 Вы потратили время на выпиливание не нужного кода.
2.2 Вы не потратили время на выпиливание кода, он не вредит, но может «авось» понадобиться. Тогда вы тратите время на поддержку кода (юнит-тесты).
Вообще, юнит-тесты заставляют прилагать усилия и благодаря этому стараться не делать лишнего и не отрываться от Земли.
Кстати, жесткость — это самое важное, намного важнее гибкости. Жесткость — это строгая типизация. Жесткость — это выражение того, что вы хотите и способность программы от этого не отклоняться.
Самое гибкое в разных направлениях — не пользоваться даже типами, а память сырую выделять. «просто объект». Вот это будет очень гибкая вещь.
Но нормально, когда пишут, все таки устанавливают некоторые жесткие ограничения. И иногда закладывают гибкость (иногда лишнюю, см. выше). И предугадывание ведет к проблемам.
Какой-то простой пример. Моделируете предметную область. Объекты: яблоко, груша, арбуз.
По YAGNI: не делаете общего предка. Понадобилось, уточнились требования — сделали. Но еще не знаете, как сделать иерархию, заказчик всё еще молчит. Но и не страшно, потом расширите.
По предугадывание. Закладываете гибкость и пишете базовый «фрукт», «овощь», «еда». Можете потом расширять иерархию, если угадали, добавлять новые фрукты, овощи. Всё для этого готово. Но проблема, если заказчика будет интересовать совсем не это, а: «форма» или «цвет» или даже «полосатость». Что в этом случае делать? Выпиливать старый предугаданный код. Может случиться, что ваша иерархия не только бесполезна, а очень мешает.
1. Вы потратили время на написание кода. Вы могли бы почти такое же время потратить и потом, но вы делали заранее.
2.1 Вы потратили время на выпиливание не нужного кода.
2.2 Вы не потратили время на выпиливание кода, он не вредит, но может «авось» понадобиться. Тогда вы тратите время на поддержку кода (юнит-тесты).
Вообще, юнит-тесты заставляют прилагать усилия и благодаря этому стараться не делать лишнего и не отрываться от Земли.
Про объекты. Либо у вас серьезные проблемы с пониманием наследования и изначального проектирования, либо на этом мысль оканчивается.
Ну тогда и я про ваши проблемы расскажу.
Есть три этапа становления программиста. Может больше, но я пока не знаю новых.
1. Новичок. Учится кодить и кодит хоть как-нибудь и радуется, что программы его вообще работают.
2. Любовь к паттернам и проектированию. Наступает после детального изучения книги банды четырех. Человеку кажется, что если он понял, как и что делает каждый паттерн, что такое наследование, то можно ВСЁ запроектировать.
3. Отказ от паттернов. Переход на эволюционное проектирование. ТДД. Да, я верно говорю — ТДД — это не просто организация процесса. Это эволюционное проектирование. Оно явно и не явно заставляет так проектировать.
Вы пока на втором этапе. Эта статья написана человеком, либо на третьем этапе, либо переходящим на третий. У него появилось откровение, что можно разбираться на ходу с проблемами (поэтому красной таблетки не существует).
Примечательно, что на каждом этапе человек считает себя профессионалом. Новичок, правда, не всегда, если рядом есть примеры хороших программистов. А вот на втором — да. Я не хочу вас оскорблять, мне тоже не удалось пропустить второй этап. Я помню, какие «причудливые» архитектуры создавал. Зато сейчас я эффективнее в разы.
Возможно будет четвертый этап — уход от говноязыков.
Есть три этапа становления программиста. Может больше, но я пока не знаю новых.
1. Новичок. Учится кодить и кодит хоть как-нибудь и радуется, что программы его вообще работают.
2. Любовь к паттернам и проектированию. Наступает после детального изучения книги банды четырех. Человеку кажется, что если он понял, как и что делает каждый паттерн, что такое наследование, то можно ВСЁ запроектировать.
3. Отказ от паттернов. Переход на эволюционное проектирование. ТДД. Да, я верно говорю — ТДД — это не просто организация процесса. Это эволюционное проектирование. Оно явно и не явно заставляет так проектировать.
Вы пока на втором этапе. Эта статья написана человеком, либо на третьем этапе, либо переходящим на третий. У него появилось откровение, что можно разбираться на ходу с проблемами (поэтому красной таблетки не существует).
Примечательно, что на каждом этапе человек считает себя профессионалом. Новичок, правда, не всегда, если рядом есть примеры хороших программистов. А вот на втором — да. Я не хочу вас оскорблять, мне тоже не удалось пропустить второй этап. Я помню, какие «причудливые» архитектуры создавал. Зато сейчас я эффективнее в разы.
Возможно будет четвертый этап — уход от говноязыков.
Что-то мне подсказывает что вы не правы =) Но, пусть каждый останется при своем мнении.
Мне как-то удаётся совмещать 2 и 3. Вроде TDD чистой воды, но после рефакторинга «получаются» паттерны. А зачастую фазой «хоть как бы тест прошёл» вообще пренебрегаешь и сразу «рисуешь» патерн, которому в обозримом будущем рефакторинг не понадобится.
Это следующий этап у меня получился почти автоматически после этапа «на
assert(sum(2,2), 4) пишем return 4»Ну так, да, паттерны сами получаются. Поэтому и говорю про отказ от паттернов. В том плане, что лучше бы о них не думать, потому как они заставляют думать наперед. Другое дело, когда они естественно появляются. Не все, конечно.
Но оказывается, есть ряд паттернов, которые часто используются и часто появляются. При этом архитектура как бы «утрясается». Сначала пишете как-то, потом рефакторингом трясете до положения, когда вам код нравится. Вместе с паттернами. Можно было бы графически нарисовать, как получается на диаграммах Эйлера, сначала смысловое пересечение, как потом в коде два разных класса соединяются через базовый, появляется степень свободы (и жесткость). Как потом отвязываемся от классов через интерфейс. Буквально, во многих случаях можно представлять графически воздействие требования, появление в результате этого необходимости пересмотреть жесткость и гибкость в каких-то измерениях (а программа — это многомерная структура, где мерность — количество независимых переменных).
Такое воображение может быть много кому помогло бы представить, почему возможно в ООП эволюционное проектирование.
Но оказывается, есть ряд паттернов, которые часто используются и часто появляются. При этом архитектура как бы «утрясается». Сначала пишете как-то, потом рефакторингом трясете до положения, когда вам код нравится. Вместе с паттернами. Можно было бы графически нарисовать, как получается на диаграммах Эйлера, сначала смысловое пересечение, как потом в коде два разных класса соединяются через базовый, появляется степень свободы (и жесткость). Как потом отвязываемся от классов через интерфейс. Буквально, во многих случаях можно представлять графически воздействие требования, появление в результате этого необходимости пересмотреть жесткость и гибкость в каких-то измерениях (а программа — это многомерная структура, где мерность — количество независимых переменных).
Такое воображение может быть много кому помогло бы представить, почему возможно в ООП эволюционное проектирование.
m36 исходит из «сильной» точки зрения — "(сможем и будем) сделать когда надо", а вы — и- «слабой» — "(лучше) сделать когда можно". Из «слабой» позиции можно охватить в разы больший scope, но, в общем, с меньшей надёжностью.
А с высоконагруженным проектом надо заранее (ага, «как слабый») продумывать механизм миграции и смены бэк-энда «на грячую».
Вопрос — почему простой в несколько часов стОит как 6-10 месяцев (1200-1700 часов) работы программиста? С этого и начинается — не хотят отдавать 300 тыр за простой — отдают 1200 тыр за всё по итогам…
А с высоконагруженным проектом надо заранее (ага, «как слабый») продумывать механизм миграции и смены бэк-энда «на грячую».
Вопрос — почему простой в несколько часов стОит как 6-10 месяцев (1200-1700 часов) работы программиста? С этого и начинается — не хотят отдавать 300 тыр за простой — отдают 1200 тыр за всё по итогам…
Потому что владельцы боятся что такой простой отпугнет пользователей и это снизит приход денег. А там доходность проекта более 1,5 млн $ в месяц. Типа лучше незаметно для пользователей накидать говно-код чтобы это не заметили, и потратить денег на это, но по итогу срубить больше (исключительно по их мнению)
Я говорю что проектировать надо всегда. Где я написал про «лучше когда можно»? Вот никогда не поверю что даже самая простая система может быть написана без предварительного проектирования. Оно в любом случае есть хоть эволюционное хоть какое. Предварительное позволяет в целом снизить стоимость дальнейшей разработки. Тут я более чем полностью согласен с дядькой написавшей книжку Совершенный код.
Разработка через тестирование это лишь организация разработки в целом. А не разработка архитектуры проекта. Это все таки разные вещи.
Я говорю что проектировать надо всегда. Где я написал про «лучше когда можно»? Вот никогда не поверю что даже самая простая система может быть написана без предварительного проектирования. Оно в любом случае есть хоть эволюционное хоть какое. Предварительное позволяет в целом снизить стоимость дальнейшей разработки. Тут я более чем полностью согласен с дядькой написавшей книжку Совершенный код.
Разработка через тестирование это лишь организация разработки в целом. А не разработка архитектуры проекта. Это все таки разные вещи.
«Лучше когда можно» — это «на стадии проектирования», до того, как реально будет нужно.
Насчёт «Code complete» — ну, С++ уже само по себе отпугивает и smells bad. Для Java это — прошлая эпоха. Если книгу про то, что водопад лучше аджиля, написал С++-ник, то это следует отнести на профессиональную деформацию восприятия: для С++ это в значительной степени так, в то время, как для Java есть автоматический рефакторинг средствами IDE и дизайн можно улучшить уже после написания кода (это возможно за счёт отсутствия у языка Java, по сравнению с С++, излишней «гибкости» в нехорошую сторону). Мартин Фаулер теперь пишет, что улучшения дизайна можно безопасно оставлять на потом.
Насчёт «Code complete» — ну, С++ уже само по себе отпугивает и smells bad. Для Java это — прошлая эпоха. Если книгу про то, что водопад лучше аджиля, написал С++-ник, то это следует отнести на профессиональную деформацию восприятия: для С++ это в значительной степени так, в то время, как для Java есть автоматический рефакторинг средствами IDE и дизайн можно улучшить уже после написания кода (это возможно за счёт отсутствия у языка Java, по сравнению с С++, излишней «гибкости» в нехорошую сторону). Мартин Фаулер теперь пишет, что улучшения дизайна можно безопасно оставлять на потом.
А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные?У Заказа могут быть просто поля с контактной информацией закзачика.
Можно сделать и просто. Потом будет не просто =)
Веселуха будет когда пользователи начнут удалять и редактировать свои профили… тогда окажется, что нормализация — это не всегда хорошо…
Нормализация как раз позволяет вполне безболезненно вносить любые изменения в архитектуру. Может мы немного по-разному понимаем этот термин?
Ну, есть шанс, что это, если разрешить, повлечёт изменение в уже сделанных ими заказах или вообще удаление их…
Ну, можно сделать версионирование — тогда данные о пользователе в заказе останутся на момент внесения или исполнения заказа…
Ну, можно сделать версионирование — тогда данные о пользователе в заказе останутся на момент внесения или исполнения заказа…
Смотря что и КАК нормализировать =) вообще уникальные профили для пользователей не проблема. у меня есть проект с 8 ролями, хотя изначально предполагалась одна, все расширилось отлично. Наверное я что то не знаю и делаю не правильно =(
А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные?
Бизнес. Сам заказчик или аналитик. Если я, как непосредственный разработчик, получаю на входе нечто вроде: «Есть сущность „Заказ“, у которого есть реквизиты „Номер“, „Дата“, „ФИО“, „Адрес“, „Телефон“, „Описание“ и „Сумма“», да ещё после уточнения получаю информацию о том, что персональные данные практически не дублируются, а если и дублируются, то информация об этом заказчику неинтересна, то какие у меня основания выделять «ФИО», «Адрес», «Телефон» в отдельную сущность, если в бизнес-процессах она как отдельная сущность не фигурирует, а фигурируют её реквизиты как реквизиты другой сущности? Введение отдельного типа сущностей усложнит архитектуру, а то и пользовательский интерфейс, и увеличит ресурсоемкость без каких-либо профитов для бизнеса. Типичный оверинженеринг. А не вводя такую сущность мы получим простое как три копейки приложение, понятное любому студенту. Изменятся бизнес-требования, например, заказчику нужны будут отчёты не только по датам, но и по «ФИО», «Адрес», «Телефон» как единой сущности, то есть в его бизнес-процессах появится сущность «покупатель и его контактные данные», тогда и введём, заодно уточнив как покупателя идентифицировать. А пока у него «покупатель» как отдельная сущность в процессах не фигурирует, то он просто вопроса не поймёт и мы будем вынуждены принимать решение (или вынудим заказчика принять непонятно зачем) исходя из своего видения, которое вполне может оказаться ошибочным в будущем. И нам придётся систему не доделывать, а переделывать.
Бизнес. Сам заказчик или аналитик. Если я, как непосредственный разработчик, получаю на входе нечто вроде: «Есть сущность „Заказ“, у которого есть реквизиты „Номер“, „Дата“, „ФИО“, „Адрес“, „Телефон“, „Описание“ и „Сумма“», да ещё после уточнения получаю информацию о том, что персональные данные практически не дублируются, а если и дублируются, то информация об этом заказчику неинтересна, то какие у меня основания выделять «ФИО», «Адрес», «Телефон» в отдельную сущность, если в бизнес-процессах она как отдельная сущность не фигурирует, а фигурируют её реквизиты как реквизиты другой сущности? Введение отдельного типа сущностей усложнит архитектуру, а то и пользовательский интерфейс, и увеличит ресурсоемкость без каких-либо профитов для бизнеса. Типичный оверинженеринг. А не вводя такую сущность мы получим простое как три копейки приложение, понятное любому студенту. Изменятся бизнес-требования, например, заказчику нужны будут отчёты не только по датам, но и по «ФИО», «Адрес», «Телефон» как единой сущности, то есть в его бизнес-процессах появится сущность «покупатель и его контактные данные», тогда и введём, заодно уточнив как покупателя идентифицировать. А пока у него «покупатель» как отдельная сущность в процессах не фигурирует, то он просто вопроса не поймёт и мы будем вынуждены принимать решение (или вынудим заказчика принять непонятно зачем) исходя из своего видения, которое вполне может оказаться ошибочным в будущем. И нам придётся систему не доделывать, а переделывать.
>Часто на собеседованиях задаю простой вопрос: Какие уровни абстракции вы видите в web-приложении.
На такой вопрос задаю встречный: «Что считаем веб-приложением и с какого уровня начинать?» :)
На такой вопрос задаю встречный: «Что считаем веб-приложением и с какого уровня начинать?» :)
Читал, что, для нормальности аналогии, строительство дома — это запуск программы, а программа — проект…
А чем вам UnitTest не работа с живыми данными?
Вы досконально знаете историю написания jQuery? Уверены, что там не было итераций говнокод-рефакториг?
Я читал только что-то вроде «зачем нужно проектирование, когда есть рефакторинг»…
«Мозги у людей отличаются в разы». Сильная фраза
Хорошая статья)
Мне тоже надоели бесконечные Scrum-митинги и презентации, я не очень-то люблю UML-диаграммы (хотя вполне хорошо их знаю), уже раздражают вопросы на тестировании типа «чем фасад отличается от адаптера, а фабрика от абстрактной фабрики» — т.к. умение найти красивое архитектурное решение считаю важнее, чем помнить его «официальное название». Все так. Но! Что в статье не отражено, так это обратная сторона.
Напишите сложный алгоритм без того, чтобы порисовать на бумажке? Придумайте сложную архитектуру, не набрасывая диаграммы классов? Начните разработку без планирования, баг-треккера (подразумевающего некоторый жизненный цикл тикетов по статусам и т.д.), без определения приоритетов (в сумме это и есть «методология») — то есть просто «пишите код», — что будет в итоге, особенно если проект крупный?
Золотая середина, без отклонения в крайности. Вот о чем речь. То, чему учил Будда почти 2 тысячелетия назад, правда в применении ко всей нашей жизни. Жизнь с тех пор изменилась, в ней появилась такая сфера, как IT. Удивительно, но чтобы понять, что эта мудрость применима и в IT-индустрии, индустрии потребовалось много лет. Сколько же длилась эта болезнь «вирусом» Rup, Scrum, UML-фанатизмом, GoF-религией. В разуме разработчиков, кажется, начался иммунный ответ к этим болезненным перекосам, но у менеджеров пока нет.
Мне тоже надоели бесконечные Scrum-митинги и презентации, я не очень-то люблю UML-диаграммы (хотя вполне хорошо их знаю), уже раздражают вопросы на тестировании типа «чем фасад отличается от адаптера, а фабрика от абстрактной фабрики» — т.к. умение найти красивое архитектурное решение считаю важнее, чем помнить его «официальное название». Все так. Но! Что в статье не отражено, так это обратная сторона.
Напишите сложный алгоритм без того, чтобы порисовать на бумажке? Придумайте сложную архитектуру, не набрасывая диаграммы классов? Начните разработку без планирования, баг-треккера (подразумевающего некоторый жизненный цикл тикетов по статусам и т.д.), без определения приоритетов (в сумме это и есть «методология») — то есть просто «пишите код», — что будет в итоге, особенно если проект крупный?
Золотая середина, без отклонения в крайности. Вот о чем речь. То, чему учил Будда почти 2 тысячелетия назад, правда в применении ко всей нашей жизни. Жизнь с тех пор изменилась, в ней появилась такая сфера, как IT. Удивительно, но чтобы понять, что эта мудрость применима и в IT-индустрии, индустрии потребовалось много лет. Сколько же длилась эта болезнь «вирусом» Rup, Scrum, UML-фанатизмом, GoF-религией. В разуме разработчиков, кажется, начался иммунный ответ к этим болезненным перекосам, но у менеджеров пока нет.
Что такое «русский скрам, бессмысленный и беспощадный», я на своей шкуре испытал три года назад…
я могу сказать одно.
вот есть такая компания, переназвав ее «ВасяИПартнерс.биз», я по приколу получил у них регистрацию. там опоздание на каждую минуту карается долларом, а каждую минуту вы должны выкладывать скрин к ним на сервер.
работа по удаленке.
у меня программисты работают по разному графику — можно и в 9 начать, и в 12. и нет проблем, чтобы кто-то остался и добил. я доверяю людям, но если спалил на халтурах — пощады не будет :)
если бы выбирал сам (как говорил Тиньков, смотри глазами клиента), то пошел бы к себе работать, где можно и прийти позже, и нет контроля за каждой минутой (все хотят часик посидеть на хабре, чего греха таить).
нужно дать людям ТВОРИТЬ. ведь программист — творческая работа. не терпит муштры, если человек умный. ИМХО разумеется.
вот есть такая компания, переназвав ее «ВасяИПартнерс.биз», я по приколу получил у них регистрацию. там опоздание на каждую минуту карается долларом, а каждую минуту вы должны выкладывать скрин к ним на сервер.
работа по удаленке.
у меня программисты работают по разному графику — можно и в 9 начать, и в 12. и нет проблем, чтобы кто-то остался и добил. я доверяю людям, но если спалил на халтурах — пощады не будет :)
если бы выбирал сам (как говорил Тиньков, смотри глазами клиента), то пошел бы к себе работать, где можно и прийти позже, и нет контроля за каждой минутой (все хотят часик посидеть на хабре, чего греха таить).
нужно дать людям ТВОРИТЬ. ведь программист — творческая работа. не терпит муштры, если человек умный. ИМХО разумеется.
Вчера здесь был пост «Иллюзия эффективной разработки: проектирование» на ту же тему.
Я полностью согласен, что люди и их профессионализм и эффективность играют ключевую роль в успехе.
Но кто-нибудь скажет мне, как таких определить?
К нам на собеседования приходит много людей, как определить, кто из них будет в десять раз эффективней, а кто нет?
Не задавать же им вопрос: Почему канализационные люки круглые?
Тесты, из серии Oracle/Sun/MS Certified, не всегда показывают эффективность, к тому же люди могут даже не знать тех технологий, которые мы используем, но все равно быть эффективными, и достойными быть нанятыми.
Я полностью согласен, что люди и их профессионализм и эффективность играют ключевую роль в успехе.
Но кто-нибудь скажет мне, как таких определить?
К нам на собеседования приходит много людей, как определить, кто из них будет в десять раз эффективней, а кто нет?
Не задавать же им вопрос: Почему канализационные люки круглые?
Тесты, из серии Oracle/Sun/MS Certified, не всегда показывают эффективность, к тому же люди могут даже не знать тех технологий, которые мы используем, но все равно быть эффективными, и достойными быть нанятыми.
Но кто-нибудь скажет мне, как таких определить?
Никак. Ну либо надо быть гением, чтобы суметь с первого раза разглядеть человека. Только в процессе работы можно выяснить кто чего стоит. И это действительно большая проблема.
Все-таки какая-то методика оценки должна быть, может быть люди, которые проводят большое количество интервью ей поделятся?
> Только в процессе работы можно выяснить кто чего стоит.
Ну вот вам и ответ! Самые «приятные» во всех отношениях организации, где я работал и работаю, при приеме на работу ограничивались самым элементарным собеседованием, а дальше испытательный срок. А вот из тех где было: покажите нам свое портфолио и расскажите о вашей роли на каждом сделаном проекте + несколько интервью разного уровня + тестовое задание на 1-2 дня и прочая херня, я очень быстро уходил т.к. при подобном подходе к набору персонала коллектив там как правило состоит из скажем так «не самых лучших» работников.
Ну вот вам и ответ! Самые «приятные» во всех отношениях организации, где я работал и работаю, при приеме на работу ограничивались самым элементарным собеседованием, а дальше испытательный срок. А вот из тех где было: покажите нам свое портфолио и расскажите о вашей роли на каждом сделаном проекте + несколько интервью разного уровня + тестовое задание на 1-2 дня и прочая херня, я очень быстро уходил т.к. при подобном подходе к набору персонала коллектив там как правило состоит из скажем так «не самых лучших» работников.
Google, Microsoft, Яндекс…
Там сейчас именно такой подход к подбору персонала, т.к. они выросли до размеров мегакорпораций и им надо очень много стандартных «винтиков» в отлаженный механизм, с их бюджетами и маркетингом это вполне оправдано. Хотя мне было бы скучно изо дня в день заниматься однообразной рутиной пусть даже в такой «громкой» конторе — зарплаты у «винтиков» там не намного больше чем в более «компактных» командах на более интересных проектах, чтобы компенсировать такую скуку.
Почему канализационные люки круглые?И как обычно на него отвечают?
Когда мне его первый раз задали, я ответил так: «потому что в круглую дырку влезет чувак примерно таких же размеров, что и в квадратную, а металла уходит на круглую дырку меньше». Задавая вопрос мне сказали, что так делают с каких-то очень давних веков, вот я и подумал, что тогда в древности у них металл был в дефиците, и они таким образом его экономили.
Потом (уже после интервью) я понял, каким бредом была моя идея, а так же то, что ответ на этот вопрос, ничего не говорит о профессионализме или эффективности программиста, поэтому сам такие не задаю, и как на него обычно отвечают не знаю.
Поэтому меня интересует, что надо спрашивать и на что обращать внимание в ответах? У меня конечно, есть любимые вопросы, но я отнюдь не уверен, что это оптимальный набор, позволяющий «раскрыть» весь потенциал кандидата.
Потом (уже после интервью) я понял, каким бредом была моя идея, а так же то, что ответ на этот вопрос, ничего не говорит о профессионализме или эффективности программиста, поэтому сам такие не задаю, и как на него обычно отвечают не знаю.
Поэтому меня интересует, что надо спрашивать и на что обращать внимание в ответах? У меня конечно, есть любимые вопросы, но я отнюдь не уверен, что это оптимальный набор, позволяющий «раскрыть» весь потенциал кандидата.
Вы написали «К нам на собеседования приходит много людей», из чего я заключил, что вы часто их проводитете и там нередко задаёте такой вопрос, вот и поинтересовался. Хотя мой ответ — «чтоб крышка не проваливалась», ваш тоже мне кажется интересным. Интереснее всего будет, если на самом деле прав вы, а непроваливающаяся крышка пошла сама собой как бесплатный бонус…
А я люблю задавать такие вопросы. Не как определяющий судьбу кандидата, разумеется, но с единственной целью: посмотреть, как человек возьмется за нестандартную задачу. Если скажет хоть что-то (сиречь, начнет думать) — ок, пойдем дальше.
Если нет — обычно это означает, что несмотря на тысячу прочитанных умных книг, первая же практическая задача поставит его в тупик.
Вопрос про люки хорош тем, что на него не существует «правильного ответа». Как и подавляющее число задач из повседневной жизни.
Если нет — обычно это означает, что несмотря на тысячу прочитанных умных книг, первая же практическая задача поставит его в тупик.
Вопрос про люки хорош тем, что на него не существует «правильного ответа». Как и подавляющее число задач из повседневной жизни.
да, этот пост меня вдохновил.
спасибо его автору :)
определить — думаю, только на испытательном. в бою.
иначе никак
спасибо его автору :)
определить — думаю, только на испытательном. в бою.
иначе никак
Странно, что еще никто не вспомнил 37signals с их книгами «Getting real» и «Rework». Оттуда много почерпнул для себя хорошего и умного. Некоторые идеи автора пересекаются с их размышлениями.
Вдохновенные люди — это, конечно, отлично, но и их нужно организовать, чтобы не было проблемы «лебедя, рака и щуки».
А в посте говорится, что не надо. Печалько.
А в посте говорится, что не надо. Печалько.
Один великолепный программист стоит десятырех раздолбаев или средненьких
Ну, не совсем уж и так. Правильно даже иметь одного продвинутого и несколько средненьких
РЕСПЕКТ!
сразу видно что практик, а не теоретик!
сразу видно что практик, а не теоретик!
Офигенно. Хочу работать в такой команде. Уже в мире ИТ 9 лет и всегда считал, что это трата времени. Многие мои знакомые программисты, у которых проекты по 10 лет, в результате все равно получается костыли и вся архитектура ООП разваливается. Не получается и даже после переписывания с 0, все равно с появлением новых требований появятся костыли. Поэтому: МЫ ПИШЕМ КОД!
ООП разваливается если он изначально спроектирован криво. Основная проблема людей что в ООП люди видят волшебную таблетку, при этом проектировать абсолютно забывают/не умеют/не способны/не хотят.
История из жизни:
АП — Архитектор проекта. Я — соотвецвенно Я.
АП: Зачем нам писать свои костыли ?! Нам надо быстрее! Мы возьмем Симфони.
Я: Ээээ ?! А почему именно Симфони ?!
АП: Я видел ролик где люди соревновались в написании хеллоу-вордов. На Симфони это сделали быстрее всего.
Я: WTF ?!?!?!
Итог… Проект до сих пор трудно и тяжело «рефакторится», так как внезапно АП понял что ORM в проекте был совершенно не нужен и привел к адскому усложнению проекта в целом.
Виноват ли в этом Симфони? вряд ли. А вот к квалификации таких архитекторов у меня много вопросов.
История из жизни:
АП — Архитектор проекта. Я — соотвецвенно Я.
АП: Зачем нам писать свои костыли ?! Нам надо быстрее! Мы возьмем Симфони.
Я: Ээээ ?! А почему именно Симфони ?!
АП: Я видел ролик где люди соревновались в написании хеллоу-вордов. На Симфони это сделали быстрее всего.
Я: WTF ?!?!?!
Итог… Проект до сих пор трудно и тяжело «рефакторится», так как внезапно АП понял что ORM в проекте был совершенно не нужен и привел к адскому усложнению проекта в целом.
Виноват ли в этом Симфони? вряд ли. А вот к квалификации таких архитекторов у меня много вопросов.
По уму, к чужим фреймворкам всё равно постепенно дописываются свои прокладки…
Я не знаю проекта без костылей. За жизнь проекта, ситуация меняется, появляются новые требования, которые уже не вяжутся с архитектурой. Что касается фреймворков, ORM, ООП, для каждой задачи нужно свое решение. Если проект можно разработать без фреймворка, то лучше без него. Если стоит задача, чтоб проект быстро работал, то лучше писать с 0.
Что касается вашей истории, вы должны были попробовать переубедить архитектора, что вы будите делать в будущем.
Что касается вашей истории, вы должны были попробовать переубедить архитектора, что вы будите делать в будущем.
ORM — опциональный элемент symfony. Хотя возможно стоило взять не Symfony Framework, а только необходимые Symfony Components.
Бля, не бывает правильного проектирования.
Вы в самом начале не знаете условий бизнес-среды. Вы обманываете себя, что знаете. Обманутые сами собой, проектируете пуйню.
А потом на деле там оказывается какая-нибудь фамилия 300 символов, и нужно менять поле в БД. Данных оказывается много с дублями, и нужна подсистема поиска дублей. и Так далее.
Поэтому только так. Живые данные, быстрые прототипы, без всяких понтов. Обкатать, понять бизнес-логику, предметную область. Утрясти функционал заказчика. Ибо круче живых прототипов ничего нет, сраные axure-generated Htmlки отдыхают, и тем более скетчи-картинки.
И потом уже спроектировать сущности, отношения, уровни абстракции, необходимые компоненты низкоуровневого слоя и тд.
Вы в самом начале не знаете условий бизнес-среды. Вы обманываете себя, что знаете. Обманутые сами собой, проектируете пуйню.
А потом на деле там оказывается какая-нибудь фамилия 300 символов, и нужно менять поле в БД. Данных оказывается много с дублями, и нужна подсистема поиска дублей. и Так далее.
Поэтому только так. Живые данные, быстрые прототипы, без всяких понтов. Обкатать, понять бизнес-логику, предметную область. Утрясти функционал заказчика. Ибо круче живых прототипов ничего нет, сраные axure-generated Htmlки отдыхают, и тем более скетчи-картинки.
И потом уже спроектировать сущности, отношения, уровни абстракции, необходимые компоненты низкоуровневого слоя и тд.
Да черта с два. Все отлично проектируется, если проектирующие люди не понимают что они делают, то это проблема проектировщиков. А не метода проектирования. Понятно что на живых данных может оказатся что вместо того чтобы готовить CSV файл народ скажет «Зачем когда у нас есть YML» и ты пойдешь делать под YML. Хотя часть сделает. Но в целом дохрена чего проектируется на раз.
welcome!
Только одна ссылка: No Silver Bullet.
Подписываюсь под каждым словом. Когда команда отбрасывает всю эту не нужную шелуху из костылей, обеспечена отличной внутренней мотивацией её эффективность повышается в десятки раз. Очень здорово, что вы об этом написали. Так как тема эта из области теологии. Многие до сих пор верят в волшебные методики.
Один великолепный программист стоит десятырех раздолбаев или средненькихЗато организация процесса в расчёте на десятерых раздолбаев или средненьких в сто раз надёжнее, чем в расчёте на одного великолепного.
Согласен. Этот гений потом уйдет «fellow» в какой-нибудь гугол, а обычным разработчикам нужно будет дальше развивать его код. И, несмотря на то, что сверхвысококвалифицированные программисты пишут очень простой, логичный, легко читаемый и поддерживаемый код — за этй внешней простотой всегда скрыт айсберг теории — которую гений знает, а средний программист по больнице — нет. Они смогут его код читать и патчить — но при попытке что-то в нем поменять это будет война миров, хаос и разрушение.
Здесь я буду краток. Мы попробовали фиксированные итерации, пробуем канбан. Так как я программист, помимо PM — могу подтвердить, что все методологии действительно сводятся к пиши-код-блять.рф.
Сколько лет опыта руководства разработкой с полной ответственностью за проекты, если не секрет? У меня в принципе немного — я чуть больше десяти лет занимался непосредственно разработкой (десктоп, с++, сеть, процессы) и сейчас шестой год руковожу (десктоп, айфоны, андроиды, вся инфраструктура). Успешных проектов пока меньше десяти :(. Но не могу сказать, что методология прямо так и не нужна. В идеальном мире, где можной выйти на улицу и нанять кучку профильных гениев — может быть. Но в суройвой объективной реальности, гле вакансии на iPhone разработчика на 100к+ на руки белыми весят месяцами (!!!) без откликов приходится работать со средними разработчиками по рынку. Просто чтобы сохранить хотя бы подобие предсказуемости и устойчивости к увольнению одного-двух человек из каманды. И тут уже не все так просто :(.
и как работаете в такой ситуации?
У меня есть некие самописные процессы, которые я вывел из существующих и на основании своего опыта. Стараюсь улучшать и дорабатывать по мере возможности.
Есть некая подборка тулзов для организации этого дела на практике. Платных, open source, что-то сам писал. Тоже потихоньку дотачиваю напильником.
Вообщем кручусь как могу. Без процессов не смог бы.
Есть некая подборка тулзов для организации этого дела на практике. Платных, open source, что-то сам писал. Тоже потихоньку дотачиваю напильником.
Вообщем кручусь как могу. Без процессов не смог бы.
гле вакансии на iPhone разработчика на 100к+ на руки белыми весят месяцами (!!!) без откликов
Вы действительно рассчитывали нанять профильного гения за сумму порядка 100к просто разместив вакансию, не проводя активный хантинг? Если требования были «гениальными», то, по-моему, неудивительно, что никто не откликнулся.
Вы действительно рассчитывали нанять профильного гения за сумму порядка 100к просто разместив вакансию, не проводя активный хантинг? Если требования были «гениальными», то, по-моему, неудивительно, что никто не откликнулся.
Нет, это я в целом привожу пример состояния рынка в дефолт сити. Требования были более чем скромные.
Тогда, странно, что к вам не стучались те, кто про разработку под iOS только на хабре читал. Хотя, может, «гениальные» требования они прочитали между строк, ориентируясь на сумму. Такое бывет. Вижу, например, знание и зарплату в 100к, так даже не дергаюсь, если на этом фреймворке только бложик «написал». Бы ла бы зарплата в 50к указана — отправил бы резюме на ту же вакансию.
У меня меньше, два года полноценное руководство отделом. До этого, правда, 6 лет назад была своя студия на фрилансе, и там были интересные проекты (мы даже прорабатывали клон sape.ru).
Во многом — у меня хорошие учителя просто, с большим опытом. Который легко подтверждается на практике.
Во многом — у меня хорошие учителя просто, с большим опытом. Который легко подтверждается на практике.
Должен сказать автору спасибо! Я уже начал думать, что я один в этом мире :)
Автор сделал очень верное наблюдение — методологии (управления, проектирования, разработки — можете продолжить список) не приносят ожидаемой от них пользы. Но при этом он делает совершенно неправильный вывод — что эти методологии не нужны. Да, бесспорно, люди важны. Опыт бесценен и незаменим. Но нельзя же строить опыт на пустом месте?
Все эти методологии — результат набитых шишек множества людей. Многим они реально помогли. Просто не надо забывать, что одни и те же слова разными людьми понимаются по разному. Да что там говорить — один и тот же человек в разные периоды своей жизни совершенно по разному относится к одним и тем же идеям.
От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана. И не всякая команда сможет сразу воспользоваться методологией, поскольку многие допущения могут лишь подразумеваться и их понимание приходит только с опытом, причем не всегда удачным.
Методологии необходимо изучать, чтобы понимать в чем их сильные и слабые стороны, какие вопросы они решают и за счет чего. Это нужно делать по тем же причинам, по каким программисту следует изучать новые языки программирования — это расширяет пространство понятий, которыми мы можем оперировать.
А вот кого стоит реально побить палкой — так это армию маркетологов, которые используют хорошие начинания вроде Agile для банального сбора денег. По факту на флаг выносится идея — «Вот мы вас щас научим и у вас наступит счастье». Грамотный маркетинг приводит к тому, что куча организаций под барабану несет свои деньги консультантам. И методологии становятся просто товаром. Очень многие покупают методологию, поскольку продавцы говорят, что успех прилагается бесплатно.
Люди — это очень важно. Хороший специалист должен быть образован. Он должен иметь большой опыт. Все обруганные в статье методологии — это чей-то опыт. Было бы глупо им разбрасываться. Поэтому я добавлю, что хороший специалист получает опыт не только за счет своих шишек, но и умеет воспользоваться чужим, как положительным, так и отрицательным.
Все эти методологии — результат набитых шишек множества людей. Многим они реально помогли. Просто не надо забывать, что одни и те же слова разными людьми понимаются по разному. Да что там говорить — один и тот же человек в разные периоды своей жизни совершенно по разному относится к одним и тем же идеям.
От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана. И не всякая команда сможет сразу воспользоваться методологией, поскольку многие допущения могут лишь подразумеваться и их понимание приходит только с опытом, причем не всегда удачным.
Методологии необходимо изучать, чтобы понимать в чем их сильные и слабые стороны, какие вопросы они решают и за счет чего. Это нужно делать по тем же причинам, по каким программисту следует изучать новые языки программирования — это расширяет пространство понятий, которыми мы можем оперировать.
А вот кого стоит реально побить палкой — так это армию маркетологов, которые используют хорошие начинания вроде Agile для банального сбора денег. По факту на флаг выносится идея — «Вот мы вас щас научим и у вас наступит счастье». Грамотный маркетинг приводит к тому, что куча организаций под барабану несет свои деньги консультантам. И методологии становятся просто товаром. Очень многие покупают методологию, поскольку продавцы говорят, что успех прилагается бесплатно.
Люди — это очень важно. Хороший специалист должен быть образован. Он должен иметь большой опыт. Все обруганные в статье методологии — это чей-то опыт. Было бы глупо им разбрасываться. Поэтому я добавлю, что хороший специалист получает опыт не только за счет своих шишек, но и умеет воспользоваться чужим, как положительным, так и отрицательным.
А ещё для сбора денег по-видимому используются всякие SOLID, MVC и дизайн-паттерны. Иначе чем объяснить то, что о них так избыточно много говорят.
Это, скорее, первичный фильтр при найме.
ну, на самом деле, если систему написали быстро и просто и она 10 лет работает, то она может быть сделана без MVC, SOLID (SOLID кул тема), и так далее, и вовсе не нуждаться в рефакторинге.
другое дело, если, как у меня, бизнес-сущности растут на грибах и правила их взаимодействия. вот там договор, а теперь у договора тарифные блоки (тариф — сложная сущность 30+ параметров), а теперь у нас еще связаны брони с договором. а теперь брони еще бывают такие и сякие, и для таких-то услуг без них нельзя создать договор… а комбинаций цен 200,000 и тд.
другое дело, если, как у меня, бизнес-сущности растут на грибах и правила их взаимодействия. вот там договор, а теперь у договора тарифные блоки (тариф — сложная сущность 30+ параметров), а теперь у нас еще связаны брони с договором. а теперь брони еще бывают такие и сякие, и для таких-то услуг без них нельзя создать договор… а комбинаций цен 200,000 и тд.
От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана.Даю 95%, что на момент создания методологии эти допущения ещё неочевидны.
я уверен, что они неочевидны и даже после этого. Но это не говорит о том, что методология бесполезна.
Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
После покупки Люцента Алкатель забросил свою систему ИП-ТВ и стал мигрировать на люцентовскую. «Родная» алкателевская была добротно спроектирована «сверху вниз» на основе решений от Оракла. Люцентовскую изначально писало какое-то подразделение испанской Телефоники для одного городка в неколько десятков тысяч человек, потом это подразделение продали Люценту и в Люценте систему стали масштабировать «снизу вверх». На той стадии, когда меня сократили из Алкателя — весна-лето 2009 — для люцентовской системы ещё не было автоматического инсталлятора, её приходилось разворачивать в полуручном режиме, при этом рещение о миграции на неё было принято уже минимум полгода как. Так что вот, пример из практики на тему «проектирование versus итеративность».
ну вообще, эволюционный рефакторинг не исключает, что после опыта снизу вверх вы оцените все риски, и сверху вниз спроектируете простой и нужный вариант функционала и быстро его напишите…
по крайней мере, У меня так бывало. у нас есть восьмая версия отчета «загрузки рекламных мест», и мой ведущий программист супер-матрицы расчета цен там сделал. в то время как первая была тупо циклами сделана и считалась на лету (зато в первую же неделю принесла полляма деревянных, при 300килорублей продаж за месяц до нее — разумеется, при пересмотре тарифов с помощью этого отчета, а не сама по себе).
по крайней мере, У меня так бывало. у нас есть восьмая версия отчета «загрузки рекламных мест», и мой ведущий программист супер-матрицы расчета цен там сделал. в то время как первая была тупо циклами сделана и считалась на лету (зато в первую же неделю принесла полляма деревянных, при 300килорублей продаж за месяц до нее — разумеется, при пересмотре тарифов с помощью этого отчета, а не сама по себе).
Ха, «родная» OVM ( OMP ) когда-то была такой-же сырой. И развивалась она также итеративно. После первых кастомизаций ее отрефакторили ( к стати все это было в рамках SMM level 3 ) обьединив 3 продукта от разных компаний в один и тогда она действительно была добротно спроектирована, но после нескольких лет улучшений вместо очередного перепроектирования с учетом новых реалий ее тупо забросили. Вообще то классическая ситуация когда игры менеджмента испортили лучший продукт на рынке на то время.
Нужно быть полнейшим дебилом, чтобы схватиться за Agile или TDD/BDD и считать, что они гарантируют успех проекту. Личную отвественность и здравый смысл не заменить ничем, а люди все пытаются это сделать, выбирая модную и убойную-все-будет-круто-инфа-100% методику. Это похоже на «купил очень дорогой фотик — стал фотографом». Нет никакой методологии, нет проектирования, если нет мозгов.
В индустрии наблюдается чудовищный overenginering — что в коде, что в процессах и управлении.
Архитектура — это не про то как закопать все в фабриках, TDD и прочих паттернов «на будущее». Она о том, как выбрать набор средств чтобы выполнить задачу в установленные сроки и с заданным качеством.
Если задачу можно решить bat-файлом за день, и забыть про нее на год до появления новых требований — надо так и сделать, не нужно для этого тянуть MVC- и IoC-фреймворки, библиотеку для моков, 100500 паттернов, производить исследования производительности и добиваться 100% покрытия тестами.
Архитектура — это не про то как закопать все в фабриках, TDD и прочих паттернов «на будущее». Она о том, как выбрать набор средств чтобы выполнить задачу в установленные сроки и с заданным качеством.
Если задачу можно решить bat-файлом за день, и забыть про нее на год до появления новых требований — надо так и сделать, не нужно для этого тянуть MVC- и IoC-фреймворки, библиотеку для моков, 100500 паттернов, производить исследования производительности и добиваться 100% покрытия тестами.
Среднестатистический гражданин вообще к перфекционизму не склонен, потому остановится на утилитарности.
Т.е. запомнит десяток команд, и будет «сисадмином». Запомнит десяток операторов и будет всю жизнь мучить стек, называясь «программистом». Освоит с горем пополам возню в Вордпрессе (никого не хочу обидеть), и будет «вебмастером».
Есть тип людей, в противовес вышеобозначенному, который чем больше узнаёт, тем больше охреневает от того, что ничего не знает. И такому не нужны никакие преподователи. Ему лишь нужны источники информации, и он выжмет из них всё, что ему надо и сделает по своему.
И он никогда не будет уверен в своих знаниях как те, кто никогда не угонится в знаниях за ним.И называется такой человек — упёртый амбициозный единоличник. И это не хорошо и не плохо, просто факт.
Если судьба так складывается и вместе собираются несколько таких людей, то может получится facebook, google, великие музыкальные произведения и тд. Но тут еще очень важна удача и обстоятельства.
Потом эти люди стареют, пишут книги как нужно все правильно делать, но мир уже изменился (в том числе и благодаря им) и на их место совсем скоро придут такие же как и они в молодости — упёртые амбициозные единоличники.
Т.е. запомнит десяток команд, и будет «сисадмином». Запомнит десяток операторов и будет всю жизнь мучить стек, называясь «программистом». Освоит с горем пополам возню в Вордпрессе (никого не хочу обидеть), и будет «вебмастером».
Есть тип людей, в противовес вышеобозначенному, который чем больше узнаёт, тем больше охреневает от того, что ничего не знает. И такому не нужны никакие преподователи. Ему лишь нужны источники информации, и он выжмет из них всё, что ему надо и сделает по своему.
И он никогда не будет уверен в своих знаниях как те, кто никогда не угонится в знаниях за ним.И называется такой человек — упёртый амбициозный единоличник. И это не хорошо и не плохо, просто факт.
Если судьба так складывается и вместе собираются несколько таких людей, то может получится facebook, google, великие музыкальные произведения и тд. Но тут еще очень важна удача и обстоятельства.
Потом эти люди стареют, пишут книги как нужно все правильно делать, но мир уже изменился (в том числе и благодаря им) и на их место совсем скоро придут такие же как и они в молодости — упёртые амбициозные единоличники.
Это так, вот только пока такие люди не создадут google или facebook их никто и не ценит, т.к. для того чтобы понять и оценить такого «упёртого амбициозного единоличника», тот кто этим занимается должен сам быть как минимум таким же. А где вы видели таких менеджеров? Замкнутый круг однако для большинства проектов получается!
Не всегда. Возьмем армию — умных мало и их перебьют, нужно строить систему и воевать математически, как римляне одно время фигачили умных варваров.
Agile именно об этом и говорит, что вам может повести и вы подберете команду, которая понимает друг друга с полуслова и пишет код б… ть. А методики — только показывают как это может а может и не работать.
Согласен, что очень очень многое зависит от людей, но очень часто нужно из говна лепить конфетки, ну не конфетки а похуже — но надо.
Agile именно об этом и говорит, что вам может повести и вы подберете команду, которая понимает друг друга с полуслова и пишет код б… ть. А методики — только показывают как это может а может и не работать.
Согласен, что очень очень многое зависит от людей, но очень часто нужно из говна лепить конфетки, ну не конфетки а похуже — но надо.
Часто разработка напоминает мне старый анекдот:
— A как делают корабли в бутылках?
— В бутылку засыпают силикатного клея, говна и трясут. Получаются разные странные штуки, иногда корабли.
— A как делают корабли в бутылках?
— В бутылку засыпают силикатного клея, говна и трясут. Получаются разные странные штуки, иногда корабли.
В отрыве от содержания статьи про Савельева.
stelazin.livejournal.com/99099.html
stelazin.livejournal.com/99402.html
Савельев еще тот троль. Он работает на публику. На тв и в интернете он будет говорить полную чушь, лишь бы люди его запомнили. В то же время в научных публикациях он предельно корректен и точен.
stelazin.livejournal.com/99099.html
stelazin.livejournal.com/99402.html
Савельев еще тот троль. Он работает на публику. На тв и в интернете он будет говорить полную чушь, лишь бы люди его запомнили. В то же время в научных публикациях он предельно корректен и точен.
Стелазин несет какую-то хрень. Я Савельева — доктора наук знаю, а хуя с горы-анонима нет.
Тем более что там журналист еще хреново написал, «серАтонин» и прочее.
Савельев прекрасно и аргументированно умывает всех — и ученых, и психологов (см. с Гордоном передачи), и так далее. Да и в жизни его теории прекрасно работают — индивидуальная изменчивость мозга объяснила многое из того, чего я не понимал много лет.
Тем более что там журналист еще хреново написал, «серАтонин» и прочее.
Савельев прекрасно и аргументированно умывает всех — и ученых, и психологов (см. с Гордоном передачи), и так далее. Да и в жизни его теории прекрасно работают — индивидуальная изменчивость мозга объяснила многое из того, чего я не понимал много лет.
А по существу? Кроме опечаток есть замечания?
Автор не журналист, а ученый.
Я согласен, как шоумен Савельев великолепен. Что ни передача, так сенсация и поверженные оппоненты.
Если теория Савельева чего-то вам объяснила, это еще не значит, что она работает.
Я, например, не могу серьезно воспринимать высказывания Савельева, типа таких:
«Мозг — странная структура. С одной стороны, он позволяет нам думать, с другой — не позволяет. Ведь как он работает? В расслабленном состоянии, когда вы отдыхаете, скажем, смотрите телевизор, мозг потребляет 9% всей энергии организма. А если вы начинаете думать, то расход повышается до 25%.»
или
«Мозг привык к этому и не верит, что завтра ему будет, чем питаться. Поэтому он категорически не хочет думать. (По этой же причине, кстати, люди склонны переедать.) „
Когда доктор наук пишет, что мозг во что-то верит, надо понимать, он разговаривает с школьниками.
Автор не журналист, а ученый.
Я согласен, как шоумен Савельев великолепен. Что ни передача, так сенсация и поверженные оппоненты.
Если теория Савельева чего-то вам объяснила, это еще не значит, что она работает.
Я, например, не могу серьезно воспринимать высказывания Савельева, типа таких:
«Мозг — странная структура. С одной стороны, он позволяет нам думать, с другой — не позволяет. Ведь как он работает? В расслабленном состоянии, когда вы отдыхаете, скажем, смотрите телевизор, мозг потребляет 9% всей энергии организма. А если вы начинаете думать, то расход повышается до 25%.»
или
«Мозг привык к этому и не верит, что завтра ему будет, чем питаться. Поэтому он категорически не хочет думать. (По этой же причине, кстати, люди склонны переедать.) „
Когда доктор наук пишет, что мозг во что-то верит, надо понимать, он разговаривает с школьниками.
Ну тут я могу сказать одно, что ознакомился с его монографиями, книгами и статьями — про энергетическую гипотезу возникновения и развития мозга; про происхождение мозга человека, «изменчивость и гениальность» и тд.
И то, что он в видео произносит одним предложением, на самом деле, за собой представляет минимум часа три лекции для неподготовленных слушателей.
К примеру, говоря о форме борозд и извилин, он отмечает, что она уникальна (более, чем отпечатки пальцев), однако не влияет на интеллект, и что формируется не за счет генов. Чтобы ОБЪЯСНИТЬ механизм, ему понадобилось около двух часов лекции для ученых-физиков. И то, он многое опускал.
Так и с любым высказыванием. Если знаешь, что за ним стоит, очень интересно.
К слову, помимо Савельева, я слушал лекции, например, член-корреспондента РАН Костантина Анохина, выложенные в инете. Но в теме мозга, вне всякого сомнения, являюсь дилетантом и доверяю мнению профессоров.
И то, что он в видео произносит одним предложением, на самом деле, за собой представляет минимум часа три лекции для неподготовленных слушателей.
К примеру, говоря о форме борозд и извилин, он отмечает, что она уникальна (более, чем отпечатки пальцев), однако не влияет на интеллект, и что формируется не за счет генов. Чтобы ОБЪЯСНИТЬ механизм, ему понадобилось около двух часов лекции для ученых-физиков. И то, он многое опускал.
Так и с любым высказыванием. Если знаешь, что за ним стоит, очень интересно.
К слову, помимо Савельева, я слушал лекции, например, член-корреспондента РАН Костантина Анохина, выложенные в инете. Но в теме мозга, вне всякого сомнения, являюсь дилетантом и доверяю мнению профессоров.
Та самая лекция
vk.com/video5892382_163680104
vk.com/video5892382_163680104
Суть проектирования не в том чтобы «сделать идеальное», а в том чтобы сделать поддерживаемое. Проект, который не рухнет под грузом правок через три года.
Отличная статья. Автору спасибо, как будто из головы мысль вытянул :)
Я в фирме пользуюсь такой последовательностью разработки веб-сервисов:
1.Описание функций
— клиент говорит — мы записываем, если что поправляем
2. Разработка макета
— строгий макет, показывает скорее какие переходы будут, окна, где расположены поля кнопки. По опыту даже на достаточно сложный проект макет делается довольно быстро. Обязательным условием нарисовать абсолютно все раскадровки сервиса вплоть до ошибок и сообщений
3. Разработка структуры базы данных — очень легко делается в mindmap.
Все! Программисты знают что им делать шаг за шагом. Озвучивают срок, мы умножаем на два, и как правило сдаем проект на 10-15 дней раньше. Клиент жутко доволен, никто не в стрессе.
Только время от времени необходимо контролировать все ли функции выполняются которые перечислены в макете.
Сам таким образом освоил две достаточно сложные системы за 2 месяца + бегал искал клиентов в графический отдел.
Это я к чему, статья отлично учит одному — не перестарайтесь с планированием, и творите в удовольствие, и с этим я абсолютно согласен :)
Я в фирме пользуюсь такой последовательностью разработки веб-сервисов:
1.Описание функций
— клиент говорит — мы записываем, если что поправляем
2. Разработка макета
— строгий макет, показывает скорее какие переходы будут, окна, где расположены поля кнопки. По опыту даже на достаточно сложный проект макет делается довольно быстро. Обязательным условием нарисовать абсолютно все раскадровки сервиса вплоть до ошибок и сообщений
3. Разработка структуры базы данных — очень легко делается в mindmap.
Все! Программисты знают что им делать шаг за шагом. Озвучивают срок, мы умножаем на два, и как правило сдаем проект на 10-15 дней раньше. Клиент жутко доволен, никто не в стрессе.
Только время от времени необходимо контролировать все ли функции выполняются которые перечислены в макете.
Сам таким образом освоил две достаточно сложные системы за 2 месяца + бегал искал клиентов в графический отдел.
Это я к чему, статья отлично учит одному — не перестарайтесь с планированием, и творите в удовольствие, и с этим я абсолютно согласен :)
> Обязательным условием нарисовать абсолютно все раскадровки сервиса вплоть до ошибок и сообщений
А зачем? Это те иерархические мелочи, которые отнимают время. Разве проект потом на каком либо этапе не дополняется какой либо вещью? ну позвонит заказчик на этапе программирования и скажет — эврика, мне нужно кое еще что. Как с этим быть? На практике оказывается что многие вещи не удобны, хотьмаке отличный.
Нельзя же понять какого температура вода, пока не войдешь в море.
А зачем? Это те иерархические мелочи, которые отнимают время. Разве проект потом на каком либо этапе не дополняется какой либо вещью? ну позвонит заказчик на этапе программирования и скажет — эврика, мне нужно кое еще что. Как с этим быть? На практике оказывается что многие вещи не удобны, хотьмаке отличный.
Нельзя же понять какого температура вода, пока не войдешь в море.
Попали не в бровь, а в глаз.
На самом деле, это не только программирования и ПМ касается — вся та же хрень творится и в области бизнеса, например. 90% мощных книжек про «маркетинг», «инвестиции», «переговоры», Кийосаки и пр. — откровенный мусор, авторы которых зачастую даже не имеют реального опыта, и зарабатывают только на впаривании этих самых книг. И в особенности ярко это проявляется в области биржевой торговли (т.н. «технический анализ») — только масштаб еще больший — кризисы и гигантские сливы денег банками и хедж-фондами как раз отсюда. Короче говоря, это довольно масштабное явление.
Спасибо за статью (и отдельно — за отсылку к прекрасному рассказу «Профессия»)!
На самом деле, это не только программирования и ПМ касается — вся та же хрень творится и в области бизнеса, например. 90% мощных книжек про «маркетинг», «инвестиции», «переговоры», Кийосаки и пр. — откровенный мусор, авторы которых зачастую даже не имеют реального опыта, и зарабатывают только на впаривании этих самых книг. И в особенности ярко это проявляется в области биржевой торговли (т.н. «технический анализ») — только масштаб еще больший — кризисы и гигантские сливы денег банками и хедж-фондами как раз отсюда. Короче говоря, это довольно масштабное явление.
Спасибо за статью (и отдельно — за отсылку к прекрасному рассказу «Профессия»)!
На пути избавления от иллюзий на правильно пути вы.
но «Один великолепный программист стоит десятырех раздолбаев или средненьких.» говорит,
что ещё длинный путь впереди.
но «Один великолепный программист стоит десятырех раздолбаев или средненьких.» говорит,
что ещё длинный путь впереди.
а посоветуйте чего-нибудь дельного, куда стремиться дальше следует?
Не уверен в этом на 100%, но мне «помогло» ведение собственных проектов с целью заработка (помимо основной работы). Проблема современного менеджмента среднего звена (помимо того что 100% людей идиоты) в том, что (как мне кажется) люди разучились считать деньги (пусть и чужие).
И как-то начинает приходить понимание, что собрать 8 человек на часовой митинг — это выкинутый человеко-день. при з/п специалиста в 60т — это грубо 3т (если речь о компаниях, то считай со всеми налогами с коэффициентом 1.5). Просто выкинутых в трубу. Что игры в «эффективный менеджмент» — обычно достаточно дороги. Что поручать разработчику верстку — это значит через 1-2-3 дня получить дерьмовый результат по цене первоклассной верстки, от лучших специалистов (которые к тому же справились бы с этим МАКСИМУМ за день). Что идеальной архитектуры не бывает. Все как зомби твердят MVC-MVC-гибкая архитектура- а внутрь заглянешь — получается тоже самое дерьмо, которое точно так же не готово к будущему, но в 5 раз дороже.
В общем что надо действовать по ситуации и всега соотносить затраты и пользу. По возможности «реальную».
Как пример — тут в соседнем топике люди рассуждали про парное программирование и про то как это хорошо и весело. Да хорошо, Да весело. Но как-то никто даже не заикнулся что прежде чем вводить такую практику, нужно — багтрекер => статистика ошибок по типам работ (грубо например количество багов на 100 строк кода), внедрили парное программирование — посмотрели статистику — изменилась ли она? на сколько изменилась? и главный вопрос — а стоят ли эти баги потраченных денег? И в большенстве случаев ответ — нет не стоят.
В этой нашей «вебориентированной» разработке цена ошибки зачастую мала (бизенесс ничего не потеряет если она случится и через пол-дня -день будет исправлена) и соответственно в парном программировании просто нет смысла.
Но «считать чужие деньги» у нас как-то не принято
И как-то начинает приходить понимание, что собрать 8 человек на часовой митинг — это выкинутый человеко-день. при з/п специалиста в 60т — это грубо 3т (если речь о компаниях, то считай со всеми налогами с коэффициентом 1.5). Просто выкинутых в трубу. Что игры в «эффективный менеджмент» — обычно достаточно дороги. Что поручать разработчику верстку — это значит через 1-2-3 дня получить дерьмовый результат по цене первоклассной верстки, от лучших специалистов (которые к тому же справились бы с этим МАКСИМУМ за день). Что идеальной архитектуры не бывает. Все как зомби твердят MVC-MVC-гибкая архитектура- а внутрь заглянешь — получается тоже самое дерьмо, которое точно так же не готово к будущему, но в 5 раз дороже.
В общем что надо действовать по ситуации и всега соотносить затраты и пользу. По возможности «реальную».
Как пример — тут в соседнем топике люди рассуждали про парное программирование и про то как это хорошо и весело. Да хорошо, Да весело. Но как-то никто даже не заикнулся что прежде чем вводить такую практику, нужно — багтрекер => статистика ошибок по типам работ (грубо например количество багов на 100 строк кода), внедрили парное программирование — посмотрели статистику — изменилась ли она? на сколько изменилась? и главный вопрос — а стоят ли эти баги потраченных денег? И в большенстве случаев ответ — нет не стоят.
В этой нашей «вебориентированной» разработке цена ошибки зачастую мала (бизенесс ничего не потеряет если она случится и через пол-дня -день будет исправлена) и соответственно в парном программировании просто нет смысла.
Но «считать чужие деньги» у нас как-то не принято
Частые споры на хабре привели меня к выводу, что все ситуации уникальны, и одни паттерны могут не работать в другом месте. Но, главное не паттерн, а понимание, почему его придумали. Я только через 5 лет внедрения XP в моей бывшей компании понял, что именно решает этот подход и почему его создавали. И это не написание идеального кода.
ok sps
Вы конечно правы, особенно про кадры. Но как всегда у каждой правды есть своя область правдивости. В частности все описанное верно для небольших независимых проектов, которые можно спокойно окинуть взором. Для проектов из нескольких команд, для сложных проектов без проектирования не обойтись, иначе будет каша.
Про методологии вам как-то не повезло. RUP сам по себе имеет какой-то дикий оверхед ( я помню PM-ов, которые гордо трясли папками документов на проектах из 5 человек — это просто цирк какой-то ), Agile также требует понимания и правильной имплементации. В целом верно то что менеджмент — это непродуктивная деятельность и сама по себе ценности не имеет, следовательно любые действия ПМ-а и вообще менеджерские пляски имели четкое обоснование для чего они нужны и какой выигрыш мы при этом получаем. Да, стоит потратить час на синхронизацию внутри команды что бы сэкономить пару дней на переделку не срастающихся интерфейсов, но делать это каждый день скорее всего непродуктивно. И так далее. С таким подходом надо оценивать любую методологию. И именно с таким подоходом окажется что чем сложнее проект тем больше требуется обсуждать и согласовывать и тогда вместо распределенного понимания структуры продукта лучше работает централизованное понимание в виду дизайна или даже архитектора проекта.
Про методологии вам как-то не повезло. RUP сам по себе имеет какой-то дикий оверхед ( я помню PM-ов, которые гордо трясли папками документов на проектах из 5 человек — это просто цирк какой-то ), Agile также требует понимания и правильной имплементации. В целом верно то что менеджмент — это непродуктивная деятельность и сама по себе ценности не имеет, следовательно любые действия ПМ-а и вообще менеджерские пляски имели четкое обоснование для чего они нужны и какой выигрыш мы при этом получаем. Да, стоит потратить час на синхронизацию внутри команды что бы сэкономить пару дней на переделку не срастающихся интерфейсов, но делать это каждый день скорее всего непродуктивно. И так далее. С таким подходом надо оценивать любую методологию. И именно с таким подоходом окажется что чем сложнее проект тем больше требуется обсуждать и согласовывать и тогда вместо распределенного понимания структуры продукта лучше работает централизованное понимание в виду дизайна или даже архитектора проекта.
Я бы никогда не устраивал менеджерские/архитекторские/мейнтейнерские пляски если бы это не было обосновано. Я хочу писать код блять. Только дело в том что когда я пишу код — весь проект уходит куда-то в степи. Каждый, со всей глубиной своего таланта, занимается тем что ему по душе. Никто не знает общих приоритетов проекта, все считают что могут пилить свои фичи месяцами. Или добавлять что хотят. Кто это будет разруливать? И как? Методологи направлены как раз на уменьшение хаоса.
Возникает иллюзия что менеджер не нужен, когда
Возникает иллюзия что менеджер не нужен, когда
(а что тут правда «Написать» по option+return срабатывает? А юзабилисты Хабра виндами пользуются?)
Возникает иллюзия что менеджер не нужен, когда заказчик способен выполнять роль менеджера, расставлять приоритеты, и определять без подсказок что нужно сейчас, а какие элементы фичи можно вынести в следующие релизы. И только опытный PM, лучше выросший из кодеров, может подсказать, как внедрение этой фичи может пагубно повлиять на всю систему. И сколько ресурсов поддержка этой фичи может съесть впоследствии. Над всякими штуками, вроде Цена фичи = Технический долг / Бизнес ценность, кто будет думать? Это только чтобы бэклог сформировать. А кто будет оптимизировать процесс, тонко разгадывая проблемы команды, а кто будет сглаживать человеческие конфликты?
Возникает иллюзия что менеджер не нужен, когда заказчик способен выполнять роль менеджера, расставлять приоритеты, и определять без подсказок что нужно сейчас, а какие элементы фичи можно вынести в следующие релизы. И только опытный PM, лучше выросший из кодеров, может подсказать, как внедрение этой фичи может пагубно повлиять на всю систему. И сколько ресурсов поддержка этой фичи может съесть впоследствии. Над всякими штуками, вроде Цена фичи = Технический долг / Бизнес ценность, кто будет думать? Это только чтобы бэклог сформировать. А кто будет оптимизировать процесс, тонко разгадывая проблемы команды, а кто будет сглаживать человеческие конфликты?
Кстати о релизах. Недавно ретвитнул:
«It's easier to pretend you're doing Kanban than to pretend you're doing Scrum. That explains many Kanban adoptions.» — @nusco
Это конечно жестко, но еще раз можно повторить то что говорят все шарлатаны-аджайл-тренеры — Каждый проект уникален, каждый продукт уникален, каждая команда уникальна, каждый заказчик уникален. То, что работает для вас, с большой вероятностью, в неизменном виде, не будет работать больше ни для кого. Поэтому нужно подключать голову, следить за процессом и эволюционировать.
«It's easier to pretend you're doing Kanban than to pretend you're doing Scrum. That explains many Kanban adoptions.» — @nusco
Это конечно жестко, но еще раз можно повторить то что говорят все шарлатаны-аджайл-тренеры — Каждый проект уникален, каждый продукт уникален, каждая команда уникальна, каждый заказчик уникален. То, что работает для вас, с большой вероятностью, в неизменном виде, не будет работать больше ни для кого. Поэтому нужно подключать голову, следить за процессом и эволюционировать.
Шикарная статья!
Отдельное огромное спасибо за ссыль на Азимова! Давным-давно читал, но забыл как называется.
Отдельное огромное спасибо за ссыль на Азимова! Давным-давно читал, но забыл как называется.
Эх, хочу такую статью на английском.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Красной таблетки не существует