В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
Поддержу. ДРАКОН как раз позволяет визуализировать ТЗ и часто определить "Царскую дорогу", одновременно снижая цикломатическую сложность решения разработчика.
Странное и повсеместное утверждение что синтаксис Go подобен С/С++ .. скорее уже Пасклю, Модуле, Джаве. Даже := взято оттуда! Кстати, если он Си-подобен, то где мои любимые union? :) (дженерики не предлагать). Горутины и каналы .. похоже, что Роберт Пайк притащил в язык Хоаровское взаимодействие процессов, забыв что оно впервые реализовано в Ада.. :) Что не нравится в Go:
err != nil -- это да, "вне конкуренции". Кстати, группы разработчиков часто настраивают линтеры так, чтобы не обработанную ошибку нельзя было подавить через _!
запятая в конце строк.. хотели избавиться от ;, зато наплодили запятых. Ни одна закрывающаяся скобка толко на новую строку не переносится.
for _,item := range slice(map|array) {} 80% циклов с таким перебором .. именно так, скрипач не нужен!
[]interface{} -- зубная боль гошника, не смотря на то, что стандартная библиотека этим переполнена по самое не балуйся.
Медленный runtime, использование пакета reflect в недрах стандартной библиотеки, что ещё снижает производительность.
Отсутствие select над слайсом каналов. В Аде такое есть, однако..
Тотальная передача по значению. Дорого и содержит острые подводные камни.
Что нравится в Go:
Простота и лаконичность синтаксиса. Это вам не Ада.. :)
Небольшая стандартная библиотека, закрывающая (пусть и не эффективно) большую часть потребностей. В принципе есть всё, что требуется.
Интерфейсы, отделенные от структур (объектов). Очень интересный и оригинальный подход в обход ООП. Та же "таблица виртуальных методов", но .. отделенная от класса. Очень переспективное направление, кмк.
ИМХО, как мнение к опросу, на который видимо опоздал.. не для споров. :)
В программировании с 1979года. Видел многое, в том числе и всё описанное в статье. Но .. ровно также видел как эти рекомендации исполнялись, мягко скажем через "задний проход".. к примеру:
версионирование. Да, был SVN (гита ещё не было в природе), продакт поднимался из специальной ветки, мастер - то что оттестировано и готово заливаться на прод, стеджинг с песочницей и ветки по трекерам задач .. "всё по уму", кроме мелочи: ветки разработки (8 программистов в команде) часто конфликтовали промеж себя и мердж делал тот, кто лил в стейджинг. Автотестов ещё не было, QA тестировал новый трекер и давал "добро" в мастер .. в итоге старый код, поломаный мерджем легко попадал в прод..
коде ревью. 2 программиста - 4 мнения о коде.. на многих местах коде ревью выливалось или в долгие обсуждения, если не споры или .. "я начальник - ты дурак".. в итого, сроки разработки срывались неоднократно. Польза? она есть конечно, когда ревьюер примерно равен или выше по опыту чем разработчик, но не наоборот..
В этой части интересен опыт разработки "хирургической бригадой". Имел всего дважды, но оба раза воспоминания только положительные.
Мониторинг ошибок, даже больше, ведение журнала ошибок .. видел ровно 1(один) раз, было крайне полезно. Как правило, не доводится до ума и часто (особенно сейчас) вижу ситуацию когда исправление новой ошибки приводит .. к появлению пары новых. Релиз месячной разработки в итого растягивается до полугода..
как-то так, на моей практике. Но, в теории - все исключительно "за". ;)
Поддержу. ДРАКОН как раз позволяет визуализировать ТЗ и часто определить "Царскую дорогу", одновременно снижая цикломатическую сложность решения разработчика.
Вот тоже на этом споткнулся и не понял почему последнее решение стало решением.
Странное и повсеместное утверждение что синтаксис Go подобен С/С++ .. скорее уже Пасклю, Модуле, Джаве. Даже := взято оттуда! Кстати, если он Си-подобен, то где мои любимые union? :) (дженерики не предлагать). Горутины и каналы .. похоже, что Роберт Пайк притащил в язык Хоаровское взаимодействие процессов, забыв что оно впервые реализовано в Ада.. :) Что не нравится в Go:
err != nil -- это да, "вне конкуренции". Кстати, группы разработчиков часто настраивают линтеры так, чтобы не обработанную ошибку нельзя было подавить через _!
запятая в конце строк.. хотели избавиться от ;, зато наплодили запятых. Ни одна закрывающаяся скобка толко на новую строку не переносится.
for _,item := range slice(map|array) {} 80% циклов с таким перебором .. именно так, скрипач не нужен!
[]interface{} -- зубная боль гошника, не смотря на то, что стандартная библиотека этим переполнена по самое не балуйся.
Медленный runtime, использование пакета reflect в недрах стандартной библиотеки, что ещё снижает производительность.
Отсутствие select над слайсом каналов. В Аде такое есть, однако..
Тотальная передача по значению. Дорого и содержит острые подводные камни.
Что нравится в Go:
Простота и лаконичность синтаксиса. Это вам не Ада.. :)
Небольшая стандартная библиотека, закрывающая (пусть и не эффективно) большую часть потребностей. В принципе есть всё, что требуется.
Интерфейсы, отделенные от структур (объектов). Очень интересный и оригинальный подход в обход ООП. Та же "таблица виртуальных методов", но .. отделенная от класса. Очень переспективное направление, кмк.
ИМХО, как мнение к опросу, на который видимо опоздал.. не для споров. :)