Comments 72
>«бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Не согласен. Вот есть у нас функция на 10 экранов. Логично было бы ее разбить на куски, которые делают что-то похожее. Пусть даже эти функции больше никто нигде не вызовет, но код в целом станет более понятный.
Вопросы про то, можно ли использовать else, return true и т.п. напомнили мне вопросы на quora.com, там тоже частенько спрашивают такую чушь. Ребята, пишите так, как вам удобно, главное чтобы ваши коллеги поняли код. Не нужно загонять себя в рамки только потому что вы где-то прочитали, что «хорошие программисты не используют else».
Не согласен. Вот есть у нас функция на 10 экранов. Логично было бы ее разбить на куски, которые делают что-то похожее. Пусть даже эти функции больше никто нигде не вызовет, но код в целом станет более понятный.
Вопросы про то, можно ли использовать else, return true и т.п. напомнили мне вопросы на quora.com, там тоже частенько спрашивают такую чушь. Ребята, пишите так, как вам удобно, главное чтобы ваши коллеги поняли код. Не нужно загонять себя в рамки только потому что вы где-то прочитали, что «хорошие программисты не используют else».
Нужно код упрощать, а не искусственно плодить функции (уменьшать экраны). Купите себе больший монитор.
Как их потом называть такие функции?
doSmth[1-N]()? doOneandTwo()? authAndPrind()? :)
Передавать в них 100500 параметров или использовать ООП, а потом ломать голову, где же еще используется член класса?
Как их потом называть такие функции?
doSmth[1-N]()? doOneandTwo()? authAndPrind()? :)
Передавать в них 100500 параметров или использовать ООП, а потом ломать голову, где же еще используется член класса?
Дело не в размере монитора, а в количестве информации, которую может усвоить человек. Гораздо проще разобраться в функции на несколько строк, а не на несколько сотен.
Есть такое понятие, как Кошелек Миллера. Человек может одновременно держать в голове от 5 до 9 объектов. Иногда приходится писать длинные функции, и лучше разбить ее на некоторые логические куски, которые будут «разгружать» внимание.
Те, кого менеджеры считают хорошим программистом и те, кого программисты считают хорошим программистом это часто разные люди. Вот прекрасный пример.
Если коротко, то человек написал в машинных кодах блек джек, в который давали поиграть клиентам, чтобы продемонстрировать технику и заключить сделку. И он написал крайне быстрый код.
Потом его попросили модифицировать код так, чтобы клиент чаще выигрывал. Он решил, что это нечестно и написал код из-за которого клиент начал проигрывать.
Когда у него потребовали всё исправить — послал менеджмент к лешему и увоилился. Человек, которого попросили прогнуть код под клиента провел очень много времени разбирая машинные коды и поражаясь глубине технического гения предшественника. В конце концов он всё-таки понял, как написана программа.
Но, из уважения к создателю, сказал менеджменту, что поправить ничего нельзя, так как он не способен понять код.
И это пример того, каким с его точки зрения должен быть идеальный программист.
Это не программист, а любитель программирования.
А программист — это тот кто китайский файрвол делает?
Программист — это тот, кто решает поставленную профессиональную задачу.
Самоуважение тоже должно быть. Кто-то решает поставленную задачу по «скрутке» или «накрутке» голосов на РОИ. И да, они тоже программисты. Но уважать таких людей?
Лично я бы не брал на работу человека, тараканы в голове которого мешают выполнению служебных обязанностей. Типа, ему вдруг не нравится, что клиенты получают десяток цветных пикселей на экране за победу. А в данном случае ещё и пишет несопровождаемый код.
Пусть он владеет инструментом разработки хоть как бог, но профессионализм заключается, кроме прочего, в способности при необходимости сжать зубы и сделать неприятную работу.
Пусть он владеет инструментом разработки хоть как бог, но профессионализм заключается, кроме прочего, в способности при необходимости сжать зубы и сделать неприятную работу.
Вы хотите сказать, что профессионализм заключается в способности при необходимости сжать зубы и совершить преступление?
«Неприятная работа» — это сутки-двое дебага с целью найти один хитрый SEGFAULT.
То, о чем здесь идет речь — это моральная дилемма.
Человек, имеющий принципы (к слову сказать, никак не связанные с его профессиональной деятельностью), не станет портить свою репутацию и становиться противен самому себе, делая то, что противоречит этим принципам.
Это касается не только программистов, а любых специалистов вообще.
И если бы все крутые специалисты были такими, как этот парень (надеюсь, что история — не чистой воды легенда), то у террористов было бы меньше оружия и хакеры не взламывали бы хорошие, годные сайты.
Нравственность можно отменить. Но результат для общества бывает плачевным.
Добрый совет. Не берите на работу людей, которые готовы совершить любую мерзость просто при наличии задачи от менеджера. Потому что эти люди, например, могут осуществить промышленный шпионаж. Или что-то еще, что им выгодно. А на вас им наплевать, как и на ваших заказчиков/клиентов и т.д…
То, о чем здесь идет речь — это моральная дилемма.
Человек, имеющий принципы (к слову сказать, никак не связанные с его профессиональной деятельностью), не станет портить свою репутацию и становиться противен самому себе, делая то, что противоречит этим принципам.
Это касается не только программистов, а любых специалистов вообще.
И если бы все крутые специалисты были такими, как этот парень (надеюсь, что история — не чистой воды легенда), то у террористов было бы меньше оружия и хакеры не взламывали бы хорошие, годные сайты.
Нравственность можно отменить. Но результат для общества бывает плачевным.
Добрый совет. Не берите на работу людей, которые готовы совершить любую мерзость просто при наличии задачи от менеджера. Потому что эти люди, например, могут осуществить промышленный шпионаж. Или что-то еще, что им выгодно. А на вас им наплевать, как и на ваших заказчиков/клиентов и т.д…
Спецназовцы тоже решают поставленные профессиональные задачи. И сантехники. И даже менеджеры решают. У вас слишком широкое определение.
Да, все они могут быть профессионалами в своей области. Спецназовец решает спецназовские задачи (хотя ему тоже может не понравиться спасать от террористов какого-нибудь несимпатичного ему человека, например, не любящего запущеный его спецслужбой файрвол; но это никого не должно волновать). Сантехник проводит водопровод на кухню, хотя ему может больше хотеться устроить шикарный фонтан у вас в гостиной. А программист решает программистские задачи. При этом личные предпочтения, приходящие в конфликт со служебными обязанностями, уместно проявлять в свободное от работы время.
Ну вот допустим есть 2 программиста — один решает задачи, поставленные работодателем, а второй решает их хуже. Но код первого раз в 10 медленнее кода второго. Какой из них лучше?
UFO just landed and posted this here
В ТЗ ничего не сказано, можно считать, что у программиста, код которого медленнее — скорость кода работодателя устраивает.
Но есть один нюанс. Писать быстрый код первый программист не умеет совсем. Не может он этого, квалификации не хватает.
Если медленный код устраивает, то в быстроте нет никакой ценности. Поэтому в современной практике редко используется ассемблер.
Соответственно, я не вижу профессиональной квалификации в способности писать ненужно быстрый код. Это навык, бесполезный до появления критичных к времени выполнения задач.
Соответственно, я не вижу профессиональной квалификации в способности писать ненужно быстрый код. Это навык, бесполезный до появления критичных к времени выполнения задач.
Вопрос то не в полезности навыка, а в том, какой программист лучше.
Лучше по какому критерию? Как профессионал при решении своих задач — первый лучше. А абсолютный зачёт невозможен. От программиста вебморд требуются одни качества, от программиста встраиваемых систем — другие.
UFO just landed and posted this here
Очевидно, что при урезаных вводных и применительно к данному случаю — первый.
Вам очевидно, что первый, другим очевидно, что второй. Вопрос подвешен в вакууме, специально, чтобы выявить эти очевидности :).
UFO just landed and posted this here
Тут целая статья посвящена такому докапыванию, так что оно в тему :).
Ну а вопрос на тему того, кого ты больше любишь — папу или маму — это специальная такая штука, которая выявляет — понимает ли уже ребёнок, что рассказывать, что кого-то ты любишь больше, чес кого-то другого — нельзя.
Не потому что ты всех любишь одинаково, а потому, что если расскажешь — то у тебя стопудов будут проблемы. Поэтому от ответа надо всеми возможными способами уходить. Самый элегантный способ это спросить — дядя, ты дурак?
ассемблер используется редко потому что непереносимо
Тут, как мне кажется, всё просто. Второй товарищ не на своем месте. Ему просто имеет смысл найти другую работу, соответствующую квалификации. Потому что когда ты часть обязанностей выполняешь лучше, чем надо, а другую — не тянешь, значит от тебя хотят не того, что ты реально умеешь.
Если бы вопрос состоял в том — что стоит сделать более квалифицированному программисту — то да, я бы с вами согласился. Но мне интересно узнать мнение по поводу того, какой из них лучше.
Никакой. Информации недостаточно.
Вы написали, что второй делает что-то хуже. Но не объяснили, что и почему. Зато, сказали, что именно хуже делает первый. То есть имеем сравнение понятного с непонятным.
А с точки зрения работодателя, естественно, хороший инженер — тот, кто решил поставленную задачу с заданным качеством и в установленный срок. Так что первый однозначно подходит. А второй — нет. Вот и весь вывод, который можно сделать на основании вашего примера.
Вы написали, что второй делает что-то хуже. Но не объяснили, что и почему. Зато, сказали, что именно хуже делает первый. То есть имеем сравнение понятного с непонятным.
А с точки зрения работодателя, естественно, хороший инженер — тот, кто решил поставленную задачу с заданным качеством и в установленный срок. Так что первый однозначно подходит. А второй — нет. Вот и весь вывод, который можно сделать на основании вашего примера.
Вы написали, что второй делает что-то хуже. Но не объяснили, что и почему.
Один в сроки закрывает задачи, другой пишет более быстрый код.
Тот кто пишет более быстрый код делает это потому что ему позволяет квалификация.
У опытного менеджера сроки всегда с запасом. Но заказчик может потребовать срочную хотелку «вчера».
Пока всё идет по плану, менеджер постарается заложить медлительность второго девелопера и будет его подгонять (если верит в то, что тот пишет код лучше). Но как только придет форс-мажор (а он обязательно случится), медлительному придется или переквалифицироваться в тяп-ляп-быстрого, или получить по мозгам очень больно. Потому что именно такие форс-мажоры, когда менеджер носится в мыле и пытается понять, что не устроило заказчика в свежеотгруженном релизе, и определяют полезность разработчика для компании.
Они оба плохи, если не умеют иначе. Хороший дев — гибкий дев. Знает, когда можно сделать хорошо и неторопливо, знает, когда можно сделать быстрый костыль.
Лично я стараюсь начальнику всегда предложить два варианта — быстрый и правильный. Объяснить Pros & cons. Пусть он выбирает. А я сделаю, как он считает правильным.
Пока всё идет по плану, менеджер постарается заложить медлительность второго девелопера и будет его подгонять (если верит в то, что тот пишет код лучше). Но как только придет форс-мажор (а он обязательно случится), медлительному придется или переквалифицироваться в тяп-ляп-быстрого, или получить по мозгам очень больно. Потому что именно такие форс-мажоры, когда менеджер носится в мыле и пытается понять, что не устроило заказчика в свежеотгруженном релизе, и определяют полезность разработчика для компании.
Они оба плохи, если не умеют иначе. Хороший дев — гибкий дев. Знает, когда можно сделать хорошо и неторопливо, знает, когда можно сделать быстрый костыль.
Лично я стараюсь начальнику всегда предложить два варианта — быстрый и правильный. Объяснить Pros & cons. Пусть он выбирает. А я сделаю, как он считает правильным.
Возможно, первый программист использует алгоритм, оптимизированный по памяти, а второй — по скорости. Какой из них лучше — зависит от ситуации и поставленной задачи.
Кому станет хуже от того, что юзер станет чаще выигрывать? Гейм-дизайнеры, полагаю, постоянно такими штуками занимаются. Больше похоже на таракан, чем на профессиональную этику.
UPD:
Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.
Кому станет хуже от того, что юзер станет чаще выигрывать?
Ну как же. Тому программисту, который написал такой код, что юзер выигрывает редко )). В потом уже другой программист, которого наняли, чтобы поправить код предыдущего, переживал по этому же поводу.
Больше похоже на таракан, чем на профессиональную этику.
Таракан, да, но по мнению некоторых, такие тараканы отличают хороших программистов от идеальных ))
Это не мой некропостинг, просто кто-то прокрастинировал с одобрением комментария пять лет.
Да, я очень удивился. Не мог отказать себе в удовольствии ответить )))
Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать
Эх, а я вот частенько гуглю базовые функции, например поиск подстроки в строке.
А все потому, что в голове конкретная каша из Java, JavaScript, PL/SQL, PHP, MS SQL, MySQL и т.д. и т.п.: где-то подсчет символов идет с 0, где-то с 1; по-разному обрабатываются NULLs, у всех разные параметры и разные допустимые значения.
Про все это можно сказать «базовые вещи», но например в мою память уже не помещаются.
Такое обычно подсказывает IDE. В JS всё сложнее, там подсказки паршиво работают, но вот для PHP всё очень даже хорошо, в Java есть типизация, тоже должно быть отлично.
Не знаю, что конкретно товарищ имел ввиду под «базовыми вещами», но вот тривиальные вещи вроде названий и парамеров конкретных функций знать в смысле «помнить наизусть» совсем необязательно.
Я, например, сколько лет программирую на Питоне, никогда не помнил, как добавляется элемент в set. Это add()? Это append()? Это insert()? Это +=? |=? «Базовой вещью» в данном случае является знание того, что set вообще существует, для чего нужен, что его не надо писать самому или использовать array/list там, где лучше всего подойдёт set. А детали не грех загуглить.
Я, например, сколько лет программирую на Питоне, никогда не помнил, как добавляется элемент в set. Это add()? Это append()? Это insert()? Это +=? |=? «Базовой вещью» в данном случае является знание того, что set вообще существует, для чего нужен, что его не надо писать самому или использовать array/list там, где лучше всего подойдёт set. А детали не грех загуглить.
Все, кто приводит обобщения, — огурцы
> Если программист не соответствует базовым требованиям, то ему рано или поздно укажут на дверь.
Имитация бурной деятельности — наше все. :)
> «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Это последствие пропаганды, в первую очередь ООП, когда оно используется без понимания, ради самого ООП, ибо кто не пишет в ООП, с того будут смеятся. :)
> Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня.
Хм, почему вы тогда дальше доколупывались до интервьюируемых, стоит ли избегать перфекционистов? :)
> «симптомы», связанные с неумением следовать парадигме разработки
А зачем следовать этим парадигмам? Ради того, чтобы следовать? Культ карго? :) PHP, JS — мультипарадигменные.
> и написание оставшейся части программы в императивном/процедурном стиле;
Основа моего кода — продедурный стиль — понятный всем. А не широкопальцевая ИБД.
> Установление индивидуальных значений в императивном коде вместо использования связывания данных
Шойта?
> насколько быстро решает простые задачи
В представлении менеджера — да че ты вые, там всего одну строчку добавить.
А то, что потом все из-за нее падает, то ему пох. :)
Но да, простые задачи нужно решать простыми способами. :)
>Первейший способ быть плохим программистом – искать сложных решений там, где есть простые.
В мире PHP (вебе) (сам из него) заклюют, если не используешь мейнстримовый фреймворк (микроскоп) для создания сайтов (забивания гвоздей). :)
Чем больше проблем ты решишь, тем более высокий у тебя рейт, и плевать, что большинство проблем самопринесенные решением неподходящим образом.
> Хороший программист это тот, кто может поддерживать чужой проект
Любой говнокодер это может :)
> тот кто может после запуска продолжать дописывать свой код
А в чем проблема? :)
> тот, чей код могут поддерживать другие люди.
+1
> Должен ли хороший программист использовать выражения return true или return false в циклах?
А в чем проблема?
> Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов?
Хороший программист старается писать понятный код…
> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Это менеджер оценить не сможет… :)
> Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами.
Я человек простой. Вижу дебила, шлю найух. :)
Имитация бурной деятельности — наше все. :)
> «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Это последствие пропаганды, в первую очередь ООП, когда оно используется без понимания, ради самого ООП, ибо кто не пишет в ООП, с того будут смеятся. :)
> Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня.
Хм, почему вы тогда дальше доколупывались до интервьюируемых, стоит ли избегать перфекционистов? :)
> «симптомы», связанные с неумением следовать парадигме разработки
А зачем следовать этим парадигмам? Ради того, чтобы следовать? Культ карго? :) PHP, JS — мультипарадигменные.
> и написание оставшейся части программы в императивном/процедурном стиле;
Основа моего кода — продедурный стиль — понятный всем. А не широкопальцевая ИБД.
> Установление индивидуальных значений в императивном коде вместо использования связывания данных
Шойта?
> насколько быстро решает простые задачи
В представлении менеджера — да че ты вые, там всего одну строчку добавить.
А то, что потом все из-за нее падает, то ему пох. :)
Но да, простые задачи нужно решать простыми способами. :)
>Первейший способ быть плохим программистом – искать сложных решений там, где есть простые.
В мире PHP (вебе) (сам из него) заклюют, если не используешь мейнстримовый фреймворк (микроскоп) для создания сайтов (забивания гвоздей). :)
Чем больше проблем ты решишь, тем более высокий у тебя рейт, и плевать, что большинство проблем самопринесенные решением неподходящим образом.
> Хороший программист это тот, кто может поддерживать чужой проект
Любой говнокодер это может :)
> тот кто может после запуска продолжать дописывать свой код
А в чем проблема? :)
> тот, чей код могут поддерживать другие люди.
+1
> Должен ли хороший программист использовать выражения return true или return false в циклах?
А в чем проблема?
> Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов?
Хороший программист старается писать понятный код…
> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Это менеджер оценить не сможет… :)
> Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами.
Я человек простой. Вижу дебила, шлю найух. :)
Я услышу контраргументы минусующих говнокодеров или нет?
Или я раскрыл чей-то секрет? :)
Или я раскрыл чей-то секрет? :)
Вы продемонстрировали местами очень плоский взгляд на вещи.
>> Хороший программист это тот, кто может поддерживать чужой проект
>Любой говнокодер это может :)
Если по-честному, то поддерживать — это:
1. Долго чинить ошибки,
2. Добавляя новую функциональность.
Понятие «долго» определяется тем, насколько нагружен проект пользователями. Для некоторых механимов поисковика Google «долго» измеряется, думаю, днями. Для некоторых узкоспецифичных научных задач это могут быть и десятилетия.
Слабый разработчик (я бы на вашем месте воздержался от определения «говнокодер», если не хотите получить его от кого-то в ответ) наделает плохих «костылей», которые не починят ошибку, а доломают систему окончательно. И разобраться в причинах уже не сможет.
Я сталкивался с ситуацией, когда код был мне «не по зубам». И всегда честно признавался руководству. Обычно в этих случаях в ответ получал: «ничего, разберешься». Главное — не брать на себя больше, чем можешь унести.
>> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
>Это менеджер оценить не сможет… :)
Менеджер, во-первых, иногда сам в прошлом — кодер, причем, часто — неплохой, раз смог вырасти. А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
Если речь идет не о стартапе из 3 человек, при приеме на работу любого специалиста всегда найдется сециалист в той же области рангом выше.
>> тот, чей код могут поддерживать другие люди.
>+1
Вы же сказали, что поддерживать любой «говнокодер» может. Так в чем проблема? Или «говнокодер» может поддерживать только код, написанный «крутокодером»? А чтобы поддерживать код слабого программиста, кто нужен?..
>Я человек простой. Вижу дебила, шлю найух. :)
Думаю, что вы лукавите. Или работаете в одиночку над инди-проектом.
>> Хороший программист это тот, кто может поддерживать чужой проект
>Любой говнокодер это может :)
Если по-честному, то поддерживать — это:
1. Долго чинить ошибки,
2. Добавляя новую функциональность.
Понятие «долго» определяется тем, насколько нагружен проект пользователями. Для некоторых механимов поисковика Google «долго» измеряется, думаю, днями. Для некоторых узкоспецифичных научных задач это могут быть и десятилетия.
Слабый разработчик (я бы на вашем месте воздержался от определения «говнокодер», если не хотите получить его от кого-то в ответ) наделает плохих «костылей», которые не починят ошибку, а доломают систему окончательно. И разобраться в причинах уже не сможет.
Я сталкивался с ситуацией, когда код был мне «не по зубам». И всегда честно признавался руководству. Обычно в этих случаях в ответ получал: «ничего, разберешься». Главное — не брать на себя больше, чем можешь унести.
>> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
>Это менеджер оценить не сможет… :)
Менеджер, во-первых, иногда сам в прошлом — кодер, причем, часто — неплохой, раз смог вырасти. А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
Если речь идет не о стартапе из 3 человек, при приеме на работу любого специалиста всегда найдется сециалист в той же области рангом выше.
>> тот, чей код могут поддерживать другие люди.
>+1
Вы же сказали, что поддерживать любой «говнокодер» может. Так в чем проблема? Или «говнокодер» может поддерживать только код, написанный «крутокодером»? А чтобы поддерживать код слабого программиста, кто нужен?..
>Я человек простой. Вижу дебила, шлю найух. :)
Думаю, что вы лукавите. Или работаете в одиночку над инди-проектом.
>наделает плохих «костылей», которые не починят ошибку, а доломают систему окончательно
Но поддержит же.
Поэтому я и говорю, что разница — в качестве кода после программиста.
>Менеджер, во-первых, иногда сам в прошлом — кодер.
Тогда это не менеджер, а замаскированный программист…
>А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
То есть все же сам менеджер не может этого определить…
>Вы же сказали, что поддерживать любой «говнокодер» может.
Перечитайте, что говорилось в статье и что я цитировал.
Улавливаете разницу:
«поддерживает говнокодер после кого-то»
и
«кто-то поддерживает после говнокодера»
? :)
Но поддержит же.
Поэтому я и говорю, что разница — в качестве кода после программиста.
>Менеджер, во-первых, иногда сам в прошлом — кодер.
Тогда это не менеджер, а замаскированный программист…
>А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
То есть все же сам менеджер не может этого определить…
>Вы же сказали, что поддерживать любой «говнокодер» может.
Перечитайте, что говорилось в статье и что я цитировал.
Улавливаете разницу:
«поддерживает говнокодер после кого-то»
и
«кто-то поддерживает после говнокодера»
? :)
>Но поддержит же.
Так — нет! Спустя пару недель (месяцев) количество записей в багтрекере начнет неумолимо расти, ситуация выйдет из под контроля и товарищ будет отстранен.
>Тогда это не менеджер, а замаскированный программист
Я видел в жизни порядка 10 хороших манагеров. Больше половины в прошлом были девелоперами. Это с трудом укладывается в молодой голове, но годам к 35-40 многим вполне себе талантливым людям надоедает писать код. Устают. Внимание не то, память не та. Но при этом они не прекращают пониимать, как это делать хорошо и правильно.
>То есть все же сам менеджер не может этого определить…
Функционально — может. Говоря о руководителе, надо под словом «может» понимать «способен получить результат». Потому что своими руками без помощи подчиненных руководитель может довольно мало. В предметной области — критически мало. Но это не значит, что он не сможет решить задачу «отличить тестовое задание, написанное хорошо от того, которое написано плохо».
Везде, где я работал, у руководителя всегда есть «правая рука» — старший разработчик, который дает руководителю технические консультации (или экспертизу) при необходимости. Обычно такого человека называют «техлид».
>«поддерживает говнокодер после кого-то»
>и
>«кто-то поддерживает после говнокодера»
Я-то разницу улавливаю. Но вы ее в своем комментарии не делали. Вы просто написали «любой говнокодер может». Это — ложное утверждение.
К слову, это утверждение ложное даже с поправкой вида «любой дурак может поддерживать код, написанный хорошим спецом». Потому что поддержка — это еще и добавление новой функциональности. А дурак просто не сможет разобраться в архитектуре сложной программы, написанной умным человеком. И надобавляет такого, что всё будит глючить.
Так — нет! Спустя пару недель (месяцев) количество записей в багтрекере начнет неумолимо расти, ситуация выйдет из под контроля и товарищ будет отстранен.
>Тогда это не менеджер, а замаскированный программист
Я видел в жизни порядка 10 хороших манагеров. Больше половины в прошлом были девелоперами. Это с трудом укладывается в молодой голове, но годам к 35-40 многим вполне себе талантливым людям надоедает писать код. Устают. Внимание не то, память не та. Но при этом они не прекращают пониимать, как это делать хорошо и правильно.
>То есть все же сам менеджер не может этого определить…
Функционально — может. Говоря о руководителе, надо под словом «может» понимать «способен получить результат». Потому что своими руками без помощи подчиненных руководитель может довольно мало. В предметной области — критически мало. Но это не значит, что он не сможет решить задачу «отличить тестовое задание, написанное хорошо от того, которое написано плохо».
Везде, где я работал, у руководителя всегда есть «правая рука» — старший разработчик, который дает руководителю технические консультации (или экспертизу) при необходимости. Обычно такого человека называют «техлид».
>«поддерживает говнокодер после кого-то»
>и
>«кто-то поддерживает после говнокодера»
Я-то разницу улавливаю. Но вы ее в своем комментарии не делали. Вы просто написали «любой говнокодер может». Это — ложное утверждение.
К слову, это утверждение ложное даже с поправкой вида «любой дурак может поддерживать код, написанный хорошим спецом». Потому что поддержка — это еще и добавление новой функциональности. А дурак просто не сможет разобраться в архитектуре сложной программы, написанной умным человеком. И надобавляет такого, что всё будит глючить.
Я как перфекционист и любитель early return крайне возмущен шовинизмом в свой адрес!
Я вот тоже не понял, что не так с return в цикле. Типа, количество точек возврата нужно снижать? Нигде ещё не встречал такой рекомендации. Пишу по-разному — как понятнее и красивее получается.
UFO just landed and posted this here
Начинающий программист — пишет код как умеет,
Опытный программист — использует паттерны, методологии и прочая,
Гуру — пишет код, как умеет.
До понимания некоторых вещей просто дорасти нужно.
Опытный программист — использует паттерны, методологии и прочая,
Гуру — пишет код, как умеет.
До понимания некоторых вещей просто дорасти нужно.
Я считаю, что единственным нормальным способом оценки программиста непрограммистом является оценка того, как отзываются о тех проектах, где он работал, руководители этих проектов. Не бросил на полпути, выполнил в срок, продолжал доработки и ничего не упало — значит все хорошо; просят сказать, где его можно найти, чтобы убить — на работу лучше не брать.
Очень спорно.
Пример: Участвовал в разработке сайта для фирмы. Директор активно влезал в разработку, придумывал все новые и новые фичи для реализации, а также требовал быстрого их ввода (важно). Зачастую для быстрой реализации этих фич приходилось страшно костылить (аж вспоминаю с горячим потом), потому что нововведения никак не подходили под экосистему портала. Тестирование и рефакторинг в таких условиях тоже были почти никаким, код худо-бедно комментировать только успевал.
В конце концов даже высокая зп не сдержала меня и я ушел. В ответ раздавались крики о том, что я ставлю фирму в неудобное положение, и теперь им нужно искать человека, который будет разбираться в том что я наговнокодил.
Так что здесь критерий «как писал раньше» нужно рассматривать неразрывно критерием «в каких условиях писал».
«Опасайтесь слова «архитектура» от программистов»
Ой, а объясните почему? Пожалуйста.
Я не понял, чем провинилась конструкция else. Если уж пытаться судить в таких примитивно-синтаксических понятиях, то большой процент else скорее может быть признаком некой полезной обстоятельности мышления.
Вот приличная статья на эту тему https://geektimes.ru/post/112017/
основатель, сео, гендиректор — какое отношение эти люди имеют к программированию? как правило эти люди больше волнуются за свой карман, а не за качество кода, но… рассуждать, как правильно, любят все, потому как «это» не мешки ворочать.
а как нужно? break и + еще одна-две инструкции? goto?
Должен ли хороший программист использовать выражения return true или return false в циклах?
Лет 10 назад, когда я еще кодировал, ответ был «нет».
а как нужно? break и + еще одна-две инструкции? goto?
Sign up to leave a comment.
Правила плохого и хорошего тона в программировании — мнения экспертов