Сообщение Re: Чужой код от 10.04.2021 7:44
Изменено 10.04.2021 7:59 gyraboo
Re: Чужой код
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?
Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его адекватно поддерживать). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос).
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?
Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его адекватно поддерживать). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос).
Re: Чужой код
Здравствуйте, merge, Вы писали:
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?
Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его адекватно поддерживать). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д, т.е. там где ограничения по перформансу, по размеру или по другим факторам приводят к тому, что код нужно писать в угоду этим факторам, а не в угоду clean code. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос).
M>Часто слышу на митингах код писал ВАся, в нем ничего не понятно, будет лучше если ВАся сам посмотрит.
M>От 25% программистов такое слышу. Причем ребята неплохие, кто жалуется
M>И может действительно код ВАси плох, но хочется решения проблем а не перекладывания
M>Что посоветуете?
Ну да, промышленный код должен не просто решать задачу, но быть понятным и поддерживаемым. Код нужно писать так, чтобы он соответствовал принципу наименьшего удивления. Другими словами, код должен быть отчуждаемым. Не должен содержать черной магии и тайных знаний (если без тайных знаний не обойтись, то нужно писать пояснения в комментариях, т.е. код должен писаться так, чтобы мидл смог его адекватно поддерживать). Третьими словами, код должен соответствовать практикам типа Clean code Стива Макконнела, Роберта Мартина, принципам рефакторинга Мартина Фаулера — по всем трем есть соотв.книги, где все эти принципы описаны. Вдобавок, нужно соблюдать общеизвестные DRY, KISS, SOLID, использовать паттерны вместо велосипедов. Все эти книги должны быть в наличии у каждого члена команды в быстром доступе, чтобы в процессе работы быстро их открывать, иначе никто читать их не будет, ведь в запарке при работе над текущей задачей у разраба нет ни сил ни желания искать эти книги. Поэтому тут спасет например программа быстрого поиска и открытия и файлов, типа Farr. На корпоративной вики должен быть манифест с явным и четким описанием этих принципов, каждый член команды должен быть согласен с ними (чтобы не пришлось уже в процессе работы постоянно кому-то из них доказывать, чем SOLID, Clean code или паттерны лучше велосипедов). Есть определенная категория программистов, которая либо не признает эти принципы, либо считает что соблюдать их необязательно, приводят свои доводы, они в некоторых случаях могут быть верны — например при разработке жестких highload-систем, или встраиваемых систем, и т.д, т.е. там где ограничения по перформансу, по размеру или по другим факторам приводят к тому, что код нужно писать в угоду этим факторам, а не в угоду clean code. Но даже там можно применять многие практики из Clean code. Если берете такого программиста в команду (ну а понять отношение программиста к этим практикам призвано собеседование), будьте готовы к такого рода рискам и трате времени на постоянные дискуссии по любому комменту в код ревью. Не говорю что это плохо, скорее полезно, но это издержки на ваши силы и на затраченное время. Далее, нужно явно внедрять культуру разработки, т.е. в процессе код ревью постоянно проверять весь код на соответствие этим принципам, заниматься евангелизмом, т.е. проводить обучение и всем повсюду тыкать в лицо этими книгами и принципами, включая менеджеров, показывать и доказывать зачем они нужны, к каким эффектам приводят и как на дистанции упрощают разработку и сопровождение кода. Если не следить на код ревью за их соблюдением, то даже разрабы, которые эти книги читали, скорее всего не будут их соблюдать. Не потому, что они такие плохие, а потому что у разраба свои сроки сдачи задачи и он поглощен решением проблемы, а не соблюдением этих принципов; и первая версия сдаваемого кода по задаче — это часто наслоение в коде результатов инженерного поиска (читай "слеплено из говна и палок"), и чтобы привести решение к промышленному виду, нужно еще потратить доп. усилия, ведь с нуля clean code никто не пишет, код растет "из сора", как и стихи, и задача код ревью и этих практик — убрать весь этот сор. Поэтому для код ревью нужен именно взгляд со стороны, от человека, который эти приницпы и сам применял, умеет видеть в коде их нарушения и предлагать конкретные улучшения, как именно нужно исправить код чтобы он стал соответствовать этим принципам, т.е. любое замечание по коде ревью должно указывать на конкретные нарушения конкретных принципов (замечания типа "тут код плохой. переделай как-нибудь по-другому" не годятся, нужны конкретные замечания типа "функция нарушает стандартные унарные формы, что приводит к плохо понимаемому и плохо поддерживаемому коду, см.книгу мартина clean code стр.XX, исправь — приведи к любой стандартной унарной форме"), и если автор кода не знаком с ними, то также указывать на источник принципа (книга и страница, название принципа) и на то, как именно нужно сделать исправление; по мере накопления опыта разрабы сами начнут эти принципы применять, и в коде ревью будет достаточно просто указывать на факт нарушения принципа, без детальных пояснений.
Подытоживая: тебе нужно либо самому вводить культуру разработки (если ты знаком с этими практиками), либо искать евангелиста их знающего и умеющего, который займется внедрением культуры разработки в команде, а также убедить менеджеров в необходимости этой культуры (а это отдельный вопрос).