Go позволяет одинаково именовать пакет в файлах с кодом модуля и с тестами, тогда у нас есть доступ к внутренней реализации модуля (императив), а не только к API модуля (декларатив). В статье нас призывают к TDD, при этом не спускаясь на императивный уровень, а формулируя тесты перед кодингом только на декларативном уровне. Но при рефакторинге я предпочёл бы иметь покрытие на императивном уровне. В наше время этого легко добиться с помощью ChatGPT. Тогда такие императивные модульные тесты не жалко выбрасывать вместе с модифицируемым кодом, если потребуется. Хорошо. А как бы улучшить Developer Experience для декларативных модульных тестов? Сплю и вижу процесс разработки по схеме: Event Modeling > BDD > Integration/Unit Tests (via gherkingen) > code for development via tests for external API of modules - package module_test / whitebox for refactoring > Unit Tests Coverage for internal functions in modules package module / blackbox for modifications (via ChatGPT).
Prompt Engineering - отдельный скилл. Я с ними (ChatGPT / Codeium) постоянно разговариваю, и часто с кривой ухмылкой. Но правильно заданный вопрос - половина решения. Конкретно тут, если вводные строго определены (сигнатура функции и код без сайд-эффектов), то результат вполне годный.
Так я хочу и на ёлку влезть и попу не ободрать. Пусть тесты пишут генераторы и роботы, они железные. А я весь в белом сочиняю BDD, которые не только для тестов полезны, но и как документация в актуальном состоянии, и как декомпозированные таски etc.
Пока не выбрал что мне больше нравится, тим или тех лид, но позже обязательно выберу.
В юности на заводе наблюдал ролевую модель. Прораб - прокладка между бригадиром и начальником цеха. Пролетарии его не слушают, а руководитель требует.
Тимлид - медиатор между бизнесом и погромистами. Часто с низкой технической квалификацией, но с гордым званием "глава разработки". Я пришёл к тому, что нужно объединить в себе обе роли. Тим + Тех = Лид. Хочешь сделать хорошо? Сделай это сам.
package main
import (
"fmt"
"sync"
)
type Counter struct {
data chan int
total chan int
}
func NewCounter() *Counter {
data := make(chan int)
total := make(chan int)
c := Counter{data, total}
go func() {
var count int
for {
select {
case increment := <-data:
count += increment
case total <- count:
}
}
}()
return &c
}
func (c *Counter) Add(v int) {
c.data <- v
}
func (c *Counter) Total() int {
return <-c.total
}
func main() {
counter := NewCounter()
var wg sync.WaitGroup
wg.Add(1000000)
for i := 0; i < 1000000; i++ {
go func() {
counter.Add(1)
wg.Done()
}()
}
wg.Wait()
fmt.Println(counter.Total())
}
package main
import "sync"
type Counter struct {
data chan int
total int
}
func NewCounter() *Counter {
data := make(chan int)
c := Counter{data, 0}
go func() {
for {
increment := <-data
c.total += increment
}
}()
return &c
}
func (c Counter) Add() {
c.data <- 1
}
func main() {
counter := NewCounter()
var wg sync.WaitGroup
wg.Add(1000000)
for i := 0; i < 1000000; i++ {
go func() {
counter.Add()
wg.Done()
}()
}
wg.Wait()
println(counter.total)
}
Говорить что в Go нет lock-free структур данных и топить за mutex это значит полностью не понимать CSP и идиомы Go связанные с многопотоком. Ещё раз: гуглим go proverbs, читаем первую. Там будет "Don't communicate by sharing memory, share memory by communicating".
Задача: Реализовать структуру-счетчик, которая будет инкрементироваться в конкурентной среде. По завершению программа должна выводить итоговое значение счетчика.
Условие: Решение без применения примитивов из пакета sync, исключительно используя канал для обеспечения потокобезопасной передачи/приёма данных.
Пытаюсь научиться лучшим практикам - никак. Помогите!
а где GoLang?
It is based on the following algorithm by Rob Pike
Конфигурация "Две партиции - четыре обработчика"
Не разбирался, что это было. Переставил кафку, теперь не воспроизводится.
Перевёл: Шпаргалка по событийному моделированию
Go позволяет одинаково именовать пакет в файлах с кодом модуля и с тестами, тогда у нас есть доступ к внутренней реализации модуля (императив), а не только к API модуля (декларатив). В статье нас призывают к TDD, при этом не спускаясь на императивный уровень, а формулируя тесты перед кодингом только на декларативном уровне. Но при рефакторинге я предпочёл бы иметь покрытие на императивном уровне. В наше время этого легко добиться с помощью ChatGPT. Тогда такие императивные модульные тесты не жалко выбрасывать вместе с модифицируемым кодом, если потребуется. Хорошо. А как бы улучшить Developer Experience для декларативных модульных тестов? Сплю и вижу процесс разработки по схеме: Event Modeling > BDD > Integration/Unit Tests (via gherkingen) > code for development via tests for external API of modules - package module_test / whitebox for refactoring > Unit Tests Coverage for internal functions in modules package module / blackbox for modifications (via ChatGPT).
Первая звёздочка на GitHub - моя!
Почему?
Буду сам пользоваться этим наглядным примером и всем советовать. Жирный плюс в карму!
Prompt Engineering - отдельный скилл. Я с ними (ChatGPT / Codeium) постоянно разговариваю, и часто с кривой ухмылкой. Но правильно заданный вопрос - половина решения. Конкретно тут, если вводные строго определены (сигнатура функции и код без сайд-эффектов), то результат вполне годный.
Так я хочу и на ёлку влезть и попу не ободрать. Пусть тесты пишут генераторы и роботы, они железные. А я весь в белом сочиняю BDD, которые не только для тестов полезны, но и как документация в актуальном состоянии, и как декомпозированные таски etc.
Спасибо! Пойду по пути велосипеда. Убер превращает Go в PHP.
Ещё могу добавить кейс, поделился коллега. Есть школы, которые натаскивают джунов проходить сеньорские собесы за часть ЗП.
В юности на заводе наблюдал ролевую модель. Прораб - прокладка между бригадиром и начальником цеха. Пролетарии его не слушают, а руководитель требует.
Тимлид - медиатор между бизнесом и погромистами. Часто с низкой технической квалификацией, но с гордым званием "глава разработки". Я пришёл к тому, что нужно объединить в себе обе роли. Тим + Тех = Лид. Хочешь сделать хорошо? Сделай это сам.
Зацените, как надо устраиваться на работу. Хакеры, чо. ?
Спасибо! Исправил:
Внутри канала тоже mutex, кстати.
Задача: Реализовать структуру-счетчик, которая будет инкрементироваться в конкурентной среде. По завершению программа должна выводить итоговое значение счетчика.
Условие: Решение без применения примитивов из пакета sync, исключительно используя канал для обеспечения потокобезопасной передачи/приёма данных.
Пытаюсь научиться лучшим практикам - никак. Помогите!
А где бы взять инструкцию, как правильно заполнять Green Card?
Поправил на "аджайлистов". Мне очень нравится идея притянуть это всё к BDD. https://eventmodeling.org/posts/what-is-event-modeling/ (на Хабре уже есть перевод, но настолько корявый даже по сравнению с моими, что лучше смотреть в оригинале).
Пожалуйста! Вдогонку https://eventmodeling.org/posts/human-natural-thinking/