Документирование кода при оставлении компании [закрытой]
Я бы посчитал это особенностью, так как изменение val на var накладывает более слабые ограничения на использование и не может нарушить код суперкласса . Аналогичная ситуация может наблюдаться с модификаторами видимости:
trait A {
protected fun print() {
...
}
}
class AImpl: A {
public override fun print() {
...
}
}
В этом примере ограничения видимости также смягчаются подклассом, хотя некоторые люди рассматривают эту технику как антипаттерн.
Как защитить значения от изменения наследованием?
В kotlin вы можете явно определить, может ли какой-либо конкретный член класса быть переопределен подклассом с помощью модификатора open. Однако в чертах все члены открыты по умолчанию. Решение состоит в том, чтобы заменить признак классом, чтобы вы могли контролировать наследование:
abstract class A {
fun print() {
...
}
val x : Int = 2;
}
class AImpl(x : Int) : A() {
override var x = x // compilation error
}
8 ответов
При работе с новым кодом, написанным кем-то другим, первое, чего не хватает новому парню (или девушке), - это обзор системы. Какие подсистемы существуют, каковы их цели и где следует искать, чтобы выполнить поставленную задачу, - вот некоторые вопросы, которые приходят на ум.
Краткий начальный документ, объясняющий общий дизайн системы (и причины, по которым этот дизайн был выбран ), возможно, с некоторыми диаграммами, я был бы очень рад получить, работая над программным обеспечением, написанным кем-то другим.
Подумайте о том, чтобы превратить вашу обзорную документацию верхнего уровня в Wiki - это позволит вашим будущим бывшим коллегам легко редактировать и расширять ее.
И обоснование (как уже упоминалось) таково. очень полезно: почему вы выбрали решение A, когда решения B и C выглядят намного лучше для случайного наблюдателя? Он может пресечь всевозможные бесконечные дискуссии в зародыше.
Хотелось бы, чтобы у меня не было здесь ничего полезного, но как получатель переноса кода во время нескольких спадов, перебалансировки навыков и т. Д., Я хотел бы повторить и добавить несколько пунктов к предыдущие ответы.
Я полагаю, ваше руководство назначило одного или нескольких человек, которые возьмут на себя вашу работу.
Вы сказали, что вам это все равно не нужно, но сейчас не время добавлять комментарии к коду.
] Уже отмечалось, что новому владельцу программного обеспечения необходим общий обзор того, что делает программное обеспечение и что для этого необходимо. Сделайте это кратким и постарайтесь не допустить, чтобы он превратился в «как должно выглядеть программное обеспечение», не беспокойтесь о том, чтобы заново спроектировать систему из могилы.
Затем переходите к практическим вопросам: кто является заинтересованными сторонами , тестировщики и все, кто участвовал и может принять участие и знать об этом программном обеспечении.
Где требования, другая документация и PR, есть ли что-нибудь особенно примечательное в PR - предстоящие требования?
Где в системе контроля версий находится программное обеспечение, все ли там есть? В самом деле?
Что необходимо для сборки программного обеспечения?
Наиболее ценное время будет потрачено на проверку последних двух пунктов: воссоздание полной среды сборки из системы контроля версий и сборки (тестирование / доставка) с машины нового владельца . Если есть время, исправьте простую проблему.
Удачи на новой работе!
там все? В самом деле?Что необходимо для сборки программного обеспечения?
Наиболее ценное время будет потрачено на проверку последних двух пунктов: воссоздание полной среды сборки из системы контроля версий и сборки (тестирование / доставка) с машины нового владельца . Если есть время, исправьте простую проблему.
Удачи на новой работе!
там все? В самом деле?Что необходимо для сборки программного обеспечения?
Наиболее ценное время будет потрачено на проверку последних двух пунктов: воссоздание полной среды сборки из системы контроля версий и сборки (тестирование / доставка) с машины нового владельца . Если есть время, исправьте простую проблему.
Удачи на новой работе!
Лично я пишу все свои документы в нисходящем стиле, сначала давая определения всем терминам (для создания общего словарного запаса), а затем объясняя рассматриваемый предмет в общих чертах, уточняя детали ниже документ. Так что такого рода документы, охватывающие все основные части системы, вполне подойдут. Также было бы неплохо, если бы вы в своих проектах приводили обоснование архитектурных решений.
Диаграммы последовательности UML для любых сложных взаимодействий классов / систем, диаграммы классов для любых более сложных объектно-ориентированных проектов и диаграммы системного уровня, которые показывают, как различные системы и приложения взаимодействуют между собой.
Это может быть само собой разумеющимся, но если проекты не компилируются / не запускаются «из коробки» при первом переходе в новую среду разработки (конечно, они должны ), пошаговое руководство о том, как все настроить и запустить, избавит новых людей от головной боли.
Вы можете объяснить дизайн проекта, как работают некоторые важные функции и, возможно, вы сможете задокументировать любые запланированные вами будущие улучшения.
Кто-то уже упоминал, что документирует всю вашу цепочку инструментов, чтобы помочь кому-то настроить среду разработки. Еще одна вещь, которая может быть слишком мета, - это документ , почему вы используете эти инструменты.
Нет ничего хуже, чем начать что-то новое и планировать вырвать все MS Word с корнем, только чтобы найти когда вы увязли в процессе, что немецкое торговое представительство должно создавать отчеты TPS в этом формате и не может использовать wizbang JSON, которым вы хотели его заменить.