Comments 52
нет
Погуглил его personal life. Ее нет
Семья с четырьмя детьми - это нет personal life?
Да ладно вам, 4 ребенка можно уложить в 8 минут. А вот если бы он действительно уделял им должное время, то и не писал бы про переработки и обучение 4 часа вне работы
Да ладно вам, 4 ребенка можно уложить в 8 минут.
Это если делать последовательно. Возможно процедуру можно оптимизировать, если использовать рекурсивный алгоритм: даётся команда старшему: уложить спать остальных и сообщить об этом, а потом остаётся уложить старшего, а он, в процессе, даёт аналогичные указания следующему ребёнку и т.д., в итоге 4-го ребёнка укладывает 3-й, того - 2-й, того - 1-й, ну и 1-го укладывает отец.
Вы просто смотрите со своей культуры. А надо с точки зрения американской культуры, где работать больше чем 40 часов в неделю - это нормально. Где отвечать на емэйлы в выхи - это нормально. Где отпуска 12 дней в год и нет отпуска по уходу по ребенку - это норма.
Программирование — это прежде всего решение задач, и оно больше связано с логикой, чем с творчеством.
Мне кажется это больше зависит от задачи.
Если задача: - Подвинь кнопку Submit на 20 пикселей вправо, то тут всё просто и понятно, никакого креатива.
А если задача связана с придумыванием новой логики на осоновании какйо-то старой, то тут уже будет креатив. (Можно-ли соединить этот сервис с этим? А тот сервис вместе с этим сервисом решит нашу проблему или не решит? и т.д. и т.п.)
Тоже самое касается и музыки, картин и пр.:
Если музыканта попросят набросать что-то из Drum and Bass, то реализация в IDM заказчика не вдохновит. Как и написанная в абстракционизме картина, при заказе картины в ренессансе.
Думаю, в профессиональной разработке для креатива остаётся очень мало места. Задача разработчика — не придумывать что-то в стиле "А что если сделать вот так или вот так, а добавлю-ка я ещё вот это". В серьёзном проекте такое непозволительно: задачи нужно решать наиболее эффективным способом, с соблюдением установленных стандартов и паттернов. Для изобретения чего-то нового лучше применять инженерный подход: выдвигать обоснованные гипотезы, проверять их, заниматься R&D и т.д. Потом еще вероятно защищать свое решение придется перед кем-то. Не думаю, что здесь есть место креативу, до какого-то уровня да, в пет проектах или небольших компаниях это может встречаться.
Вы забыли про великое искусство именования переменных 😀
Вообще же тут ближе к писательству: можно код писать в стиле Эллочки Людоедки пользуясь 20 словами в примитивном стиле либо же в стиле Улисса, чтобы потом ночами разбираться где там что. Выбор остается за человеком, а соответственно и результат перестает быть чисто техническим.
Эффективные способы, стандарты и паттерны это хорошо. Но, как по мне большая доля творчества все таки проявляется в том чтобы все это применить к твоей конкретной задаче, которая в своём конечном виде, вполне реально, не имеет решения в открытом доступе. При этом каждый раз нужно понимать что эффективнее использовать конкретно в этом случае, иначе будешь забивать гвозди микроскопом.
Идеальный программист — это такой программист, который, сначала, будет долго думать, а, потом сядет и одним длинным листом напишет всё, что надо. Как-то так.
На мой взгляд, эта книга больше похожа на самопрезентацию Мартина для его будущих работодателей. Вот посмотрите какой я просветленный самурай. Можете приковать меня к комьютеру и давать миску риса в неделю, а я вам AGI сделаю в перерывах между медитациями.
Идеальный – это смотря для кого. Для менеджмента, для коллег, для друзей или семьи? Для разных лиц это будет разный человек, причем одни пожелания будут противоречить другим.
Мартин описал идеального со стороны менеджмента – работящий сверхурочно, все свободное время тратящий на свое обучение, чтобы еще больше пользы приносить компании, где работает.
В книге Мартина "Идеальная работа" врезалась в память одна строчка: "...хороший программист должен знать около десятка ЯП". У меня сразу возникли сомнения в его адекватности)))
После этой строчки все его труды для меня под сомнением
Наверное важно, что такое ЯП и насколько глубоко предполагается знать. А так это совсем не сложно.
Берём по одному из каждой категории ниже. Очень реально за свою карьеру поработать либо плотно с каким-нибудь языком из каждой категории (разве что 9ю добавил для широты кругозора), либо хотя бы уметь прочитать, чтобы примерно понять что там происходит
C/C++/Java/C#
python/go/lua
latex / markdown / asciidoc
SQL
cmd / powershell / bash
html / xml / css / js
json / yaml / ini
формулы excel / макросы VBA / R
haskell / rust / F# / asm / lisp / prolog /erlang
RegEx
markdown
SQL
html / xml / css / js
json / yaml / ini
это не языки программирования:
markdown - это язык разметки (текста)
SQL - язык запросов (к БД)
html / xml / css - языки разметки и оформления
json - текстовый формат обмена данными
yaml - специальный язык для структурированной записи информации, обладающий простым синтаксисом, формат сериализации данных, концептуально близкий к языкам разметки
ini - текстовый файл, который содержит параметры чего-либо в виде строк "Var01=value01"
Да даже если считать языки программирования. Вот я сисадмин, но всё равно в той или иной степени знаю следующие языки (чтобы написать скрипт, подправить сайт, найти, почему что-то не работает, использовал во время учёбы и т.д., то есть, это и то, что я готов использовать прямо сейчас, и то, для чего потребуется освежить в памяти те или иные вещи, но это всё равно быстрее, чем учить с нуля):
Python
JavaScript
Java
C++
C
Ruby
Perl
PHP
Pascal
Assembler
А человек, который именно программист, явно должен знать не меньше.
А человек, который именно программист, явно должен знать не меньше.
это уже мемный баян или бородатый мем
Вакансия: водитель. Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО. Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей — обязательны. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Но знать несколько языков - это как раз вполне возможно, там же базовые принципы часто похожи, а, чего не знаешь, можно нагуглить, или даже среда разработки подскажет. А, если в чём-то ошибся, обычно можно исправить без какого-то заметного ущерба, почитав документацию или задав вопрос на форуме (понятно, речь не про софт для банков, управления оборудованием и т.п.). Ну и получить знания разных языков программисту проще, чем водителю навыки вождения самых разных машин. Если бы водители могли бесплатно скачивать гоночные болиды Формулы-1 и трассы для них, то и многие работодатели ожидали бы от водителей, что они умеют их водить - хотя бы потому, что это показывало бы, что человек развивается, и готов осваивать новое, а не привык годами крутить баранку автомобиля одной конкретной модели.
Знать немного синтаксис - это не то же самое, что "знать язык".
В книге Мартина "Идеальная работа" врезалась в память одна строчка: "...хороший программист должен знать около десятка ЯП".
Я бы сказал, не хороший, а просто достаточно старый.
Вот список стандартный для тех кому за 40 в порядке изучения:
Basic, Assembler, Fortran (или аналогичная старина), Pascal, PL-SQL, SQL, C++, C#, JS, TS.
Мне 41. Чуток помню basic, delphi (да это подвид паскаля, как cpp у с), php, js. Но говнокодить могу на любом языке. Но философией разработки владею только для php и delphi. А это самое важное для разработчика. Если ты написал несколько пет-проектов на десятке языков это еще не значит, что ты их знаешь.
Sql не яп, его знать строго обязательно для бэкендеров.
Философия разработки и на Delphi уже меняется. Проверьте и попробуйте написать кроссплатформенный пет-проект на FMX с дженериками, анонимками и тасками, например.
Дженирики я ещё в 2008 году использовал, если память не изменяет. А кроссплатформенность на дельфе под вопросом. Зачем? Это чисто виндовая вещь для малого бизнеса, имхо.
Ну вот об этом и речь. Вы плохо знаете его современные способности. Инлайны, выведение типов, локальный скоуп, новые фреймворки, кроссплатформенные возможности. Бэкенд под Линукс прекрасно пишется с использованием бэкенд фреймворков. Гуи приложения и игры под мобильные или полностью кроссплатформенные платформы - тоже.
Исключительно винда - это пережиток. Это уже давно не так.
Вероятно, это все нужно было делать в студенчестве, когда не было полноценной работы, а потом дошлифовывать до профессионализма
Нельзя отрицать, что Роберт Мартин — отличный разработчик с огромным опытом.
А с чего вы взяли что он отличный разработчик?
Именно. Вы знаете хоть один значимый продукт/сервис/библиотеку/фреймфорк/алгоритм за которым стоял бы Мартин хотя бы как "один из"?
Может он коммитер в каких-нить больших делах типа Java/Linux/PostgreSQL ?
Может он участвует в развитии серьезных стандартов или спецификаций?
Я честно пытался что-то найти: нету ничего.
Чувак известен сомнительными книгами от которых больше вреда чем пользы (а для начинающих так вообще один только вред), и тем что учит других как программировать, и тем что одним из первых вписался в Agile-движняк (отдельная сковорода ему в аду за это).
Он популист от IT. Не читайте его и не слушайте.
Aх да, и пока люди втыкают мне минуса в предыдущий коммент я таки накину ещё:
Предмет моей личной ненависти к "дядюшке" это то, что именно он ввел в обиход акроним SOLID. Эта эпичная малоприложимая к реальности хрень, в которую буковки подбирали, чтобы выглядело красиво.
Вот вам подробное обсуждение в Подлодке, где в частности коснулись и того, почему с SOLID плохо почти все, от людей поумнее меня: https://www.youtube.com/watch?v=3deXOXWlHeg&t=6356s
Критических и дельных статей по теме в этих ваших интернетах полно. На любых языках.
Но кто услышит тихий голос разума на фоне рева толпы? (с)
По мне, его объяснения и идеи так плохи. Просто он каждый раз доводит их до абсурда, где от них больше вреда чем пользы. Поэтому буквально его рекомендациями пользоваться нельзя.
Что касается вредности SOLID, то здесь аналогично. SOLID - это базовые и самоочевидные вещи, которые просто не нужно понимать буквально и не нужно доводить до абсурда.
Т.е. например если не разделили интерфейс, то кто-то реализуя его оставит ненужный метод не реализованным. А потом кто-то его исиользует. Абсурд же? Проще ведь разделить.
Смешал все в одном объекте (нарушил S и O), хотя поделить было легче легкого. Теперь трудно тестировать. Нужно доработать - придется трогать код который уже в продакшне. Ведь удобнее было бы сразу сделать так, чтобы потом можно было подменить какого-то провайдера вместо того чтобы вырезать этого провайдера по живому.
L вообще не стоит упоминания. Мы можем не пользоваться наследованием, но уж если пользоваться, то наверно лучше правильно.
D - по сути имея IoC контейнер мы уже им пользуемся.
SOLID - это базовые и самоочевидные вещи, которые просто не нужно понимать буквально и не нужно доводить до абсурда.
В том то и дело что нет. Это всё отнюдь не самоочевидно.
Вокруг "O" например вообще большие обсуждения: люди понимают по разному.
https://www.naildrivin5.com/blog/2019/11/14/open-closed-principle-is-confusing-and-well-wrong.html
А если накинуть контекст? не все ЯП знаете ли поддерживают OOП и как тогда быть например с "L"?
Даже "S" на практике далеко не всегда имеет смысл строго следовать.
Короче, в целом, это все субъективно и спорно. Мягко говоря.
Но раздули просто до какого-то библейского откровения.
Еще он сторонник опенспейсов
В комнате стоит приглушенный шум разговоров. Каждая пара находится в пределах слышимости от всех остальных пар. У каждого члена команды есть возможность услышать, что кто-то оказался в затруднении. Каждый знает, что происходит у других. Программисты могут интенсивно общаться между собой.
Может возникнуть опасение, что такое окружение отвлекает. Что из-за постоянного шума и разговоров ничего не удастся сделать. Но все не так страшно. Более того, в такой обстановке «боевого командного пункта» продуктивность не только не снижается, а, как показывает исследование Мичиганского университета, может даже возрасти вдвое.
"Каждый знает, что происходит у других." прекрасно же.
Кек! Тоже не поклонник Дяди Боба, но приводить местечковый подкаст в качестве аргумента против всемирно известного автора книг и общепринятой практики - это мощно.
На SOLID может и не надо молиться, как и на любые рекомендации по проектированию, но как показывает практика, прям ненависть к SOLID испытывают те, кто никогда ничего сложного не писал и больше года над проектом не работал.
приводить местечковый подкаст в качестве аргумента против всемирно известного автора книг и общепринятой практики
Вам не кажется, что надо смотреть на содержание, а не на известность автора? Не знаю как в данном случае, но вполне может оказаться что автор местечкового подкаста имеет опыт поболее всемирно известного автора книг. Вот в книге Мартина по шарпу много откровенной ерунды. Надо жевать кактус потому что Дядя Боб (у которого на шарпах реального опыта ноль, а сама книга похоже что для пиара его сына) или руководствоваться здравым смыслом?
Остальное в солиде кроме LSP слишком широко сформулировано и в целом является капитанством - делайте хорошо, а плохо не делайте.
К примеру SRP. Наверное никто не будет спорить что классы нельзя делать слишком большими и GodObject это плохо. Но что значит "единственная ответственность"? В стандартной библиотеке дотнета есть класс System.IO.File, он может читать из фала, писать в файл и еще всякое прочее вроде копирования, удаления и т.п. Чтение из файла и запись в файл это одна ответственность - работа с файлом, или две разные?
Мартиновская формулировка OCP это ерунда
They are closed for modification. Extending the behavior of a module does not result in changes to the source, or binary, code of the module. The binary executable version of the modulewhether in a linkable library, a DLL, or a .EXE fileremains untouched.
Менять код нельзя, готовая сборка меняться не должна, видимо надо на каждую новую фичу надо делать новую дллку. А как иначе можно добавить новую реализацию интерфейса без изменения бинарников? У Бертрана Мейера (автора принципа) сформулировано нормально и там больше про организацию разработки. Есть разъяснения, сформулирована проблема, показаны разные способы ее решения, написано про исключения из правил. Еще у него тоже есть свои пять принципов, как говорится "меня терзают смутные сомнения".
Может быть разгадка кроется в названии книги? "Идеальный программист" для работодателя😅
Нельзя отрицать, что Роберт Мартин — отличный разработчик с огромным опытом
Смотрю, коллеги уже зацепились за эту фразу. Вот и я заинтересовался, а почему это нельзя такого отрицать? А давайте попробуем отрицать. Итак, у "отличного разработчика с огромным опытом" есть страница у тёти Вики. Там про то, что дядя Боб подписывал Agile Manifesto, писал книги и консультирует по улучшению процессов. Про программирование только то, что он самоучка и разрабатывал профессионально с 17и лет. Подозрительно, не правда ли?
Дальнейшее расследование вывело на страницу в линкедине, где указано, что с 91го года (более 30 лет) Мартин " Trainer, consultant, speaker." До этого он так же был менеджером больше чем разработчиком. Возможно Consultant в Rational (90-91гг.) — это разработка, а не руководство. И, судя по рекомендациям какую-то часть времени в Teledyne (но не больше 5и лет) он так же писал код.
Итого. "Отличный разработчик" — маловероятно. "С огромным опытом" — точно нет. Ну, и не удивительно, что книги написаны с точки зрения менеджера, а не разработчика.
Автор сравнивает программирование с музыкой, искусством или боевыми искусствами, что для меня кажется совершенно неверным
Тут я с вам не соглашусь. Любая инженерия — это искусство. Опять же, тётя Вика даёт нам десяток определений и инженерия подходит под любое из них.
Возможно Consultant в Rational (90-91гг.) — это разработка, а не руководство.
https://en.wikipedia.org/wiki/Rational_unified_process
А еще веселее наблюдать за тем, как консультантско-менеджерские темы канули в лету и их как и не было. Не принято немодным хвастаться. На крайний случай преподнести в новой обертке.
Тут написано, что RUP появился в 2003-м году. Через 12 лет после того, как её покинул наш герой. В линкедине указано, что он работал над Rose.
Не, я не подразумевал, что именно он над ним работал (потому что намеков на это не нашел). Скорее в целом. Что же касается этого случая, тут больше намек на то, что компанейка (как сама компания, так и окружение) подходящая была. Вскоре, в 95г., --первая книга.
Что до Википедии:
1995: Rational Corporation purchases Objectory AB.
1996: Rational Objectory Process (ROP) 4.0 is developed. Rational extends Objectory with internal Rational architecture concepts and introduces iterative concepts to it.
https://scottambler.com/unified-process-history/ и https://scottambler.com/what-happened-to-rup/
позитивный отзыв о RUP
The loss of RUP is definitely a step backwards, as it did provide a spectrum of flexibility and formality, driven by project requirements and risk, and we now seem to have to choose between Agile and waterfall. Just as RUP was mistakenly instantiated as waterfall, we’re starting to see the same happen with Agile, where we have excessively long Discovery exercises producing requirements baselines, with sprints effectively being milestones in a waterfall plan. This challenge is particularly acute in UK Government, where ‘Service Assessments’ are required early in the delivery lifecycle, which require a comprehensive specification of solution functionality. Feels like we’re heading back into the methodological Dark Ages sometimes.
На счёт переработок и тд - Ричард Фейман так же говорил, что он полностью погружался в работу в ущебр семье. Он это осознавал и был благодарен жене за то что она занималась детьми и семейным делами. Так что если под словом "идеальный" понимать именно знающий, скиловый, умный и т.п. то выходит что так - надо полностью заниматься программированием/работой, а не личной жизнью.
звучит как оправдания. я бы посмотрел, как вы размеренно, попивая кофеек изучаете, например, rnn, гугловские архитектуры для ml, или ещё какую-либо хоть сколько-нибудь сложную тему.
Почему «Идеальный программист» Роберта Мартина далёк от реальности: критический взгляд