Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
Отличная статья. Но вот по первому пункту я не вполне согласен. Что такое плохой код знают все (ну естественно хеллоувордщиков я в расчет не беру) и в 90% плохой код создается осознанно. Причем осознанно он пишется даже хорошими разработчиками.
Тут причин может быть масса, от собственной лени программиста (и уверенности что все равно никто смотреть не будет) до плохо организованного процесса разработки (плохое проектирование- отсюда множественные костыли или постоянная погоня за количеством набитых символов в единицу времени — отсюда индусский код )
Но тем не менее первый шаг все равно верный — плохой код хоть и пишут, но не любят писать. А изящные и красивые (а посему единственно верные) решения нравятся всем и приносят удовлетворение от проделанной работы
Тут причин может быть масса, от собственной лени программиста (и уверенности что все равно никто смотреть не будет) до плохо организованного процесса разработки (плохое проектирование- отсюда множественные костыли или постоянная погоня за количеством набитых символов в единицу времени — отсюда индусский код )
Но тем не менее первый шаг все равно верный — плохой код хоть и пишут, но не любят писать. А изящные и красивые (а посему единственно верные) решения нравятся всем и приносят удовлетворение от проделанной работы
Ну и автор же верно говорит, что ненависть надо вдалбливать чисто административными методами — давая понять, что плохой код в принципе не будет включаться в проект.
Не всегда, глаза «замыливаются», а использование одних и тех же практик держит человека в уверенности, что код его хорош. Потому ведь порой взгляд со стороны даёт не плохой пример, что да как в коде не так.
Вы не правы, на самом деле люди считают что метод из 200 строк это нормально, он логически завершон. И класс с 500 методами это тоже нормально, ведь все методы относятся к этому классу непосредственно. Такая логика программистов встречается довольно таки часто, я такое слышал и видел даже от довольно таки опытных программистов.
Не со всем согласен с Вами на тему «Что такое плохой код знают все». Приведу пример:
К нам в контору пришел парень, хороший такой, много чего читал, неплохо разбирается в теории программирования, знает стандартные алгоритмы и паттерны, с опытом работы… Ну, в общем нормальный такой Junior. Но когда его взяли, начались грабли, описанные автором этой статьи. А иногда и хуже. Примеры давать не буду — запарно оформлять. Тут были простыни на 800 строк в методах типа onNeedDataSource(), и т.д.
Так вот. Выяснилось, что он, проработав 1.5 года в конторе, которая занималась Web-разработкой на .net не умеет писать по-другому. Почему? — а потому, что они там все так писали. Его так научили. Или не критиковали за это. И в релизы это входило. Но он-то не виноват в этом. Он просто никогда не видел нормальных проектов. И сейчас он радуется как ребёнок, когда у него получается писать красиво и аккуратно.
Я только хочу сказать, что для того, чтобы уметь писать нормальный код надо знать, что это такое. Надо его хотя бы раз увидеть и понять. Простой литературой тут не обойтись.
К нам в контору пришел парень, хороший такой, много чего читал, неплохо разбирается в теории программирования, знает стандартные алгоритмы и паттерны, с опытом работы… Ну, в общем нормальный такой Junior. Но когда его взяли, начались грабли, описанные автором этой статьи. А иногда и хуже. Примеры давать не буду — запарно оформлять. Тут были простыни на 800 строк в методах типа onNeedDataSource(), и т.д.
Так вот. Выяснилось, что он, проработав 1.5 года в конторе, которая занималась Web-разработкой на .net не умеет писать по-другому. Почему? — а потому, что они там все так писали. Его так научили. Или не критиковали за это. И в релизы это входило. Но он-то не виноват в этом. Он просто никогда не видел нормальных проектов. И сейчас он радуется как ребёнок, когда у него получается писать красиво и аккуратно.
Я только хочу сказать, что для того, чтобы уметь писать нормальный код надо знать, что это такое. Надо его хотя бы раз увидеть и понять. Простой литературой тут не обойтись.
А изящные и красивые (а посему единственно верные) решения нравятся всем и приносят удовлетворение от проделанной работы
К сожалению, многие не получают удовлетворение от изящного решения, а скорее от денег, которые можно получить за быстрое и работающее решение.
К сожалению, многие не получают удовлетворение от изящного решения, а скорее от денег, которые можно получить за быстрое и работающее решение.
Почему-то, зная программистов, не верится, что таких много. Обычно — это оправдание собственной лени и непрофессионализма ;).
С такими надо проводить душеспасительные беседы по поводу отношения к работе и приоритетов. Опять же, всё зависит от того, насколько решение реально работает и насколько его быстрота повлеяла на качество и, соответственно, лёгкость дальнейшего развития.
С такими надо проводить душеспасительные беседы по поводу отношения к работе и приоритетов. Опять же, всё зависит от того, насколько решение реально работает и насколько его быстрота повлеяла на качество и, соответственно, лёгкость дальнейшего развития.
Обычно это люди, которые выбирают профессию программиста ради большой ЗП.
Соответственно, обычно они не мотивированы к обучению вообще, и являются кодерами ниже среднего уровня. IMHO, таких людей надо увольнять. Объясняя при этом, что они пытаются заниматься не своим делом.
Соответственно, обычно они не мотивированы к обучению вообще, и являются кодерами ниже среднего уровня. IMHO, таких людей надо увольнять. Объясняя при этом, что они пытаются заниматься не своим делом.
«Как писать кошерный код, не приходя в сознание».
Если бы не было пункта 3, статью можно было бы назвать именно так.
Правило номер 0 — сначала думать, потом «гнать код». Спасает от всего остального, но это нанотехнология.
Если бы не было пункта 3, статью можно было бы назвать именно так.
Правило номер 0 — сначала думать, потом «гнать код». Спасает от всего остального, но это нанотехнология.
Думать — сложно, сами ж знаете… а вот 90% того что получается, как раз и есть «нанотехнология» :(
Когда начальство буквально стоит над душой со словами «это должно было работать вчера!!!», на правило номер 0 не остается времени. Тут, конечно, проблема менеджмента, который ставит неадекватные сроки и не особо спрашивает программистов, справятся ли они, но, в крупных компаниях, именно так рождаются тонны ужасного, непродуманного кода.
Не согласен с пунктом 2. Никогда не любил показывать незаконченную работу. Ревьюировать сразу перед коммитом или после него — это одно. А ревьюировать код, который разработчик ещё сам не просмотрел, — раздражает. Код много раз переделывается в процессе. И даже самые лучшие программисты в той или иной ситуации могут сначала написать некий убогий набросок, а потом уже причесать архитектуру.
4. и 5. — очень хорошие ходы ) учат думать.
Так получилось, что мне выдалась возможность руководить небольшой группой разработчиков. И, из этого опыта я вынес только одно, человеку нужно привить желание учиться, никакие ревизии кода группой или по отдельности, никакие переходы на личности не помогут, если у человека просто нет желания учиться
Статья хорошая. По поводу жесткости и ненависти не совем согласен. Адекватный человек с первого раза воспринимает замечания, если толково пояснить вашу мысль, а иногда даже и пояснять не надо. Главное рассказать критерии плохого кода команде, можно даже в формате tech-talk. Крайне желательно приводить в качестве примеров код сотрудников, который вы посчитали плохим и который они совсем недавно писали. На личности естественно переходить не надо. Человек (автор) сам увидит то, что вы хотели показать, и сделает выводы.
Кстати, в программе подготовки к SCJD описываются стандарты кодирования с разных точек зрения. Иногда попахивает клиникой, но почитать стоит.
Кстати, в программе подготовки к SCJD описываются стандарты кодирования с разных точек зрения. Иногда попахивает клиникой, но почитать стоит.
От слова «код» рябит в глазах. Если бы вы научили ваших подопечных программировать, а не «писать [хороший] код», то работа получилась бы более эффективной.
Бросаться «фабриками» и «декораторами» — это вообще слёзы. Подумать только, в 21 веке кто-то считает книжку Банды Четырех серебряной пулей программирования.
Бросаться «фабриками» и «декораторами» — это вообще слёзы. Подумать только, в 21 веке кто-то считает книжку Банды Четырех серебряной пулей программирования.
Второе логически вытекает из первого, а вот вторым без первого заниматься как-то бессмысленно. Пускай это отчасти жонглирование словами. Но если бы процесс написания книги именовался бы среди авторов «писанием букв (слов, предложений)», а исполнение произведений среди музыкантов — «игрой нот» или «давлением клавиш», это явно бы имело оттенок небрежности и халтуры. Написаный код — это побочный эффект деятельности программиста, и меня удивляет почему скалькированое с английского «писать код» стало популярнее слова «программировать». Не находите странным?
Серебрянные пули, как известно, все переплавили в бижутерию одновременно с танками. Но источники знаний остались те же: «Структура и интерпретация компьютерных программ» Абельсона и Сассмана, «Алгоритмы и структуры данных» Вирта. Можно Кнута для общего развития.
Серебрянные пули, как известно, все переплавили в бижутерию одновременно с танками. Но источники знаний остались те же: «Структура и интерпретация компьютерных программ» Абельсона и Сассмана, «Алгоритмы и структуры данных» Вирта. Можно Кнута для общего развития.
Не поверите… но и даже старика Брукса почитываем) Проблемы в сфере ИТ мало чем изменились с тех пор.
Вы путаете необходимое и достаточное условие. Я говорил, что хороший код необходим для успешного продукта, но нигде не говорил, что этого достаточно.
Хм. Интересно, где это написано, что я не учу людей программировать ;)? Если не верите — прочтите как минимум мою статью про «пластелиновую архитектуру», на которую ссылка в тексте есть. Там я как раз говорю о том, что без грамотной и обдуманной архитектуры любой код бессмысленен.
По поводу пули: Если вы внимательно читали главы Брукса, дописанные в 1995, как ответ самому себе на те мысли, то должны были увидеть, что ООП называется наиболее серьёзным прорывом за последние 25 лет. Но, конечно же, серебрянной пули всё так же нет.
Хм. Интересно, где это написано, что я не учу людей программировать ;)? Если не верите — прочтите как минимум мою статью про «пластелиновую архитектуру», на которую ссылка в тексте есть. Там я как раз говорю о том, что без грамотной и обдуманной архитектуры любой код бессмысленен.
По поводу пули: Если вы внимательно читали главы Брукса, дописанные в 1995, как ответ самому себе на те мысли, то должны были увидеть, что ООП называется наиболее серьёзным прорывом за последние 25 лет. Но, конечно же, серебрянной пули всё так же нет.
«хороший код необходим для успешного продукта»
это неверно. продукт может быть успешным и с ужасной архитектурой и плохим кодом. и таких случаев большинство.
это неверно. продукт может быть успешным и с ужасной архитектурой и плохим кодом. и таких случаев большинство.
Да. Поленился я расписывать конкретику, а зря :). Имеется в виду продукт, который будет расширяться, над которым будут работать несколько человек. Продукт, к команде которого можно без особого труда добавить ещё программистов, чтобы развитие шло ещё скорее и активнее. Ну и много чего ещё к характеристикам такого продукта можно добавить, что без хорошего кода не выйдет.
Если эти характеристики не играют ключевого значения, проект «одноразовый» и поддерживаться вряд ли будет, а основная его цель — «срубить денег сейчас», то, конечно, всё, что я говорю, к нему не применимо.
Если эти характеристики не играют ключевого значения, проект «одноразовый» и поддерживаться вряд ли будет, а основная его цель — «срубить денег сейчас», то, конечно, всё, что я говорю, к нему не применимо.
Вы снова пытаетесь разделить всё на «хорошо» и «плохо», на «одноразовый продукт» и «продукт который будет расширяться и поддерживаться».
«Продукт который будет расширяться и поддерживаться» так же может иметь плохую архитектуру и плохой код и быть при этом вполне финансово успешным.
Да и стратегия «сговнять абы как(но без явных багов) лишь бы быстрей запустить» а потом ЕСЛИ деньги пойдут — выкинуть и переписать по уму с учётом новых реалий — иногда оказывается более правильной, чем «долго-долго» и [возможно] правильно что-то писать, а потом запуститься и не суметь «продать» (а такое часто бывает. люди ведь ошибаются в оценках)
«Продукт который будет расширяться и поддерживаться» так же может иметь плохую архитектуру и плохой код и быть при этом вполне финансово успешным.
Да и стратегия «сговнять абы как(но без явных багов) лишь бы быстрей запустить» а потом ЕСЛИ деньги пойдут — выкинуть и переписать по уму с учётом новых реалий — иногда оказывается более правильной, чем «долго-долго» и [возможно] правильно что-то писать, а потом запуститься и не суметь «продать» (а такое часто бывает. люди ведь ошибаются в оценках)
«выкинуть и переписать по уму с учётом новых реалий» обычно не бывает :). Ну вообще, конечно, как всегда — всё очень зависит от конкретной ситуации.
Согласен. Яркий пример — Facebook. Написать на PHP, потом упереться в скорость его работы, написать транслятор с PHP на C++, куски кода провернуть через этот транслятор.
А придите на любой форум где знатоки обсуждают проблемы нагруженных сайтов. И предложите кому нибудь написать транслятор PHP -> C++. Смешают с гавном тут же.
А придите на любой форум где знатоки обсуждают проблемы нагруженных сайтов. И предложите кому нибудь написать транслятор PHP -> C++. Смешают с гавном тут же.
Не, ну это же классика кун-фу:
Сначала ты не знаешь, что нельзя делать то-то
Потом знаешь, что нельзя делать то-то
Потом ты понимаешь, что иногда таки можно делать то-то
Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
Когда тебя спрашивают «как мне добиться желаемого», ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: «вообще-то, главное — гармония.»
На вопрос обиженных учеников: «а как ее добиться?», ты говоришь: «никогда не делайте то-то».
Классика кун-фу от RSDN
Сначала ты не знаешь, что нельзя делать то-то
Потом знаешь, что нельзя делать то-то
Потом ты понимаешь, что иногда таки можно делать то-то
Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
Когда тебя спрашивают «как мне добиться желаемого», ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: «вообще-то, главное — гармония.»
На вопрос обиженных учеников: «а как ее добиться?», ты говоришь: «никогда не делайте то-то».
Классика кун-фу от RSDN
Видел эту зарисовку сотню раз, но так и не смог ее понять :(. Как из пункта три ( «Потом ты понимаешь, что иногда таки можно делать то-то», например «потом ты понимаешь, что иногда таки можно использовать goto») осуществляется переход к пункту четыре ( «Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.» — это что, человек неожиданно нашел еще шестьдесят шесть способов выстрелить себе в ногу, осознал что они не просто так появились, что есть редкие случае когда они применимы, и это для него «желаемое»? У мастера что, желание стрелять себе в ногу? O_O). Может кто из гуру кун-фу пояснит старику? ^_^
Переход от каждого пункта к следующему приходит с опытом. Хорошо применяется эта классика к сравнию чисел с правающей точкой.
1.Сначала ты не знаешь, что нельзя сравнивать числа с плавающей точкой при помощи операци = или !=
2.Потом знаешь, что нельзя сравнивать числа через = или !=, а надо использовать функцию Equals и задвать точность сравнения.
3.Потом ты понимаешь, что иногда таки можно сравнивать числа при помощи операций = или !=
4.Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться сравнения чисел, и все из них практически равноправны.
5.Когда тебя спрашивают «сравнить числа с плавающей точкой», ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: «вообще-то, главное — гармония.»
На вопрос обиженных учеников: «а как ее добиться?», ты говоришь: «никогда не сравнивайте числа с плавающей точкой через операцию = или !=».
1.Сначала ты не знаешь, что нельзя сравнивать числа с плавающей точкой при помощи операци = или !=
2.Потом знаешь, что нельзя сравнивать числа через = или !=, а надо использовать функцию Equals и задвать точность сравнения.
3.Потом ты понимаешь, что иногда таки можно сравнивать числа при помощи операций = или !=
4.Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться сравнения чисел, и все из них практически равноправны.
5.Когда тебя спрашивают «сравнить числа с плавающей точкой», ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: «вообще-то, главное — гармония.»
На вопрос обиженных учеников: «а как ее добиться?», ты говоришь: «никогда не сравнивайте числа с плавающей точкой через операцию = или !=».
1. НЕНАВИСЬ!!!
…
…
n. Profit!
…
…
n. Profit!
Мне в свое время понимать плохо/хорошо помогла книга Code Complete Стива МакКоннела. За статью-спасибо =)
Нам Review Board помог резко улучшить качество и единообразность кода.
Почему во всех статьях ненависть в Switch Case?
Если вижу в коде кучу if else if else меняю на switch и ещё никто не сказал, что плохо выглядит. С дефолтной подсветкой в зенде, очень даже читабельно.
Если вижу в коде кучу if else if else меняю на switch и ещё никто не сказал, что плохо выглядит. С дефолтной подсветкой в зенде, очень даже читабельно.
Попробую пояснить: switch / case наиболее удобная структура, чтобы разруливать бизнес-логику программы, причём самым поганым образом. Например: один метод отвечает за всё. Этому методу передаётся параметр, и есть десять-двадцать кейсов, которые, в зависимости от этого параметра, выполняют совершенно разные задачи, абсолютно не связанные между собой.
Дополню. Временами получается так, что этот параметр или аналогичный ему передается в несколько функций, исполняемых последовательно, и в каждой имеется switch-case/if-elsif или что-то подобное. Обычно это признак неправильной разбивки (вернее неразбивки) на классы, и лечится достаточно очевидным образом — в зависимости от константы выбирается класс или берется экземпляр этого класса, и у него последовательно дергаются методы с кодом, аналогичным соответствующей ветки switch. К сожалению, это не всегда просто на практике, т.к. корни проблемы могут расти из аналогичной шняги уровнем ниже, и т.д. — по моему опыту, такой код часто является лишь следствием того, что неправильно сделано все остальное :)
Дисклеймер: ничего не имею против switch, если применять его по назначению
Дисклеймер: ничего не имею против switch, если применять его по назначению
«ненависть» — всё же думаю литературный приём.
Проблема с switch/портянкой ifов в том что там часто бывает заложена логика предметной области. И Когда таких случаев накапливается много — такой метод становится большим => его сложно понимать и поддерживать для него unit-test.
Решения можете погуглить (или посмотреть в книге фаулера про рефакторинг): замена условного оператора полиморфизмом (в туже куча — замена состоянием/стратегией)
Проблема с switch/портянкой ifов в том что там часто бывает заложена логика предметной области. И Когда таких случаев накапливается много — такой метод становится большим => его сложно понимать и поддерживать для него unit-test.
Решения можете погуглить (или посмотреть в книге фаулера про рефакторинг): замена условного оператора полиморфизмом (в туже куча — замена состоянием/стратегией)
Например, в Java после добавления полноценных Enum'ов надобность в switch остается разве что при работе с внешним интерфейсом по кодам или при парсинге. И даже в этих случаях Enum может быть элегантнее switch'а.
Позитивная статья. Пара замечаний.
Нулевым пунктом для такого новоявленного руководителя я бы добавил ТАКТИЧНОСТЬ.
Уверен каждый сталкивался с ситуацией, когда разработчик упорно защищает своё решение, отвергая аргументы и используя какие-то «крайние» случаи в качестве мотивации своего решения. И часто подобные разговоры заканчивают применением административного ресурса.
А происходит это зачастую вот почему (считаем что разработчик вполне адекватен): вы вербально/паравербально/невербально высказали свою суждение которое звучит примерно как «Вася ты идиот» и иногда ещё «а я умный». В такой ситуации Вася ествественно начинает защищать своё решение + иногда переходит в атаку. Как итог — потери времени, ухудшение отношений.
Поверьте, закатавание глаз, характерное приоткрыванеи рта с цокающим звуком, поднятие брови, разведение рук, качание головой, и некоторые микромимические жесты — всё это способно за пол секунды донести до Васи вашу мысль о том, что «вам очень жаль что Вася такой дебил, вы глубоко скорбите а том, что компания наняла такого идиота и вам бесконечно жаль что приходится тратить время на таких идиотов». Ни о каком конструктивном общении после этого не может быть и речи.
Кстати «Объясните ребятам» — формулировка которая тоже возвышает новоявленного руководителя и принижает опыт «ребят». Лучше общаться не с «ребятами» а с «коллегами».
Автор исходит из того, что новоявленному руководителю лучше знать как должен выглядеть «хороший код» и «хорошая архитектура» и что организация готова это всё оплачивать (что бывает ой как не всегда).
Проблема в том что «все ошибаются». И наш новоявленный руководитель скорей всего тоже. Это не «громкие слова». Посмотрите: В гугле регулярно «что-то» происходит, в яндексе какие-то проблемы, в твиттере, взгляните на эволюции API java, на протокол X. Люди, более квалифицированные чем наш новоиспеченный руководитель постоянно допускают ошибки.
Поэтому вместо навязывания (что будет встречено сопротивлением), лучше показать альтернативное решение, и тактично УБЕДИТЬ человека в том что так лучше(приводя доводы, а не пытаясь давить на человека или использовать административный ресурс). Может так статься что и «не лучше» (почти всегда есть грань, за которой фанатичное следование некоторым правилам уже не приносит пользы, а время тратит, но фанатики могут её не видеть)
«НЕНАВИСТЬ» — хочется надеятся, что это слово вы использовали лишь для «крассногослофца».
«Собирайтесь всей командой раз в неделю, и пусть кто-нибудь ищет в коде грязь и антипаттерны.» — для этого удобно бывает использовать инструменты которые собирают метрики и строят красивые графики (например Sonar ). Начать можно с размера класса, размеров методов, количества методов, поиска копипаста и наличие циклических зависимостей.
Про «паттерны». Раньше я тоже думал что очень хорошо чтобы разработчики знали эти самые паттерны. А вот в последнее время, если честно, всё больше и больше начинаю сомневаться.
Дело в том, что когда мы проектируем «с оглядкой на» DI,SERP, и некоторые другие столь же очевидные вещи, то практически весь букет структурных и порождающих паттернов вырисовывается «сам собой». Получается что нет особой необходимости в том, чтобы лишний раз подчеркнуть «а вот здесь у нас будет использован паттерн Proxy» + когда мы отталкиваемся от паттернов, а не от того что нам нужно сделать — у меня складывается ощущение, что мы ставим телегу впереди лошади.
Нулевым пунктом для такого новоявленного руководителя я бы добавил ТАКТИЧНОСТЬ.
Уверен каждый сталкивался с ситуацией, когда разработчик упорно защищает своё решение, отвергая аргументы и используя какие-то «крайние» случаи в качестве мотивации своего решения. И часто подобные разговоры заканчивают применением административного ресурса.
А происходит это зачастую вот почему (считаем что разработчик вполне адекватен): вы вербально/паравербально/невербально высказали свою суждение которое звучит примерно как «Вася ты идиот» и иногда ещё «а я умный». В такой ситуации Вася ествественно начинает защищать своё решение + иногда переходит в атаку. Как итог — потери времени, ухудшение отношений.
Поверьте, закатавание глаз, характерное приоткрыванеи рта с цокающим звуком, поднятие брови, разведение рук, качание головой, и некоторые микромимические жесты — всё это способно за пол секунды донести до Васи вашу мысль о том, что «вам очень жаль что Вася такой дебил, вы глубоко скорбите а том, что компания наняла такого идиота и вам бесконечно жаль что приходится тратить время на таких идиотов». Ни о каком конструктивном общении после этого не может быть и речи.
Кстати «Объясните ребятам» — формулировка которая тоже возвышает новоявленного руководителя и принижает опыт «ребят». Лучше общаться не с «ребятами» а с «коллегами».
Автор исходит из того, что новоявленному руководителю лучше знать как должен выглядеть «хороший код» и «хорошая архитектура» и что организация готова это всё оплачивать (что бывает ой как не всегда).
Проблема в том что «все ошибаются». И наш новоявленный руководитель скорей всего тоже. Это не «громкие слова». Посмотрите: В гугле регулярно «что-то» происходит, в яндексе какие-то проблемы, в твиттере, взгляните на эволюции API java, на протокол X. Люди, более квалифицированные чем наш новоиспеченный руководитель постоянно допускают ошибки.
Поэтому вместо навязывания (что будет встречено сопротивлением), лучше показать альтернативное решение, и тактично УБЕДИТЬ человека в том что так лучше(приводя доводы, а не пытаясь давить на человека или использовать административный ресурс). Может так статься что и «не лучше» (почти всегда есть грань, за которой фанатичное следование некоторым правилам уже не приносит пользы, а время тратит, но фанатики могут её не видеть)
«НЕНАВИСТЬ» — хочется надеятся, что это слово вы использовали лишь для «крассногослофца».
«Собирайтесь всей командой раз в неделю, и пусть кто-нибудь ищет в коде грязь и антипаттерны.» — для этого удобно бывает использовать инструменты которые собирают метрики и строят красивые графики (например Sonar ). Начать можно с размера класса, размеров методов, количества методов, поиска копипаста и наличие циклических зависимостей.
Про «паттерны». Раньше я тоже думал что очень хорошо чтобы разработчики знали эти самые паттерны. А вот в последнее время, если честно, всё больше и больше начинаю сомневаться.
Дело в том, что когда мы проектируем «с оглядкой на» DI,SERP, и некоторые другие столь же очевидные вещи, то практически весь букет структурных и порождающих паттернов вырисовывается «сам собой». Получается что нет особой необходимости в том, чтобы лишний раз подчеркнуть «а вот здесь у нас будет использован паттерн Proxy» + когда мы отталкиваемся от паттернов, а не от того что нам нужно сделать — у меня складывается ощущение, что мы ставим телегу впереди лошади.
Про тактичность согласен на 100%. И соглашусь, что местами бываю не слишком тактичен. Но это, в принципе, работает. Главное — адекватность.
Ну а про доводы и административный ресурс — это философия :). Как всегда, через полчаса понимаешь, что втянулся в пустую дискуссию и, если её не прекратить сейчас, то потратится куча времени «ни о чём». Опять же, всё зависит от конкретного человека. Если студент-выпускник, ещё не нюхавший пороху, пытается переубедить человека с десятилетним стажем в чём-то очевидном… Тяжело тут без административного ресурса, ой тяжело.
Ну а про доводы и административный ресурс — это философия :). Как всегда, через полчаса понимаешь, что втянулся в пустую дискуссию и, если её не прекратить сейчас, то потратится куча времени «ни о чём». Опять же, всё зависит от конкретного человека. Если студент-выпускник, ещё не нюхавший пороху, пытается переубедить человека с десятилетним стажем в чём-то очевидном… Тяжело тут без административного ресурса, ой тяжело.
про пустые рабочие дискуссии — я всё же более чем уверен, что в большинстве случаев причиной этому становится именно бестактность, которая ведёт к тому что один из участников обсуждения начинает упорствовать, лишь бы доказать что он «не верблюд». Если есть несколько решений, прозрачные требования и у каждого из решений есть свои плюсы и минусы — то выбрать лучшее достаточно просто, если при этом авторы «других» решений не чувствуют себя идиотами.
«Но это, в принципе, работает»
Вы наверно хотели сказать «пока вроде бы срабатывало»?)
В туже кучу что и «административный ресурс» и «философия»: вы размышляли над тем почему разработчики работают, почему они работают хорошо или спустя рукава, почему они работают именно здесь хотя могли бы работать в тысячах других таких же «средних проектах ниочём»?
«Но это, в принципе, работает»
Вы наверно хотели сказать «пока вроде бы срабатывало»?)
В туже кучу что и «административный ресурс» и «философия»: вы размышляли над тем почему разработчики работают, почему они работают хорошо или спустя рукава, почему они работают именно здесь хотя могли бы работать в тысячах других таких же «средних проектах ниочём»?
К сожалению, есть люди, которые думают, что стаж в кодах конвертируется в скилы / знания / опыт как 1:1.
))))) заговорился
SERP — ЧИТАТЬ КАК SRP
SERP — ЧИТАТЬ КАК SRP
«с заказчиком»
Заказчику обычно всё-равно. Он этот птичий язык не знает и знать не хочет.
«внутри команды»
Иногда возможно. Но как я уже говорил — от фраз подобных «а вот здесь мы используем паттерн Цепочка Обязанностей» — у меня стойкое ощущение что телега ставится впереди лошади. И это не говоря уже о том, что люди часто по разному понимают смысл одних и тех же паттернов (так например когда люди говорят что у них архитектура на основе MVC — часто можно обнаружить, что никакой «M» у них там вовсе нет). Для общения внутри команды на мой взгляд намного полезней когда все участники могут свободно «писать» используя какбэUMLные нотации.
Заказчику обычно всё-равно. Он этот птичий язык не знает и знать не хочет.
«внутри команды»
Иногда возможно. Но как я уже говорил — от фраз подобных «а вот здесь мы используем паттерн Цепочка Обязанностей» — у меня стойкое ощущение что телега ставится впереди лошади. И это не говоря уже о том, что люди часто по разному понимают смысл одних и тех же паттернов (так например когда люди говорят что у них архитектура на основе MVC — часто можно обнаружить, что никакой «M» у них там вовсе нет). Для общения внутри команды на мой взгляд намного полезней когда все участники могут свободно «писать» используя какбэUMLные нотации.
Просто использовать устоявшиеся названия паттернов проще, чем объяснять решение на пальцах. Да и слыша такое модель сразу в голове выстраивается, все дальнейшее изложение становится лишним.
Если же каждый раз объяснять детально, тратится довольно много времени, плюс есть риск что-то забыть.
P.S. А вот в случае, когда говорят об MVC, а по факту модели-то там и нет — это уже необразованность вида «слышу звон, не знаю, где он». Здесь необходимо проводить просвещение. Все паттерны имеют строго заданную структуру и поведение, поэтому любое отклонение должно быть явно озвучено.
Если же каждый раз объяснять детально, тратится довольно много времени, плюс есть риск что-то забыть.
P.S. А вот в случае, когда говорят об MVC, а по факту модели-то там и нет — это уже необразованность вида «слышу звон, не знаю, где он». Здесь необходимо проводить просвещение. Все паттерны имеют строго заданную структуру и поведение, поэтому любое отклонение должно быть явно озвучено.
Подумал ещё немного на эту тему. Возможно использование названий паттернов будет давать пользу при передачи задания от «старшего» к «младшему» в коллективах «я начальник, ты — дурак». Ну т.е. когда даётся явное указание как надо сделать конкретную вещь — то действительно проще сказать «реализуй здесь „мост“». Если же начинается обсуждение вариантов — то выйгрыш сходит на нет — начинается разрисоывавание вараинтов и «компактность» «сделай здесь мост» — пропадает.
Вы как-то упустили момент, что руководителю авторитет сначала надо заработать. Если начинать с озалупливания годами выстраданного командой кода — столкнетесь с мощнейшим противодействием. И потом, разломать, как известно, проще чем построить.
Второй момент — лишь вкратце упомянуто про проседание «текущих финансовых показателей», а ведь это основное препятствие к рефакторингу старых проектов. Ни один топ-менеджер не даст вам карт-бланш на пару лет. Будут с тоской вспоминать ушедшего руководителя, говоря «пусть глючило, зато продавалось»
Третий момент — сам не раз сталкивался с программерами, сыплящими названиями паттернов направо и налево. А стоит заглянуть в код и видишь: тут красиво, ООП, все дела, а вот в этот угол стыдливо припрятали все то, что не вписалось в красивую паттернированную архитектуру. И чем дальше — тем больше таких помоек в коде, как ни странно. Настоящие гуру порой и не знают этих ваших «декораторов» и «синглтонов», однако применяют их интуитивно и не задумываясь.
Четыре. Ревью доверьте самой команде. Один пишет, другой проверяет. Роли перемешиваются на разных задачах среди команды. Вариантов хорошего решения задач не так много, а вот варианты развесистой лапши практически бесконечны, и если ее не видит один говнокодер — увидит другой. вместе придут к более правильному решению. Ну а вы проконтролируете незаметно.
Пять, на последок. Тут вот все исходят из адекватности и профессионализма сотрудников. Смелое допущение. Выявите главных аутсайдеров. Если надежда есть — развивайте их. Если нет — до свидания.
Второй момент — лишь вкратце упомянуто про проседание «текущих финансовых показателей», а ведь это основное препятствие к рефакторингу старых проектов. Ни один топ-менеджер не даст вам карт-бланш на пару лет. Будут с тоской вспоминать ушедшего руководителя, говоря «пусть глючило, зато продавалось»
Третий момент — сам не раз сталкивался с программерами, сыплящими названиями паттернов направо и налево. А стоит заглянуть в код и видишь: тут красиво, ООП, все дела, а вот в этот угол стыдливо припрятали все то, что не вписалось в красивую паттернированную архитектуру. И чем дальше — тем больше таких помоек в коде, как ни странно. Настоящие гуру порой и не знают этих ваших «декораторов» и «синглтонов», однако применяют их интуитивно и не задумываясь.
Четыре. Ревью доверьте самой команде. Один пишет, другой проверяет. Роли перемешиваются на разных задачах среди команды. Вариантов хорошего решения задач не так много, а вот варианты развесистой лапши практически бесконечны, и если ее не видит один говнокодер — увидит другой. вместе придут к более правильному решению. Ну а вы проконтролируете незаметно.
Пять, на последок. Тут вот все исходят из адекватности и профессионализма сотрудников. Смелое допущение. Выявите главных аутсайдеров. Если надежда есть — развивайте их. Если нет — до свидания.
Самая большая беда конечно с пунктом 2. Это когда все понимают, что проект доведен до ахтунгового состояния, но манагеры продолжают гнать фичи, потому что иначе проект быстро уходит в минус. А рефакторинг до какого-то этапа еще и кол-во глюков будет увеличивать, тестов-то (скорее всего) у нас нетуть…
По поводу первого — хорошим вопросом к команде может быть вопрос в стиле «Вы хорошо знаете проект. Как вы сами-то думаете, какие есть у него недостатки технического плана, и что мы могли бы улучшить?». Если команда состоит из хороших специалистов, которые вынуждены херачить в силу пункта 2 или плохой наследственности проекта, они сами все расскажут, и останется лишь соглашаться :) А вот если нет… тут, боюсь, универсального совета быть не может.
С третьим моментом соглашусь двумя руками. Было очень диковинно читать первый раз про паттерны — оказывается, мы половину из них придумали сами, решая свои задачи, а большая часть остальных нам не нужна в силу того, что решаемые ими проблемы отсутствуют в языке разработки. Подозреваю, что подвести новичков от программирования к паттернам таким вот «естественным путем» было бы интересным опытом.
По поводу первого — хорошим вопросом к команде может быть вопрос в стиле «Вы хорошо знаете проект. Как вы сами-то думаете, какие есть у него недостатки технического плана, и что мы могли бы улучшить?». Если команда состоит из хороших специалистов, которые вынуждены херачить в силу пункта 2 или плохой наследственности проекта, они сами все расскажут, и останется лишь соглашаться :) А вот если нет… тут, боюсь, универсального совета быть не может.
С третьим моментом соглашусь двумя руками. Было очень диковинно читать первый раз про паттерны — оказывается, мы половину из них придумали сами, решая свои задачи, а большая часть остальных нам не нужна в силу того, что решаемые ими проблемы отсутствуют в языке разработки. Подозреваю, что подвести новичков от программирования к паттернам таким вот «естественным путем» было бы интересным опытом.
Если честно, то паттерны открывают новые абстракции, которые можно комбинировать между собой и с уже имеющимся опытом. Без опыта работы изучение паттернов скорее вредно, чем полезно.
А вообще не изучать паттерны — тоже плохо, т.к. самому приходится долго искать подобное решение. Помню, до чтения паттернов я как-то изобрел «Фабричный метод». И ушло у меня на это часа 4.
А вообще не изучать паттерны — тоже плохо, т.к. самому приходится долго искать подобное решение. Помню, до чтения паттернов я как-то изобрел «Фабричный метод». И ушло у меня на это часа 4.
2 года руковожу небольшой группой. Ремарки:
— «покажите», «заразите», «объясните»… — это работает только для поддающихся внушению и готовых изменятся, некоторых вы просто сотрясанием воздуха с места не сдвините
— не нужно учить паттернам (читай — фактам), человек должен ДУМАТЬ САМ, и он в процессе переизобретёт ваши паттерны
— не нужно сидеть и ревьювить код (против стилевого анализатора ничего против не имею) — нужно правильно давать правильные задания и следить за их реализацией по ходу работы. И вообще зачем нужен такой программист, после которого нужно потратить тонну времени на ревью, исправление, переревью… — так лучше пусть уж руководитель пишет, сэкономиться время/деньги. По сути это проблема — следствие невыполнения следующего пункта.
— нужно разделять кодера и разработчика. Архитектурой должно заниматься ограниченное количество профессионалов. Кодеру должно быть дано достаточно детальное задание, желательно со структурой классов, диаграммой состояний и т.д. Тогда и результат будет предсказуем. У нас вообще не любят планировать и разрабатывать, у нас принято сразу реализовывать, а потом героически бороться с результатом.
— человек — существо ленивое и хитрое и всегда будет использовать возможность работать по-меньше и по-хуже если это допустимо. В конце концов это бизнес, а людей способных работать на идею немного. Поэтому организация и мотивация труда должна быть на высоте. И не требуйте от людей того, чего сами не делаете!
— «покажите», «заразите», «объясните»… — это работает только для поддающихся внушению и готовых изменятся, некоторых вы просто сотрясанием воздуха с места не сдвините
— не нужно учить паттернам (читай — фактам), человек должен ДУМАТЬ САМ, и он в процессе переизобретёт ваши паттерны
— не нужно сидеть и ревьювить код (против стилевого анализатора ничего против не имею) — нужно правильно давать правильные задания и следить за их реализацией по ходу работы. И вообще зачем нужен такой программист, после которого нужно потратить тонну времени на ревью, исправление, переревью… — так лучше пусть уж руководитель пишет, сэкономиться время/деньги. По сути это проблема — следствие невыполнения следующего пункта.
— нужно разделять кодера и разработчика. Архитектурой должно заниматься ограниченное количество профессионалов. Кодеру должно быть дано достаточно детальное задание, желательно со структурой классов, диаграммой состояний и т.д. Тогда и результат будет предсказуем. У нас вообще не любят планировать и разрабатывать, у нас принято сразу реализовывать, а потом героически бороться с результатом.
— человек — существо ленивое и хитрое и всегда будет использовать возможность работать по-меньше и по-хуже если это допустимо. В конце концов это бизнес, а людей способных работать на идею немного. Поэтому организация и мотивация труда должна быть на высоте. И не требуйте от людей того, чего сами не делаете!
— не нужно сидеть и ревьювить код (против стилевого анализатора ничего против не имею) — нужно правильно давать правильные задания и следить за их реализацией по ходу работы. И вообще зачем нужен такой программист, после которого нужно потратить тонну времени на ревью, исправление, переревью… — так лучше пусть уж руководитель пишет, сэкономиться время/деньги. По сути это проблема — следствие невыполнения следующего пункта.
Такой программист нужен, потому что других на рынке труда ничтожно мало. Да, найти можно — но код подавляющего большинства ревьювить надо. И если в команде больше 2-3 человек то вопрос «а насколько быстро мы сможем найти замену Васе, если его переедет каток?» встает достаточно остро, потому как текучку никто не отменял. Вот и приходится работать не с идеальными программистами, а с теми кто есть на рынке и кто впишется в бюджет О_О.
Архитектурой должно заниматься ограниченное количество профессионалов. Кодеру должно быть дано достаточно детальное задание, желательно со структурой классов, диаграммой состояний и т.д.
Увы, на практике настолько подробная детализация занимает столько же времени, сколько само кодирование. Для большинства прикладных задач такой подход малоприменим. Вот если автоматизацию бизнеса по шаблону штамповать — тада да :).
человек — существо ленивое и хитрое и всегда будет использовать возможность работать по-меньше и по-хуже если это допустимо.
Под этим подпишусь. Именно поэтому мыши плакали, кололись но продолжали ревьювить :)
Раньше тоже думали что ревью нам не нужно. Потом стали применять — эффект ощутимый. Количество заворачиваемых тестировщиками задачи снизилось процентов на 30.
Даже гуру периодически допускают ляпы. Если дробить задачи помельче — то ревью занимает минуты.
Что касается разделения программистов и кодеров — это позволительно, если команда достаточно большая. Если три-пять человек, то эффект обратный будет. А больше 7 человек, как говорят психологи, уже плохо управляемая группа.
В маленькой команде задачи распределяются по уровню продвинутости разработчика.
в остальном согласен
Даже гуру периодически допускают ляпы. Если дробить задачи помельче — то ревью занимает минуты.
Что касается разделения программистов и кодеров — это позволительно, если команда достаточно большая. Если три-пять человек, то эффект обратный будет. А больше 7 человек, как говорят психологи, уже плохо управляемая группа.
В маленькой команде задачи распределяются по уровню продвинутости разработчика.
в остальном согласен
Ревью кода себя окупает, и быстро начинает приносить прибыль.
Лишь малая часть этой прибыли — улучшение того кода, для которого проводится ревью.
Чуть большая часть — это уменьшение подобных ошибок у всех, кто участвовал в разборе.
И, наконец, самая ощутимая часть — то, что разработчики начинают внимательнее относиться к коду, и начинают находить не только рассмотренные ошибки, а также и другие проблемные места. А повышение квалификации разработчиков сильно влияет на качество проекта в перспективе.
Лишь малая часть этой прибыли — улучшение того кода, для которого проводится ревью.
Чуть большая часть — это уменьшение подобных ошибок у всех, кто участвовал в разборе.
И, наконец, самая ощутимая часть — то, что разработчики начинают внимательнее относиться к коду, и начинают находить не только рассмотренные ошибки, а также и другие проблемные места. А повышение квалификации разработчиков сильно влияет на качество проекта в перспективе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководитель проекта: три шага команды к совершенному коду