Архив рубрики: мысли в слух

Мнение о книге "Гарри Поттер и методы рационального мышления" и пара мылсей вообще о книгах

 

В системной инженерии (системном мышлении, что-то в последнее время достаточно часто употребляется и то и другое) есть понятие дисциплины и технологии. Дисциплина - это то, что лежит в основе, то, на чем строиться каркас вашего мышления в той или иной области. Устаревает дисциплина достаточно медленно, десять-двадцать лет, может и больше. Технология - это нечто практическое, применяемое здесь и сейчас для решения конкретной задачи. В рамках одной дисциплины может быть достаточно много технологий. Технологии устаревают быстро - год, два, пять (может и дольше, но значительно быстрее чем дисциплина). Например, ООП - это дисциплина. Как разобрался я в ней в конце 20 века, так ничего особо нового в основе своей в ООП не поменялось. А вот C# или Java - это технологии. Не смотря на то, что С# появился плюс-минус в тот же период (в 1998-2001), а в моей жизни чуть позже, году в 2002. Но это не отменяет того факта, что C# это технология. Сколько раз он менялся... Сейчас уже во всю идет речь о 10 версии, а есть еще тесно связанные с самим C# версии Framework. И таки примеров можно привести кучу из всех видов человеческой деятельности. Подходы к построению систем водопровода и отопления, в части расчета диаметров, мощности повышающих насосов и котлов - это дисциплина. Да меняется, да п в каких-то частях устаревает, но в целом меняется медленно. А вот конкретными технологиями здесь могут быть всякие полипропилены или металопластики. Которые появились и сейчас используются, но не факт, что через 5-10 лет им не придет что-то на замену. И как при помощи C# или Java вы можете выражать свои мысли в ООП стиле, так и при помощи металопластиковых или полипропиленовых труб вы можете делать отопление по подходам заложенным в дисциплине.

Введение немного затянулось, но, как мне кажется, оно важно. Так вот, кроме дисциплин и базирующихся на них технологий, есть еще и нечто базовое, то что в нашем мозге отвечает за общую картину мира. И именно на эту картину мира ложатся дисциплины и технологии. Можно ли изучить C# и начать его применять не зная принципов ООП? Да можно. Вот только результат будет получаться не очень. Можно научиться паять пропиленовые трубы и собрать самому систему отопления? Можно, только опять могут быть проблемы с результатом. Аналогично с дисциплинами. Наш мозг устроен так, что все, что не укладывается в наши ментальные модели или игнорируется, или, когда игнорировать ну совсем не получается, вызывает когнитивный диссонанс, по итогам которого эти самые модели могут поменяться. Это всегда тяжело, энергетически затратно и занимает определенное время. Поэтому если у вас стоит выбрать что почитать, то первый приоритет должен быть у того, что меняет ваши базовые ментальные модели в лучшую сторону. Вторым приоритетом - изучение дисциплин. На последнем месте конкретные технологии. Нет, я не говорю про то, что надо игнорировать знания по технологиям :) Во всем нужна золотая середина. Большая часть вашего познавательного импульса должна идти в сторону базовых ментальных моделей и дисциплин, а уже это позволит вам оперативно изучать технологии.

Теперь, собственно, к книге. Книга является фанфиком на тему, как следует из названия, вселенной Гарри Поттера. Да, в книге те же персонажи, в книге многие персонажи даже похожи на своих прототипов из оригинальной серии. Но в целом, эта книга о другом. О том, что такое рациональное мышление, как его можно (и нужно) применять в жизни. В общем эта книга о том, какие ментальные модели у нас должны быть в основе. Эсли проводить аналогии, то эта книга аналоги Голдратовской книги "Цель". Только "Цель" является заманухой для теории ограничений систем, а эта книга является заманухой для методов рационального мышления. 

Читать ли эту книгу? Да! Она и написана очень хорошо (исключение 11 глава, но может и она кому-то понравится), и эта именно та книга, которая должна преподаваться еще в школе, как прививка от элементов мракобесия которое твориться в головах, к сожалению, очень существенной части нашего социума.

Мнение о книге "Гарри Поттер и методы рационального мышления" и пара мылсей вообще о книгах

 

В системной инженерии (системном мышлении, что-то в последнее время достаточно часто употребляется и то и другое) есть понятие дисциплины и технологии. Дисциплина - это то, что лежит в основе, то, на чем строиться каркас вашего мышления в той или иной области. Устаревает дисциплина достаточно медленно, десять-двадцать лет, может и больше. Технология - это нечто практическое, применяемое здесь и сейчас для решения конкретной задачи. В рамках одной дисциплины может быть достаточно много технологий. Технологии устаревают быстро - год, два, пять (может и дольше, но значительно быстрее чем дисциплина). Например, ООП - это дисциплина. Как разобрался я в ней в конце 20 века, так ничего особо нового в основе своей в ООП не поменялось. А вот C# или Java - это технологии. Не смотря на то, что С# появился плюс-минус в тот же период (в 1998-2001), а в моей жизни чуть позже, году в 2002. Но это не отменяет того факта, что C# это технология. Сколько раз он менялся... Сейчас уже во всю идет речь о 10 версии, а есть еще тесно связанные с самим C# версии Framework. И таки примеров можно привести кучу из всех видов человеческой деятельности. Подходы к построению систем водопровода и отопления, в части расчета диаметров, мощности повышающих насосов и котлов - это дисциплина. Да меняется, да п в каких-то частях устаревает, но в целом меняется медленно. А вот конкретными технологиями здесь могут быть всякие полипропилены или металопластики. Которые появились и сейчас используются, но не факт, что через 5-10 лет им не придет что-то на замену. И как при помощи C# или Java вы можете выражать свои мысли в ООП стиле, так и при помощи металопластиковых или полипропиленовых труб вы можете делать отопление по подходам заложенным в дисциплине.

Введение немного затянулось, но, как мне кажется, оно важно. Так вот, кроме дисциплин и базирующихся на них технологий, есть еще и нечто базовое, то что в нашем мозге отвечает за общую картину мира. И именно на эту картину мира ложатся дисциплины и технологии. Можно ли изучить C# и начать его применять не зная принципов ООП? Да можно. Вот только результат будет получаться не очень. Можно научиться паять пропиленовые трубы и собрать самому систему отопления? Можно, только опять могут быть проблемы с результатом. Аналогично с дисциплинами. Наш мозг устроен так, что все, что не укладывается в наши ментальные модели или игнорируется, или, когда игнорировать ну совсем не получается, вызывает когнитивный диссонанс, по итогам которого эти самые модели могут поменяться. Это всегда тяжело, энергетически затратно и занимает определенное время. Поэтому если у вас стоит выбрать что почитать, то первый приоритет должен быть у того, что меняет ваши базовые ментальные модели в лучшую сторону. Вторым приоритетом - изучение дисциплин. На последнем месте конкретные технологии. Нет, я не говорю про то, что надо игнорировать знания по технологиям :) Во всем нужна золотая середина. Большая часть вашего познавательного импульса должна идти в сторону базовых ментальных моделей и дисциплин, а уже это позволит вам оперативно изучать технологии.

Теперь, собственно, к книге. Книга является фанфиком на тему, как следует из названия, вселенной Гарри Поттера. Да, в книге те же персонажи, в книге многие персонажи даже похожи на своих прототипов из оригинальной серии. Но в целом, эта книга о другом. О том, что такое рациональное мышление, как его можно (и нужно) применять в жизни. В общем эта книга о том, какие ментальные модели у нас должны быть в основе. Эсли проводить аналогии, то эта книга аналоги Голдратовской книги "Цель". Только "Цель" является заманухой для теории ограничений систем, а эта книга является заманухой для методов рационального мышления. 

Читать ли эту книгу? Да! Она и написана очень хорошо (исключение 11 глава, но может и она кому-то понравится), и эта именно та книга, которая должна преподаваться еще в школе, как прививка от элементов мракобесия которое твориться в головах, к сожалению, очень существенной части нашего социума.

Производство и потребление

 Условно нашу деятельность можно разделить на производство и потребление. О чем это я? Если после нашей деятельности остаются какие-то артефакты, которые можно использовать в дальнейшем, то это производство. Если по результатам деятельности артефактов не остается, то это потребление. Давайте посмотрим на примерах, как это выглядит и какую пользу можно получить от такого деления.

Если подходить в этом разрезе, то очень многие вещи становятся не очевидными. Например, вы сидите на совещании, обсуждаете какие-то вопросы, расходитесь, а зафиксированного протокола и поручений нет. Все, вы не занимались производством, вы занимались потреблением. Вы пошли гулять с семьей, покатались на лыжах, выпили вкусного чая, получили массу положительных эмоций и сделали кучу отличных фоток, это... Да, вы правильно поняли, это производство.

Согласен, разделение достаточно необычно, но если начинать думать под таким углом, то втыкание в фейсбук это потребление, ровно до тех пор, пока вы не оказываетесь отписаны от тех сообщений, которые "на повтыкать", и подписаны на те сообщения, которые порождают иди, заметки, задачи. Чуть напомню, я сторонник подхода - все что не записано, то продолбано. И это относиться к задачам, проектам, информации и идеям. Поэтому, если вы читаете книгу и не делаете пометки на полях, не строите минд-мапу по содержимому, не выписываете интересные идеи, не ставите себе задачи на основе прочитанного, то вы занимаетесь потреблением. Если книжка художественна, то отлично! Почему? Да потому, что в потреблении ничего плохого нет! Во всем нужна золотая середина, нужна нагрузка на мозг, нужна нагрузка на тело, нужен отдых. И нагрузка на тело может быть отдыхом для мозга. И, кстати, наоборот. А вот если вы читаете книгу по специальности, то пометки нужны. Наш мозг устроен очень интересно, все чем мы не пользуемся, он старается забыть (исключение, то что несет высокую эмоциональную нагрузку, но и это забывается, если не продолжать накручивать эти воспоминания). В чем ценность книг? На мой взгляд в том, что они порождают мысли на тему, полезные инструменты, новые области применения наших навыков и т.д. Если мы находимся в зоне какой-то проблемы, в книге находим решение и тут же его применяем, то у нас в копилке остается инструмент для конкретной проблемы. Все что мы не применили сразу и не зафиксировали во внешней памяти, рано или поздно, имеет шанс быть утерянным. Нет, если вы перечитываете одну и ту же книгу, читаете несколько книг по теме, то есть шанс оставить при себе и не закрепленные на практике вещи, а вот все остальное - увы и ах. То же самое действует и с изучением программирования, прочитали главу в книжке, сразу решите пару задач на закрепление. Нет в книге задач? Придумайте сами или погуглите задачи на заданную тему.

Ладно, с книгами разобрались, с совещаниями, надуюсь тоже, а что-же со всем остальным? В любой ситуации включайте голову, если вам идея понравилась, то просто то чем занимаетесь, пропустите через этот фильтр. Если делаете что-то по работе, а по результатам фильтра получается потребление, то, скорее всего, что-то идет не так. Если играете с собакой, то может имеет смысл изучить пару прикольных штук, которые пригодятся чтобы удивить друзей (ну или поразучивать команды для сдачи ОКД, а там и физический артефакт появится). Но во всем надо без фанатизма, да, возможно, лежание перед телевизором и втыкание в юмористическое шоу не является производством, но время от времени, почему бы и нет, главное, чтобы был баланс, между производством и потреблением.

P.s. Эта статья, как и многие другие в моем блоге, это артефакты по результатам чтения, просмотра видео, участия в конференциях или просто размышлений. Пусть остаются следы, к которым я смогу вернуться, а может по этим следам пройдет и еще кто-нибудь.

Производство и потребление

 Условно нашу деятельность можно разделить на производство и потребление. О чем это я? Если после нашей деятельности остаются какие-то артефакты, которые можно использовать в дальнейшем, то это производство. Если по результатам деятельности артефактов не остается, то это потребление. Давайте посмотрим на примерах, как это выглядит и какую пользу можно получить от такого деления.

Если подходить в этом разрезе, то очень многие вещи становятся не очевидными. Например, вы сидите на совещании, обсуждаете какие-то вопросы, расходитесь, а зафиксированного протокола и поручений нет. Все, вы не занимались производством, вы занимались потреблением. Вы пошли гулять с семьей, покатались на лыжах, выпили вкусного чая, получили массу положительных эмоций и сделали кучу отличных фоток, это... Да, вы правильно поняли, это производство.

Согласен, разделение достаточно необычно, но если начинать думать под таким углом, то втыкание в фейсбук это потребление, ровно до тех пор, пока вы не оказываетесь отписаны от тех сообщений, которые "на повтыкать", и подписаны на те сообщения, которые порождают иди, заметки, задачи. Чуть напомню, я сторонник подхода - все что не записано, то продолбано. И это относиться к задачам, проектам, информации и идеям. Поэтому, если вы читаете книгу и не делаете пометки на полях, не строите минд-мапу по содержимому, не выписываете интересные идеи, не ставите себе задачи на основе прочитанного, то вы занимаетесь потреблением. Если книжка художественна, то отлично! Почему? Да потому, что в потреблении ничего плохого нет! Во всем нужна золотая середина, нужна нагрузка на мозг, нужна нагрузка на тело, нужен отдых. И нагрузка на тело может быть отдыхом для мозга. И, кстати, наоборот. А вот если вы читаете книгу по специальности, то пометки нужны. Наш мозг устроен очень интересно, все чем мы не пользуемся, он старается забыть (исключение, то что несет высокую эмоциональную нагрузку, но и это забывается, если не продолжать накручивать эти воспоминания). В чем ценность книг? На мой взгляд в том, что они порождают мысли на тему, полезные инструменты, новые области применения наших навыков и т.д. Если мы находимся в зоне какой-то проблемы, в книге находим решение и тут же его применяем, то у нас в копилке остается инструмент для конкретной проблемы. Все что мы не применили сразу и не зафиксировали во внешней памяти, рано или поздно, имеет шанс быть утерянным. Нет, если вы перечитываете одну и ту же книгу, читаете несколько книг по теме, то есть шанс оставить при себе и не закрепленные на практике вещи, а вот все остальное - увы и ах. То же самое действует и с изучением программирования, прочитали главу в книжке, сразу решите пару задач на закрепление. Нет в книге задач? Придумайте сами или погуглите задачи на заданную тему.

Ладно, с книгами разобрались, с совещаниями, надуюсь тоже, а что-же со всем остальным? В любой ситуации включайте голову, если вам идея понравилась, то просто то чем занимаетесь, пропустите через этот фильтр. Если делаете что-то по работе, а по результатам фильтра получается потребление, то, скорее всего, что-то идет не так. Если играете с собакой, то может имеет смысл изучить пару прикольных штук, которые пригодятся чтобы удивить друзей (ну или поразучивать команды для сдачи ОКД, а там и физический артефакт появится). Но во всем надо без фанатизма, да, возможно, лежание перед телевизором и втыкание в юмористическое шоу не является производством, но время от времени, почему бы и нет, главное, чтобы был баланс, между производством и потреблением.

P.s. Эта статья, как и многие другие в моем блоге, это артефакты по результатам чтения, просмотра видео, участия в конференциях или просто размышлений. Пусть остаются следы, к которым я смогу вернуться, а может по этим следам пройдет и еще кто-нибудь.

Производство и потребление

 Условно нашу деятельность можно разделить на производство и потребление. О чем это я? Если после нашей деятельности остаются какие-то артефакты, которые можно использовать в дальнейшем, то это производство. Если по результатам деятельности артефактов не остается, то это потребление. Давайте посмотрим на примерах, как это выглядит и какую пользу можно получить от такого деления.

Если подходить в этом разрезе, то очень многие вещи становятся не очевидными. Например, вы сидите на совещании, обсуждаете какие-то вопросы, расходитесь, а зафиксированного протокола и поручений нет. Все, вы не занимались производством, вы занимались потреблением. Вы пошли гулять с семьей, покатались на лыжах, выпили вкусного чая, получили массу положительных эмоций и сделали кучу отличных фоток, это... Да, вы правильно поняли, это производство.

Согласен, разделение достаточно необычно, но если начинать думать под таким углом, то втыкание в фейсбук это потребление, ровно до тех пор, пока вы не оказываетесь отписаны от тех сообщений, которые "на повтыкать", и подписаны на те сообщения, которые порождают иди, заметки, задачи. Чуть напомню, я сторонник подхода - все что не записано, то продолбано. И это относиться к задачам, проектам, информации и идеям. Поэтому, если вы читаете книгу и не делаете пометки на полях, не строите минд-мапу по содержимому, не выписываете интересные идеи, не ставите себе задачи на основе прочитанного, то вы занимаетесь потреблением. Если книжка художественна, то отлично! Почему? Да потому, что в потреблении ничего плохого нет! Во всем нужна золотая середина, нужна нагрузка на мозг, нужна нагрузка на тело, нужен отдых. И нагрузка на тело может быть отдыхом для мозга. И, кстати, наоборот. А вот если вы читаете книгу по специальности, то пометки нужны. Наш мозг устроен очень интересно, все чем мы не пользуемся, он старается забыть (исключение, то что несет высокую эмоциональную нагрузку, но и это забывается, если не продолжать накручивать эти воспоминания). В чем ценность книг? На мой взгляд в том, что они порождают мысли на тему, полезные инструменты, новые области применения наших навыков и т.д. Если мы находимся в зоне какой-то проблемы, в книге находим решение и тут же его применяем, то у нас в копилке остается инструмент для конкретной проблемы. Все что мы не применили сразу и не зафиксировали во внешней памяти, рано или поздно, имеет шанс быть утерянным. Нет, если вы перечитываете одну и ту же книгу, читаете несколько книг по теме, то есть шанс оставить при себе и не закрепленные на практике вещи, а вот все остальное - увы и ах. То же самое действует и с изучением программирования, прочитали главу в книжке, сразу решите пару задач на закрепление. Нет в книге задач? Придумайте сами или погуглите задачи на заданную тему.

Ладно, с книгами разобрались, с совещаниями, надуюсь тоже, а что-же со всем остальным? В любой ситуации включайте голову, если вам идея понравилась, то просто то чем занимаетесь, пропустите через этот фильтр. Если делаете что-то по работе, а по результатам фильтра получается потребление, то, скорее всего, что-то идет не так. Если играете с собакой, то может имеет смысл изучить пару прикольных штук, которые пригодятся чтобы удивить друзей (ну или поразучивать команды для сдачи ОКД, а там и физический артефакт появится). Но во всем надо без фанатизма, да, возможно, лежание перед телевизором и втыкание в юмористическое шоу не является производством, но время от времени, почему бы и нет, главное, чтобы был баланс, между производством и потреблением.

P.s. Эта статья, как и многие другие в моем блоге, это артефакты по результатам чтения, просмотра видео, участия в конференциях или просто размышлений. Пусть остаются следы, к которым я смогу вернуться, а может по этим следам пройдет и еще кто-нибудь.

Избавляемся от лишнего

 Есть очень полезная практика, с которой можно столкнуться в различных областях нашей деятельности. В практиках доведения дел до конца, он заключается в регулярных ритуалах просмотра списка дел и безжалостного выбрасывания тех из них, которые утратили свою актуальность или по которым мы понимаем, что делать это мы все равно не будем. В отношении вещей в доме, действует тот же совет, если вы какую-то вещь не использовали уже лет 5, то не захламляйте ей шкаф (гараж, сарай), а безжалостно выкидывайте. В разработке ПО этот подход применяется, например, в рамках Backlog grooming. Логика та же самая, смотрим, что устарело и нам больше не потребуется и удаляем соответствующие требования (пользовательские истории). Но, несмотря на известность практики, мы ее почему-то не используем по отношению к коду. А может и не нужно? Давайте обсудим под катом.

Разработчики очень любят свой код, иначе это так себе разработчики :) Но вот в чем штука, самый лучший код, это тот код, который не написан. Действительно, чем меньше мы пишем кода, и чем лучше при этом решаем поставленную задачу, тем мы более ценны, как программист. Но вот код уже написан, а задача - устарела. И? Может его удалить?

Я когда рассказываю про качество кода, всегда привожу подслушанную где-то цитату: Код мы пишем один раз, а читаем много раз. И это не только про то, чтобы код был поддерживаемым. Основная цена написанного нами кода складывается не из трудозатрат на реализацию, а из трудозатрат на эксплуатацию кода. Сюда входит и ресурсы системы на которой код эксплуатируется и трудозатраты наши или наших коллег, которые возникают в случаях касания с нашим кодом. Но есть ли проблема с кодом, который устарел и больше не используется? На самом деле да. В монолите, даже если он не вызывается, он будет подгружаться в память, если устарел целый микросервис, то будут тратиться ресурсы на его поднятие и, как минимум, память (если вызовов нет, то процессор тратиться не будет). Но ресурсы все дешевеют и дешевеют, и может трудозатраты которые затратит разработчик чтобы выпилить устаревший код будут выше, чем стоимость этих ресурсов? Здесь тоже не все просто. Какие могут быть кейсы с неиспользуемым кодом?

1. Вы изменяете некий фрагмент кода, от которого зависит неиспользуемый код. Вы свою задачу решили, все ведет себя ожидаемо и тут падабт тесты на неиспользуемом коде. Вы тратите время на то, чтобы разобраться что упало, усложняете логику своего кода, чтобы проходили тесты в неиспользуемом коде. Оно вам надо? Хотя, если у вас нет тестов и перестал корректно работать неиспользуемый код, то вы про это не узнаете, и вам не надо будет тратить на это время... А вы уверены, что такая ситуация лучше? Ведь при отсутствии тестов, вам не найти какой используемый код вы сломали...

2. Выходит новый коллега, начинает знакомиться с кодом. Понятно, что он это будет делать в рамках каких-то дефектов, как правило древних, до которых сто лет не доходили руки. И вот ресурс тратиться на устаревшие дефекты, в устаревшем коде, которые к тому-же могут ничего не рассказать новичку о том коде, который реально используется.

3. Вы меняете технологическую платформу, базу данных, брокер или еще что-то. Если у вас все хорошо, то основная часть изменений будет в слое маскирующим реализацию от бизнес-логики. Но такое бывает не всегда, да и предусмотреть все в таких адаптерах бывает невозможно. И вот вы начинаете править неиспользуемый код, чтобы он тоже работал с новыми адаптерами.

4. Неиспользуемый код будет тестироваться, как минимум в рамках регрессов. А это тоже вычислительные (при автоматизированном) и человеческие (при ручном) ресурсы. Да и потерю времени никто не отменял.

Надо ли бросать все и вот прям завтра идти и выпиливать неиспользуемый код? Сложно сказать, здесь всегда должен быть баланс между плюсами и минусами. Устарел отчет, рабочий процесс или модуль - изолированную часть выпилить будет просто, выгоды получите сразу. А вот всякие мелочи, выпиливать дорого, в первую очередь, в связи с затратами на их поиск. Но нужно понимать эти выгоды и работая над кодом постоянно смотреть, а нет ли тут кода, который можно убрать? Главное, чтобы рефакторинг по удалению неиспользуемого кода не превратился в рефакинг, были, к сожалению, и такие прецеденты... Кстати, упомянутые выше тесты, вам помогут с выпиливанием, главное не забыть выпилить и неиспользуемые тесты.

Избавляемся от лишнего

 Есть очень полезная практика, с которой можно столкнуться в различных областях нашей деятельности. В практиках доведения дел до конца, он заключается в регулярных ритуалах просмотра списка дел и безжалостного выбрасывания тех из них, которые утратили свою актуальность или по которым мы понимаем, что делать это мы все равно не будем. В отношении вещей в доме, действует тот же совет, если вы какую-то вещь не использовали уже лет 5, то не захламляйте ей шкаф (гараж, сарай), а безжалостно выкидывайте. В разработке ПО этот подход применяется, например, в рамках Backlog grooming. Логика та же самая, смотрим, что устарело и нам больше не потребуется и удаляем соответствующие требования (пользовательские истории). Но, несмотря на известность практики, мы ее почему-то не используем по отношению к коду. А может и не нужно? Давайте обсудим под катом.

Разработчики очень любят свой код, иначе это так себе разработчики :) Но вот в чем штука, самый лучший код, это тот код, который не написан. Действительно, чем меньше мы пишем кода, и чем лучше при этом решаем поставленную задачу, тем мы более ценны, как программист. Но вот код уже написан, а задача - устарела. И? Может его удалить?

Я когда рассказываю про качество кода, всегда привожу подслушанную где-то цитату: Код мы пишем один раз, а читаем много раз. И это не только про то, чтобы код был поддерживаемым. Основная цена написанного нами кода складывается не из трудозатрат на реализацию, а из трудозатрат на эксплуатацию кода. Сюда входит и ресурсы системы на которой код эксплуатируется и трудозатраты наши или наших коллег, которые возникают в случаях касания с нашим кодом. Но есть ли проблема с кодом, который устарел и больше не используется? На самом деле да. В монолите, даже если он не вызывается, он будет подгружаться в память, если устарел целый микросервис, то будут тратиться ресурсы на его поднятие и, как минимум, память (если вызовов нет, то процессор тратиться не будет). Но ресурсы все дешевеют и дешевеют, и может трудозатраты которые затратит разработчик чтобы выпилить устаревший код будут выше, чем стоимость этих ресурсов? Здесь тоже не все просто. Какие могут быть кейсы с неиспользуемым кодом?

1. Вы изменяете некий фрагмент кода, от которого зависит неиспользуемый код. Вы свою задачу решили, все ведет себя ожидаемо и тут падабт тесты на неиспользуемом коде. Вы тратите время на то, чтобы разобраться что упало, усложняете логику своего кода, чтобы проходили тесты в неиспользуемом коде. Оно вам надо? Хотя, если у вас нет тестов и перестал корректно работать неиспользуемый код, то вы про это не узнаете, и вам не надо будет тратить на это время... А вы уверены, что такая ситуация лучше? Ведь при отсутствии тестов, вам не найти какой используемый код вы сломали...

2. Выходит новый коллега, начинает знакомиться с кодом. Понятно, что он это будет делать в рамках каких-то дефектов, как правило древних, до которых сто лет не доходили руки. И вот ресурс тратиться на устаревшие дефекты, в устаревшем коде, которые к тому-же могут ничего не рассказать новичку о том коде, который реально используется.

3. Вы меняете технологическую платформу, базу данных, брокер или еще что-то. Если у вас все хорошо, то основная часть изменений будет в слое маскирующим реализацию от бизнес-логики. Но такое бывает не всегда, да и предусмотреть все в таких адаптерах бывает невозможно. И вот вы начинаете править неиспользуемый код, чтобы он тоже работал с новыми адаптерами.

4. Неиспользуемый код будет тестироваться, как минимум в рамках регрессов. А это тоже вычислительные (при автоматизированном) и человеческие (при ручном) ресурсы. Да и потерю времени никто не отменял.

Надо ли бросать все и вот прям завтра идти и выпиливать неиспользуемый код? Сложно сказать, здесь всегда должен быть баланс между плюсами и минусами. Устарел отчет, рабочий процесс или модуль - изолированную часть выпилить будет просто, выгоды получите сразу. А вот всякие мелочи, выпиливать дорого, в первую очередь, в связи с затратами на их поиск. Но нужно понимать эти выгоды и работая над кодом постоянно смотреть, а нет ли тут кода, который можно убрать? Главное, чтобы рефакторинг по удалению неиспользуемого кода не превратился в рефакинг, были, к сожалению, и такие прецеденты... Кстати, упомянутые выше тесты, вам помогут с выпиливанием, главное не забыть выпилить и неиспользуемые тесты.

Что не так с качеством?

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Что не так с качеством?

Я не очень понимаю, в какой момент произошел слом в массовом сознании, но я его наблюдаю регулярно и систематически.
Но то что слом произошел, причем совсем недавно, и не только в России, это факт. Как вам вот такие два определения качества:
1. ИСО 8402—86: Качество — совокупность свойств и характеристик продукции или услуги, которые придают им способность удовлетворять обусловленные или предполагаемые потребности потребителя.
2. ГОСТ Р ИСО 9000-2015: Качество — степень соответствия совокупности присущих характеристик объекта требованиям.
Видите разницу, под катом мои мысли на эту тему.

Ключевая разница этих определений в том, что в 86 году под качеством понимали удовлетворение потребностей потребителя, в 2015 соответствие требованиям.
И вот уже в голове голосом Райкина звучит:
-У вас к пуговицам претензии есть?
- Нет, к пуговицам претензий нет, пришиты намертво.
Аналитик отвечает только за то, чтобы в TFS (или какая у вас там система управления требованиями) появились пользовательские истории для Scrum или требования для остальных методологий. Ой, простите, Скрам это не методология, это всего лишь фреймворк, который, кстати, тоже не про удовлетворение потребностей потребителя, а про ритуальные действия, которые должны выполняться строго в соответствии с требованиями. Но не суть, аналитики написали некий текст, разработчик в соответствии с этим текстом написал функционал, инженер по тестированию проверил, все работает так, как написано в требовании. Пришиты намертво, не оторвешь. Вот только пользоваться этим нельзя. Например, по тому, что никто не подумал о реальной ситуации где это будет работать. Об обрывах связи, о больших наборах данных, о том, что пользователя выбесит вводить одно и то же значение 100 раз подряд. А это ведь я рассказываю про идеальный сценарий, с выделенной аналитикой, разработкой и тестированием.
Мы все забываем про потребителя. Причем даже не обязательно вешнего. Рассмотрим самый ужасающий пример такой забывчивости: программиста. Кто является потребителем продукта за качество которого отвечает программист? Остановитесь, подумайте. Кто? Пользователь? Отлично, если программист когда пишет код думает о пользователе, о том как будут пользоваться системой, в каком окружении она будет работать, что можно сделать, чтобы если уж не облегчить жизнь пользователю, то хотя бы не усложнить. Но в большинстве случаев нет даже этого. Ну вот в требовании написано реализовать А. Ну и что, что то что написано не удобно, ломает логику системы, да и использоваться не будет пока не сделают Б, которого даже в планах пока нет. Надо сделать А, вот и сделаю как понял, а там хоть трав.. Ну в смысле а там коммит, ревью, пуш, закрыть задачу и пойти налить кофе.
А ведь кроме несчастного пользователя потребителями труда программиста являются: инженеры по тестированию, специалисты по внедрению, специалисты технической поддержки и ПРОГРАММИСТЫ!!! И ладно, тестировщиков не жаль, админы пусть мудохаются с развертыванием как хотят, тех. поддержка? А это вообще кто такие? Но блин, как можно не думать про себя любимого? Как можно писать методы на сотни строк кода? Ты что, завтра увольняешь и больше не будешь пытаться разобраться в этом спагетти? Как можно в сложной лямбде, находящейся внутри другой лямбды, которая находится по соседству с третей лямбдой использовать имя переменной параметра i (при этом тип сущностей в итерируемой коллекции пусть будет Персона)? Ну а писать catch внутри которого ничего нет, это вообще как? Это что, желание подольше искать неуловимую ошибку?
В Кайдзен есть очень правильный постулат: "Следующий процесс – это потребитель. Вся работа представляет собой ряд процессов, и в каждом процессе имеется свой потребитель и свой поставщик. Большинство работающих в организациях людей имеют дело с внутренним потребителем. Никогда не передавайте бракованные запасные части или неверную информацию людям, участвующим в следующем процессе.".  У каждого кто занимается разработкой программного обеспечения должна постоянно в голове быть мысль: не передавать брак или неверную информацию дальше. Ведь следующий по цепочке это и ты в том числе. Сделал плохо сегодня, придется переделывать завтра. Не предусмотрел сегодня, придется переделывать завтра. Как и с любым принципом, не надо перегибать палку. Не надо доводить мысль до абсолюта, вот пока не доведу до хрустального совершенства, на следующий этап не пущу. Но надо делать максимально хорошо, уверяю вас, плохо оно само получится.
P.s. Сорри за такую сумбурную портянку текста, наболело что-то...

Кто все эти люди?

На форумах MSDN задали вопрос "Поясните, пожалуйста, с примерами, чем junior и middle отличаются от senior?". Ответ на этот вопрос будет или субъективным, или очень формальным. Многие организации идут по второму пути. Вводят что мидла должен соответствовать критериям А, Б; миддл критериям В, Г; а синьор должен еще и Д и Е. За такими формальными штуками в эти организации. Под катом мое субъективное мнение никого ни к чему не обязывающее.



Junior - разработчик с небольшим опытом на применяемой платформе. С хорошим качеством может решать похожие задачи. Задачи с которыми раньше не сталкивался вызывают существенный перерасход по времени и выполняются с низким качеством (здесь могут быть как откровенные баги, так и архитектурные ошибки). Практически никогда не думает об альтернативных возможностях работы кода.
Middle - разработчик с опытом реальной разработки на платформе от года и выше. С хорошим качеством и в приемлемые сроки решает как повторяющиеся так и новые задачи. Архитектурные вещи, как правило, косячит. При написании кода предусматривает альтернативные сценарии (контроль входных данных, обработка ошибок).
Senoir - разработчик с очень хорошим знанием платформы. Может не только решать задачи, но и видит когда их можно не решать, может предложить альтернативные способы реализации лучше удовлетворяющие функциональным или нефункциональным требованиям. Полностью с приемлемым качеством может разрабатывать архитектуру средних и крупных программных систем. В зависимости от того к чему лежит душа в дальнейшем или все больше занимается архитектурными вещами и переходит в архитекторы, или больше занимается проработкой требований, обучением коллег и переходит в тимлиды.