Понятно, давайте отправим разработчиков на тренинги, наймем консультантов, чтобы проконсультировали какие тренинги правильные, какие нет. Если проконсультируют плохо, отправим на тренинги консультантов или наймем суперконсультантов для обучения консультантов…
У меня нет ощущения, что верные технологии это панацея. Верные технологии в руках неправильных людей будут нести все тот же отпечаток страха, формализма и(или) раздолбайства. Тесты будут писаться на «отвали» и т.д. Про «скрам и стендапы» вообще молчу, подход, который хорош для бойскаутских лагерей, применять в программировании — решение очень незрелых людей или ДЛЯ очень незрелых людей. К сожалению когда болезнь становится массовой, ее начинают считать за норму, лично я никогда в жизни больше не буду работать в компании, где используется скрам и стендапы, при этом у меня нет ни малейшего страха кода, я всегда анализирую существующий код и делаю его рефакторинг, если он не оптимален независимо от наличия-отсутствия тестов. У меня есть глаза, я вижу что делает код, я вижу какие участки он затрагивает и т.д.
Как и многие петли с подкреплением, цикл страха невероятно трудно разорвать. До сих пор я не наблюдал ни одного случая успешного выхода из него. Если он начался в вашей компании, то очень хотелось бы услышать о вашем опыте!
может быть только один — менять руководителя разработки, так как это проблема не логическая а психо-логическая
Всегда недоумевал над фразами «работает — не трожь» и «лучшее — враг хорошего». Разработчик должен знать весь код и как он работает, критически его анализировать и улучшать. Не должно быть белых пятен. Это не вопрос команды в целом, это вопрос психологии руководителя или главного разработчика. Если они боятся, то могут заразить страхом других. Всегда нужно вносить правки:
а) Максимально хорошо и продуманно с точки зрения работы всей системы
б) Предварительно как следует с работой этой самой системы ознакомившись
Также всегда нужно вести максимально подробную документацию безо всяких ссылок на то что бизнесу надо побыстрей и т.п. Если вы не знаете досконально как работает ваша система, проблема может вскрыться в любой момент.
В плане ответственности чиновников за свои действия вобщем-то давным давно все ясно, но в плане конкретного диалога обе стороны — детский сад. Писать человеку, которого не уважаешь: Да в чем тебе завидовать, трусливое чудило, ты понимаешь в космонавтике меньше чем я в балете значит просто опускаться до уровня низкоинтеллектуальных разборок.
Да и вообще странно с какой стати локальный срач на фб становится предметом статьи на хабре.
Беда в том, что большинство документаций и гайдов, которые я нашел, подразумевают, что читающий их человек довольно хорошо разбирается в предметной области и все понимает, в моем случае это было не так и на свою первую настройку xDebug я в сумме потратил 4-5 часов за 2 вечера.
Для Хрома есть расширение xDebug helper… С ним даже самый тупой потратит не больше 30 минут.
О да, на предыдущем месте работы начальник был именно таким. Добавление дополнительного условия в функцию требовало создания отдельного «сервиса» с функцией с тем же именем, из которой вызывалась бы функция изначального класса, на результат накладывалось бы условие, а в код, откуда вызывается функция, один из этих классов — с условием или без — передавался бы через депенденси инджекшн. Это все безмерно меня удивляло на фоне того, что механизмы, которые реально требовали оптимизации, не оптимизировались под предлогом того, что у нас нет на это времени и ресурсов. Понятно, что после испытательного срока я оттуда ушел, поскольку никакого понимания не было.
Главное, что мне удалось уяснить из статьи, что Вишну спит, ему снится Брахма, а Брахме снится все остальное — этот тезис единственный, способный логично пояснить все прочее содержание вышеизложенного.
Продумать и написать один раз максимально расширяемый код, а не исправлять каждый раз имеющийся после каждого небольшого изменения бизнес-логики и является в моем понимании максимально расширяемым кодом, написанным по минимуму, так как в долгосрочной перспективе хорошо расширяемый код освобождает от необходимости его переписывать.
Вы никогда не замечали, что программистов, любящих писать код, интересует не результат работы, а процесс, о чем и описано в статье. Человек, который наедается программированием(ну или может более правильное слово «кодированием»), обращает больше внимания на архитектуру и целостность решения. Из лени писать код он делает минимум, или оптимальный минимум. Конечно, для этого интерес к программированию и увлеченность должна была присутствовать хотя бы в прошлом, чтобы не копипастить куски кода. То есть обретение лени пот отношению к кодированию не значит появление безответственности по отношению к результату, возможно иногда наоборот. Мне вспоминается случай одного моего знакомого, который любил писать всякие умопомрачительные вещи, чтобы все восторгались. И он сказал простую фразу: «Если какая-то задача меня по настоящему увлекла, мне пофиг что говорит работодатель», Также вспоминаю еще двух знакомых, программистов топ класса в своей области, которые на форумах демонстрировали просто феноменальный интеллект в подходах к решению задач, но при этом периодически проваливали реальные проекты просто потому, что им было скучно.
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.
Если написанное мной «ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.» для вас вытекает в
видел я таких… он просто копипастит его в четвертый раз и бежит пить пивко.
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.
Программист становится хорошим, когда он наелся программированием, и оно перестает его интересовать как таковое. В этом случае он начинает искать простейшие и эффективнейшие пути для решения задачи — ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.
В первую очередь спасибо за статью, думаю все же она вполне может быть полезна и труд не напрасен. Но насчет вашей фразы
Но для кругозора или устройства в крупные компании, просто кодинга мало, там спросят как работают хеши или что вы знаете про деревья.
мне не очень понятно, что за фетиш такой — «крупные компании». Если речь идет о гугл или яндекс, думаю там даже знания о том как работают хэши и что я знаю про деревья будет очень мало. И совершенно не вижу никакой необходимости работать в т.н. «крупных компаниях». Думаю понимание хэширования и умение им в нужный момент пользоваться пригодится даже в самой самой мелкой компании.
Всегда нужно смотреть, какая получается выгода. Если элемент ищется один раз даже в очень большом массиве после клика пользователя, то пользователю абсолютно все равно, отработает код за 1 миллисекунду или за 100 миллисекунд, и в этих случаях лучше писать как удобно.
Когда же скорость по настоящему критична, например когда поиск происходит часто и много раз, то имеет смысл просто сразу индексировать массив и находить значения моментально. В случае когда необходимо булево значение вообще использовать Object или Set.
Случаев, когда замена indexOf на includes или filter + map на reduce принесет ощутимую пользовательскому глазу выгоду не так много, к тому же методы разработчиками браузеров постоянно допиливаются и показатели меняются. Можно вдруг обнаружить, что filter + map в ряде случаев быстрее, чем reduce, а простой перебор цикла еще быстрее. Посему для кода использовать что более удобно — например includes использовать просто логичней и красивей, когда нужно булево значение, чем indexOf !== false, а для быстрого поиска использовать индексацию.
Я внедрял 1С много лет в том числе и систему бюджетирования, которая в изначальном сыром виде возможно и не является 100% юзер френдли, но представляет собой вполне сносный каркас, который при небольшом допиливании под конкретную ситуацию становится в т.ч. и юзер френдли. Чтобы заполнить данные по продажам на основе показателей предыдущих периодов, достаточно указать в настройках либо регистр продаж, либо счета бухгалтерского учета, на которых данные по продажам аккумулируются и нажать кнопку Заполнить. Половина из того, что написали вы мне не очень понятна. Я не понимаю зачем отслеживать версионность объектов для бюджетирования. На мой взгляд эта фраза лишена всякого смысла.
Большое спасибо за книгу, но есть вопрос-замечание:
В книге написано: Никогда ни в коем случае не изменяйте предыдущее состояние. Но не написано почему, хочется понять механизм как это работает.
Потому что например у меня есть проект на чистом реакте, и я хочу перевести его на редакс:
В состоянии есть свойство data, содержащее обычные табличные строки с данными, то есть массив объектов, и есть свойство dataStructure, где эти данные представлены иерархически с группировками, нужной сортировкой и рассчитанными итогами по колонкам…
И вот в моем проекте есть функция changeDataValue(row, column, newValue), куда передается строка, что уже неудобно, потому что сделав копию мне придется найти эту строку в копии
Хорошо, я проиндексирую строки и пишу
const {data} = [...this.state] //скопировали
row = data[row.index] //Нашли нужную строку в копии
row[column.path] = newValue //Установили значение
но теперь мне нужно пересчитать итоги по группировке, группировка находится в row.parent и ссылается это свойство на строку из dataStructure, то есть после
row.parent[column.path] += newValue - oldValue
получается измененным свойство dataStructure, И здесь возникает вопрос на что это может повлиять. Копировать dataStructure с его двусторонними связями children и parent как-то не очень хочется. Это может быть и долго на тысячах строк данных и муторно алгоритмически и не очень понятно зачем.
PS И замените пожалуйста «так же» на «также», потому что в том контексте, в котором это используется в книге, нужно писать слитно. «Также» — тоже, кроме того, «Так же» — таким же образом. Когда вы пишете «Мы изменили page.js, так же изменим App.js» это означает, что в App.js нужно внести изменения аналогичные изменениям page.js, что противоречит контексту. Я не грамма-наци, когда это встречается в статьях — легко пропускаешь мимо глаз, но в книге это бросается в глаза.
Если разработано для России, было бы интересно для всех функций и конструкций иметь русские аналоги, как это организовано в 1С — ЕСЛИ ИНАЧЕ и т.п.
У меня нет ощущения, что верные технологии это панацея. Верные технологии в руках неправильных людей будут нести все тот же отпечаток страха, формализма и(или) раздолбайства. Тесты будут писаться на «отвали» и т.д. Про «скрам и стендапы» вообще молчу, подход, который хорош для бойскаутских лагерей, применять в программировании — решение очень незрелых людей или ДЛЯ очень незрелых людей. К сожалению когда болезнь становится массовой, ее начинают считать за норму, лично я никогда в жизни больше не буду работать в компании, где используется скрам и стендапы, при этом у меня нет ни малейшего страха кода, я всегда анализирую существующий код и делаю его рефакторинг, если он не оптимален независимо от наличия-отсутствия тестов. У меня есть глаза, я вижу что делает код, я вижу какие участки он затрагивает и т.д.
может быть только один — менять руководителя разработки, так как это проблема не логическая а психо-логическая
а) Максимально хорошо и продуманно с точки зрения работы всей системы
б) Предварительно как следует с работой этой самой системы ознакомившись
Также всегда нужно вести максимально подробную документацию безо всяких ссылок на то что бизнесу надо побыстрей и т.п. Если вы не знаете досконально как работает ваша система, проблема может вскрыться в любой момент.
Да и вообще странно с какой стати локальный срач на фб становится предметом статьи на хабре.
Для Хрома есть расширение xDebug helper… С ним даже самый тупой потратит не больше 30 минут.
habr.com/post/422679/#comment_19091403
или написание функционала, который уже есть в существующих библиотеках, а возможно даже в проекте.
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.
мне не очень понятно, что за фетиш такой — «крупные компании». Если речь идет о гугл или яндекс, думаю там даже знания о том как работают хэши и что я знаю про деревья будет очень мало. И совершенно не вижу никакой необходимости работать в т.н. «крупных компаниях». Думаю понимание хэширования и умение им в нужный момент пользоваться пригодится даже в самой самой мелкой компании.
Когда же скорость по настоящему критична, например когда поиск происходит часто и много раз, то имеет смысл просто сразу индексировать массив и находить значения моментально. В случае когда необходимо булево значение вообще использовать Object или Set.
Случаев, когда замена indexOf на includes или filter + map на reduce принесет ощутимую пользовательскому глазу выгоду не так много, к тому же методы разработчиками браузеров постоянно допиливаются и показатели меняются. Можно вдруг обнаружить, что filter + map в ряде случаев быстрее, чем reduce, а простой перебор цикла еще быстрее. Посему для кода использовать что более удобно — например includes использовать просто логичней и красивей, когда нужно булево значение, чем indexOf !== false, а для быстрого поиска использовать индексацию.
В книге написано: Никогда ни в коем случае не изменяйте предыдущее состояние. Но не написано почему, хочется понять механизм как это работает.
Потому что например у меня есть проект на чистом реакте, и я хочу перевести его на редакс:
В состоянии есть свойство data, содержащее обычные табличные строки с данными, то есть массив объектов, и есть свойство dataStructure, где эти данные представлены иерархически с группировками, нужной сортировкой и рассчитанными итогами по колонкам…
И вот в моем проекте есть функция changeDataValue(row, column, newValue), куда передается строка, что уже неудобно, потому что сделав копию мне придется найти эту строку в копии
Хорошо, я проиндексирую строки и пишу
но теперь мне нужно пересчитать итоги по группировке, группировка находится в row.parent и ссылается это свойство на строку из dataStructure, то есть после
получается измененным свойство dataStructure, И здесь возникает вопрос на что это может повлиять. Копировать dataStructure с его двусторонними связями children и parent как-то не очень хочется. Это может быть и долго на тысячах строк данных и муторно алгоритмически и не очень понятно зачем.
PS И замените пожалуйста «так же» на «также», потому что в том контексте, в котором это используется в книге, нужно писать слитно. «Также» — тоже, кроме того, «Так же» — таким же образом. Когда вы пишете «Мы изменили page.js, так же изменим App.js» это означает, что в App.js нужно внести изменения аналогичные изменениям page.js, что противоречит контексту. Я не грамма-наци, когда это встречается в статьях — легко пропускаешь мимо глаз, но в книге это бросается в глаза.