Тем не менее, подумав еще раз, склоняюсь к тому, что явная оптимизация лучше. В общем случае, если Вы программируете на всем, что допускает возможность программирования, это сослужит Вам добрую службу.
Например, пишете Вы код, знаете хорошо повадки компилятора. Ок. Потом Вы решили сделать Ваше приложение кроссплатформенным, каков будет масштаб изменений? Явно оптимизированное приложение гораздо проще перенести, в другой ОС будет другой компилятор, который не будет столь же продвинутым, и сделает неэффективный код.
У Вас есть хорошая библиотека, которую Вам нужно перенести на другой ЯП для другого проекта. Опять же неизвестно, что там будет за компилятор, кто будет исполнять полученный код. Известно только одно — явно оптимизированный код с большей вероятностью будет выполняться более оптимально везде, где это может быть. Нормально делай — нормально будет.
И вот куда мне во всей этой куче ситуаций нужно впихнуть знание, что «компилятор С# в такой-то конкретной ситуации неявно догадывается о том, что я хочу сделать». ИМХО, на таком уровне хорошо бы и мне представлять, что именно я написал, и какие есть пути оптимизации.
На мой взгляд, явная оптимизация всё-таки показатель того, что человек понимает, что происходит за ширмой IDE, в которой он работает. И она учит этому пониманию и других, особенно если это прокомментировано в коде.
Насчёт потоков и синхронизации — по большей части согласен. Но все равно слишком много «если». Все-таки правильно написал товарищ выше, что лучше писать явно оптимальный код, который и тебя будет держать в тонусе, и твоих последователей, нежели держать в голове нюансы работы компилятора.
Хорошего про 1С могу сказать только одно: они не сделали нормальный Си-подобный язык. В итоге в студенческие годы я так и не смог его освоить (молодой был, глупый, начитался вакансий в газетах), за что очень благодарен создателям языка 1С. Всё-таки это не моё…
Мне тоже подумалось про «если будет в теле цикла», но вот то, что Вы написали — это Ваше 100%-ное знание или просто идеализация компиляторов? А если будет поток? Тоже компилятор будет анализировать, используется ли функция в потоке, или меняется ли массив другими потоками? Теоретически это возможно, практически это тоже и возможно, и скорее всего так и есть, НО… Всё-таки я привык к тому, что «машина делает ровно то, что Вы написали, а не то, что Вы имели в виду»… Вот мой последний проект, например, работает нормально только при отключенной оптимизации. И вообще у нас так повелось, что если программа сбоит, попробуй отключить оптимизацию.
Плюсую. Эта статья скорее о том, что неявная оптимизация может сильно подгадить. И вообще не понятно, для каких нубов нужна такая «неявная оптимизация». Я не пишу на C#, но например, если в теле цикла меняется размер массива, или если массив может меняться из другого потока, то «оптимизированная» компилятором функция может вести себя не так, как ожидает программист. Т.к. в условии цикла, по сути, будет проверяться не текущий размер массива, а размер массива на момент входа в цикл. Хорошо, если массив уменьшается, тогда, возможно, Вы получите исключение типа «выход за пределы массива», и будете долго врубаться, в чем собственно дело. А если массив увеличивается, а Ваш цикл (поток?) проходит не по всем его элементам, а только по части, ошибки будут очень неявными, и искать их будет на порядок труднее…
Ответственность это фикция уже потому, что продукт делается за фиксированное время. Независимо от ответственности. Производительность труда довольно стабильная штука. Постоянно работать по 16 часов можно недели две, потом производительность падает, и всё, приехали. Но зависимо от квалификации. Можно пару раз пойти не тем путём, сжечь все силы на переработках, а проблема будет в архитектуре. Можно выбрать удачную архитектуру и в рабочем режиме, без переработок, заполнить её функционалом. Вопрос в том, кого Вы выбрали руководителем проекта.
Опять же, сбоящая подсистема тормозит всю команду, т.к. она стопорит продукт, и архитектор вынужден участвовать в поиске ошибок. Поэтому квалифицированный кодер для проекта лучше неквалифицированного. Вопрос в том, кого Вы набрали в исполнители.
Если архитектор налажал со сроками/архитектурой/ТЗ для исполнителей, то никакая ответственность тут не поможет. Вы ведь его не расстреляете, и деньги с него не возьмёте, и что Вы хотите от него услышать на совещании? Толпа народа вызовет у него лишь желание изворачиваться, и проблема, скорее всего, будет от вас скрыта до дедлайна и после дедлайна и так далее. Лучше переговорить с ним доверительно с глазу на глаз, переговорить доверительно с другими «звёздами» и ведущими, использовав коммуникационные навыки, и уже потом без него принимать решение о дальнейших действиях — либо менять архитектора на другого ведущего спеца из команды, либо… Либо докладывать начальству о катастрофе в разработке проекта.
Обратите внимание, цитата из первого правила: «Я знал немало руководителей, которые полностью перекладывали технические вопросы на подчинённых, восхищались людьми, умеющими делать технику, и задавали только два вопроса: «Когда будет готово?» и «Что необходимо для работы?». Это отличный стиль руководства для неспециалиста. Подводный камень здесь только один — кадровая политика. Ошибка в кадровой политике может вылиться в срыв проекта и потерю должности. Если с кадрами повезло, то остаётся лишь обеспечить их работу. О том, как её обеспечивать — читайте следующие правила.»
По шестому правилу с Вашей критикой согласен.
Что касается остальных — не согласен. Мне, в свою очередь, кажется, что Вы недооцениваете такое понятие как архитектура проекта. Возможно, недопонимаете это понятие. Отсюда недопонимание роли архитектора.
На мой взгляд, архитектор — это человек, который определяет, какие классы/объекты будут в программе, какие у них методы, какие действия выполняются объектами с помощью этих методов. Он объясняет сотрудникам, какие классы нужны, как он их объединит для решения задачи. После этого те, кто понял архитектуру, делают свои предложения по архитектуре, кто не понял — идут реализовывать свои ТЗ.
Тут, конечно, возможно недопонимание. В сложном проекте могут быть десятки и даже сотни подсистем, и все они должны слаженно работать. Для простых проектов архитектура часто очевидна и архитектор почти не нужен.
Отчасти Вы правы — статья написана в результате работы в одной команде, и под впечатлением того, как делать не надо. Советы написаны по принципу «от противного». В моей команде пытались уравнивать «звёздного» программиста с просто хорошими, отсюда возникло правило 6. Безусловно, категоричность не доведёт до добра, но я начинаю понимать японцев, которые обижаются, если идущего, скажем, в отдел кадров сотрудника попросить захватить с собой документ для отдела кадров — для этого есть курьер. Конечно, ключевой показатель работы — это продукт, и для его достижения правила нужно иногда нарушать. Но нельзя строить работу так, чтобы нарушение правил было нормой. Ну и, конечно, у каждого правила есть разумные границы применения.
Статья, в основном, адресована тем, кто путает «ответственность, лидерские качества и умение повести за собой людей» с наличием прямых рук для создания продукта. Творческим людям нужные творческие задачи и творческая мотивация, тогда они создадут классный продукт. «Зажечь» их может только творческий человек, азартный опытный разработчик. Он, правда, не должен навязывать исполнителям свои методы решения задачи. Его задача — архитектура, плюс некоторые предложения по реализации. Если исполнитель хочет по-другому, пусть делает по-другому. Хорошая архитектура — это когда подсистему можно переписать с нуля, использовав только ТЗ, заменить её в проекте, и проект продолжит работу как и раньше.
Если руководитель хочет решить поставленную задачу, ему следует проанализировать предложенные правила. Правда пара комментариев получилась лучше статьи. Правила слишком бескомпромиссные. Для рутины действительно нужны обычные разработчики, они не так склонные менять место работы. В сочетании с опытом они являются хоть какой-то страховкой от кадровых катаклизмов (типа увольнения нескольких ключевых спецов, из которых я предложил собрать команду).
Что значит «ответственен»? Мне непонятна эта абстракция слова «ответственен».
Ответственность — это фикция. Квалификация — это гарантия результата.
Квалифицированный сотрудник сделает задачу при нормальной ответственности. Неквалифицированный руководитель провалит проект при самой высочайшей его ответственности.
Отстаивать сроки должен представитель администрации. Который должен быть поставлен в известность о вариантах разработки. О том, сколько работы необходимо ещё выполнить. Стоит понимать, что ускорение разработки возможно только в одном случае — если перегрузить работников. Это можно делать краткосрочно, за доплату и с предоставлением последующего отдыха. За это заказчик должен доплатить. Соответственно, руководитель должен иметь представление о вариантах развития событий. Архитектор должен эти варианты ему обозначить. Какой режим и срок разработки нормальный, какой — интенсивный, какой — сверхинтенсивный, какой не реален. Если обсуждается изменение ТЗ в части возможностей продукта — тогда архитектор нужен. Если говорить про сроки — все варианты развития событий (в т.ч. вариант предоставления сырого макета с последующей доводкой) должен знать администратор.
Основной посыл статьи в том, что работа делится на две части — административную и техническую. И администратор в продукте играет почти никакую роль, лишь подбирает технические кадры. Соответственно, технари тоже должны быть от административных вопросов изолированы.
Спасибо за ответ. Я подразумевал, что задачи распределяет архитектор. Он же назначает сроки. Он же участвует в совещаниях, посвященных технической стороне продукта. Если совещаются по срокам, он туда не идёт. Он же назначает премии.
1С-ники это не совсем те программисты, о которых идёт речь.
Хороший инженер часто ответственнее начальника. Т.к. он может влиять на ситуацию и болеет за то дело, которое делает. Руководитель тоже болеет, но сделать ничего не может.
Отличный коммент. Командой я не руководил. Статья родилась как ответ на виденное в жизни… На попытки некоторых товарищей собрать команду лоботрясов, которые должны сделать сложный проект. При этом системного архитектора там не было.
Все Ваши замечания очень годные. За исключением пары — про совещания. Имеется в виду не совещание с коллегами, а совещание по административной части. Болтовня в чайной часто перерастает в техническое совещание. Против технических совещаний я ничего не имею.
У Вас, судя по всему, более позитивный опыт в работе. У меня не так.
Я прокрастинирую от того, что меня заставляют заниматься разнородными задачами. В частности, сейчас мне нужно выпустить извещение на изменение схемы, сходить в архив, получить номер, поправить схему, спаять кабель для проверки изделия, исправить программу и кучу всего прочего. Из всего этого хочу я делать только одну задачу — это писать программу. Паять кабель тоже интересно — руки работают, а голова отдыхает. Вопрос — почему нельзя схему поручить электронщику, программу — программисту, а бумажки — какому-нибудь помощнику по бумажкам — этот вопрос для меня открытый. Разделение труда? Нет, не слышали…
В общем, сначала это было интересно, а сейчас реально раздражает.
Ваши советы вроде «Мыслите в рамках 24 часов» для меня звучат примерно так: «Чувак, смирись с тем, что твой рабочий день организовали хреново и попробуй с этим жить». Я таки лучше попробую добиться результата.
Кстати, лично я пока не боюсь ответственности и уверен в результате. Меня просто достало постоянное переключение с одного на другое.
Хмм… Простите, конечно, но суть технологии раскрыта слабовато, т.к. обход дерева не раскрывает всей мощи автоматного программирования. А вот АЭС вполне можно запрограммировать набором конечных автоматов. Но и неавтоматные подсистемы будут нужны. Вообще говоря «автоматное программирование» к документации не имеет отношения. «Конечные автоматы», «машина состояний» — это парадигма построения алгоритма управления. А документация — это уже детали продукта. Документация может быть или не быть для любой парадигмы.
В сложных системах управления конечные автоматы позволяют построить программу такой же структуры, что и управляемое устройство. В этом вся вкуснота. Автоматы позволяют не ломать голову над организацией программы (с неизбежными ошибками и архитектурными ограничениями), а просто по структуре аппаратной системы построить программную систему. Работает такая штука хорошо.
Граф никогда не формируется по коду. Наоборот, код формируется по графу. Парадигма позволяет рисовать типовые графы состояний, и генерить по ним код.
Если требования заказчика изменились, то графику придётся в любом случае менять, если Ваш проект сопровождается графикой. Если он не сопровождается графикой, тогда не придётся менять. Вопрос в сложности продукта. Если продукт сложный — без графа состояний никуда.
Тов. Шалыто, рекомендующий пихать конечные автоматы всюду, демонстрирует классическую ситуацию, когда тема диссертации заняла человека всецело.
Ничего тут коррумпированного нет. Работодатель отчитывается только перед заказчиком, в основном. Налоговой абсолютно до фени нормы времени и труда. Это всё госзаказчик требует обычно. И да, возможно, оно ему надо. Но эту работу вешать на технарей — неправильно. Для этого можно завести бумажечный отдел.
С подписями, в принципе, всё нормально. Если говорить про документацию по ГОСТ. А вот с отчётами и планами — это труба просто. Разраб, по идее, должен выпустить своё КД и пояснилово к нему. Потом отладить опытный образец. Всё. Когда разраб начинает писать планы, отчёты, он перестаёт делать свою работу. А план с отчётом любой школьник может написать, неправильно бросать на такую плёвую задачу специалиста с хорошей зарплатой.
Например, пишете Вы код, знаете хорошо повадки компилятора. Ок. Потом Вы решили сделать Ваше приложение кроссплатформенным, каков будет масштаб изменений? Явно оптимизированное приложение гораздо проще перенести, в другой ОС будет другой компилятор, который не будет столь же продвинутым, и сделает неэффективный код.
У Вас есть хорошая библиотека, которую Вам нужно перенести на другой ЯП для другого проекта. Опять же неизвестно, что там будет за компилятор, кто будет исполнять полученный код. Известно только одно — явно оптимизированный код с большей вероятностью будет выполняться более оптимально везде, где это может быть. Нормально делай — нормально будет.
И вот куда мне во всей этой куче ситуаций нужно впихнуть знание, что «компилятор С# в такой-то конкретной ситуации неявно догадывается о том, что я хочу сделать». ИМХО, на таком уровне хорошо бы и мне представлять, что именно я написал, и какие есть пути оптимизации.
На мой взгляд, явная оптимизация всё-таки показатель того, что человек понимает, что происходит за ширмой IDE, в которой он работает. И она учит этому пониманию и других, особенно если это прокомментировано в коде.
Спасибо, буду знать :)
Опять же, сбоящая подсистема тормозит всю команду, т.к. она стопорит продукт, и архитектор вынужден участвовать в поиске ошибок. Поэтому квалифицированный кодер для проекта лучше неквалифицированного. Вопрос в том, кого Вы набрали в исполнители.
Если архитектор налажал со сроками/архитектурой/ТЗ для исполнителей, то никакая ответственность тут не поможет. Вы ведь его не расстреляете, и деньги с него не возьмёте, и что Вы хотите от него услышать на совещании? Толпа народа вызовет у него лишь желание изворачиваться, и проблема, скорее всего, будет от вас скрыта до дедлайна и после дедлайна и так далее. Лучше переговорить с ним доверительно с глазу на глаз, переговорить доверительно с другими «звёздами» и ведущими, использовав коммуникационные навыки, и уже потом без него принимать решение о дальнейших действиях — либо менять архитектора на другого ведущего спеца из команды, либо… Либо докладывать начальству о катастрофе в разработке проекта.
Что касается остальных — не согласен. Мне, в свою очередь, кажется, что Вы недооцениваете такое понятие как архитектура проекта. Возможно, недопонимаете это понятие. Отсюда недопонимание роли архитектора.
На мой взгляд, архитектор — это человек, который определяет, какие классы/объекты будут в программе, какие у них методы, какие действия выполняются объектами с помощью этих методов. Он объясняет сотрудникам, какие классы нужны, как он их объединит для решения задачи. После этого те, кто понял архитектуру, делают свои предложения по архитектуре, кто не понял — идут реализовывать свои ТЗ.
Тут, конечно, возможно недопонимание. В сложном проекте могут быть десятки и даже сотни подсистем, и все они должны слаженно работать. Для простых проектов архитектура часто очевидна и архитектор почти не нужен.
Отчасти Вы правы — статья написана в результате работы в одной команде, и под впечатлением того, как делать не надо. Советы написаны по принципу «от противного». В моей команде пытались уравнивать «звёздного» программиста с просто хорошими, отсюда возникло правило 6. Безусловно, категоричность не доведёт до добра, но я начинаю понимать японцев, которые обижаются, если идущего, скажем, в отдел кадров сотрудника попросить захватить с собой документ для отдела кадров — для этого есть курьер. Конечно, ключевой показатель работы — это продукт, и для его достижения правила нужно иногда нарушать. Но нельзя строить работу так, чтобы нарушение правил было нормой. Ну и, конечно, у каждого правила есть разумные границы применения.
Статья, в основном, адресована тем, кто путает «ответственность, лидерские качества и умение повести за собой людей» с наличием прямых рук для создания продукта. Творческим людям нужные творческие задачи и творческая мотивация, тогда они создадут классный продукт. «Зажечь» их может только творческий человек, азартный опытный разработчик. Он, правда, не должен навязывать исполнителям свои методы решения задачи. Его задача — архитектура, плюс некоторые предложения по реализации. Если исполнитель хочет по-другому, пусть делает по-другому. Хорошая архитектура — это когда подсистему можно переписать с нуля, использовав только ТЗ, заменить её в проекте, и проект продолжит работу как и раньше.
Ответственность — это фикция. Квалификация — это гарантия результата.
Квалифицированный сотрудник сделает задачу при нормальной ответственности. Неквалифицированный руководитель провалит проект при самой высочайшей его ответственности.
Отстаивать сроки должен представитель администрации. Который должен быть поставлен в известность о вариантах разработки. О том, сколько работы необходимо ещё выполнить. Стоит понимать, что ускорение разработки возможно только в одном случае — если перегрузить работников. Это можно делать краткосрочно, за доплату и с предоставлением последующего отдыха. За это заказчик должен доплатить. Соответственно, руководитель должен иметь представление о вариантах развития событий. Архитектор должен эти варианты ему обозначить. Какой режим и срок разработки нормальный, какой — интенсивный, какой — сверхинтенсивный, какой не реален. Если обсуждается изменение ТЗ в части возможностей продукта — тогда архитектор нужен. Если говорить про сроки — все варианты развития событий (в т.ч. вариант предоставления сырого макета с последующей доводкой) должен знать администратор.
Основной посыл статьи в том, что работа делится на две части — административную и техническую. И администратор в продукте играет почти никакую роль, лишь подбирает технические кадры. Соответственно, технари тоже должны быть от административных вопросов изолированы.
Нет!!!
Совет №11 — выкиньте time tracking!!!
Хороший инженер часто ответственнее начальника. Т.к. он может влиять на ситуацию и болеет за то дело, которое делает. Руководитель тоже болеет, но сделать ничего не может.
Все Ваши замечания очень годные. За исключением пары — про совещания. Имеется в виду не совещание с коллегами, а совещание по административной части. Болтовня в чайной часто перерастает в техническое совещание. Против технических совещаний я ничего не имею.
У Вас, судя по всему, более позитивный опыт в работе. У меня не так.
В общем, сначала это было интересно, а сейчас реально раздражает.
Ваши советы вроде «Мыслите в рамках 24 часов» для меня звучат примерно так: «Чувак, смирись с тем, что твой рабочий день организовали хреново и попробуй с этим жить». Я таки лучше попробую добиться результата.
Кстати, лично я пока не боюсь ответственности и уверен в результате. Меня просто достало постоянное переключение с одного на другое.
В сложных системах управления конечные автоматы позволяют построить программу такой же структуры, что и управляемое устройство. В этом вся вкуснота. Автоматы позволяют не ломать голову над организацией программы (с неизбежными ошибками и архитектурными ограничениями), а просто по структуре аппаратной системы построить программную систему. Работает такая штука хорошо.
Граф никогда не формируется по коду. Наоборот, код формируется по графу. Парадигма позволяет рисовать типовые графы состояний, и генерить по ним код.
Если требования заказчика изменились, то графику придётся в любом случае менять, если Ваш проект сопровождается графикой. Если он не сопровождается графикой, тогда не придётся менять. Вопрос в сложности продукта. Если продукт сложный — без графа состояний никуда.
Тов. Шалыто, рекомендующий пихать конечные автоматы всюду, демонстрирует классическую ситуацию, когда тема диссертации заняла человека всецело.
С подписями, в принципе, всё нормально. Если говорить про документацию по ГОСТ. А вот с отчётами и планами — это труба просто. Разраб, по идее, должен выпустить своё КД и пояснилово к нему. Потом отладить опытный образец. Всё. Когда разраб начинает писать планы, отчёты, он перестаёт делать свою работу. А план с отчётом любой школьник может написать, неправильно бросать на такую плёвую задачу специалиста с хорошей зарплатой.