С моей точки зрения хорошие код и архитектура обычно субъективны. То есть для данного проекта может и то, что в статье, хорошо, а для другого - это плохо. Всегда нужен контекст. А вот при открытии нового проекта или забытого старого всегда!! кажется, что он плохо написан. Ну то есть он правда плохо написан, но хороших я за много лет ещё не видел ни одного))))
Перерабатывать не обязательно, и даже вредно. И да, проекты действительно иногда оказываются не нужны заказчику. Сейчас или в итоге никогда. Если такое случается часто, то скорее всего что-то не так с менеджментом компании и они не хотят или пока не научились реагировать на изменяющийся рынок. Но если это случилось один раз, и далее менеджеры поняли, что надо что-то менять, то значит не все потеряно.
Давайте так. Это две стороны - бизнес и наемный работник. Бизнес всегда ожидает большего, а получает меньше. Зарплату тоже всегда хочется побольше, да чтоб ещё времени со второй и третьей работой на удалёнке хватало совмещать (лично я не против, если результат при этом на ура!). Идеал где-то посередине. Но с автором можно согласиться в том, что бигтехи за последние несколько лет испортили нас - можно было получать 500 тр, при этом не особо переживая о сроках и качестве результата всей команды, а только о формальной отработке.
Очень интересно читать комментарии коллег, которые пока ещё не изучили SQL, но горой стоят за свои любимые ORM-ы. Но факт в том, что каждый однажды доростает до изучения SQL, и его мир меняется...
С моей точки зрения хорошие код и архитектура обычно субъективны. То есть для данного проекта может и то, что в статье, хорошо, а для другого - это плохо. Всегда нужен контекст. А вот при открытии нового проекта или забытого старого всегда!! кажется, что он плохо написан. Ну то есть он правда плохо написан, но хороших я за много лет ещё не видел ни одного))))
Перерабатывать не обязательно, и даже вредно. И да, проекты действительно иногда оказываются не нужны заказчику. Сейчас или в итоге никогда. Если такое случается часто, то скорее всего что-то не так с менеджментом компании и они не хотят или пока не научились реагировать на изменяющийся рынок. Но если это случилось один раз, и далее менеджеры поняли, что надо что-то менять, то значит не все потеряно.
Давайте так. Это две стороны - бизнес и наемный работник. Бизнес всегда ожидает большего, а получает меньше. Зарплату тоже всегда хочется побольше, да чтоб ещё времени со второй и третьей работой на удалёнке хватало совмещать (лично я не против, если результат при этом на ура!). Идеал где-то посередине. Но с автором можно согласиться в том, что бигтехи за последние несколько лет испортили нас - можно было получать 500 тр, при этом не особо переживая о сроках и качестве результата всей команды, а только о формальной отработке.
Очень интересно читать комментарии коллег, которые пока ещё не изучили SQL, но горой стоят за свои любимые ORM-ы. Но факт в том, что каждый однажды доростает до изучения SQL, и его мир меняется...
Есть книга "Чистый код" Р. Мартин. Там много практических советов, но даже они не всегда помогают.
Хорошо, но мало. В реальных проектах кода много. Одну простую функцию, да, легко сделать читаемой. Но что делать с 5000+ строчек кода в файле...
Целый мир...
Да. Похоже это разница между выводом через return локальной переменной и именованным выводом без return. Так что автор тоже прав.