Если в вашей компании это работает и компания в финансовом смысле чувствует себя хорошо — то это хорошо)
Я даже Вам немного завидую.
Но всё же дедлайны иногда имеют объективную необходимость, например при запуске спутника на марс, срочной трансплантации, ну и датой начала массовой рекламной кампании)
в ней не будет «резкого» торможения. При необходимости осуществить торможение — она перенесёт центр тяжести максимально назад и вниз и начнёт тормозить сохраняя равновесие. При этом будет некоторое отрицательное ускорение. Развить большее ускорение торможения она не сможет.
ну а в случае отказа или резкого изменения центра тяжести — боулинг
Фаулера, который, как считается, широко формализовал такие понятия как IoC
А ещё Фаулер задавался вопросом
The question, is what aspect of control are they inverting?/blockquote>
У меня, если честно, тоже возникает такой вопрос когда я слышу про IoC. Тот же пример про шаблонный ментод. Экземпляр класса всё так же вызывает метод экземпляра класса-участника иерархии с шаблонными методами. В чём инверсия? Где поменялось направление?
Любопытно, что многие капчаборцы используют нейронные сети для борьбы с поворотом изображений символов по сравнению с «эталоном».
Если сравнивать не обзбражение и эталон, а результаты применения к ним каких-либо преобразований нечувствительных к повроту — то результаты будут лучше а нейронные сети могут и не понадобится.
Беглое гугление по поводу преобразований нечувствительных к повороту выдаёт нам например слова «лог-полярное преобразование» + «вейвлет преобразование»
интересно… он как бэ улыбается, но при этом голова, похоже, немного «втянута», стоит в закрытой позе + складки пиджака усиливают ощущение что он напряжен
«с заказчиком»
Заказчику обычно всё-равно. Он этот птичий язык не знает и знать не хочет.
«внутри команды»
Иногда возможно. Но как я уже говорил — от фраз подобных «а вот здесь мы используем паттерн Цепочка Обязанностей» — у меня стойкое ощущение что телега ставится впереди лошади. И это не говоря уже о том, что люди часто по разному понимают смысл одних и тех же паттернов (так например когда люди говорят что у них архитектура на основе MVC — часто можно обнаружить, что никакой «M» у них там вовсе нет). Для общения внутри команды на мой взгляд намного полезней когда все участники могут свободно «писать» используя какбэUMLные нотации.
про пустые рабочие дискуссии — я всё же более чем уверен, что в большинстве случаев причиной этому становится именно бестактность, которая ведёт к тому что один из участников обсуждения начинает упорствовать, лишь бы доказать что он «не верблюд». Если есть несколько решений, прозрачные требования и у каждого из решений есть свои плюсы и минусы — то выбрать лучшее достаточно просто, если при этом авторы «других» решений не чувствуют себя идиотами.
«Но это, в принципе, работает»
Вы наверно хотели сказать «пока вроде бы срабатывало»?)
В туже кучу что и «административный ресурс» и «философия»: вы размышляли над тем почему разработчики работают, почему они работают хорошо или спустя рукава, почему они работают именно здесь хотя могли бы работать в тысячах других таких же «средних проектах ниочём»?
Вы снова пытаетесь разделить всё на «хорошо» и «плохо», на «одноразовый продукт» и «продукт который будет расширяться и поддерживаться».
«Продукт который будет расширяться и поддерживаться» так же может иметь плохую архитектуру и плохой код и быть при этом вполне финансово успешным.
Да и стратегия «сговнять абы как(но без явных багов) лишь бы быстрей запустить» а потом ЕСЛИ деньги пойдут — выкинуть и переписать по уму с учётом новых реалий — иногда оказывается более правильной, чем «долго-долго» и [возможно] правильно что-то писать, а потом запуститься и не суметь «продать» (а такое часто бывает. люди ведь ошибаются в оценках)
«ненависть» — всё же думаю литературный приём.
Проблема с switch/портянкой ifов в том что там часто бывает заложена логика предметной области. И Когда таких случаев накапливается много — такой метод становится большим => его сложно понимать и поддерживать для него unit-test.
Решения можете погуглить (или посмотреть в книге фаулера про рефакторинг): замена условного оператора полиморфизмом (в туже куча — замена состоянием/стратегией)
«хороший код необходим для успешного продукта»
это неверно. продукт может быть успешным и с ужасной архитектурой и плохим кодом. и таких случаев большинство.
Нулевым пунктом для такого новоявленного руководителя я бы добавил ТАКТИЧНОСТЬ.
Уверен каждый сталкивался с ситуацией, когда разработчик упорно защищает своё решение, отвергая аргументы и используя какие-то «крайние» случаи в качестве мотивации своего решения. И часто подобные разговоры заканчивают применением административного ресурса.
А происходит это зачастую вот почему (считаем что разработчик вполне адекватен): вы вербально/паравербально/невербально высказали свою суждение которое звучит примерно как «Вася ты идиот» и иногда ещё «а я умный». В такой ситуации Вася ествественно начинает защищать своё решение + иногда переходит в атаку. Как итог — потери времени, ухудшение отношений.
Поверьте, закатавание глаз, характерное приоткрыванеи рта с цокающим звуком, поднятие брови, разведение рук, качание головой, и некоторые микромимические жесты — всё это способно за пол секунды донести до Васи вашу мысль о том, что «вам очень жаль что Вася такой дебил, вы глубоко скорбите а том, что компания наняла такого идиота и вам бесконечно жаль что приходится тратить время на таких идиотов». Ни о каком конструктивном общении после этого не может быть и речи.
Кстати «Объясните ребятам» — формулировка которая тоже возвышает новоявленного руководителя и принижает опыт «ребят». Лучше общаться не с «ребятами» а с «коллегами».
Автор исходит из того, что новоявленному руководителю лучше знать как должен выглядеть «хороший код» и «хорошая архитектура» и что организация готова это всё оплачивать (что бывает ой как не всегда).
Проблема в том что «все ошибаются». И наш новоявленный руководитель скорей всего тоже. Это не «громкие слова». Посмотрите: В гугле регулярно «что-то» происходит, в яндексе какие-то проблемы, в твиттере, взгляните на эволюции API java, на протокол X. Люди, более квалифицированные чем наш новоиспеченный руководитель постоянно допускают ошибки.
Поэтому вместо навязывания (что будет встречено сопротивлением), лучше показать альтернативное решение, и тактично УБЕДИТЬ человека в том что так лучше(приводя доводы, а не пытаясь давить на человека или использовать административный ресурс). Может так статься что и «не лучше» (почти всегда есть грань, за которой фанатичное следование некоторым правилам уже не приносит пользы, а время тратит, но фанатики могут её не видеть)
«НЕНАВИСТЬ» — хочется надеятся, что это слово вы использовали лишь для «крассногослофца».
«Собирайтесь всей командой раз в неделю, и пусть кто-нибудь ищет в коде грязь и антипаттерны.» — для этого удобно бывает использовать инструменты которые собирают метрики и строят красивые графики (например Sonar ). Начать можно с размера класса, размеров методов, количества методов, поиска копипаста и наличие циклических зависимостей.
Про «паттерны». Раньше я тоже думал что очень хорошо чтобы разработчики знали эти самые паттерны. А вот в последнее время, если честно, всё больше и больше начинаю сомневаться.
Дело в том, что когда мы проектируем «с оглядкой на» DI,SERP, и некоторые другие столь же очевидные вещи, то практически весь букет структурных и порождающих паттернов вырисовывается «сам собой». Получается что нет особой необходимости в том, чтобы лишний раз подчеркнуть «а вот здесь у нас будет использован паттерн Proxy» + когда мы отталкиваемся от паттернов, а не от того что нам нужно сделать — у меня складывается ощущение, что мы ставим телегу впереди лошади.
«и предложения»
массовый мобильный IM (как jimm) ) + геолокация=
0)помимо очевидного
1)географически привязанные чаты вроде «Шоколадницы на ул.Такойто» (всякие брендирования и доп сервисы от организаций)
2)Поиск людей поблизости — уверен «молодёжь» оценит (+продажа свистелок-перделок вроде выдели свой ник в результатах поиска)
3)уникальная маркетинговая информация. IM в телефоне чаще включен чем выключен => данные о потоках людей и их характеристиках (где сколько и как часто тратят). Для некоторых такие срезы для заданных точек могут оказаться очень интересными. В некотором смысле шанс стать офлайновым гуглом который всё про всё знает.
Спецификация тоже к сожалению не спасает.А бескомпромиссная позиция — часто оказывается ошибочной.
Что же нас может «спасти»?
1)Стремиться планирование проекта таким образом, чтобы самые важные функции были реализованы в первую очередь — если «в конце» проекта выяснится что сроки нельзя подвинуть по объективным причинам, а сделать «всё» не успели по любым причинам- продукт можно будет запуститься с неполной функциональностью, и доделать оставшееся после запуска.
2)Диалог и поиск компромисса. Новые «фичи» появляются всегда (заказчики могут быть идиотами, подрядчики могут быть идиотами, да и просто в предметной области произошли изменения — отсюда всегда появляются новые фичи). Если реализация этих фич требует значительных затрат — заказчик должен об этом знать и они должны оплачиваться.
Я даже Вам немного завидую.
Но всё же дедлайны иногда имеют объективную необходимость, например при запуске спутника на марс, срочной трансплантации, ну и датой начала массовой рекламной кампании)
www.youtube.com/watch?v=q1M4ka9EsFM&feature=player_embedded
визитка — набор велоинструментов
визитка-самолётик
имхо просто прикольный враиант
ну а в случае отказа или резкого изменения центра тяжести — боулинг
Ну и да — отказы систем стабилизации дадут начало новому виду спорта — автобоулинг.когда такая штука «споткнётся» — катиться она будет ой как хорошо.
Вася говорит Пете что делать
Петя говорит Васе что делать
Инверсия управления.
В случае с шаблонным методом — я его действительно не вижу класс-клиент как вызвал методы исполнителя так и вызывает.
А ещё Фаулер задавался вопросом
Если сравнивать не обзбражение и эталон, а результаты применения к ним каких-либо преобразований нечувствительных к повроту — то результаты будут лучше а нейронные сети могут и не понадобится.
Беглое гугление по поводу преобразований нечувствительных к повороту выдаёт нам например слова «лог-полярное преобразование» + «вейвлет преобразование»
Заказчику обычно всё-равно. Он этот птичий язык не знает и знать не хочет.
«внутри команды»
Иногда возможно. Но как я уже говорил — от фраз подобных «а вот здесь мы используем паттерн Цепочка Обязанностей» — у меня стойкое ощущение что телега ставится впереди лошади. И это не говоря уже о том, что люди часто по разному понимают смысл одних и тех же паттернов (так например когда люди говорят что у них архитектура на основе MVC — часто можно обнаружить, что никакой «M» у них там вовсе нет). Для общения внутри команды на мой взгляд намного полезней когда все участники могут свободно «писать» используя какбэUMLные нотации.
даже на хабре были статьи:
habrahabr.ru/blogs/personal/13534/
habrahabr.ru/blogs/algorithm/48518/
SERP — ЧИТАТЬ КАК SRP
«Но это, в принципе, работает»
Вы наверно хотели сказать «пока вроде бы срабатывало»?)
В туже кучу что и «административный ресурс» и «философия»: вы размышляли над тем почему разработчики работают, почему они работают хорошо или спустя рукава, почему они работают именно здесь хотя могли бы работать в тысячах других таких же «средних проектах ниочём»?
«Продукт который будет расширяться и поддерживаться» так же может иметь плохую архитектуру и плохой код и быть при этом вполне финансово успешным.
Да и стратегия «сговнять абы как(но без явных багов) лишь бы быстрей запустить» а потом ЕСЛИ деньги пойдут — выкинуть и переписать по уму с учётом новых реалий — иногда оказывается более правильной, чем «долго-долго» и [возможно] правильно что-то писать, а потом запуститься и не суметь «продать» (а такое часто бывает. люди ведь ошибаются в оценках)
Проблема с switch/портянкой ifов в том что там часто бывает заложена логика предметной области. И Когда таких случаев накапливается много — такой метод становится большим => его сложно понимать и поддерживать для него unit-test.
Решения можете погуглить (или посмотреть в книге фаулера про рефакторинг): замена условного оператора полиморфизмом (в туже куча — замена состоянием/стратегией)
это неверно. продукт может быть успешным и с ужасной архитектурой и плохим кодом. и таких случаев большинство.
Нулевым пунктом для такого новоявленного руководителя я бы добавил ТАКТИЧНОСТЬ.
Уверен каждый сталкивался с ситуацией, когда разработчик упорно защищает своё решение, отвергая аргументы и используя какие-то «крайние» случаи в качестве мотивации своего решения. И часто подобные разговоры заканчивают применением административного ресурса.
А происходит это зачастую вот почему (считаем что разработчик вполне адекватен): вы вербально/паравербально/невербально высказали свою суждение которое звучит примерно как «Вася ты идиот» и иногда ещё «а я умный». В такой ситуации Вася ествественно начинает защищать своё решение + иногда переходит в атаку. Как итог — потери времени, ухудшение отношений.
Поверьте, закатавание глаз, характерное приоткрыванеи рта с цокающим звуком, поднятие брови, разведение рук, качание головой, и некоторые микромимические жесты — всё это способно за пол секунды донести до Васи вашу мысль о том, что «вам очень жаль что Вася такой дебил, вы глубоко скорбите а том, что компания наняла такого идиота и вам бесконечно жаль что приходится тратить время на таких идиотов». Ни о каком конструктивном общении после этого не может быть и речи.
Кстати «Объясните ребятам» — формулировка которая тоже возвышает новоявленного руководителя и принижает опыт «ребят». Лучше общаться не с «ребятами» а с «коллегами».
Автор исходит из того, что новоявленному руководителю лучше знать как должен выглядеть «хороший код» и «хорошая архитектура» и что организация готова это всё оплачивать (что бывает ой как не всегда).
Проблема в том что «все ошибаются». И наш новоявленный руководитель скорей всего тоже. Это не «громкие слова». Посмотрите: В гугле регулярно «что-то» происходит, в яндексе какие-то проблемы, в твиттере, взгляните на эволюции API java, на протокол X. Люди, более квалифицированные чем наш новоиспеченный руководитель постоянно допускают ошибки.
Поэтому вместо навязывания (что будет встречено сопротивлением), лучше показать альтернативное решение, и тактично УБЕДИТЬ человека в том что так лучше(приводя доводы, а не пытаясь давить на человека или использовать административный ресурс). Может так статься что и «не лучше» (почти всегда есть грань, за которой фанатичное следование некоторым правилам уже не приносит пользы, а время тратит, но фанатики могут её не видеть)
«НЕНАВИСТЬ» — хочется надеятся, что это слово вы использовали лишь для «крассногослофца».
«Собирайтесь всей командой раз в неделю, и пусть кто-нибудь ищет в коде грязь и антипаттерны.» — для этого удобно бывает использовать инструменты которые собирают метрики и строят красивые графики (например Sonar ). Начать можно с размера класса, размеров методов, количества методов, поиска копипаста и наличие циклических зависимостей.
Про «паттерны». Раньше я тоже думал что очень хорошо чтобы разработчики знали эти самые паттерны. А вот в последнее время, если честно, всё больше и больше начинаю сомневаться.
Дело в том, что когда мы проектируем «с оглядкой на» DI,SERP, и некоторые другие столь же очевидные вещи, то практически весь букет структурных и порождающих паттернов вырисовывается «сам собой». Получается что нет особой необходимости в том, чтобы лишний раз подчеркнуть «а вот здесь у нас будет использован паттерн Proxy» + когда мы отталкиваемся от паттернов, а не от того что нам нужно сделать — у меня складывается ощущение, что мы ставим телегу впереди лошади.
массовый мобильный IM (как jimm) ) + геолокация=
0)помимо очевидного
1)географически привязанные чаты вроде «Шоколадницы на ул.Такойто» (всякие брендирования и доп сервисы от организаций)
2)Поиск людей поблизости — уверен «молодёжь» оценит (+продажа свистелок-перделок вроде выдели свой ник в результатах поиска)
3)уникальная маркетинговая информация. IM в телефоне чаще включен чем выключен => данные о потоках людей и их характеристиках (где сколько и как часто тратят). Для некоторых такие срезы для заданных точек могут оказаться очень интересными. В некотором смысле шанс стать офлайновым гуглом который всё про всё знает.
Что же нас может «спасти»?
1)Стремиться планирование проекта таким образом, чтобы самые важные функции были реализованы в первую очередь — если «в конце» проекта выяснится что сроки нельзя подвинуть по объективным причинам, а сделать «всё» не успели по любым причинам- продукт можно будет запуститься с неполной функциональностью, и доделать оставшееся после запуска.
2)Диалог и поиск компромисса. Новые «фичи» появляются всегда (заказчики могут быть идиотами, подрядчики могут быть идиотами, да и просто в предметной области произошли изменения — отсюда всегда появляются новые фичи). Если реализация этих фич требует значительных затрат — заказчик должен об этом знать и они должны оплачиваться.