суть тестирования не только нахождении/предотвращении багов. Но и в «закреплении» поведения.
Допустим, придумаем гипотетический проект с вашей «тривиальной» функцией. Она где-то используется. Приходит другой разработчик. И вдруг, по нам неизвестным причинам меняет местами имя и фамилию. Легко, совершенно легко вообразить, что наше приложение нигде на это никак не реагирует. Но эти имена и фамилии автоматически распечатываются на конвертах — и не приходят к адресатам.
Выдуманный пример, конечно. Но мало ли.
Или. Пришел другой разработчик. И решил, что будет функция будет возвращать внезапно — имя сервера. Даже для этого изменил название функции. Еще и средствами IDE. Вроде и имя адекватное и код внутри адекватный, а уже возвращает не то, что Вы задумали. При этом, новый разработчик не учел все связи. А вы эти все связи не зафиксировали в тестах.
А был бы тест — новый разработчик сразу же обнаружил бы падение. И ему пришлось бы разобраться в причинах.
Я не сиплюсплюсник, но есть некоторые возражения. Первые символы действительно важны для группировки. Они отражают то, как мыслит программист. И хотелось бы, чтобы мысли вращались вокруг предметной области, а не реализации. Т.е. важнее то, что значит переменная, а не то, где она находится и ее тип.
А вообще, очень бы неплохо было бы, чтобы IDE поддерживали не просто выпадающий список, но и «кнопки» для группировки. Т.е. выпадающий список по умолчанию, но сверху (снизу) тулбар, с «private», «static» и т.д.
Что-то я с ходу не осознал, откуда берется «очевидно».
Допустим, берем такую иголку, которая может пересечь только одну линию. Разломав на куски, вероятность падения хотя бы одним будет другая. Мы также будем получать случаи, когда оба куска падают на линии. С согнутой иголкой вообще проблемы. Совсем не независимые события.
Ну и если бы было так просто, то вероятность падения длинной иголки равна была вероятности короткой иголки при той же решетке. Иглу можно гнуть в кольцо, а можно в спираль. Можно в зигзаг нулевой ширины и очень короткой длины.
обязательной составляющей адекватного ответа является упоминание резкого возрастания сложности поддержки проекта, созданного с использованием исключительно процедурного подхода, при росте его объема. Для многих это неочевидно
И для меня это не очевидно. Эта штуку (разделение на куски и скрывание кода и данных) в ООП называют инкапсуляцией. Но это никак не является брендом исключительно ООП. С помощью процедур (функций) и их вложения друг в друга прекрасно скрывается код. Разбиение на отдельные модули, тоже хорошо инкапсулирует. И без ООП.
ООП разве что соответствует мозгам среднего человека в моделировании какой-то предметной области. Моделирование зависит от самого мышления. ООП — это такой гуманитарный подход в моделировании. Близкий большинству людей.
Мы же вроде про программистов здесь писали. Про дартов-пенсионериусов. Хотя, может это я только так представил. Программист, который любит писать код, разрабатывать, проектировать — будет этим и заниматься. Тут не особо есть руководящие должности.
Желающих поруководить чуть менее чем 100%. И они находят такие места. Гораздо раньше 50-ти.
А на счет перегорания… Я от программистов слышал жалобы еще до 30-ти, что уже ничего не хочется. А 30 лет — чуть ли не смерть.
Перегорание — это психологическая черта. Оно наступает скорее не от возраста, а от эго. Скорее всего такие люди до 50-ти не доработают сами и увольняться просить не надо.
Потом, возраст программистов будет в любом случае расти. Раньше по-сути не было образования и компьютеров у людей, если получили высшее образование до 90-х годов. И практически неоткуда было взяться старикам в этой отрасли. Вначале двухтысячных все были молодые. Теперь же программистов немало и они взрослеют, стареют. Куда они денутся? Неужели каждый начнет руководить? Да нет столько руководящих должностей. И далеко не каждому нравится руководящая должность — ковыряние в бумагах и лизать кому-то повыше.
При этом, много программистов не только переходят в зрелый возраст, но и опыт растет, что немаловажно. Если вы хотите оставаться программистом (не знаю ваш возраст), то и через 10 лет будете видеть новые горизонты о что нужно почитать, что узнать. Поэтому опыт важен. И поэтому, никуда эти программисты не денутся.
Это не молодым надо уступать дорогу, а молодым надо тянуться в знаниях к опытным. Качество образования ухудшается. Работающие с каждым годом увеличивают опыт. ВУЗы за 5 лет не в состоянии дать даже минимальных знаний, потому как объем их неуклонно растет.
После 40 или после 50-ти, например, я с трудом представляю, что пошел бы на завод. Или заработать денег и сидеть дома? Нет. Открыть «бизнес»? Не всем интересно.
Опыт и алкоголизм побеждают молодость и энтузиазм…
Но действительно интересно, какой возраст кажется молодым людям уже старостью. Я тоже раньше думал, что 40 — это кранты в нашей отрасли. Но вот, будет скоро. Не замечаю каких-то ухудшений сообразительных способностей. Местами даже улучшилось. Конечно, это всё благодаря чтениям и тренировкам. Неайтишники и люди не интеллектуального труда возможно в 40 уже совсем плохо думают.
Взгляды с опытом, конечно, поменялись. Начал смотреть с подозрительностью на новые технологии. Из-за этого иногда мне закидывают, что я немодный или олдскульный. Т.е. молодой, с одним-двумя (до пяти) лет опыта, обязательно будет считать себя продвинутым, а меня пенсионером, который пресекает попытки втулить в проект что-то новое.
Это с т.з. молодого. С моей т.з., всё немного иначе. Не имеют слишком большого значения фреймворки, новые подходы. Гораздо важнее подход к разбиению задач, к моделированию, к последовательности действий при разработке, в стратегии разработки. С моей т.з. молодежь часто слишком занята хвастовством, кто больше кнопок знает или испробовал какую-то библиотеку, услышал какое-то слово. А азов ни в какую не хочет знать.
Программирование, к сожалению, не слишком интеллектуальная деятельность. И в программировании можно много встретить людей, которые путают умение мыслить с коллекционированием знаний-мелочевок. Вот, сравнить если с физикой, там такое не проходит. Там можно знать от силы 10 формул, но уметь выводить все.
Ни в коем случае, я не думаю, что нужно использовать только свои велосипеды. Но и концентрация на инструментах, а не на задаче, приводит к плачевным ситуациям. Как минимум грозят выбором не тех инструментов. Потом, грозят тем, что слишком впечатлительный молодой падаван пытается внедрять всё, что услышал.
Потом, проблемы с возрастом не очевидны.
1. 10 лет назад действительно, людей за 40 не брали программистами. Но похоже, у этого была объективная причина: люди, которые в то время были старше, скорее всего обучались и получили высшее образование не в области айти.
2. Многие, бывавшие в США или Лондоне, отмечают, что там работают программистами люди и под 70. Причем есть целые коллективы из таких стариков. Т.е. это косвенно подтверждает пункт 1.
3. Знакомые HR-ы говорят, что на счет возраста сейчас беспокоиться не о чем, всё это чушь.
Есть еще одна мысль. Молодым можно платить меньше, используя их амбиции. Компании не стесняясь в вакансиях так и пишут, что ищут «молодых», «амбициозных», «с огнем в глазах».
Молодые и амбициозные, сразу после ВУЗа, за представляют, что за 30-ать они будут владельцами крупных компаний или по крайней мере, крупными начальниками, а не чернорабочими кодерами. Но вот, бывает такое, что человек любит свою работу, любит писать код и поэтому и в 30 и в 40 (и скорее всего, пока ногами не вынесут вперед) будет заниматься тем, что ему нравится.
Я вас вполне понимаю и только за — писать чистый код. И тоже считаю, что это быстро. Также, если сильно долго думать, то код может стать нечистым. Как раз желание писать быстро порождает необходимость в лаконичности.
Но мы про прототипы. Применяю я ТДД или нет — сильно влияет на чистоту. Имею ввиду постоянный рефакторинг. Чтобы соблюдать чистоту, нужно на каждом шаге рефакторить (и как это без тестов делать? с ошибками разве что). Если не рефакторить, то значит «планировать заранее» — а это уже никаким боком не относится к прототипированию. Знали бы, что получится, то не нужно было бы прототип писать.
Рефакторинг замедляет разработку. Может и ускорить местами, поэтому в прототипе тоже делается, но от случая к случаю.
Потом, чистота кода — это немного неоднозначное явление. Из большого метода в 1000 строк легко в нормальном IDE буквально почти мышкой сделать маленькие — повыносить методы, классы и т.д. А вот из порезанного кода не всегда получается перекроить что-то совсем новое. Вы при рефакторинге смотрите не повторяющиеся куски, выносите, думаете, какое имя дать более правильное. Но тем не менее, такое улучшение кода дает увеличение производительности где-то только в перспективе. В близкой перспективе может оказаться, что код, разбитый на куски, имеет неявные зависимости между разными частями. И как только стукнет в голову изменить ход работы прототипа кардинально — сразу возникают проблемы.
Делать методы маленькими, заботиться о чистоте — это хорошо для большого процесса и «ленивого» создания архитектуры. Т.е. в том случае, когда это не прототип и вы имеете время. И после каждого шага любуетесь кодом и сглаживаете неровности.
Потом, прототип должен быть небольшим. Если у вас в прототипе такой объем кода, который уже тянет на проект и надо будет его развивать, читать другим людям, поддерживать — то скорее всего это уже не прототип и что-то сделали неправильно.
Поэтому, лучше всего использовать, повторюсь, другие, декларативные языки. Чтобы можно было как можно короче, как можно быстрее проверить идею. А не бороться с говнокодом с помощью рефакторинга.
А вообще, мы спорим сейчас о двух крайностях. Я с одной стороны (и другие), вы с другой. Да, недорогие рефакторинги можно в прототипе и проводить — менять имена например. С выносом методов не так очевидно. Тоже можно, но так, чтобы не откатываться если что. В прототипировании нет правил — цель — что-то проверить и как можно с меньшими потерями. Качество, количество багов не так интересует, как «показать результат побыстрее».
Вы используеете статику, не проверяете переменные и так далее — но не нужно всё запихивать в одну 1000-строковую функцию
Почему не нужно? Разница между прототипом и не прототипом — не следование в первом случае ТДД. Т.е. не покрывается тестами и не рефакторится. Поэтому в прототипе, 1000 строк в методе — да без проблем. Если это единственный логический кусок. Лезет напрямую в базу? Да тоже без проблем. Это просто отдельный большой логический кусок.
Фокус в том, что потом рефакторить такой один метод вполне не сложно, если прототип останется. Но разбиение на небольшие методы, и написание тестов — замедляет разработку, хотя не сильно. А если прототип не выстрелит, как идея вообще? Стоит ли тратить время на тесты и на постоянный рефакторинг?
Потом, сам прототип призван что-то показать. Его можно будет оставить, если только он вообще делает что нужно, а не имитирует. Например, я делал прототип. Чтобы не тратить время, хотел набросать быстро на MS-SqlServer. Логично. На SQL можно гораздо быстрее что-то набросать. Задача прототипа — всего лишь увидеть, работает ли предложенная мат-модель на реальных данных или нет. Т.е. дает нужный результат или нет. Оказалась засада — не выдержал сервер работы с деревьями. Хотя, меня скорость совершенно в прототипе не интересовала. Но он как-то совсем не мог работать. Пришлось перенести частично в процедуры на дотнете. Начал прототип дышать и работать.
Но на чистовик нужно было переписывать совершенно другое. Модель только оставить. А само хранение данных, обработка, алгоритмы, — совсем другие.
Разрабатывать тот прототип по ТДД не имело смысла, т.к. ТДД — это постоянная поддержка кода в чистоте на случай изменений. Т.е. нацелена на то, чтобы можно было развивать продукт. Но задача прототипа — не развитие прототипа.
Если уже не хочется тратить время на написание кода два раза, то выбирают функциональный язык, который хорошо работает с любыми данными и позволяет даже в прототипе соблюдать лаконичность кода.
В общем, да — само убирание со всех уровней дублирования логики и дублирования данных — это то, что приводит к улучшению читаемости и к улучшению надежности. Также дает возможность потом оптимизировать.
Но вот:
закешировать результат тяжелых вычислений, минимизировать обращения к БД, удаленным обьектам,
Не так. Закешировать — это продублировать. Это никогда не улучшает читаемость. Кеширование — это дублирование данных. Появляются новые проблемы — проблемы синхронности данных. Нужно создавать механизмы, проверяющие актуальность кеша, или обновляющие кеш при изменении главного источника данных. Есть БД — значит там главный источник данных.
Кеширование — это уже оптимизация. Т.е. низкоуровневая оптимизация. Ее не надо делать в процессе разработки, только в конце.
Вот почему я пишу, что хорошие программисты покупают сервера. Если программисты оптимизируют все время, то в коде появляются монстроидальные конструкции, дублирующие данные. Появляются неявные зависимости. И тогда добавить сервера и решить проблему железом просто не получится.
Один из замечательный приемов оптимизации — писать как можно проще. Это дает больше возможностей в дальнейшем распараллелить работу. Между потоками, между процессами, между серверам и как угодно.
А вы сталкивались с тем, что не только некого выбирать, но и некому?
Интересный парадокс. Можно пройтись по собеседованиям, даже по крупным компаниям с большими ЗП, а там сами собеседующие задают вопросы, на которые не знают ответа. Я всё понимаю, можно всего не знать. Простительно. Но задавать вопросы, на которые нет правильных представлений… Это не единичные случаи, а гораздо больше 50% собеседований.
Компании часто попадают в ловушку, ставя не на тех. Самое неудобное положение у компании, когда она берет первых работников и не может их оценить. А потом, эти становятся ядром и собеседуют остальных.
Меня убило, когда взяли на работу главного базовика, который не мог установить связь — один к одному. Почему? Потому что брали первого базовика и не базовики. Не догадались задавать вопросы по базам данных. Хотя и программисты, но сами видимо не знали таких вещей.
Хорошие программисты бывают. Достаточно правильных взглядов.
Еще один кричащий всеобщий случай. Как определить где г… внокодер, а где нормальный программист? Посадить за машину писать код — не представляется возможным, потому что день на собеседование уйдет, а не все программисты могут выделить (обычно они тайком уходят с текущей работы).
Язык программирования — это язык. И очевидно — программист, это тот, кто умеет хорошо читать код. Т.е. элементарно провести собеседование — дать на листке кусок говнокода и дать посчитать ошибки, дать рекомендации по стилю, по исправлению.
Разве не очевидно, что программист — это в первую очередь читатель кода? У опытного и который сейчас работает и работает хорошо — глаз настроен на код. Таким способом на собеседовании никого не обманешь.
И вопрос: кто так проводит собеседования? Почему спрашивают фиг знает что, а главный навык не проверяют? Да потому что собеседующие почти везде тоже смысл программирования еще не «догнали». Вот так и живем.
Тут несколько факторов.
1. Очень редкие проекты. Т.е. среди работодателей. Те программисты, которые хотели бы этим заниматься, не всегда находят выход. На родине, как минимум. А занимаясь этим, чувствуют себя зажатыми в рамки и что не могут сменить работу — нет между работодателями конкуренции. Например, обидно заниматься сложным математическим проектом, а работодатель при этом дает денег меньше, чем тупому рисователю сайтов. И не потому, что он не ценит работу, а потому, что осознает — этот человек не уйдет в скором времени. Некуда. Я когда-то так ушел с математических проектов в бизнес-приложения. Недавно мой знакомый, который работал много лет в области ИИ тоже ушел.
2. Смотря что называть тривиальным уровнем.Вы оцениваете математика только как выпускника какого-то программисткого направления. Я физик. По образованию. И это никак не мешало мне работать в ИИ (даже помогало). Конечно, я в универе не изучал ни теорию графов, ни теорию алгоритмов и дискретной математики как предмета не было. Пришлось потом почитать. Математика настолько обширна по направлениям, что мне лично тяжело даже сказать, как определить математика. Знать всю математику или даже половину, маленькую часть — невозможно. Хотя бы иметь эрудицию и умение читать и разбираться — и то ладно.
А программистов еще плюс к этому плохо учат. Мало у кого есть опыт учебы в нескольких универах. Я преподавал программистам. И точно скажу: образовательная программа с т.з. математики у программистов очень слабая. У них достаточно нагрузки по другим вещам, которые тоже надо «пробежать». Где время взять на хороший математический курс? Из этого следуют забавные наблюдения:
2.1. Программисты не тянут (большинство) математические проекты. Но при этом рынок труда диктует высокие цены на программистов.
2.2. Математики получают мало. Т.е. люди, которые чистые математики, без умения писать программы — не ценятся, потому что рынок труда другой.
2.3. Программисты, которые тянут математику, десять раз подумают — идти ли в матаналитики, это сразу ограничивает в деньгах (может ограничивать), т.к. средние зарплаты ниже. С другой стороны плюс ко всему уход в такую специализацию — это потеря востребованности в широком круге обычных задач.
А вообще, многие хотят заниматься романтическими вещами. А жизнь заставляет быть прагматиками.
Мне думается, что интересные задачи есть везде, лишь бы над программистом не висели и не говорили как что делать. Хороший программист найдет, как автоматизировать любую деятельность, включая рутину.
Там ниже писали, что хорошо для компании держать толпу джуниоров и несколько опытных надзирателей. Мол джуниоры мало денег получают. Практика такая есть, но неверная. Значит синьйоры там так себе. Потому что если работа повторяется и ее кому-то хотят спихнуть — скорее всего не хватает чего-то в опыте, чтобы избавиться от повторяющейся деятельности.
Я подразумеваю под НЗ и неинтересными задачами то, что вам начинают навязывать рутину и что с ней делать. А еще, говорил о НЗ и ВЗ в рамках одной конторы. Если там есть вообще проекты, то людей с НЗ бросают на самые неинтересные задачи. Если взять просто по рынку зарплаты и связь с интересными задачами, то наверное, никак не коррелирует. Даже и не знаю, что такое «интересные задачи» вообще, если мониторить рынок. Там где модный фреймворк используют? Это только для наработки опыта. Какие-то интересные математические, алгоритмические проекты очень редкие и как правило, на сайты с вакансиями не вывешиваются.
Зависит.
Только я говорил о тенденции, что зарплаты на рынке при найме новых программистов растут быстрее, чем поднимают ЗП тем, кто работает на одном месте.
А то, что программисты много просят на собеседовании — это уж как кто себя оценивает. Я только за то, чтобы брали более дорогих программистов. Только жестче отбирали. Меньше людей, но более качественных гораздо выгоднее.
Это я общую идею озвучил. Как — другая тема. И сложно это. В большинстве своем конторы ограничиваются тем, что дают минимум и если попросят. Потому как те, кто дает деньги, не компетентны в программировании. А сами программисты, обычно, не знают зарплат друг друга. И самый простой способ — смотреть на самооценку.
Но отсюда и минусы появляются. Практически в зарплатах сильная корреляция в сторону — кого наняли позже, а не с компетентностью. Что негативно сказывается на кадрах и на текучке. Сильный минус — это сортировка людей по должностям в зависимости от уровня зарплаты, которую попросили. Как бы лучше опытным решать более глобальные проблемы. Эффективнее.
Но не значит, что такую работу вообще не надо проводить. Иногда могут быть после какой-то длительной работы и цифры о работниках. Производительность/качество. Это самый честный показатель. Лапша-говнокод выстреливает багами всегда. Если багов нет — можете считать, что там не говнокод. Если человек сумел так тщательно покрыть юнит-тестами — и быстро сделать проект — то почему-бы и нет. Но вообще, это слишком гипотетическая ситуация. Говнокод и баги очень сильно коррелируют. И если собрать цифры не только по скорости завершения задач, но и по времени, сколько правили, какая стоимость поддержки — вот и цифры. Конечно, это всё сложно — тяжело отделить работу одного человека от другого, если они в команде работают.
Не знаю я «как», у меня только идеи, «что» )))
Теоретически, было бы неплохо, если бы какая-то вымышленная компания проводила какое-то независимое тестирование, довольно полное в разных направлениях. (иногда кажется полезным на собеседованиях тесты на IQ давать, а то уж очень странные люди не отсеиваются).
Если компания не проводит работу по определению эффективности и компетентности, то рано или поздно попадает в ситуацию, когда верхушку занимают некомпетентные люди. Потому что последних больше и они больше боятся потерять работу. Тогда верхушка не меняется, а снизу происходит беспрерывная текучка. Странная ситуация. Компания ставит не на тех и боится, что потеряет «ключевых работников». А «ключевые работники» — мерило опыта других вновь пришедших людей — боятся более компетентных и стараются их подмять
Есть и эффективность с т.з. компании. Т.е. если программист — то его производительность и качество продукта. Эти вещи могут в разы и десятки раз отличаться. А некоторые программисты откровенно вредят. После них надо переписывать.
При этом каждый думает о себе как о профессионале. Если будут знать зп друг друга, начнутся обиды. Конечно, если контора считает эту производительность и как-то оценивает сотрудников. А сотрудников своя производительность не заботит.
Был занимательный случай. Откровенно тупой программист каким-то образом обманул кого-то там на собеседовании и выпросил бОльшую по меркам конторы зп. Кстати, он сам не ожидал, что дадут. Далее, в святой уверенности, что ему должны так платить за профессионализм, работал почти год. При этом его отношение к работе было такое: «работаю очень медленно, но как я думаю — правильно. Потому что я профессионал».
В итоге примитивный проект, на который не больше месяца должно было уйти, он писал год. Причем, надо теперь переписывать.
Это я к тому, что люди не склонны считать прибыль компании. Не склонны думать о своей производительности. А склонны думать только о том, что компания им должна, просто за то, что они что-то там знают (или думают, что знают). Иногда, даже часто, встречается среди них мнение, что есть идеальный процесс разработки, идеальные конторы, где работают так как надо: это значит, что платят людям там деньги, а они медленно, со схемами, с утверждениями, с иерархиями и со всем, что может показаться правильным — разрабатывают. Т.е. правильно — это просто правильно, без критериев. Что-то вроде — лучше год писать, но правильно, чем месяц, но не правильно. Забывая — что год — это всё экономические показатели.
Так что лучше уровень зарплат друг друга не знать. А конторам отслеживать компетентность и выравнивать зп в нужном направлении. Чтобы у хороших программистов не было мотивов уходить, а у плохих не было мотивов оставаться.
А вот тезис, что следует предпочесть интересную работу с меньшей ЗП неинтересной с большей ЗП, при прочих равных, уже не так очевиден.
Следует из «НЗ — сильный демотиватор». ВЗ и НЗ — понятия относительные. Даже с ВЗ на квартиру в столице пахать и пахать. Просто есть оглядка на рынок.
Потом, есть еще неявная связь зарплаты и задач. Если вас возьмет на работу контора, давая вам по меркам конторы ВЗ, то отношение к вам будет другое и задачами другими будут грузить. Более интересными и важными. Если же возьмут на низкую, то можете буквально сразу обнаружить, что некомпетентные по сравнению с вами люди начинают вами командовать и затыкать вами дырки в каких-то рутинных задачах. Также, скорее всего, в конторе с низкими ЗП вы не найдете сильного коллектива.
Про отпуск я говорил только в смысле — не единым отпуском живем. Конечно, получать удовольствие от работы — не значит выходить за рабочий график. Отдых для эффективной работы тоже очень важен.
Допустим, придумаем гипотетический проект с вашей «тривиальной» функцией. Она где-то используется. Приходит другой разработчик. И вдруг, по нам неизвестным причинам меняет местами имя и фамилию. Легко, совершенно легко вообразить, что наше приложение нигде на это никак не реагирует. Но эти имена и фамилии автоматически распечатываются на конвертах — и не приходят к адресатам.
Выдуманный пример, конечно. Но мало ли.
Или. Пришел другой разработчик. И решил, что будет функция будет возвращать внезапно — имя сервера. Даже для этого изменил название функции. Еще и средствами IDE. Вроде и имя адекватное и код внутри адекватный, а уже возвращает не то, что Вы задумали. При этом, новый разработчик не учел все связи. А вы эти все связи не зафиксировали в тестах.
А был бы тест — новый разработчик сразу же обнаружил бы падение. И ему пришлось бы разобраться в причинах.
А вообще, очень бы неплохо было бы, чтобы IDE поддерживали не просто выпадающий список, но и «кнопки» для группировки. Т.е. выпадающий список по умолчанию, но сверху (снизу) тулбар, с «private», «static» и т.д.
Я считал вероятность, а не число пересечений.
Допустим, берем такую иголку, которая может пересечь только одну линию. Разломав на куски, вероятность падения хотя бы одним будет другая. Мы также будем получать случаи, когда оба куска падают на линии. С согнутой иголкой вообще проблемы. Совсем не независимые события.
Ну и если бы было так просто, то вероятность падения длинной иголки равна была вероятности короткой иголки при той же решетке. Иглу можно гнуть в кольцо, а можно в спираль. Можно в зигзаг нулевой ширины и очень короткой длины.
И для меня это не очевидно. Эта штуку (разделение на куски и скрывание кода и данных) в ООП называют инкапсуляцией. Но это никак не является брендом исключительно ООП. С помощью процедур (функций) и их вложения друг в друга прекрасно скрывается код. Разбиение на отдельные модули, тоже хорошо инкапсулирует. И без ООП.
ООП разве что соответствует мозгам среднего человека в моделировании какой-то предметной области. Моделирование зависит от самого мышления. ООП — это такой гуманитарный подход в моделировании. Близкий большинству людей.
Желающих поруководить чуть менее чем 100%. И они находят такие места. Гораздо раньше 50-ти.
А на счет перегорания… Я от программистов слышал жалобы еще до 30-ти, что уже ничего не хочется. А 30 лет — чуть ли не смерть.
Перегорание — это психологическая черта. Оно наступает скорее не от возраста, а от эго. Скорее всего такие люди до 50-ти не доработают сами и увольняться просить не надо.
Потом, возраст программистов будет в любом случае расти. Раньше по-сути не было образования и компьютеров у людей, если получили высшее образование до 90-х годов. И практически неоткуда было взяться старикам в этой отрасли. Вначале двухтысячных все были молодые. Теперь же программистов немало и они взрослеют, стареют. Куда они денутся? Неужели каждый начнет руководить? Да нет столько руководящих должностей. И далеко не каждому нравится руководящая должность — ковыряние в бумагах и лизать кому-то повыше.
При этом, много программистов не только переходят в зрелый возраст, но и опыт растет, что немаловажно. Если вы хотите оставаться программистом (не знаю ваш возраст), то и через 10 лет будете видеть новые горизонты о что нужно почитать, что узнать. Поэтому опыт важен. И поэтому, никуда эти программисты не денутся.
Это не молодым надо уступать дорогу, а молодым надо тянуться в знаниях к опытным. Качество образования ухудшается. Работающие с каждым годом увеличивают опыт. ВУЗы за 5 лет не в состоянии дать даже минимальных знаний, потому как объем их неуклонно растет.
После 40 или после 50-ти, например, я с трудом представляю, что пошел бы на завод. Или заработать денег и сидеть дома? Нет. Открыть «бизнес»? Не всем интересно.
Но действительно интересно, какой возраст кажется молодым людям уже старостью. Я тоже раньше думал, что 40 — это кранты в нашей отрасли. Но вот, будет скоро. Не замечаю каких-то ухудшений сообразительных способностей. Местами даже улучшилось. Конечно, это всё благодаря чтениям и тренировкам. Неайтишники и люди не интеллектуального труда возможно в 40 уже совсем плохо думают.
Взгляды с опытом, конечно, поменялись. Начал смотреть с подозрительностью на новые технологии. Из-за этого иногда мне закидывают, что я немодный или олдскульный. Т.е. молодой, с одним-двумя (до пяти) лет опыта, обязательно будет считать себя продвинутым, а меня пенсионером, который пресекает попытки втулить в проект что-то новое.
Это с т.з. молодого. С моей т.з., всё немного иначе. Не имеют слишком большого значения фреймворки, новые подходы. Гораздо важнее подход к разбиению задач, к моделированию, к последовательности действий при разработке, в стратегии разработки. С моей т.з. молодежь часто слишком занята хвастовством, кто больше кнопок знает или испробовал какую-то библиотеку, услышал какое-то слово. А азов ни в какую не хочет знать.
Программирование, к сожалению, не слишком интеллектуальная деятельность. И в программировании можно много встретить людей, которые путают умение мыслить с коллекционированием знаний-мелочевок. Вот, сравнить если с физикой, там такое не проходит. Там можно знать от силы 10 формул, но уметь выводить все.
Ни в коем случае, я не думаю, что нужно использовать только свои велосипеды. Но и концентрация на инструментах, а не на задаче, приводит к плачевным ситуациям. Как минимум грозят выбором не тех инструментов. Потом, грозят тем, что слишком впечатлительный молодой падаван пытается внедрять всё, что услышал.
Потом, проблемы с возрастом не очевидны.
1. 10 лет назад действительно, людей за 40 не брали программистами. Но похоже, у этого была объективная причина: люди, которые в то время были старше, скорее всего обучались и получили высшее образование не в области айти.
2. Многие, бывавшие в США или Лондоне, отмечают, что там работают программистами люди и под 70. Причем есть целые коллективы из таких стариков. Т.е. это косвенно подтверждает пункт 1.
3. Знакомые HR-ы говорят, что на счет возраста сейчас беспокоиться не о чем, всё это чушь.
Есть еще одна мысль. Молодым можно платить меньше, используя их амбиции. Компании не стесняясь в вакансиях так и пишут, что ищут «молодых», «амбициозных», «с огнем в глазах».
Молодые и амбициозные, сразу после ВУЗа, за представляют, что за 30-ать они будут владельцами крупных компаний или по крайней мере, крупными начальниками, а не чернорабочими кодерами. Но вот, бывает такое, что человек любит свою работу, любит писать код и поэтому и в 30 и в 40 (и скорее всего, пока ногами не вынесут вперед) будет заниматься тем, что ему нравится.
Меня интересует эта тема, т.к. возраст увеличивается. Но никто цифр не дает.
Но мы про прототипы. Применяю я ТДД или нет — сильно влияет на чистоту. Имею ввиду постоянный рефакторинг. Чтобы соблюдать чистоту, нужно на каждом шаге рефакторить (и как это без тестов делать? с ошибками разве что). Если не рефакторить, то значит «планировать заранее» — а это уже никаким боком не относится к прототипированию. Знали бы, что получится, то не нужно было бы прототип писать.
Рефакторинг замедляет разработку. Может и ускорить местами, поэтому в прототипе тоже делается, но от случая к случаю.
Потом, чистота кода — это немного неоднозначное явление. Из большого метода в 1000 строк легко в нормальном IDE буквально почти мышкой сделать маленькие — повыносить методы, классы и т.д. А вот из порезанного кода не всегда получается перекроить что-то совсем новое. Вы при рефакторинге смотрите не повторяющиеся куски, выносите, думаете, какое имя дать более правильное. Но тем не менее, такое улучшение кода дает увеличение производительности где-то только в перспективе. В близкой перспективе может оказаться, что код, разбитый на куски, имеет неявные зависимости между разными частями. И как только стукнет в голову изменить ход работы прототипа кардинально — сразу возникают проблемы.
Делать методы маленькими, заботиться о чистоте — это хорошо для большого процесса и «ленивого» создания архитектуры. Т.е. в том случае, когда это не прототип и вы имеете время. И после каждого шага любуетесь кодом и сглаживаете неровности.
Потом, прототип должен быть небольшим. Если у вас в прототипе такой объем кода, который уже тянет на проект и надо будет его развивать, читать другим людям, поддерживать — то скорее всего это уже не прототип и что-то сделали неправильно.
Поэтому, лучше всего использовать, повторюсь, другие, декларативные языки. Чтобы можно было как можно короче, как можно быстрее проверить идею. А не бороться с говнокодом с помощью рефакторинга.
А вообще, мы спорим сейчас о двух крайностях. Я с одной стороны (и другие), вы с другой. Да, недорогие рефакторинги можно в прототипе и проводить — менять имена например. С выносом методов не так очевидно. Тоже можно, но так, чтобы не откатываться если что. В прототипировании нет правил — цель — что-то проверить и как можно с меньшими потерями. Качество, количество багов не так интересует, как «показать результат побыстрее».
Почему не нужно? Разница между прототипом и не прототипом — не следование в первом случае ТДД. Т.е. не покрывается тестами и не рефакторится. Поэтому в прототипе, 1000 строк в методе — да без проблем. Если это единственный логический кусок. Лезет напрямую в базу? Да тоже без проблем. Это просто отдельный большой логический кусок.
Фокус в том, что потом рефакторить такой один метод вполне не сложно, если прототип останется. Но разбиение на небольшие методы, и написание тестов — замедляет разработку, хотя не сильно. А если прототип не выстрелит, как идея вообще? Стоит ли тратить время на тесты и на постоянный рефакторинг?
Потом, сам прототип призван что-то показать. Его можно будет оставить, если только он вообще делает что нужно, а не имитирует. Например, я делал прототип. Чтобы не тратить время, хотел набросать быстро на MS-SqlServer. Логично. На SQL можно гораздо быстрее что-то набросать. Задача прототипа — всего лишь увидеть, работает ли предложенная мат-модель на реальных данных или нет. Т.е. дает нужный результат или нет. Оказалась засада — не выдержал сервер работы с деревьями. Хотя, меня скорость совершенно в прототипе не интересовала. Но он как-то совсем не мог работать. Пришлось перенести частично в процедуры на дотнете. Начал прототип дышать и работать.
Но на чистовик нужно было переписывать совершенно другое. Модель только оставить. А само хранение данных, обработка, алгоритмы, — совсем другие.
Разрабатывать тот прототип по ТДД не имело смысла, т.к. ТДД — это постоянная поддержка кода в чистоте на случай изменений. Т.е. нацелена на то, чтобы можно было развивать продукт. Но задача прототипа — не развитие прототипа.
Если уже не хочется тратить время на написание кода два раза, то выбирают функциональный язык, который хорошо работает с любыми данными и позволяет даже в прототипе соблюдать лаконичность кода.
Но вот:
Не так. Закешировать — это продублировать. Это никогда не улучшает читаемость. Кеширование — это дублирование данных. Появляются новые проблемы — проблемы синхронности данных. Нужно создавать механизмы, проверяющие актуальность кеша, или обновляющие кеш при изменении главного источника данных. Есть БД — значит там главный источник данных.
Кеширование — это уже оптимизация. Т.е. низкоуровневая оптимизация. Ее не надо делать в процессе разработки, только в конце.
Вот почему я пишу, что хорошие программисты покупают сервера. Если программисты оптимизируют все время, то в коде появляются монстроидальные конструкции, дублирующие данные. Появляются неявные зависимости. И тогда добавить сервера и решить проблему железом просто не получится.
Один из замечательный приемов оптимизации — писать как можно проще. Это дает больше возможностей в дальнейшем распараллелить работу. Между потоками, между процессами, между серверам и как угодно.
Интересный парадокс. Можно пройтись по собеседованиям, даже по крупным компаниям с большими ЗП, а там сами собеседующие задают вопросы, на которые не знают ответа. Я всё понимаю, можно всего не знать. Простительно. Но задавать вопросы, на которые нет правильных представлений… Это не единичные случаи, а гораздо больше 50% собеседований.
Компании часто попадают в ловушку, ставя не на тех. Самое неудобное положение у компании, когда она берет первых работников и не может их оценить. А потом, эти становятся ядром и собеседуют остальных.
Меня убило, когда взяли на работу главного базовика, который не мог установить связь — один к одному. Почему? Потому что брали первого базовика и не базовики. Не догадались задавать вопросы по базам данных. Хотя и программисты, но сами видимо не знали таких вещей.
Хорошие программисты бывают. Достаточно правильных взглядов.
Еще один кричащий всеобщий случай. Как определить где г… внокодер, а где нормальный программист? Посадить за машину писать код — не представляется возможным, потому что день на собеседование уйдет, а не все программисты могут выделить (обычно они тайком уходят с текущей работы).
Язык программирования — это язык. И очевидно — программист, это тот, кто умеет хорошо читать код. Т.е. элементарно провести собеседование — дать на листке кусок говнокода и дать посчитать ошибки, дать рекомендации по стилю, по исправлению.
Разве не очевидно, что программист — это в первую очередь читатель кода? У опытного и который сейчас работает и работает хорошо — глаз настроен на код. Таким способом на собеседовании никого не обманешь.
И вопрос: кто так проводит собеседования? Почему спрашивают фиг знает что, а главный навык не проверяют? Да потому что собеседующие почти везде тоже смысл программирования еще не «догнали». Вот так и живем.
1. Очень редкие проекты. Т.е. среди работодателей. Те программисты, которые хотели бы этим заниматься, не всегда находят выход. На родине, как минимум. А занимаясь этим, чувствуют себя зажатыми в рамки и что не могут сменить работу — нет между работодателями конкуренции. Например, обидно заниматься сложным математическим проектом, а работодатель при этом дает денег меньше, чем тупому рисователю сайтов. И не потому, что он не ценит работу, а потому, что осознает — этот человек не уйдет в скором времени. Некуда. Я когда-то так ушел с математических проектов в бизнес-приложения. Недавно мой знакомый, который работал много лет в области ИИ тоже ушел.
2. Смотря что называть тривиальным уровнем.Вы оцениваете математика только как выпускника какого-то программисткого направления. Я физик. По образованию. И это никак не мешало мне работать в ИИ (даже помогало). Конечно, я в универе не изучал ни теорию графов, ни теорию алгоритмов и дискретной математики как предмета не было. Пришлось потом почитать. Математика настолько обширна по направлениям, что мне лично тяжело даже сказать, как определить математика. Знать всю математику или даже половину, маленькую часть — невозможно. Хотя бы иметь эрудицию и умение читать и разбираться — и то ладно.
А программистов еще плюс к этому плохо учат. Мало у кого есть опыт учебы в нескольких универах. Я преподавал программистам. И точно скажу: образовательная программа с т.з. математики у программистов очень слабая. У них достаточно нагрузки по другим вещам, которые тоже надо «пробежать». Где время взять на хороший математический курс? Из этого следуют забавные наблюдения:
2.1. Программисты не тянут (большинство) математические проекты. Но при этом рынок труда диктует высокие цены на программистов.
2.2. Математики получают мало. Т.е. люди, которые чистые математики, без умения писать программы — не ценятся, потому что рынок труда другой.
2.3. Программисты, которые тянут математику, десять раз подумают — идти ли в матаналитики, это сразу ограничивает в деньгах (может ограничивать), т.к. средние зарплаты ниже. С другой стороны плюс ко всему уход в такую специализацию — это потеря востребованности в широком круге обычных задач.
А вообще, многие хотят заниматься романтическими вещами. А жизнь заставляет быть прагматиками.
Там ниже писали, что хорошо для компании держать толпу джуниоров и несколько опытных надзирателей. Мол джуниоры мало денег получают. Практика такая есть, но неверная. Значит синьйоры там так себе. Потому что если работа повторяется и ее кому-то хотят спихнуть — скорее всего не хватает чего-то в опыте, чтобы избавиться от повторяющейся деятельности.
Я подразумеваю под НЗ и неинтересными задачами то, что вам начинают навязывать рутину и что с ней делать. А еще, говорил о НЗ и ВЗ в рамках одной конторы. Если там есть вообще проекты, то людей с НЗ бросают на самые неинтересные задачи. Если взять просто по рынку зарплаты и связь с интересными задачами, то наверное, никак не коррелирует. Даже и не знаю, что такое «интересные задачи» вообще, если мониторить рынок. Там где модный фреймворк используют? Это только для наработки опыта. Какие-то интересные математические, алгоритмические проекты очень редкие и как правило, на сайты с вакансиями не вывешиваются.
Только я говорил о тенденции, что зарплаты на рынке при найме новых программистов растут быстрее, чем поднимают ЗП тем, кто работает на одном месте.
А то, что программисты много просят на собеседовании — это уж как кто себя оценивает. Я только за то, чтобы брали более дорогих программистов. Только жестче отбирали. Меньше людей, но более качественных гораздо выгоднее.
Но отсюда и минусы появляются. Практически в зарплатах сильная корреляция в сторону — кого наняли позже, а не с компетентностью. Что негативно сказывается на кадрах и на текучке. Сильный минус — это сортировка людей по должностям в зависимости от уровня зарплаты, которую попросили. Как бы лучше опытным решать более глобальные проблемы. Эффективнее.
Но не значит, что такую работу вообще не надо проводить. Иногда могут быть после какой-то длительной работы и цифры о работниках. Производительность/качество. Это самый честный показатель. Лапша-говнокод выстреливает багами всегда. Если багов нет — можете считать, что там не говнокод. Если человек сумел так тщательно покрыть юнит-тестами — и быстро сделать проект — то почему-бы и нет. Но вообще, это слишком гипотетическая ситуация. Говнокод и баги очень сильно коррелируют. И если собрать цифры не только по скорости завершения задач, но и по времени, сколько правили, какая стоимость поддержки — вот и цифры. Конечно, это всё сложно — тяжело отделить работу одного человека от другого, если они в команде работают.
Не знаю я «как», у меня только идеи, «что» )))
Теоретически, было бы неплохо, если бы какая-то вымышленная компания проводила какое-то независимое тестирование, довольно полное в разных направлениях. (иногда кажется полезным на собеседованиях тесты на IQ давать, а то уж очень странные люди не отсеиваются).
Если компания не проводит работу по определению эффективности и компетентности, то рано или поздно попадает в ситуацию, когда верхушку занимают некомпетентные люди. Потому что последних больше и они больше боятся потерять работу. Тогда верхушка не меняется, а снизу происходит беспрерывная текучка. Странная ситуация. Компания ставит не на тех и боится, что потеряет «ключевых работников». А «ключевые работники» — мерило опыта других вновь пришедших людей — боятся более компетентных и стараются их подмять
При этом каждый думает о себе как о профессионале. Если будут знать зп друг друга, начнутся обиды. Конечно, если контора считает эту производительность и как-то оценивает сотрудников. А сотрудников своя производительность не заботит.
Был занимательный случай. Откровенно тупой программист каким-то образом обманул кого-то там на собеседовании и выпросил бОльшую по меркам конторы зп. Кстати, он сам не ожидал, что дадут. Далее, в святой уверенности, что ему должны так платить за профессионализм, работал почти год. При этом его отношение к работе было такое: «работаю очень медленно, но как я думаю — правильно. Потому что я профессионал».
В итоге примитивный проект, на который не больше месяца должно было уйти, он писал год. Причем, надо теперь переписывать.
Это я к тому, что люди не склонны считать прибыль компании. Не склонны думать о своей производительности. А склонны думать только о том, что компания им должна, просто за то, что они что-то там знают (или думают, что знают). Иногда, даже часто, встречается среди них мнение, что есть идеальный процесс разработки, идеальные конторы, где работают так как надо: это значит, что платят людям там деньги, а они медленно, со схемами, с утверждениями, с иерархиями и со всем, что может показаться правильным — разрабатывают. Т.е. правильно — это просто правильно, без критериев. Что-то вроде — лучше год писать, но правильно, чем месяц, но не правильно. Забывая — что год — это всё экономические показатели.
Так что лучше уровень зарплат друг друга не знать. А конторам отслеживать компетентность и выравнивать зп в нужном направлении. Чтобы у хороших программистов не было мотивов уходить, а у плохих не было мотивов оставаться.
Следует из «НЗ — сильный демотиватор». ВЗ и НЗ — понятия относительные. Даже с ВЗ на квартиру в столице пахать и пахать. Просто есть оглядка на рынок.
Потом, есть еще неявная связь зарплаты и задач. Если вас возьмет на работу контора, давая вам по меркам конторы ВЗ, то отношение к вам будет другое и задачами другими будут грузить. Более интересными и важными. Если же возьмут на низкую, то можете буквально сразу обнаружить, что некомпетентные по сравнению с вами люди начинают вами командовать и затыкать вами дырки в каких-то рутинных задачах. Также, скорее всего, в конторе с низкими ЗП вы не найдете сильного коллектива.
Про отпуск я говорил только в смысле — не единым отпуском живем. Конечно, получать удовольствие от работы — не значит выходить за рабочий график. Отдых для эффективной работы тоже очень важен.
Вообще, да, я написал очевидные вещи.